feat(SKILL.md): add plan-audit skill for comprehensive plan review and criteria assessment

skills/format-report-fix/SKILL.md

@@ -1,39 +0,0 @@
----
-name: format-report-fix
-description: Output format for reporting fixes.
----
-
-## Report Fix — Output Format
-
-# Context
-When explaining fixes to the user, use a standardized format with concrete examples and causality.
-
-# Format (one fix per block)
-`### <number> Fix — <short title>`
-`**#<id>** — <brief description>`
-- **Before**: what caused the problem (behavior + cause)
-- **Example**: real scenario showing the impact (numeric/concrete)
-- **Fix**: provide the concrete code/text change, ready to copy-paste, in this format:
-```markdown
-- **Fix**: 
-    - **File**: `path/to/file.ext`
-    - **Change**: 
-        ```diff
-        - old code/text
-        + new code/text
-        ```
-```
-
-# Example
-```
-### 9 Fix — Explanation with examples
-**#14** — Arrow onRetry recreated every render
-Before: onRetry={(id) => {...}} inline in .map → new function on every render → MessageBubble (memo) re-renders even when nothing changed.
-Example: 50 messages, you type a letter → 50 MessageBubbles re-render needlessly.
-Fix: handleRetryDispatch with useCallback — stable across renders. Only the bubble with changed data updates.
-```
-
-# Rules
-- Never just "fixed X" — show before, real impact example, and after.
-- The example must be numeric/concrete (e.g., "50 messages, you type a letter").
-- Concise: one fix per block, no defensive prose.

skills/plan-audit/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: plan-audit
+description: Runs after a plan exists and before any edit. Forces the model to decompose every aspect of the plan and pass each one through fixed criteria, then return a verdict. Use when reviewing a plan for a change before implementing it.
+---
+
+# Plan Audit
+
+## What it's for
+Sits between planning and editing. Decompose the plan into every aspect and stress each one under fixed criteria. Surface problems before touching the code.
+
+## Method
+1. Decompose the plan into aspects. One aspect = one atomic change touching a single point.
+2. Pass each aspect, in order, through criteria 1 to 11.
+3. One failed criterion on one aspect = the plan is not perfect.
+4. Empty plan, or no plan at all, is not a pass.
+
+## Criteria
+1. Cause vs symptom — fixing the root cause or only the visible symptom?
+2. Completeness — does every aspect have a cause and an action?
+3. Internal coherence — do two aspects contradict each other?
+4. Dependencies — is the order correct? Anything depending on work not yet done?
+5. Edge cases — empty, null, double, extreme, concurrent inputs covered?
+6. Side effects — what breaks elsewhere when this aspect is touched?
+7. Ambiguity / assumptions — unstated assumptions that can collapse?
+8. Verifiability — does every change have an observable test (input → expected output)?
+9. Scope / YAGNI — more than needed? Touches unrelated things?
+10. Reversibility — if it fails, can it be rolled back without damage?
+11. Simplicity & readability — is the resulting code simple and readable?
+
+## Output
+No operational output. Only the verdict:
+- `PLAN PERFECT` — every aspect passes every criterion.
+- `NEEDS CHANGES` — one line per failed aspect: `- #<criterion> <name> — <reason>`.
+
+## Rules
+- Never say "looks fine" without running the full decomposition.
+- One aspect at a time. No skipping.
+- The verdict is the answer. No prose around it.