Stop re-litigating decisions you already made.
“Why did we decide that, and why are we arguing about it again?”
A running log where each entry captures the decision, the context, the options, the why, and when to revisit.
What this skill does
Captures a decision the moment it is made, in a form future-you can search and trust. Each entry names the decision, the context that made it necessary, the options on the table, the reason one won, and the condition that should make you revisit it. Six months from now, when someone asks "why is it built this way," the answer is one grep away instead of a debate. It writes one entry at a time and never touches the log without your go-ahead.
Inputs
- Works today with: the decision and the thinking behind it, described or pasted. It produces a clean, structured entry.
- More powerful connected to a repo: it appends entries as numbered markdown files you can grep, diff, and review.
- Sharper with a notes or wiki tool: the log lives where the rest of the project context lives.
- Sharper with a context pack or handoff: decisions logged here feed straight into orientation for the next session.
How it works
- 1The five-field entry (fixed)
Every entry carries exactly these, in order.
- Decision what was decided, in one sentence, stated as done.
- Context the situation and constraint that forced a choice.
- Options considered the real alternatives, including the one you rejected and why.
- Why the reason this option won over the others.
- Revisit when the condition that should reopen this, a date, a threshold, an event.
- 2One entry at a time
Each call gets its own entry. The skill does not batch a week of decisions into one blob. One decision, one greppable record, one number.
- 3Greppable by design
Plain markdown, consistent headings, a stable ID. So
grep routingacross the log finds every decision that ever touched routing, in seconds, forever. - 4Supersede, never erase
When a decision is reversed, you do not delete the old entry. You write a new one that links back and marks the old one superseded. The trail of why-we-changed-our-mind is as valuable as the decisions themselves.
- 5Revisit triggers
Every entry ends with a condition to revisit, not a vague "someday." "Revisit when volume passes 10k/day" is a trigger. "Revisit later" is not.
Output format
DECISION 0007 · Route onboarding by company size · status: accepted
DECISION
New signups are routed to an owner by company-size band, not by persona.
CONTEXT
Persona routing mis-assigned ~1 in 3 signups. The team lost trust in the
queue and started hand-sorting, which defeated the automation.
OPTIONS CONSIDERED
- Persona match (rejected: too noisy, data was sparse on new signups).
- Company-size band (chosen).
- Round-robin (rejected: ignores fit entirely).
WHY
Size band is reliably present on a fresh signup; persona is not. Fewer
inputs, fewer ways to be wrong.
REVISIT WHEN
Persona data coverage on new signups passes ~80%, or volume passes 10k/day.
(draft, not saved. approve to append as 0007 in the log)
Tips
- Nothing is written to the log without your explicit approval. The skill drafts the entry and shows it; you decide if it lands.
- No entry ships without all five fields. An entry with no "options considered" is not a decision record, it is a note.
- A superseded decision is linked, never deleted. History stays intact.
- The revisit condition is concrete, an event or a threshold, not "later."
Turn a cold start into a warm one with one doc.
A single pack that tells a new session or teammate what the project is, where things live, what's decided, and the next move.
Capture the session context so you can resume it cold.
An end-of-session brief: progress, decisions, unfinished items with next steps, and the fragile details, then it asks whether to save.