feat: refresh shared skills catalog

skills/emergency-procedures/SKILL.md

@@ -1,83 +1,27 @@
 ---
 name: emergency-procedures
 description: >
-  Recovery protocols when development loops fail, agent context is corrupted, git state is tangled,
-  or quality gates break. Use when development becomes chaotic, thrashing loops occur, or when asked to recover state.
-concerns: [system-one-balance]
+  Recover from repeated failed fixes, tangled git state, or lost task context when ordinary debugging cannot make progress or recovery is requested.
+scope: global
 ---
 
-# Emergency Recovery Procedures
+# Recovery
 
-Standardized protocols for halting cascading failures, stabilizing git state, restoring agent context, and recovering working development branches.
+1. Stop speculative edits. Inspect status, diffs, branch, HEAD, and the current
+   failure. Re-read the active objective and relevant repository conventions.
+2. Preserve work before changing branches or discarding anything. A branch at HEAD
+   preserves commits only. Save tracked staged/unstaged diffs and copy relevant
+   untracked files into an identified recovery location; or use a repository-approved
+   snapshot method that captures those files. Verify the snapshot can recover them.
+   Account for ignored files when relevant; do not accidentally collect credentials.
+3. Identify a known-good checkpoint from tests or history. Prefer a separate
+   worktree for investigation so the user's current checkout remains intact.
+   Returning to the previous branch is not evidence that it is healthy.
+4. Recover or fix the smallest demonstrated cause. Split work by meaningful
+   behavior, without line-count limits or a new approval gate for the same task.
+5. Verify the relevant recovery outcome and report the preserved state and next step.
 
----
-
-## Phase 0: Setup and Protocols
-
-1. **Circuit-Breaker Invariants**:
-   - **Halt Implementation**: When an agent gets stuck in a thrashing loop, stop writing additional code immediately.
-   - **Zero Destructive Discards**: Never run destructive commands (`git reset --hard`, `git clean -fdx`) without creating a safe backup branch or stash first.
-   - **Isolate the Failure**: Determine whether the defect is environment, git state, code regression, or context divergence.
-
----
-
-## Phase 1: Ingest and Check
-
-1. Detect emergency signals:
-   - **Context Loss**: Agent suggests solutions contradicting established repo patterns or attempts wide, unsolicited rewrites.
-   - **Git Confusion**: Unmerged conflicts, detached HEAD state, or untracked changes scattered across directories.
-   - **Test Thrashing**: Attempted fixes repeatedly break tests in alternating cycles.
-2. Freeze and document:
-   - Record the current git commit SHA, active branch, and modified file list (`git status`).
-
----
-
-## Phase 2: Processing (Core Logic)
-
-### Step 1: Secure Working State
-Before making any changes, preserve the current uncommitted state:
-```bash
-# Create a safety branch with current WIP
-git checkout -b emergency-backup-$(date +%Y%m%d%H%M%S)
-git add -A
-git commit -m "emergency: snapshot before recovery"
-```
-
-### Step 2: Roll Back to Last Known Good State
-Return to the main branch or stable checkpoint:
-```bash
-git checkout -
-git status
-```
-
-### Step 3: Re-anchor Context
-1. Inspect the last stable commit and review actual working patterns in the codebase.
-2. Read project README, architecture docs, or `SPEC.md` to re-align goals.
-3. Formulate the single smallest task that can be verified in isolation.
-
-### Step 4: Decompose Complex Tasks
-If a task ballooned in complexity:
-1. Break down the task into steps of ≤ 50 lines of change each.
-2. Sequence steps so each can be independently tested and committed.
-3. Obtain user confirmation on the refined task plan before re-attempting.
-
----
-
-## Phase 3: The System One Balance Pass
-
-- **Augment, Don't Handcuff**:
-  - Do NOT panic or spam long conversational apologies. State the issue concisely, show the preserved backup branch, and propose the recovery plan.
-  - Safe inspection (`git status`, `git diff`, `git log`) must be executed immediately without confirmation gates.
-  - Reserve confirmation prompts strictly for discarding branches or rolling back production databases.
-
----
-
-## Phase 4: Output Execution & Verification
-
-1. Verify:
-   - Workspace working tree is clean or returned to a stable, reproducible state.
-   - Test suite passes on the recovered base.
-2. Deliver the incident summary:
-   - Root cause of the disruption.
-   - State of the backup branch.
-   - Concrete, small next step to resume forward progress safely.
+Never bulk-stage user work, clean untracked files, or reset the checkout just to
+make status clean. Existing authorization governs recovery; ask only if the next
+step would discard work or change scope without authorization. Follow
+[shared workflow](../../protocols/workflow.md).