agentleFS
tomimortomimor/skills/skills/grill-me/SKILL.md

grill-me

Skill2 starsChanged 5 months agoMITView on GitHub

Interview the user relentlessly about every aspect of their plan or design until you reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. 1. One question at a time. Never batch. Wait for each answer before moving on. 2. Always use the AskQuestion tool. Never list options inline in chat. Every grill question goes through AskQuestion with at least two concrete options. 3. Always recommend an answer. For every question, include your…

193 other projects use a version of this, 73 of them edited.

Adopted by

Most recently taken up by

Used with

Projects with it also use brief-to-tasks, writing-beats and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • julianoczkowskiSkill

    brief-to-tasks

    Break a design brief into an ordered checklist of independently buildable tasks using vertical slices. Saves as a markdown checklist. Use when user wants to break down work, create tasks from a brief, plan implementation order, or mentions "tasks" or "breakdown".

    Also in 7 projects that use this

  • LesaniSkill

    writing-beats

    Shape an article as a journey of beats, choose-your-own-adventure style. The user picks a starting beat from the raw material, you write only that beat, then offer options for where to pivot next, beat by beat, until the article reaches a natural end. Use when the user has raw material and wants to assemble it as a narrative rather than an argument.

    Also in 66 projects that use this

  • simo97Skill

    request-refactor-plan

    Use this skill when user wants to create a refactor plan.

    Also in 43 projects that use this

  • simo97Skill

    migrate-to-shoehorn

    Migrate test files from `as` type assertions to @total-typescript/shoehorn. Use when user mentions shoehorn, wants to replace `as` in tests, or needs partial test data.

    Also in 71 projects that use this

  • LesaniSkill

    writing-shape

    Take a markdown file of raw material and shape it into an article through a conversational session — drafting candidate openings, growing the piece paragraph by paragraph, arguing about format (lists, tables, callouts, quotes) at each step. Use when the user has a pile of notes, fragments, or a rough draft and wants help turning it into something publishable.

    Also in 65 projects that use this

  • liufeng1976Skill

    setup-ts-deep-modules

    Wire dependency-cruiser into a TypeScript repo so each package is a deep module — implementation hidden in subfolders, reachable only through its entry-point files. User-invoked.

    Also in 42 projects that use this

  • +2 more from simo97

The file

Show its rules and text

We split this skill into the rules it gives an agent

19 rules. 0 are common, 15 are distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 177 edited versions we read keep these.

  • 15

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    One question at a time: Never batch. Wait for each answer before moving on.

    line 15
  2. Very specific:

    Always use the AskQuestion tool: Never list options inline in chat.

    line 16
  3. Distinctive:

    Explore the codebase before asking: If a question can be answered by reading files, running git, or searching the repo, do that first …

    line 20
  4. Distinctive:

    Resolve dependencies in order: Don't ask about leaf decisions before their parents are settled.

    line 22
  5. Distinctive:

    Before asking anything, sketch the tree of decisions in your head:

    line 37
  6. Distinctive:

    Don't show the tree to the user.

    line 43
  7. Distinctive:

    Try to resolve it from the codebase first: If there's a precedent, an existing pattern, or a config that already answers the question, read …

    line 49
  8. Very specific:

    Otherwise, ask via AskQuestion: Use this format:

    line 51
  9. Distinctive:

    Stop grilling when any of these is true:

    line 62
  10. Distinctive:

    Every branch you can see is resolved or explicitly deferred.

    line 64
  11. Distinctive:

    When done, produce a short summary:

    line 70
  12. Very specific:

    Every AskQuestion call must look roughly like this:

    line 82
  13. Very specific:

    Do NOT ask multiple questions in one message or one AskQuestion call when they aren't independent.

    line 96
  14. Distinctive:

    Do NOT list options as a markdown bullet list in chat -- use the tool.

    line 97
  15. Distinctive:

    Do NOT ask questions whose answers are already in the codebase.

    line 98
  16. Distinctive:

    Do NOT skip the recommendation.

    line 99
  17. Distinctive:

    Do NOT keep grilling once the tree is resolved.

    line 100
  18. Distinctive:

    Do NOT make it adversarial.

    line 101
  19. Distinctive:

    Do NOT yes-machine a weak premise.

    line 102

