foreman-debug — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited foreman-debug (Agent Skill) and scored it 92/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 2 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 2 flagged
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
(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 FIRSTA 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.
line, the 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. Theregression almost always lives in the diff.
passed it in? Keep walking up the call stack until you reach the origin. Fix there, not at the symptom.
Find working code that does the same thing elsewhere in the repo. List every difference between it and the broken path, however small — "that can't matter" is how root causes hide.
State one specific hypothesis: "the root cause is X because Y." Make the smallest change that tests it. One variable at a time. If it doesn't hold, form a new hypothesis — do not stack a second fix on top of an unproven first.
this root cause* and will pass once it's fixed — exactly the red-green discipline foreman-tdd already uses. A fix with no test that proves it does not count.
stays green. Read the output; do not assume.
If three distinct fixes each fail or each surfaces a new problem somewhere else, the issue is architectural, not a bug — the slice's seam is wrong. Stop patching. Hand back to foreman-tdd with a clear note for its FOREMAN-SUMMARY: set escalate: true with a one-line statement of the structural problem (e.g. "ISS-012 assumes a synchronous store but the queue is async — the seam can't hold"). A wrong architecture is Foreman's human's call, not another guess.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.