agentleFS
mayankjain1815-commitsmayankjain1815-commits/CITADEL/skills/grill/SKILL.md

grill

Skill4 starsChanged 4 months 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.

87 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use write-skill, root-cause and 9 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 5 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 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

  • sahinSkill

    execute

    Also in 5 projects that use this

  • assisjpSkill

    file-pr

    Prepare and open or update an authorized pull request with a concise problem-first description and verifiable evidence. Use when the user asks to create, file, open, or update a PR. Do not use merely to review a diff or when publication is not authorized.

    Also in 3 projects that use this

  • Arman-KudaibergenovSkill

    write-plan

    Этот скилл MUST быть вызван когда есть design.md и нужно разбить доработку на атомарные задачи (2-5 мин) с точными путями файлов и критериями проверки в tasks.md. SHOULD также вызывать как промежуточный шаг между brainstorm и subagent-dev. Do NOT использовать для обсуждения идеи — используй brainstorm; для выполнения задач — используй subagent-dev.

    Also in 3 projects that use this

The file

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 68 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 68 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)

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.