القائمة
Find the root cause of a failure with evidence, then fix it. Use this when something is broken: a bug, a failing test, an unexpected result, or an error you need to track down.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | debug |
| description | Find the root cause of a failure with evidence, then fix it. Use this when something is broken: a bug, a failing test, an unexpected result, or an error you need to track down. |
| user-invocable | true |
Find and fix bugs systematically using evidence, never guessing.
Auto Mode suppresses confirmation prompts and proceed-pauses — not the one clarifying question that can matter here: if the symptom isn't reproducible and the exact error/repro steps aren't given, state your reading of it for the user to override (debugging the wrong symptom wastes the whole effort). Don't ask "what's the repro?" from blank — lead with your best-inferred symptom and repro and invite correction: "I read the failure as X on step Y — correct me if not." This is the clarifying rendering of the recommendation-backed-question convention (godmode:recommend-convention) in rules/godmode-recommend.md. Once you can reproduce, proceed: fix immediately after the root cause is found, surface assumptions inline, and treat course-corrections as normal input. Don't loop on trivia.
Follow the 4-step protocol strictly. Do NOT skip steps.
Output: "The bug is [X]. Expected [Y]. Triggered by [Z]."
If stuck gathering evidence: use @researcher agent to search the codebase for related patterns, recent changes, or similar bugs.
Output:
H1 (most likely): [hypothesis] — confirm by [check]
H2: [hypothesis] — confirm by [check]
H3: [hypothesis] — confirm by [check]
Output: "Root cause: [exact cause] at [file:line]"
config/quality-gates.txt):
Output: "Fixed [root cause]. Added test [name]. All quality gates pass."
| Step | Agent | Purpose |
|---|---|---|
| HYPOTHESIZE | MUST spawn @researcher when >5 files may be involved | Search codebase for related patterns, recent changes, similar bugs in parallel |
| FIX | Always spawn @test-writer for low-coverage areas | Ensure regression test coverage around the fix, especially in undertested code |
| Post-fix | MUST spawn @security-auditor for security-sensitive fixes | Validate that fixes touching auth, input handling, or data access are safe |
Rule: Never explore the codebase inline when @researcher can do it in parallel.
Once the root cause is found (end of Step 3), decide how the fix re-enters the workflow spine:
.planning/missions/<mission_id>/ROADMAP.md describing the bug and root cause, then pick it up later with /brief N. The brief captures the why + what, /plan N breaks it down, and /build N ships it.In Auto Mode, fix now unless the bug clearly needs design work — then append a work unit and say so inline.
Appended work-unit note (for .planning/missions/<mission_id>/ROADMAP.md):
- Fix: [root cause summary] — bug found by /debug.
Root cause: [cause] at [file:line]. Needs: regression test + minimal fix.
Close every debug run with one consolidated result block. The per-step **Output:** lines above narrate the protocol as you go; this block is the single legible summary the user reads at the end — it leads with the terminal state, summarizes the work, and names one next move:
file:line evidence."Fixed [root cause] at [file:line]. Added regression test [name]; all quality gates pass. Run
/shipto take the fix to a PR."
When the fix is deferred instead of applied now, the next-step names the work-unit handoff:
"Root cause: [cause] at [file:line]. Appended a work unit to
.planning/missions/<mission_id>/ROADMAP.md. Run/brief Nto plan the fix."
Spine: find the root cause, then either fix now (/ship) or append a work unit to .planning/missions/<mission_id>/ROADMAP.md and resume the spine at /brief N.
Check a built unit goal-backward: classify every brief acceptance criterion COVERED / PARTIAL / MISSING with concrete evidence, so you know what is truly done. Use when: verify N, check whether unit N is done, confirm the goals for roadmap unit N are met.
Turn a numbered roadmap unit into a single brief — why + what + spec — so implementation is unambiguous. Use when: brief N, write the brief for N, capture requirements for roadmap unit N before building.
"Execute a plan in dependency-ordered waves — run independent steps concurrently in isolated worktrees, one atomic, quality-gated commit per step. Use when: build N, execute the plan for N, run the build for roadmap unit N."
Pre-mission discovery: discuss and think out candidate directions for the next feature mission, converge on one concrete proposal, and capture the reasoning as a durable artifact that /mission later reads as its seed. Use when: ideate, what should the next mission be, explore options before committing to a charter. Does not start or mutate any mission — it stops at a proposal.
Start or switch to a named feature mission and capture its purpose, constraints, and numbered roadmap, so every later step shares the same context. Use this to begin a new feature cycle or update its direction — it drives bin/godmode-mission, maintains the project-global .planning/PROJECT.md, and writes the mission's .planning/missions/<mission_id>/ROADMAP.md.
Turn a brief into an ordered, dependency-aware tactical plan plus a per-criterion verification plan, so building is mechanical. Use when: plan N, break down the brief for N, produce the build plan for roadmap unit N.