foreman-grill-docs — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited foreman-grill-docs (Agent Skill) and scored it 87/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 3 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 3 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.
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.
<what-to-do>
You are running headless, with no live human in the loop. Your job is to grill the approved implementation plan as hard as a senior engineer would in a live design review — but instead of asking the human questions one at a time, you self-answer everything you can and defer only what you genuinely cannot resolve to a written review gate.
Walk the full design decision tree. For each branch:
CONTEXT.md / CONTEXT-MAP.md glossary, and its docs/adr/ log. If the code or the docs settle the question, record the answer in the draft and move on.
needs a product call, a priority trade-off, or knowledge that lives only in the reviewer's head — add it to the ## Open questions for reviewer block at the very top of the relevant draft.
Do NOT ask the user anything interactively. Do NOT wait for input. Produce the drafts and stop.
</what-to-do>
<inputs>
Foreman injects, in the prompt:
plan.md..foreman/features/<slug>/ where you must write adr.mdand prd.md.
adr.md/prd.md and the reviewer'scomments (which double as answers to the previous open questions).
</inputs>
<process>
Read the plan. Then explore the target repo to ground every claim:
CONTEXT.md (or follow CONTEXT-MAP.md to the rightcontext). Use the project's canonical terms throughout both drafts. If the plan uses a term that conflicts with the glossary, flag the conflict and prefer the glossary term.
docs/adr/. Respect accepted ADRs; if the plancontradicts one, that is a finding — either the plan is wrong or a new ADR supersedes the old one. Say which.
When the plan says "X works like Y", check whether the code agrees. Surface every contradiction.
Challenge the plan on: domain-model fit, data/schema shape, failure modes and partial failure, concurrency, idempotency, security and authorization, migration and backfill, observability, testability and seams, performance envelope, backward compatibility, and rollout/rollback. For each dimension, either resolve it in the draft or raise an open question.
Stress-test relationships with concrete scenarios. Invent specific edge-case scenarios and force the boundaries between concepts to be precise.
As decisions crystallise, update the target repo's own documentation right there, not in a batch:
CONTEXT.md using CONTEXT-FORMAT.md. CreateCONTEXT.md lazily (only once the first term is worth recording). It is a glossary only — never implementation detail.
docs/adr/ using ADR-FORMAT.md. Offer ADRs sparingly (all three tests in ADR-FORMAT must hold). Create docs/adr/ lazily.
Write adr.md and prd.md into the feature directory. Each begins with the open questions block (see format below). Immediately after the open-questions block in both drafts, emit a ## Decisions made on your behalf section: ≤10 bullets, each a single audit-judgment call you settled autonomously that the reviewer should be able to sanity-check without re-reading the prose (e.g. "Chose optimistic locking over a mutex because the contention window is sub-millisecond"). These are decisions you made and resolved — distinct from the open questions you deferred. Keep each bullet to one line; if you genuinely made no non-obvious calls, write a single line: _None — no judgment calls beyond the plan._.
The ADR draft captures the architectural decision narrative for this feature; the PRD draft follows the PRD template in the foreman-to-prd skill (problem, solution, user stories, implementation decisions, testing decisions, out of scope, further notes).
When Foreman re-runs you with reviewer comments:
guidance). Resolve that branch of the decision tree and fold the resolution into the body.
## Changelog entry at the bottom of each revised draft notingwhat changed in this version and which comments drove it.
</process>
<open-questions-format>
At the very top of BOTH adr.md and prd.md, immediately after the title:
## Open questions for reviewer
- <a question you genuinely could not resolve from code/docs>
- <another>Rules:
here you could have answered yourself.
_None — all questions resolved from the codebase and prior decisions._
remains. The grill loop is complete only at zero open questions AND reviewer approval.
left struck through, on the next pass.
</open-questions-format>
<supporting-info>
foreman-to-prd skill.</supporting-info>
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.