Claude-skill-registry d-plan-fix
Create execution plan to fix root cause. Creates ./.gtd/debug/current/FIX_PLAN.md
git clone https://github.com/majiayu000/claude-skill-registry
T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/d-plan-fix" ~/.claude/skills/majiayu000-claude-skill-registry-d-plan-fix && rm -rf "$T"
skills/data/d-plan-fix/SKILL.mdCore responsibilities:
- Read root cause analysis
- Propose fix approach
- Decompose into atomic tasks
- Define verification criteria </role>
Flow: Load Root Cause → Plan → Verify → Write </objective>
<context> **Flags:**
— Regenerate plan even if FIX_PLAN.md exists--force
Required files:
— Must exist./.gtd/debug/current/ROOT_CAUSE.md
Output:
</context>./.gtd/debug/current/FIX_PLAN.md
<standards_and_constraints>
<philosophy>Fix the Cause, Not the Symptom
The plan must address the root cause identified, not just mask the symptom.
Aggressive Atomicity
Each plan: 2-3 tasks max. No exceptions.
Side Effect Awareness
| Type | Check | Action |
|---|---|---|
| Breaking Change | API/interface changes? | Document in plan |
| Regression | What else uses this code path? | Add regression test task |
| Performance | Hot path affected? | Add verification criterion |
| Data | State/schema changes? | Add migration task |
<design_principles>
Core Principles
Mantra: "Optimize for Evolution, not just Implementation."
- Gall's Law: Reject complexity. Start with the smallest working modular monolith.
- Single Source of Truth: Data must be normalized. If state exists in two places, you have designed a bug.
- Complete Path Principle: Information never teleports. Every producer needs a consumer. Every event needs a handler.
- Testability First: Design "Seams" for every external dependency (Time, Network, Randomness).
- Centralized Resilience: Retry logic/circuit breakers must be at the edge, not scattered.
Blueprint Checklist
- Data Model: Defined schemas (SQL/JSON) with exact types.
- Constraints: What must ALWAYS be true? (e.g., "Balance >= 0").
- Failure Modes: Handling partial failures and data corruption.
- Error Taxonomy: Define Retryable vs Fatal errors. </design_principles>
<task_types> Automation-first rule: If agent CAN do it, agent MUST do it. Checkpoints are for verification AFTER automation.
| Type | Use For | Autonomy |
|---|---|---|
| Everything agent can do independently | Fully autonomous |
| Visual/functional verification | Pauses for user |
| Implementation choices | Pauses for user |
</task_types>
</standards_and_constraints>
<process>1. Validate Environment
Bash:
if ! test -f "./.gtd/debug/current/ROOT_CAUSE.md"; then echo "Error: No root cause found. Run /d-verify first." exit 1 fi
2. Check Existing Plan
Bash:
test -f "./.gtd/debug/current/FIX_PLAN.md"
If exists AND
NOT set:--force
- Display: "Using existing plan. Use --force to regenerate."
- Skip to Offer Next
3. Load Root Cause
Read
./.gtd/debug/current/ROOT_CAUSE.md.
Extract:
- Root cause description
- Affected files
- Expected vs actual behavior
4. Plan Fix
Display:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ GTD:DEBUG ► PLANNING FIX ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
4a. Gather Context
Load ROOT_CAUSE.md and affected source files. Use root cause findings to inform design constraints defined in
<design_principles>.
4b. Decompose into Tasks
- Identify all changes needed.
- Break into atomic tasks (2-3 max) using
.<task_types> - Define done criteria for each.
4c. Write FIX_PLAN.md
Write to
./.gtd/debug/current/FIX_PLAN.md using this template:
--- created: { date } root_cause: { brief one-liner } --- # Fix Plan ## Objective {What this fix delivers and why} ## Context - ./.gtd/debug/current/ROOT_CAUSE.md - {affected source files} ## Architecture Constraints - **Single Source:** {Where is the authoritative data?} - **Invariants:** {What must ALWAYS be true?} - **Resilience:** {How do we handle failures?} - **Testability:** {What needs to be injected/mocked?} ## Tasks <task id="1" type="auto"> <name>{Task name}</name> <files>{exact file paths}</files> <action> {Specific implementation instructions} - What to do - What to avoid and WHY </action> <done>{How we know this task is complete}</done> </task> <task id="2" type="auto"> ... </task> ## Success Criteria - [ ] Original symptom no longer occurs - [ ] {Additional measurable outcome} - [ ] No regressions (existing tests pass) ## Rollback Plan {How to undo changes if something goes wrong}
5. Verify Plan
Check:
- Tasks are specific (no "fix the bug")
- Done criteria are measurable
- 2-3 tasks max
- All files specified
- Side effects addressed
- Adherence to
<prohibitions>
If issues found: Fix before writing.
</process><offer_next>
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ GTD:DEBUG ► FIX PLANNED ✓ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Fix plan written to ./.gtd/debug/current/FIX_PLAN.md {X} tasks defined | Task | Name | |------|------| | 1 | {name} | | 2 | {name} | ───────────────────────────────────────────────────── ▶ Next Up /d-execute — execute the fix plan ─────────────────────────────────────────────────────
</offer_next>
<forced_stop> STOP. The workflow is complete. Do NOT automatically run the next command. Wait for the user. </forced_stop>