decision-record
Skill3 starsChanged 17 days agoMITView on GitHub
Record why a decision was made, what was excluded, and under what conditions to revisit it — as an ADR that points at the rules rather than restating them. Covers which decisions qualify, why decision categories with different lifecycles get separate numbering spaces, and superseding instead of rewriting. Use when a heavyweight decision has just been settled and the reasoning would otherwise be lost.
6 other projects use a version of this.
Adopted by
Most recently taken up by
- Rome-1/obsidian-claude-startertheir own version, first seen Nov 1, 2026
- migavel508/wisprnote-skillstheir own version, first seen Nov 1, 2026
- TriunaLabs/skillstheir own version, first seen Sep 30, 2026
- murphytrueman/design-system-opstheir own version, first seen Sep 23, 2026
- June74/agentic-workflowtheir own version, first seen Aug 15, 2026
- Throokie/claude-code-skillstheir own version, first seen Mar 24, 2026
Other versions6 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 6
- murphytrueman/design-system-ops★ 197same name
- Rome-1/obsidian-claude-starter★ 5same name
- Throokie/claude-code-skills★ 1same name
- June74/agentic-workflow★ 0same name
- migavel508/wisprnote-skills★ 0same name
- TriunaLabs/skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository15 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- constraint-by-typesSkill
- decision-interviewSkill
- deliverable-languageSkill
- spec-before-codeSkill
- ui-contract-assetsSkill
- ui-contract-auditSkill
- ui-contract-baselineSkill
- ui-contract-designSkill
- ui-contract-enforceSkill
- ui-contract-glossarySkill
- ui-contract-layoutSkill
- ui-contract-setupSkill
- ui-contractSkill
- ui-contract-wireframeSkill
The file
We split this skill into the rules it gives an agent
5 rules. 0 are common, 5 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 4 edited versions we read keep these.
5
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 34
Not every choice earns a file.
- Distinctive: line 37
Real alternatives were excluded: If there was only ever one option, there is no reasoning to preserve
- Distinctive: line 40
If the domain skill that invoked this one grades its own decisions by weight, use that grading: the heavyweight tier gets a record, the …
- Distinctive: line 49
When revisiting the fast category, you would have to re-read every decision — including the slow ones you must specifically not touch
- Distinctive: line 63
If a superseding record must correct a count or a name in several places of the old one, list those places explicitly in the new record.
“Common” is measured: kept by at least 6 in 10 of the 4 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.
Files
Decision record
The authoritative document owns what is currently correct. A decision record owns why it was chosen, what was excluded, and under what conditions to revisit — nothing else.
| Records | Lives in | |
| Rule | What is currently correct | The authoritative document's clauses — the single authority |
| Decision | Why it was chosen then, what was ruled out, when to revisit | The decision record |
An ADR must not restate rules
It never states "what is currently correct", so it is structurally incapable of contradicting the authoritative document. That is precisely what separates it from the separately-maintained decision log that decision-interview forbids: a log restates conclusions and drifts; a record points at them and can't.
Point at a clause. Never copy it.
One exception: judgements the rule's own editor must see
A decision record is the right home for "why" only when whoever needs it will go looking for it. One class of judgement fails that test: the person most likely to re-tread an overturned conclusion is whoever is editing the rule itself, at the moment of editing — and they will not open a second file first.
For that class a domain skill may require an appendix inside the authoritative document — was / became / why overturned — instead of a record. Two conditions, both required:
- The skill declares it. An appendix that is merely tolerated reads as an unmarked violation of "point at a clause, never copy it"; a declared one is a rule with a reason, and the next reader stops trying to fix it
- It records what was ruled out, never what is currently correct. The exception moves where the reasoning lives, not what it may say. An appendix that starts stating current rules has become a second authority — the exact failure this cut exists to prevent
Overturned judgements are easier to re-tread than current ones, precisely because they looked reasonable — they looked reasonable to you too, once. That is why they are never deleted, whichever of the two homes they get.
Which decisions qualify
Not every choice earns a file. Three tests — a decision that passes all three qualifies:
- Hard to reverse. Undoing it means reworking things that were built on top of it
- Real alternatives were excluded. If there was only ever one option, there is no reasoning to preserve
- It has a revisit condition you can name. "If X turns out to be false, this should be reopened"
If the domain skill that invoked this one grades its own decisions by weight, use that grading: the heavyweight tier gets a record, the rest live as clauses only.
Separate numbering spaces for categories with different lifecycles
Decisions of genuinely different kinds do not belong in one incrementing sequence. The test is lifecycle: who makes them, how often they are revisited, and what it costs to overturn one.
Two concrete consequences of mixing them:
- A burst of five decisions from one fast-moving category buries two from a slow-moving one
- When revisiting the fast category, you would have to re-read every decision — including the slow ones you must specifically not touch
The harder evidence: supersede only ever happens within a category. A decision of one kind never supersedes a decision of another kind. If the supersede relation doesn't cross the boundary, the numbering space shouldn't either.
So: one directory per category, each incrementing independently. Cross-category references are allowed, but reference the number only, never restate the content.
Which categories exist is the domain skill's call, not this one's — but the boundary must come from a distinction the project already has, not a new one invented for filing purposes.
Supersede, never rewrite
An accepted record is not edited. When a single decision inside it is overturned, write a new record that supersedes that decision and says so in its header. The old file stays exactly as it was.
Rewriting destroys the one thing the record was for: knowing what was believed, and when.
If a superseding record must correct a count or a name in several places of the old one, list those places explicitly in the new record. Leave the old text alone.
Shape
A record carries: status and date; what it relates to and what it supersedes; the background that made the decision necessary; the decision itself; the alternatives excluded and why; the costs knowingly accepted; and the revisit conditions.
The excluded-alternatives section is the one people drop, and the one that pays. Six months on, the question is almost never "what did we decide" — it is "did we already think about X".
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.

