agentleFS
Jason-hub-starJason-hub-star/model-orchestrator/skills/decision-sheet/SKILL.md

decision-sheet

Skill0 starsChanged 2 months agoMITView on GitHub

Turn an ambiguous plan into a decided spec before implementation by writing one question file where every question already carries a recommended answer, so the user only edits what is wrong. Use for “interrogate this plan”, “what do we need to decide”, “make this a spec”, “그릴미”, or any pre-build request where the target is still fuzzy. Not for code that already exists and needs fixing.

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 1 is distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Never hand over a blank: Every question ships with a recommended answer and its reason.

    line 13
  2. Very specific:

    Write docs/status/DECISIONS-<topic>.md (project root if docs/ is absent):

    line 23
  3. Very specific:

    When nothing is open, prepend a summary table (decision · evidence · reversal cost) to the same file.

    line 42
  4. Very specific:

    Use converge-plan when a decision is expensive and still uncertain, goal-contract when the spec is settled and the work spans multiple …

    line 55

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

Decision Sheet

A file-round-trip variant of Matt Pocock's grill-me interview. The original asks one question at a time in chat and needs the user present for the whole session; this stage writes all questions at once, pre-fills a recommended answer for each, and treats an empty answer as agreement. The user's job is editing, not writing.

Principles

  • Read the code before asking. Anything answerable from code, docs, or commits is not a question. It becomes a "confirm only" row with a file path as evidence.
  • Never hand over a blank. Every question ships with a recommended answer and its reason.
  • Close upstream decisions first. A decision whose answer changes the downstream questions is upstream. Round 1 asks 10–15 upstream decisions; round 2 asks the 25–35 downstream ones with round 1 fixed.
  • Sort by reversal cost. Expensive-to-undo decisions (names, public surfaces, storage formats) come first; taste comes last.
  • Visual choices need a comparison artifact. Colors, type, and layout asked as text produce fake agreement; attach a rendered comparison instead.
  • Done means zero open items, not a question count.

Workflow

  1. Confirm this is pre-build work. If code already exists, use aim-before-build instead.
  2. Scout the codebase for facts. Each fact becomes a confirm-only row.
  3. Write docs/status/DECISIONS-<topic>.md (project root if docs/ is absent):
# Decisions — <topic> · round 1
> Leave the answer blank if the recommendation is right. Move the [x] to change it; two checked boxes count as unresolved.

## R1-01 · <area>  [upstream]
Q. <one-line decision>
- [x] <recommended> ← recommended. Evidence: `path/file.ts:41`
- [ ] <alternative A>
- [ ] <alternative B>
Answer:

## R1-02 · confirm only  [answered by code]
<what the code already does> (`path/file.ts:12`)
Leave blank to keep it; write here to change it:
  1. When the user replies, read the file. Blank = recommendation adopted. ? = unresolved: dig further or propose the cheapest experiment. A changed answer reopens its downstream branch, and the known cost of that choice is written next to it so the next session does not rediscover it.
  2. When nothing is open, prepend a summary table (decision · evidence · reversal cost) to the same file. That file is the spec draft; do not write a second document. Archive it once the work ships.

Reading the result

SignalMeaningAction
Most answers blankRecommendations fitProceed to round 2
Over half changedThe plan was misreadRe-read before round 2
More than five ?Not ready to decideRun converge-plan first
Questions are all tasteReversal-cost sort was skippedRewrite the questions

Next

Use converge-plan when a decision is expensive and still uncertain, goal-contract when the spec is settled and the work spans multiple turns, or implement directly for a small reversible change.

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.