القائمة
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.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Integrate and use @stll/folio-agents, the framework-neutral LLM tool layer over @stll/folio-core: function-calling tools that read and mutate a .docx document, with every mutation landing as a tracked change or comment pending human review. Load this skill when wiring folio's tools into an agent's tool-use loop (TanStack AI, Vercel AI SDK, raw Anthropic/OpenAI SDKs, or a custom loop), choosing between the headless reviewer bridge and the live-editor-ref bridge, or summarizing what changed between two document versions.
Create a new implementation plan in the repo's planning area.
Shape a feature or problem before implementation. Use this when the request is still fuzzy, when several solutions are possible, or when execution risks outrunning product clarity.
Process automated PR review comments systematically. Use this for CodeRabbit, Gemini, GitHub Copilot, Devin, Greptile, and similar bots.
Run a security-focused code audit with a generic checklist first, then layer on repo-specific risks.
Review and update third-party dependencies. Use this when asked to upgrade packages, survey new minor or major releases for useful features, assess whether a repository can adopt them, or validate whether a release looks suspicious before bumping it.
| 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: