القائمة
Disciplined diagnosis loop for hard bugs and performance regressions. Use only when user instructs or other skill references.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Standard workflow to implement a plan. Use only when user instructs or other skill references.
Manage interactive or persistent terminal sessions. Must use before running these sessions, like start a dev server, SSH, REPL, ...
Guidelines to help you write code smartly by using workers. Only use
Workflow to transform vague ideas into validated designs and stepped implementation plans. Use only when user instructs or other skill references.
Review a plan before implementation. Use only when user instructs or other skill references.
Inspect Git history and uncommitted changes to obtain delta in blueprint.
| name | diagnose-hard-bugs |
| description | Disciplined diagnosis loop for hard bugs and performance regressions. Use only when user instructs or other skill references. |
A discipline for hard bugs. Skip phases only when explicitly justified. No code change.
This is the skill. Everything else is mechanical. If you have a fast, deterministic, agent-runnable pass/fail signal for the bug, you will find the cause — bisection, hypothesis-testing, and instrumentation all just consume that signal. If you don't have one, no amount of staring at code will save you.
Spend disproportionate effort here. Be aggressive. Be creative. Refuse to give up.
git bisect run it.scripts/hitl-loop.template.sh so the loop is still structured. Captured output feeds back to you.Build the right feedback loop, and the bug is 90% fixed.
Treat the loop as a product. Once you have a loop, ask:
A 30-second flaky loop is barely better than no loop. A 2-second deterministic loop is a debugging superpower.
The goal is not a clean repro but a higher reproduction rate. Loop the trigger 100×, parallelize, add stress, narrow timing windows, inject sleeps. A 50%-flake bug is debuggable; 1% is not — keep raising the rate until it's debuggable.
Stop and say so explicitly. List what you tried. Ask the user for:
Do not proceed to hypothesize without a loop. Do not proceed to Phase 2 until you have a loop you believe in.
Run the loop. Watch the bug appear.
Confirm:
Do not proceed until you reproduce the bug.
Generate 3–5 ranked hypotheses before testing any of them. Single-hypothesis generation anchors on the first plausible idea.
Each hypothesis must be falsifiable: state the prediction it makes.
Format: "If is the cause, then will make the bug disappear / will make it worse."
If you cannot state the prediction, the hypothesis is a vibe — discard or sharpen it.
Show the ranked list to the user before testing. They often have domain knowledge that re-ranks instantly ("we just deployed a change to #3"), or know hypotheses they've already ruled out. Cheap checkpoint, big time saver.
Each probe must map to a specific prediction from Phase 3. Change one variable at a time.
Tool preference:
Tag every debug log with a unique prefix, e.g. [DEBUG-a4f2]. Cleanup at the end becomes a single grep. Untagged logs survive; tagged logs die.
Perf branch. For performance regressions, logs are usually wrong. Instead: establish a baseline measurement (timing harness, performance.now(), profiler, query plan), then bisect.
After finding the root cause, give a detailed and concrete report to the user. Required before declaring done:
[DEBUG-...] instrumentation removed (grep the prefix)