grill-me — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited grill-me (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 the user relentlessly about every aspect of a design or plan until every branch of the decision tree has a resolution. This skill is for after brainstorming has produced a design — it stress-tests what exists, it does not create something new.
When NOT to use:
Before asking anything, write down your current read of the design/plan's strength and your confidence in it:
HYPOTHESIS: This design handles the happy path well but has three unresolved edge cases around auth state transitions.
CONFIDENCE: ~50% — haven't examined: error recovery flow, concurrent access, data migration pathThe number forces honesty. If you can't articulate what might be wrong, you're not ready to grill — read the design again.
When confidence is below ~70%, append what's still unresolved. This tells the user exactly where the gaps are.
Format:
Q: What happens when the payment service is down mid-transaction?
GUESS: You probably have a retry queue with exponential backoff, because that's the standard pattern — but I don't see it in the design.Wait for the user to react before asking the next question.
Why one at a time:
Why attach a guess:
Don't jump between topics. Follow one branch of the decision tree to its conclusion before moving to the next. For each branch:
Example tree for an API design:
Authentication
├── Token format → resolved: JWT with RS256
│ ├── Refresh strategy → resolved: rotating refresh tokens
│ └── Token expiry → resolved: 15min access, 7day refresh
├── Rate limiting → resolved: per-user, sliding window
└── Error responses → UNRESOLVED — what code for expired vs invalid?The most dangerous answers are where the user says what a thoughtful answer sounds like rather than what they actually decided. Watch for:
When you hear these, ask:
"If you didn't have to justify this to anyone, what would you actually decide?"
If a question can be answered by exploring the codebase, explore the codebase instead of asking. This is faster for the user and often more accurate — the code doesn't rationalize.
When you find code that contradicts the design, flag it:
The design says "all errors return structured JSON," but `src/handlers/errors.ts` has three places that throw raw strings. Which is the source of truth?As you resolve branches, maintain a running summary. After every 3-5 resolved branches, restate what was decided:
Resolved so far:
- Auth: JWT with RS256, rotating refresh tokens
- Rate limiting: per-user sliding window, 100 req/min
- Error format: structured JSON with error code + message + request_id
Still unresolved:
- Error codes for expired vs invalid tokens
- Whether rate limit headers are included in 429 responsesThis prevents drift — the user can spot contradictions between early and late resolutions.
You're done when you can answer yes to both:
If you've gone several rounds and still can't predict, stop and say: "I've asked X questions and I still can't predict your reactions on [topic]. Something foundational is missing. Want to step back and reframe?"
Don't grind past the point of diminishing returns. If the remaining branches are genuinely low-risk, say so and move on.
| Rationalization | Reality |
|---|---|
| "The design is solid, we don't need to grill it" | If you can't predict the user's answer to the next three questions about it, there are gaps you haven't found. |
| "Asking too many questions wastes their time" | Time wasted by 4-6 targeted questions is small. Time wasted by implementing an ambiguous design is enormous. |
| "We'll figure it out during implementation" | "We'll figure it out later" means "we'll figure it out under time pressure, in code, with switching costs." That's the expensive version. |
| "They said 'it depends,' so I should move on" | "It depends" means the decision tree has an unresolved branch. Push for a concrete answer or flag it as an open risk. |
| "I don't want to be annoying" | You're not being annoying — you're being thorough. The user asked to be grilled. One question at a time with a guess attached is respectful, not aggressive. |
| "The codebase contradicts the design, but it's probably fine" | Contradictions between code and design are never "probably fine." They're ambiguity that will bite during implementation. |
| "We've covered enough, I'll just note the rest as open questions" | Open questions are fine if they're genuinely low-risk. If they're in the critical path, they're not open questions — they're unmade decisions. |
| "I'll attach my guess but keep it safe" | Safe guesses don't surface gaps. Be visibly willing to be wrong — that's where the value is. |
After completing grill-me:
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.