← Back to the library
Thinking and decisions

Decision record

Turn supplied discussion into a decision record with status, rationale, alternatives, consequences, owners, and a practical glossary.

Works with the context you provideVersion 1.0.0

Record a business decision and its unresolved edges

Use only information supplied in the conversation and this skill text. Do not browse, call tools, inspect files, execute code, create artifacts, or take external actions. Return the work directly in chat. Attribute material claims to supplied source labels or quotations; a pasted URL is a source label, not evidence that its contents were checked. Distinguish supplied facts, reasonable interpretations, proposals, and unknowns.

Inputs and scope: Use the discussion, decision question, participants, dates, source labels, existing record if updating, and evidence of agreement. Do not infer acceptance from a recommendation or silence. If a decision-changing input is absent, ask the smallest useful question and complete the portions supported by available material. State assumptions explicitly; do not manufacture facts, approvals, dates, or completion evidence.

Method 1. Identify the concrete choice and its business context. A reversible or unsurprising decision can still deserve a record when it affects coordination, responsibility, or future interpretation. 2. Separate what was decided from what was discussed, proposed, deferred, rejected, or remains disputed. Use an explicit status and distinguish the decision date from the date the record is drafted. 3. Capture the rationale, supporting evidence, constraints, and alternatives considered, including the reason each was not selected. Avoid retrofitting a cleaner argument than the supplied discussion supports. 4. Record consequences, affected parties, obligations, owners, review triggers, and open questions. Attribute responsibility only where assigned; label a suggested owner as proposed. 5. Resolve terminology with a short glossary when ambiguity affects execution. Preserve common customer vocabulary and aliases; show contextual meanings and test them against a realistic scenario rather than imposing new jargon. 6. When updating an existing record, identify the changed decision, new evidence, and superseded portions. Preserve historical context and unresolved disagreement; do not backdate an inferred choice or claim durable persistence.

Output: Return title, status, context, decision, rationale, alternatives, consequences, owners and dates when supplied, open questions, review trigger, source notes, and glossary if useful.

Quality checks: Verify that acceptance, attribution, dates, and consequences are evidenced. Keep proposals visible, avoid invented sequential record IDs, and distinguish a substantive change from a wording clarification.

Worked example: A team agrees to trial weekly invoice batching for one month, while the finance lead wants daily handling for overdue accounts. Record an accepted trial with that exception and a month-end review; do not describe weekly batching as permanent policy. Define 'overdue' using the supplied payment terms, or mark its definition unresolved if terms are absent.