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.
Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the decision tree, resolving dependencies between decisions one by one.
If arguments were passed, treat them as the subject to grill. Otherwise, ask what to stress-test before starting. If a question can be answered by exploring the codebase or reading existing files, do that instead of asking.
NEVER use the AskUserQuestion tool; ask questions as plain text output.
ONE question per turn. Then STOP. Wait for reply. No lists. No "and also". No follow-ups. No bundled sub-questions. One ? per response. Violating this defeats the skill; the user needs space to think, not a wall of questions.
If a question leads to more nested branches, move those to a new question. Never nest question numbers.
Index each question as Q1, Q2, Q3, …
← recommended. Example:A. Option one ← recommended B. Option two C. Option three
The user can reply with just a letter. If they pick a non-recommended option, acknowledge the tradeoff before moving on.
Before starting the session, explore the codebase for existing documentation:
Most repos have a single context:
/
├── CONTEXT.md
├── docs/
│ └── adr/
│ ├── 0001-event-sourced-orders.md
│ └── 0002-postgres-for-write-model.md
└── src/If a CONTEXT-MAP.md exists at the root, the repo has multiple bounded contexts. The map points to where each one lives:
/
├── CONTEXT-MAP.md
├── docs/
│ └── adr/ ← system-wide decisions
└── src/
├── ordering/
│ ├── CONTEXT.md
│ └── docs/adr/ ← context-specific decisions
└── billing/
├── CONTEXT.md
└── docs/adr/Create files lazily, only when you have something to write. If no CONTEXT.md exists, create one when the first term is resolved. If no docs/adr/ exists, create it when the first ADR is needed.
When the user uses a term that conflicts with the existing language in CONTEXT.md, call it out immediately. Example: "Your glossary defines 'cancellation' as X, but you seem to mean Y; which is it?"
When the user uses vague or overloaded terms, propose a precise canonical term. Example: "You're saying 'account'; do you mean the Customer or the User? Those are different things in your glossary."
When domain relationships are being discussed, invent edge-case scenarios that probe the boundaries and force precision.
When the user states how something works, check whether the code agrees. If you find a contradiction, surface it. Example: "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 away; don't batch. Use the format in docs/CONTEXT-FORMAT.md.
CONTEXT.md is a glossary and nothing else, totally devoid of implementation details, specs, or architecture notes.
Only offer to create an ADR when all three are true:
If any of the three is missing, skip the ADR. Use the format in docs/ADR-FORMAT.md.
CONTEXT.md reflects all resolved terminology,Produce a decision record covering:
CONTEXT.md during this session.~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.