grill-yourself
Skill4 starsChanged 3 months agoApache-2.0View on GitHub
Inverted grill — the model interrogates its own plan on the user's behalf, ghost-writing the hard questions in the user's voice and answering each with a recommendation, so the human's job shrinks to rendering verdicts. Use when the user wants a plan stress-tested but doesn't know what questions to ask, says "grill yourself," or asks the model to red-team its own proposal. Checkpoints every verdict to brainstorms/ so the session survives interruption.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- ian-pascoe/skillstheir own version, first seen Nov 1, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- ian-pascoe/skills★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository25 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- adr-writingSkill
- authoring-goal-contractsSkill
- collaborating-asyncSkill
- committing-changesSkill
- cross-agent-dispatchSkill
- documenting-decisionsSkill
- feature-status-registrySkill
- grill-meSkill
- handling-micro-fixesSkill
- multi-instance-dispatchSkill
- notifying-the-developerSkill
- orchestrating-goal-loopsSkill
- orchestrating-lean-dispatchSkill
- performance-playbookSkill
- python-project-patternsSkill
- recovering-from-failuresSkill
- running-build-checkpointsSkill
- searching-prior-artSkill
- security-checklistSkill
- selecting-review-gatesSkill
- severity-calibrationSkill
- syncing-framework-docsSkill
- testing-playbookSkill
- wrapping-up-sessionsSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 30
Never make the user ask to have things simplified twice.
- Distinctive: line 74
If a question is someone else's call or needs data the user lacks, record it under Flagged for others and move on — don't guess.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Purpose: freeze frontier-level interrogation into a reusable pattern. The model plays both interrogator and expert; the human stays the arbiter. A secondary and explicit goal is teaching: over repeated sessions the user should begin anticipating the questions unaided. Success includes this skill becoming less necessary.
Roles
- The model ghost-writes the questions a top-tier skeptical engineer would ask about the current plan, phrased in the user's voice, one at a time — and answers each with a concrete recommendation.
- The user renders a verdict per question: accept, amend X, dig deeper, or explain (a first-class move, never a failure state — it means re-teach at a lower altitude before asking for a verdict).
Three-altitude format (default for every question)
- Headline — one plain sentence a tired person can act on alone.
- Plain-language layer — what's at stake, why this question exists, which taxonomy category it belongs to, and an everyday analogy.
- Technical layer — full detail and the recommendation's mechanics. Offer it; don't force it. If the user says they're tired, lead with altitudes 1–2 only and hold 3 for request.
Never make the user ask to have things simplified twice. If they downshift once, stay downshifted for the rest of the session.
The question taxonomy (the heart of this skill)
Walk the plan against these categories. Not every category applies to every plan; say so and skip rather than manufacture a question. Order by risk, not by list position.
- Validity — Does this measure/do what it claims? What confound would make the result mean something else? (Rule: separate the thing tested from the scaffolding around it; add a control condition.)
- Checker ceiling — Can whoever verifies the work recognize quality they couldn't produce? (Rule: verification is easier than generation — move intelligence into checklists the weaker checker can audit.)
- Ground truth — What is actually true here, independent of anyone's performance? (Rule: authored manifests and historical records beat even an expert's transcript; experts get graded too.)
- Goodhart — If we optimize against this measure, does it corrupt? (Rule: hold out a vault the optimization loop never sees; open it only at declared milestones.)
- Signal vs. noise — Is run-to-run variance louder than the effect? (Rule: repeat runs, report median + range, only trust non-overlapping ranges; treat divergence in reference runs as a defect in the task, not the runner.)
- Consumer — Who reads the output and what decision changes? (Rule: a measurement with no attached decision is a hobby; name every consumer and emit a view per consumer.)
- Opportunity cost — What's the best thing NOT done because of this? (Rule: triage by perishability — spend scarce resources only on what nothing else can do; re-run the budget math after scope grows.)
- Staleness — What changes under this over time, and how would we know? (Rule: pin baselines to versions; retire them to history rather than discard; alarm on same-conditions drift.)
- Leakage — What escapes (into training data, into public view, into the optimization loop) and what does the escape corrupt? (Rule: keep one never-published yardstick; treat post-publication scores as suspect-high.)
Session mechanics
- Open by listing the taxonomy branches you intend to walk for THIS plan, so the user sees the terrain and can reorder.
- One question per turn. Recommended answer always attached. Wait for the verdict before proceeding.
- If a question is someone else's call or needs data the user lacks, record it under Flagged for others and move on — don't guess.
- Scope-growth audit: accepted answers add work. Every few questions, re-ask category 7 against the plan's own growth.
Checkpointing (inherited from grill-me)
One file per topic at brainstorms/YYYY-MM-DD-<topic-slug>.md, same
structure as grill-me (Highlights / Key decisions / Open threads / Flagged
for others / Q&A log). Append the exchange the moment a verdict lands,
before asking the next question. Record verdicts verbatim. Resume protocol
identical to grill-me: find the file, replay highlights, continue from the
first open thread, never re-ask answered questions.
Teaching stance
You are not just resolving decisions; you are demonstrating how to think about problems. Name the taxonomy category aloud each time so the pattern becomes visible and transferable. If the user starts asking a category's question before you do, say so — that's the skill working.
Worked example
See brainstorms/2026-07-01-fable-eval-design.md — the session that
produced this skill, in which the user grilled the model over a nine-
question walk of an eval-suite design.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

