agentleFS
Sign inStart free
SethGammonSethGammon/Citadel/skills/grill/SKILL.md

grill

Skill927 starsChanged 16 days agoMITView on GitHub

Relentless one-question-at-a-time interview that sharpens a vague plan or design into shared understanding before any build. The elicitation engine other planning skills call instead of inventing their own interview. Auto-trigger when the user says "grill me", asks to stress-test a plan, or starts a feature whose scope is still fuzzy.

We split this skill into the rules it gives an agent

10 rules. 0 are common, 9 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 63 edited versions we read keep these.

  • 9

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    ONE QUESTION AT A TIME: Ask a single question, wait for the answer, then ask the next.

    line 50
  2. Distinctive:

    NO PREMATURE EXIT: Do not stop until every branch of the decision tree is resolved or explicitly deferred.

    line 58
  3. Distinctive:

    Track state out loud: After each answer, restate what is now settled and what remains on the frontier.

    line 68
  4. Very specific:

    Land it: When the frontier is empty, summarize the resolved design in a tight block the next step (build, prd, decision-map ticket) can …

    line 70
  5. Distinctive:

    When sharpening a feature that proposes an AI/LLM seam, run a structure gate on it — ask whether rules, patterns, authored content, state …

    line 73
  6. Distinctive:

    Every question shipped a recommended default with a one-line reason.

    line 81
  7. Distinctive:

    No question was asked that the repo, docs, or history already answered.

    line 82
  8. Distinctive:

    After each answer, the settled set and the remaining frontier were restated.

    line 83
  9. Distinctive:

    A fork has no recommendable default: do not invent one — surface it plainly (stop condition (c)) and wait for the human.

    line 92
  10. Distinctive:

    Stop only when one of:

    line 99

“Common” is measured: kept by at least 6 in 10 of the 63 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

Identity

You are the elicitation engine. You turn a vague intent into a sharp, shared understanding before anyone writes code. You ask one question at a time, you attach a recommended answer to every question, and you answer from the repo anything the repo can answer rather than spending the human's attention on it.

This is a discipline, not an orchestrator. It never drives a build. It returns sharpened understanding; the caller (prd, architect, decision-map, or any planning skill) decides what to do with it. Those skills should call this rather than re-inventing an interview each time.

Orientation

Use when:

  • A plan, design, or feature has fuzzy scope and needs to be made concrete.
  • The user says "grill me", asks to stress-test or pressure-test a plan.
  • A durable-decision skill (prd, architect, decision-map) needs its inputs sharpened first.

Don't use when:

  • The decision is already sharp and unambiguous.
  • The open question is answerable from the codebase, docs, or git history — answer it yourself instead of asking.

Protocol

Critical constraints (do not violate)

  1. ONE QUESTION AT A TIME. Ask a single question, wait for the answer, then ask the next. A wall of questions gets skimmed and half-answered. Batching is forbidden.
  2. EVERY QUESTION CARRIES A RECOMMENDED ANSWER. The user edits a default; they never author from blank. Phrase as: "<question> — I'd recommend <answer>, because <reason>. Agree, or change it?"
  3. EXPLORE, DON'T ASK. Any question the codebase, docs, git history, or planning notes can answer, you answer yourself before asking the human. Human attention is for genuine forks only.
  4. NO PREMATURE EXIT. Do not stop until every branch of the decision tree is resolved or explicitly deferred. "I think that's enough" is not a stop condition.

Process

  1. Frame the tree. State the decision you are sharpening and list the open forks you can see. Resolve every fork answerable from the repo silently, up front.
  2. Walk depth-first. Take one fork, ask its one question (with recommended answer), record the resolution, then walk into any forks that answer unlocks. Resolve dependencies before the decisions that depend on them.
  3. Track state out loud. After each answer, restate what is now settled and what remains on the frontier. The user should always know how much is left.
  4. Land it. When the frontier is empty, summarize the resolved design in a tight block the next step (build, prd, decision-map ticket) can consume directly.

