Menu
Diagnose and fix a bug or unexpected behavior. Traces the problem through the dependency graph, adds logging if needed, and proposes a fix. Use when something is broken, producing wrong output, or behaving unexpectedly.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Bump the project version across all files that carry it. Pass the new version as the argument (e.g. /bump-version 0.4.0).
Full code navigation — replaces grep, glob, and file reads. Find symbol definitions, trace callers and callees, read source code, and map module structure. Pass symbol names or questions as arguments.
Generate a PR description as a Markdown file in .claude/scratch using git history and code analysis. Fills in the project's PR template.
Plan implementation before writing code. Analyzes codebase structure and dependencies, asks clarifying questions, and writes a scoped implementation spec.
Based on SOC occupation classification
| name | debug |
| description | Diagnose and fix a bug or unexpected behavior. Traces the problem through the dependency graph, adds logging if needed, and proposes a fix. Use when something is broken, producing wrong output, or behaving unexpectedly. |
| argument-hint | <description of the bug or unexpected behavior> |
| allowed-tools | Bash Edit Skill |
Diagnose and fix: $ARGUMENTS
Step 1 — Understand the problem
Ask me what the intended behavior is, what the current output is, and how to reproduce it. Do not start investigating until you understand what "fixed" looks like.
Step 2 — Trace through the graph
Run /code-analysis <suspected function or module> on the area where the bug likely lives. Use the edges to trace the call chain and the source blocks to read the code — follow caller/callee relationships to find where the bad data or wrong behavior originates.
If the bug could be in multiple places, batch all candidates into a single /code-analysis call using comma-separated targets (e.g. /code-analysis FuncA, FuncB, FuncC) — do not invoke /code-analysis once per candidate. If you don't know where to start, run /code-analysis with no arguments first to get the module boundaries.
Do not read files directly. Use the source blocks returned by the analysis instead.
Step 3 — Narrow down
Don't overthink. If the graph narrows it to a few files but you're unsure which is the source, add logging statements to gain a better understanding. Run the code and read the output.
Step 4 — Diagnose
Write a brief diagnosis: what's broken, why, and which callsites are affected (from the code-analysis results). Share it with me before proposing a fix.
Step 5 — Wait for approval
Propose the fix. Do not write any code until I approve. If the fix touches a function with a BREAKING verdict from check, list all affected callsites in the proposal.
