القائمة
Systematic root-cause analysis. Activate when something is broken and the obvious fix didn't work — when you've tried two things and need to actually think instead of guessing harder.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Author a new task for the eval suite — JSON spec + reference implementation + verified validation. Activate when the user asks to add an eval task, write a benchmark task, or extend the suite. Encodes the 6 hard-won pitfalls from prior post-mortems.
Add multi-language variants (Python / Go / C / C++ / Rust / Zig — 6 supported languages) to an existing eval task. Activate when the user wants to make an eval task language-agnostic or extend the variant rollout. Companion to eval-task-author.
Design a public API contract — function signatures, types, error model, example usage — BEFORE implementing. Activate when adding a new public function / endpoint / library, when changing an existing public surface, or when the user says "design an API for". Frontier models do this naturally; local models often code first and accidentally lock in bad shapes.
Produce a design doc BEFORE writing code for any non-trivial change — new subsystems, public API changes, anything >500 lines or crossing module boundaries. Activate when the user asks for a design, when you find yourself about to invent a non-trivial structure on the fly, or when "let me just start coding" would be premature.
Orient yourself in an unfamiliar codebase BEFORE editing. Activate at the start of any non-trivial task in a repo you don't already know cold — wrong file, wrong style, wrong layer is the most common local-model failure mode and this skill prevents it.
Clean commits, atomic units, meaningful messages, no random staging. Activate any time the user is about to commit, push, or open a PR — local models often stage too aggressively or write messages that don't explain why. Frontier models do this naturally.
| name | debugging-methodology |
| description | Systematic root-cause analysis. Activate when something is broken and the obvious fix didn't work — when you've tried two things and need to actually think instead of guessing harder. |
| allowed_tools | ["bash","read_file","edit_file","grep"] |
| recommends_subagent | false |
You're not here to apply patches until something stops failing. You're here to understand why. The patch falls out of the understanding for free.
1. Reproduce reliably
2. Form a specific hypothesis
3. Design the cheapest experiment that would falsify it
4. Run the experiment
5. If hypothesis falsified, form a new one. Otherwise refine.
6. When the hypothesis predicts behavior at the source level, you're done.
Each cycle should take minutes, not hours. If you're stuck for more than 30 minutes on one hypothesis without an experiment, your hypothesis is too vague.
A bug you can reproduce in 10 seconds is debuggable. A bug that happens "sometimes" is not — your first job is to find the conditions that make it deterministic.
A specific hypothesis predicts what happens at a specific line of code. Not
"there's a race condition somewhere" — "the value of count after line 42 is
zero, but line 43 expects it to be positive."
Vague hypotheses can't be falsified. Specific hypotheses can.
This is the lever. For any hypothesis, ask: what's the smallest, fastest thing I can do that would change my belief about it?
print at the suspected line. The first tool. Don't be too proud for it.assert invariants that should hold. If the assert trips, you've moved.pdb.set_trace() when you need to poke around interactively.python3.10 works and python3.11 doesn't, run both side by side.Avoid:
python3 --version, go versionpip freeze | diff <(ssh other pip freeze) -env | diff <(ssh other env) -.env? Different config?locale — sort order, decimal separator, encoding all changegit log --since=yesterday — what changed?git bisect — find the breaking commitpip install --upgrade ran somewhere?
apt update && apt upgrade?time.sleep and see if the failure rate changesfor i in {1..100}; do pytest test_x; doneself.thing when it crashed?-fsanitize=address), MSan.print likely changed memory layout (heap allocation pattern) or timing
(forced a flush). The bug is real; your repro is fragile.After 4-5 cycles of hypothesis → experiment with no progress, you're in one of these states:
strace, ltrace, gdb, perf.If genuinely stuck, spawn a sub-agent with deep-counsel. Hand it the full
problem context — what you've tried, what each experiment told you, where you
think you're stuck. Sometimes a fresh framing breaks it.