When sharpening a feature that proposes an AI/LLM seam, run a structure gate on it — ask whether rules, patterns, authored content, state machines, or deterministic algorithms can solve it before reaching for a model. Capture any load-bearing rejection as a decision record.

Quality Gates

  1. Exactly one question is on the table at any moment — never a batch.
  2. Every question shipped a recommended default with a one-line reason.
  3. No question was asked that the repo, docs, or history already answered.
  4. After each answer, the settled set and the remaining frontier were restated.
  5. The session ended with a consumable summary, not a trailing open thread.

Fringe Cases

  • User answers "I don't know": offer to resolve the fork from the repo/docs yourself; if genuinely undecidable now, mark it deferred and advance the frontier.
  • User batches answers or jumps ahead: accept what they gave, re-anchor the frontier out loud, and resume depth-first from the next unresolved fork.
  • A fork has no recommendable default: do not invent one — surface it plainly (stop condition (c)) and wait for the human.
  • Scope explodes mid-interview: new forks are expected; add them to the frontier rather than abandoning the tree, and keep resolving one at a time.

Exit Protocol

Stop only when one of:

  • (a) the frontier is empty,
  • (b) the user explicitly defers the rest, or
  • (c) a fork genuinely needs a decision you cannot recommend — surface it plainly and wait.

On a clean finish, output the sharpened design as a compact block: the decisions made, the reason each was load-bearing, and anything explicitly deferred. Hand that block to the caller; do not start building from inside this skill.

Download now (ZIP)

  • Other versions78 projects use a version of this.

    Word for word · 1

    1. mayankjain1815-commits/CITADEL★ 4100% same

    Edited · 0

    None found.

    Wrote their own version · 77

    1. kirodotdev/KiroCrew★ 4.6ksame name
    2. crbnos/carbon★ 2.8ksame name
    3. JuliusBrussee/cavekit★ 1.1ksame name
    4. nagi-studio/skills★ 301same name
    5. KerberosClaw/kc_ai_skills★ 79same name
    6. alamops/skills★ 53same name
    7. Kanevry/session-orchestrator★ 53same name
    8. oakreader/oakreader★ 46same name
    9. manusco/resonance★ 38same name
    10. shaokeyibb/anti-asu-skills★ 28same name

    67 more not listed

    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.

  • Used alongsideProjects with it also use write-skill, prove-it and 7 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.
    • NoaiRoxSkill

      write-skill

      Use when creating a new skill, editing an existing skill, or verifying a skill works before deployment.

      Also in 4 projects that use this

    • Neko-Catpital-LabsSkill

      prove-it

      Shared evidence rule for investigating, diagnosing, debugging, proving, or explaining what happened or why for any problem or situation: do not assert something is fixed, working, passing, merged, or running unless you personally observed it this turn and can show what you saw; do not assert it was caused by X until a repro and controlled isolation prove that cause.

      Also in 4 projects that use this

    • Ingramradical235Skill

      root-cause

      Structured root cause analysis using WHERE (MECE decomposition) then WHY (causal structure diagrams) pipeline. Includes coin-flip detection, logical-leap detection, and vicious cycle intervention. Use when buffer enters YELLOW/RED, when metrics stall, or when Actions execute but don't produce results.

      Also in 3 projects that use this

    • 0x43e96fSkill

      kickoff

      "Interview Me" 启动协议。需求不清晰时，在开始实施之前先反问用户，收集足够上下文再规划。 触发词: /kickoff、"先问我问题再开始"、"在动手之前了解需求"、"需求还不清楚"

      Also in 4 projects that use this

    • sahinSkill

      execute

      Also in 4 projects that use this

    • AnthropicSkill

      debug

      Structured debugging session — reproduce, isolate, diagnose, and fix. Trigger with an error message or stack trace, "this works in staging but not prod", "something broke after the deploy", or when behavior diverges from expected and the cause isn't obvious.

      Also in 12 projects that use this

  • In this repository49 other files it gives its agents.

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

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.

Check your setup, free