メニュー
Track down a behavior that used to work and now fails, changed, or regressed. Use this when a bug report points to a recent breakage, especially when the cause is not obvious yet.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/stella/.github --skill regression-huntコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SKILL.md を表示中
| name | regression-hunt |
| description | Track down a behavior that used to work and now fails, changed, or regressed. Use this when a bug report points to a recent breakage, especially when the cause is not obvious yet. |
Track down a behavior that used to work and now fails, changed, or regressed. Use this when a bug report points to a recent breakage, especially when the cause is not obvious yet.
$ARGUMENTS — A short description of what regressed.
Helpful extras when available:
A plain-English bug report is enough to start.
Everything else is mechanical. With a fast, deterministic, agent-runnable pass/fail signal, bisection and hypothesis testing all just consume it. Without one, no amount of staring at code will save you. Spend disproportionate effort here. Be aggressive. Be creative. Refuse to give up.
Try these in roughly this order:
bun run test -- --bail -t "<pattern>" — so flags wired into the
script (--preload, custom setup) are preserved; calling bun test
directly bypasses them. Avoid bun --bun test from a worktree root.
Note that bun test positional arguments are file path patterns,
not test names; use -t "<pattern>" to filter by test name and
--bail to fast-fail.AbortSignal.timeout(10_000) so a hung request does not rot the loop.git bisect run bun run test -- --bail -t "<test-name>".
Verify the harness actually fails on a known-bad commit before
starting — bun test exits 0 when no test names match, which would
silently mark every commit as good and produce the wrong culprit.Then treat the loop as a product. Iterate on it:
A 30-second flaky loop is barely better than no loop. A 2-second deterministic loop is a debugging superpower.
For non-deterministic bugs the goal is a higher reproduction rate, not a clean repro. Loop the trigger 100×, parallelise, narrow timing windows, inject sleeps. A 50%-flake bug is debuggable; 1% is not — keep raising the rate until it is.
If you genuinely cannot build a loop, stop and say so explicitly. List what you tried. Ask the user for: environment access, a captured artifact (HAR, log dump, screen recording with timestamps), or permission to add temporary instrumentation. Do not proceed to hypothesise without a loop.
Only if a correct seam exists — one where the test exercises the real bug pattern as it occurs at the call site. A test at the wrong seam (too shallow, single-caller test when the bug needs multiple callers, unit test that cannot replicate the trigger chain) gives false confidence.
If no correct seam exists, that itself is the finding. Note it and flag the architectural gap for step 10. The codebase is preventing the bug from being locked down.
Prefer focused integration tests over deep unit tests when the regression crosses layers. If the area has no automated harness, build the smallest reproducible check and say why a proper regression test was not added yet.
Single-hypothesis generation anchors on the first plausible idea. Each hypothesis must be falsifiable — state its prediction:
If is the cause, then will make it disappear / will make it worse.
If you cannot state a prediction, the hypothesis is a vibe — sharpen or discard. Show the ranked list to the user before testing; domain knowledge often re-ranks instantly ("we just deployed a change to #3"). Don't block on it if the user is AFK; proceed with your own ranking.
Use git history when helpful, but do not stop at blame; verify the actual
cause. For regressions specifically, git bisect run against your step 2
loop is often the fastest path to the offending commit.
Each probe must map to a specific prediction from step 4. Change one variable at a time.
Preference:
bun --inspect-brk is a runtime flag that must
attach to the process actually running the code, which means wrapping
it in bun run <script> will not propagate to the spawned child.
Either prepend --inspect-brk to the test command inside your
package script temporarily, or invoke directly while replicating the
flags the script wires — e.g. bun --inspect-brk test --preload ./setup.ts <file-path>. Open the printed devtools:// URL in
Chrome, set one breakpoint at the suspected fault. One breakpoint
beats ten logs.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.
For performance regressions, logs are usually wrong. Establish a baseline
measurement first — prefer Bun.nanoseconds() over performance.now() on
the backend (sharper resolution, no Node-portability tax), or a query plan
for DB regressions — then bisect. Measure first, fix second.
[DEBUG-...] instrumentation removed (grep the prefix)Ask: what would have prevented this regression? Make this recommendation after the fix is in — you have more information now than when you started.
Lenses to apply: