d-plan-fix
About
The d-plan-fix skill creates executable fix plans from verified root cause analyses, generating a structured FIX_PLAN.md with atomic tasks and verification criteria. It reads ROOT_CAUSE.md and is designed to feed directly into the d-execute workflow for implementation. Use this skill after root cause verification to systematically plan corrective actions.
Quick Install
Claude Code
Recommended/plugin add https://github.com/majiayu000/claude-skill-registrygit clone https://github.com/majiayu000/claude-skill-registry.git ~/.claude/skills/d-plan-fixCopy and paste this command in Claude Code to install this skill
Documentation
Core 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:**--force— Regenerate plan even if FIX_PLAN.md exists
Required files:
./.gtd/debug/current/ROOT_CAUSE.md— Must exist
Output:
./.gtd/debug/current/FIX_PLAN.md</context>
<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 |
|---|---|---|
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>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 --force NOT set:
- 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>
GitHub Repository
Related Skills
algorithmic-art
MetaThis Claude Skill creates original algorithmic art using p5.js with seeded randomness and interactive parameters. It generates .md files for algorithmic philosophies, plus .html and .js files for interactive generative art implementations. Use it when developers need to create flow fields, particle systems, or other computational art while avoiding copyright issues.
subagent-driven-development
DevelopmentThis skill executes implementation plans by dispatching a fresh subagent for each independent task, with code review between tasks. It enables fast iteration while maintaining quality gates through this review process. Use it when working on mostly independent tasks within the same session to ensure continuous progress with built-in quality checks.
executing-plans
DesignUse the executing-plans skill when you have a complete implementation plan to execute in controlled batches with review checkpoints. It loads and critically reviews the plan, then executes tasks in small batches (default 3 tasks) while reporting progress between each batch for architect review. This ensures systematic implementation with built-in quality control checkpoints.
cost-optimization
OtherThis Claude Skill helps developers optimize cloud costs through resource rightsizing, tagging strategies, and spending analysis. It provides a framework for reducing cloud expenses and implementing cost governance across AWS, Azure, and GCP. Use it when you need to analyze infrastructure costs, right-size resources, or meet budget constraints.
