.claude/skills/d-plan-fix/SKILL.md
Create execution plan to fix root cause. Creates ./.gtd/debug/current/FIX_PLAN.md
npx skillsauth add Hoang604/get-thing-done d-plan-fixInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Core responsibilities:
Flow: Load Root Cause → Plan → Verify → Write </objective>
<context> **Flags:**--force — Regenerate plan even if FIX_PLAN.md existsRequired files:
./.gtd/debug/current/ROOT_CAUSE.md — Must existOutput:
./.gtd/debug/current/FIX_PLAN.md
</context><standards_and_constraints>
<philosophy>The plan must address the root cause identified, not just mask the symptom.
Each plan: 2-3 tasks max. No exceptions.
| 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 |
</philosophy><design_principles>
Mantra: "Optimize for Evolution, not just Implementation."
<task_types> Automation-first rule: If agent CAN do it, agent MUST do it. Checkpoints are for verification AFTER automation.
| Type | Use For | Autonomy |
| ------------------------- | ------------------------------------- | ---------------- |
| auto | Everything agent can do independently | Fully autonomous |
| checkpoint:human-verify | Visual/functional verification | Pauses for user |
| checkpoint:decision | Implementation choices | Pauses for user |
</task_types>
</standards_and_constraints>
<process>Bash:
if ! test -f "./.gtd/debug/current/ROOT_CAUSE.md"; then
echo "Error: No root cause found. Run /d-verify first."
exit 1
fi
Bash:
test -f "./.gtd/debug/current/FIX_PLAN.md"
If exists AND --force NOT set:
Read ./.gtd/debug/current/ROOT_CAUSE.md.
Extract:
Display:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
GTD:DEBUG ► PLANNING FIX
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Load ROOT_CAUSE.md and affected source files. Use root cause findings to inform design constraints defined in <design_principles>.
<task_types>.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}
Check:
<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>
testing
manual trigger by user, do not auto invoke
tools
manual trigger by user, do not auto invoke
development
Trace execution paths and document how code actually behaves. Use when you need to understand how features work, walk through code flows, explain component behavior, trace where data comes from, understand relationships between components, or audit for orphaned events and dead code.
testing
Guide users through a structured workflow for co-authoring documentation. Use when user wants to write documentation, proposals, technical specs, decision docs, or similar structured content. This workflow helps users efficiently transfer context, refine content through iteration, and verify the doc works for readers. Trigger when user mentions writing docs, creating proposals, drafting specs, or similar documentation tasks.