grill-with-docs — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited grill-with-docs (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
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.
Source: mattpocock/skills - engineering/grill-with-docs
<what-to-do>
Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
Ask the questions one at a time, waiting for feedback on each question before continuing.
If a fact can be found by exploring the codebase, look it up instead of asking. The decisions, though, are mine - put each one to me and wait.
Do not enact the plan until I confirm we have reached a shared understanding.
</what-to-do>
<supporting-info>
During codebase exploration, also look for existing documentation:
Most repos have a single context:
/
├── CONTEXT.md
└── src/If a CONTEXT-MAP.md exists at the root, the repo has multiple contexts. The map points to where each one lives:
/
├── CONTEXT-MAP.md
├── src/
│ ├── ordering/
│ │ └── CONTEXT.md
│ └── billing/
│ └── CONTEXT.mdCreate files lazily - only when you have something to write. If no CONTEXT.md exists, create one when the first term is resolved.
When the user uses a term that conflicts with the existing language in CONTEXT.md, call it out immediately. "Your glossary defines 'cancellation' as X, but you seem to mean Y - which is it?"
When the user uses vague or overloaded terms, propose one precise term to use everywhere. "You're saying 'account' - do you mean the Customer or the User? Those are different things."
When domain relationships are being discussed, stress-test them with specific scenarios. Invent scenarios that probe edge cases and force the user to be precise about the boundaries between concepts.
When the user states how something works, check whether the code agrees. If you find a contradiction, surface it: "Your code cancels entire Orders, but you just said partial cancellation is possible - which is right?"
When a term is resolved, update CONTEXT.md right there. Don't batch these up - capture them as they happen. Use the format in CONTEXT-FORMAT.md.
Don't couple CONTEXT.md to implementation details. Only include terms that are meaningful to domain experts. CONTEXT.md is a glossary and nothing else - not a spec, not a scratch pad.
ADR creation is explicit-ask only, via /document adr "<title>". The grill records decisions in the exit plan, saved on agreement to .claude/state/plans/YYYY-MM-DD-<topic>.md, never in an ADR (review-time: a proposal is free-form text no hook can see)
For a plan with genuine cross-domain tension or competing approaches, convene a panel (see rules/parallel-agents.md) instead of grilling solo:
rules/agent-routing.md), each with a read-only brief and a distinct stance to argue (review-time: panel-vs-solo judgment)(review-time: protocol guidance)rules/communication.md; the panel never messages the user directly (review-time: cadence discipline)(review-time: panel-vs-solo judgment)</supporting-info>
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.