agentleFS
Sign inStart free
wilbeibiwilbeibi/wilbeibi-skills/skills/grill-me/SKILL.md

grill-me

Skill2 starsChanged 2 months agoMITView on GitHub

Interview the user one question at a time until a plan is resolved, capturing durable decisions in CONTEXT.md or ADRs when the repo warrants it. Use when asked to "grill me," stress-test a design, or challenge assumptions before implementation.

193 other projects use a version of this, 11 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

We split this skill into the rules it gives an agent

10 rules. 0 are common, 6 are distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 177 edited versions we read keep these.

  • 6

    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:

    Read the plan, linked docs, code, or local files needed to understand the topic first.

    line 13
  2. Distinctive:

    Ask one question at a time.

    line 14
  3. Distinctive:

    Follow branches that affect implementation of the current scope.

    line 16
  4. Distinctive:

    If a question can be answered by exploring the codebase, explore instead of asking.

    line 17
  5. Distinctive:

    Stop when the key implementation decisions are resolved.

    line 19
  6. Very specific:

    Only when the repo already keeps CONTEXT.md, CONTEXT-MAP.md, or docs/adr/, or the interview resolves terminology or a decision worth …

    line 32
  7. Very specific:

    Update the appropriate CONTEXT.md as soon as terminology is resolved — it is a glossary and relationship map for project-specific language, …

    line 34
  8. Very specific:

    Use CONTEXT-MAP.md only when the repository has multiple bounded contexts.

    line 35
  9. Very specific:

    Create docs lazily: no CONTEXT.md or docs/adr/ until there is real resolved content, and keep them short enough that future agents actually …

    line 37
  10. Distinctive:

    Stop earlier if the user asks to stop or accepts the remaining recommendations.

    line 44

“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 about a plan or design until the key decisions needed to implement the current scope are resolved.

How to run it

  • Read the plan, linked docs, code, or local files needed to understand the topic first.
  • Ask one question at a time. Wait for the answer before the next question.
  • For each question, state your recommended answer and a one-line why.
  • Follow branches that affect implementation of the current scope; record optional or out-of-scope branches for later. Resolve dependencies between key decisions in order.
  • If a question can be answered by exploring the codebase, explore instead of asking.
  • Push on fuzzy words, hidden assumptions, edge cases, dependencies between decisions, and reversibility.
  • Stop when the key implementation decisions are resolved. Summarize the agreed plan and record remaining non-blocking questions as follow-ups.

Question patterns

  • "What outcome would make this change a success?"
  • "Which existing concept owns this behavior?"
  • "What is the smallest scenario that proves the design works?"
  • "What breaks if this assumption is false?"
  • "What would a future maintainer be tempted to change back?"
  • "Which term should be canonical, and which aliases should be avoided?"

Capturing decisions

Only when the repo already keeps CONTEXT.md, CONTEXT-MAP.md, or docs/adr/, or the interview resolves terminology or a decision worth outliving the conversation. Check for those files before proposing new ones.

  • Update the appropriate CONTEXT.md as soon as terminology is resolved — it is a glossary and relationship map for project-specific language, not a spec or scratchpad.
  • Use CONTEXT-MAP.md only when the repository has multiple bounded contexts.
  • Offer an ADR only for decisions that are hard to reverse, surprising without context, and based on a real tradeoff.
  • Create docs lazily: no CONTEXT.md or docs/adr/ until there is real resolved content, and keep them short enough that future agents actually read them.

For glossary format, read CONTEXT-FORMAT.md. For ADR format and thresholds, read ADR-FORMAT.md.

Notes

  • Preserve the requested one-question-at-a-time format while the interview is needed.
  • Stop earlier if the user asks to stop or accepts the remaining recommendations.
  • Ported from mattpocock/skills (MIT), adapted to this repo's conventions and voice.

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.

Check your setup, free