Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →visionforge-ou/foreman-debug
Headless root-cause debugging loop for a Foreman worker whose tests, build, or acceptance check are failing — especially on a retry. Find the root cause before changing anything, fix at the source with a regression test, and never thrash on symptom patches. Used inside a foreman-tdd build session; emits no summary of its own.
Passed 14 of 19 test cases with the skill, and 12 of 19 without it.
3 fixed13 passed either way5 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 3 test cases the skill fixed. Same model, same prompt, with and without the skill.
You have attempted three distinct fixes for an async event processing bug: adjusting the retry backoff, changing the lock timeout, and flushing the socket buffer. Each fix caused a new downstream failure in the job queue slice. What is the required course of action?
| Checked | Without skill | With skill |
|---|---|---|
| Stops attempting code fixes for the slice | Passed | Passed |
| Flags the issue as architectural and requests escalation with `escalate: true` | Missed | Passed |
The instructions your model reads when the skill loads.
(Adapted from obra/superpowers systematic-debugging (MIT) — see NOTICE. Made
headless: removed the "discuss with your human partner" hand-offs — under Foreman
there is no live human, so a genuine architectural dead end becomes a FOREMAN-SUMMARY
escalate from the surrounding foreman-tdd run, not a question. Folded the regression
step into Foreman's existing foreman-test + evidence contract.)
You are invoked inside a foreman-tdd build session when something is failing: a
red test that should be green, the project test/lint/typecheck command, the issue's
acceptance_check, or a distilled failure report from a prior attempt. You run
headless — do not ask questions. Find the root cause, fix it at the source, and
hand control back to foreman-tdd. You emit no FOREMAN-SUMMARY of your own; the
foreman-tdd run owns the single summary block.
NO FIX WITHOUT ROOT-CAUSE INVESTIGATION FIRST
A symptom patch that makes the red go away without explaining why it was red is a failure — it will bounce at Foreman's merge gate or resurface on the next slice.
ERROR lines in the foreman-test log on disk. The message often is
the answer. If a distilled failure report from a prior attempt is in your context,
treat its "why it was rejected" as the starting hypothesis, not noise to re-discover.foreman-test
(use --fast while iterating). If it is flaky, that is the bug — chase the
nondeterminism (ordering, time, shared state), don't paper over it.git diff the slice against the integration branch. The
regression almost always lives in the diff.test cases passed, vs 12 / 19 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.