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.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
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.
Basé sur la classification professionnelle SOC
| 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.