“Common” is measured: kept by at least 6 in 10 of the 177 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Grill Me

Interview the user relentlessly about every aspect of their plan or design until you reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one.

Core Rules

  1. One question at a time. Never batch. Wait for each answer before moving on.
  2. Always use the AskQuestion tool. Never list options inline in chat. Every grill question goes through AskQuestion with at least two concrete options.
  3. Always recommend an answer. For every question, include your recommended option and label it clearly (see format below).
  4. Explore the codebase before asking. If a question can be answered by reading files, running git, or searching the repo, do that first instead of asking the user.
  5. Resolve dependencies in order. Don't ask about leaf decisions before their parents are settled.

Workflow

Step 1: Anchor the plan

Restate the plan or design as a "How Might We" problem statement, in 1-3 sentences, so both of you are working from the same baseline. The HMW framing forces clarity on what's actually being solved -- not just what's being built. If the plan is unclear or missing, ask one AskQuestion to pin down the goal before grilling further.

Example: instead of "we'll add a rate limiter," restate as "How might we keep abusive traffic from degrading API latency for paying users?" -- now the grill has a target.

Step 2: Build the decision tree (internally)

Before asking anything, sketch the tree of decisions in your head:

  • Roots: the highest-level choices (architecture, scope, ownership, success criteria).
  • Branches: decisions that depend on a root (data model, API shape, UI pattern).
  • Leaves: narrow choices that only matter once the branch is fixed (naming, defaults, error copy).

Don't show the tree to the user. Use it to order questions.

Step 3: Walk the tree, one question at a time

For each unresolved node, in dependency order:

  1. Try to resolve it from the codebase first. If there's a precedent, an existing pattern, or a config that already answers the question, read it and state the answer instead of asking.
  2. Otherwise, ask via AskQuestion. Use this format:

    • prompt: the question itself, followed by a 1-2 sentence rationale and your recommendation. Mark the recommended option with (recommended) in the option label.
    • options: 2-5 concrete, mutually exclusive choices. Always include an Other / explain option so the user can redirect you.
  3. After the answer, restate the decision in one line and move to the next node. If the answer opens new branches, add them to the tree before continuing.

Step 4: Stop conditions

Stop grilling when any of these is true:

  • Every branch you can see is resolved or explicitly deferred.
  • The user says stop, enough, or equivalent.
  • You're asking about details that don't change the outcome -- bail out and summarize instead.

Step 5: Summarize the shared understanding

When done, produce a short summary:

  • The plan in 2-3 sentences (updated with the decisions made).
  • A bullet list of resolved decisions: Decision -> chosen option.
  • A bullet list of explicitly deferred items, if any.
  • An assumptions ledger: unverified claims the plan is now betting on. For each, name the bet in one line and, if obvious, how it could be invalidated. Example: Assumes Postgres can sustain 5k writes/s at our row size -- not benchmarked. This is the negative space of the grill: what survived not because it was confirmed, but because nobody challenged it yet.

Question Format

Every AskQuestion call must look roughly like this:

  • prompt: one clear question, then Recommended: <option>. Why: <one sentence>.
  • options: each option is a short phrase. The recommended one ends with (recommended).
  • allow_multiple: false unless the decision is genuinely multi-select (e.g. picking which validations to run).

Example shape (do not copy verbatim, adapt to the actual question):

  • prompt: "Where should the rate limiter live? Recommended: edge middleware. Why: it stops abusive traffic before it hits app servers."
  • options: Edge middleware (recommended), App-level middleware, Per-route decorator, Other / explain.

Anti-Patterns

  • Do NOT ask multiple questions in one message or one AskQuestion call when they aren't independent.
  • Do NOT list options as a markdown bullet list in chat -- use the tool.
  • Do NOT ask questions whose answers are already in the codebase.
  • Do NOT skip the recommendation. "I don't know, what do you think?" is not a grill.
  • Do NOT keep grilling once the tree is resolved. Wrap up.
  • Do NOT make it adversarial. Direct and probing, not hostile.
  • Do NOT yes-machine a weak premise. If the underlying goal is shaky, say so with specificity and propose a sharper framing -- don't grill the leaves of a bad tree.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.