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.
In this repository9 other files it gives its agents.
- absorbSkill
- agent-starterSkill
- aim-before-buildSkill
- converge-planSkill
- evidence-auditSkill
- goal-contractSkill
- harness-auditSkill
- morning-briefSkill
- phase-loopSkill
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
- Distinctive: line 13
Never hand over a blank: Every question ships with a recommended answer and its reason.
- Very specific: line 23
Write docs/status/DECISIONS-<topic>.md (project root if docs/ is absent):
- Very specific: line 42
When nothing is open, prepend a summary table (decision · evidence · reversal cost) to the same file.
- Very specific: line 55
Use converge-plan when a decision is expensive and still uncertain, goal-contract when the spec is settled and the work spans multiple …
≈ “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.
Files
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
- Confirm this is pre-build work. If code already exists, use
aim-before-buildinstead. - Scout the codebase for facts. Each fact becomes a confirm-only row.
- Write
docs/status/DECISIONS-<topic>.md(project root ifdocs/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:- 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. - 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
| Signal | Meaning | Action |
| Most answers blank | Recommendations fit | Proceed to round 2 |
| Over half changed | The plan was misread | Re-read before round 2 |
More than five ? | Not ready to decide | Run converge-plan first |
| Questions are all taste | Reversal-cost sort was skipped | Rewrite 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.
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
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.

