agentleFS
michielvandermeermichielvandermeer/skills/skills/grill-with-docs/SKILL.md

grill-with-docs

Skill9 starsChanged 19 days agoMITView on GitHub

A relentless round-by-round interview to sharpen a plan or design, which also creates docs (ADRs and glossary) as we go.

We split this skill into the rules it gives an agent

1 rule. 0 are common, 0 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 178 edited versions we read keep these.

  • 0

    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. Very specific:

    When the request asks for a /prototype, or a question turns out to need one, run it after the Frontier is empty and before the ending below.

    line 13

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

Bring the checkout up to date first — pull, with submodules — so the facts you declare and the files you edit are current.

Run a grilling session: read grilling/SKILL.md and domain-modeling/SKILL.md and follow both — neither loads as a skill. The glossary entries and ADRs that session produces are yours to write, in this session: /domain-modeling times the glossary entries and states an ADR as a declaration, and an ADR that waits for Spec time is written in the same turn as the Spec.

When the request asks for a /prototype, or a question turns out to need one, run it after the Frontier is empty and before the ending below; its verdict is the last set of declarations, and only a Spec that is written names its folder.

Issues live in the repo's Tracker: carry out each operation on one — file, read, list, rewrite, set status, comment, link, close — as .agents/refs/tracker.md says, or as setup/LOCAL.md says when the repo has no ref.

Once the Read-back is confirmed, take exactly one ending. The confirmed Read-back is the only test — a forecast in an earlier Round is not confirmation.

Change to implement — the settled design still names a change. Read to-spec/SKILL.md and follow it, then retro/SKILL.md — neither loads as a skill. /to-spec rewrites the Issue this session started from into the Spec. A mixed Read-back ("do not build X, do build Y") takes this ending for Y; X is Out of Scope on that Spec.

Work we will not do — the whole settled design names no change. Skip /to-spec. Close the Issue this session started from as not planned, when there is one; Issues filed during the session for branches still wanted stay open. Glossary entries already written stay; write no ADR that was waiting for Spec time. Say that you wrote no Spec because nothing will be built. Then read retro/SKILL.md and follow it — /retro does not load as a 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.