Decision Memos skill for Codex

A decision memo works when the decider can say yes or no after one read, the strongest alternative is represented fairly enough that its advocate would sign off on the description, and the costs of the recommendation are stated as plainly as its benefits. If the memo cannot be summarised as “decide X by Y; we recommend Z because W”, it is not ready.

Before writing

1. Name the decision as a question with a yes/no or a choice: “Should we move support to 24/7 coverage in Q1?” not “Support coverage”.
2. Name the decider (one person) and the deadline, and what happens if no decision is made by then. If there is no decider, find one before writing.
3. Collect evidence: data, customer quotes, costs, constraints. Read related docs in the repo or folder (previous memos, ADRs, metrics). Mark gaps rather than guessing.
4. Talk to (or read the arguments of) people who favour other options. A memo that ignores the best counter-argument will be stalled by it.

Format choice

Situation	Format
Most decisions, reversible, one team	One-pager (template below)
Large, cross-functional, hard to reverse	Narrative memo up to six pages, read silently at the start of the meeting
Purely technical architecture choice	ADR (see architecture-decision-records)
Comparing vendors after an evaluation	Recommendation memo from the vendor-evaluation output
Requesting budget or headcount for a new initiative	Business case (see proposal-writing)

One-pager template

# Decision: <question>
**Decider:** <name> | **Decide by:** <date> | **Author:** <name> | **Status:** draft / in review / decided
**Recommendation:** <option> - <one-sentence reason>
**Cost / impact:** <money, people, time; what we stop doing>
**Reversibility:** two-way door (cheap to undo by <how>) | one-way door (<why hard to undo>)

## Context
<3-6 sentences: what is happening, why now, what we know (with numbers), what we do not.>

## Options
| | A. Do nothing | B. <option> | C. <option> |
|---|---|---|---|
| <criterion 1, e.g. customer impact> | | | |
| <criterion 2, e.g. 12-month cost> | | | |
| <criterion 3, e.g. time to effect> | | | |
| <criterion 4, e.g. risk> | | | |

## Recommendation and trade-offs
<Why this option wins on the criteria that matter most. What we give up. Who is worse off.>

## Risks and mitigations
- <risk> -> <mitigation, owner>

## What would change this recommendation
<Specific evidence or events, e.g. "if pilot churn exceeds 5%", "if vendor price rises above $X".>

## If approved, next steps
| Step | Owner | Date |
|---|---|---|

Writing rules

• Bottom line up front. The first five lines carry the decision, the recommendation and the cost.
• Always include “do nothing” (or “keep current plan”) as an option, with its real cost. Doing nothing is rarely free.
• Criteria come before the comparison and reflect what the decider values. Agree them with the decider in advance for contentious topics.
• Numbers over adjectives: “adds $180k/year and 2 hires”, not “a significant investment”. Give ranges when uncertain and say where each number came from.
• Steelman the alternatives. If a colleague prefers option C, describe it in a way they would accept, then explain why B still wins.
• State who loses: which team, customer segment or project bears the cost.
• Separate facts, estimates and opinions in wording (“data shows”, “we estimate”, “we believe”).
• No hedging stack (“it may potentially be possible that”). One qualifier, or none.
• One page means one page; move supporting analysis to an appendix with links.

Narrative memos (up to six pages)

For large decisions, prose forces clearer reasoning than slides. Structure:

1. Purpose and the decision requested (first paragraph)
2. Background and the customer or business problem, with data
3. Tenets or principles guiding the decision (optional, short)
4. Options considered and how they compare
5. Recommendation, plan, costs and risks
6. Open questions
7. Appendix: data, detailed financials, FAQs anticipating reviewer questions

Readers read silently at the start of the meeting and annotate; the author answers questions after. Write so a reader with no context can follow.

Pre-mortem check

Before finalising, write two or three sentences answering: “It is a year later and this decision failed. What most likely happened?” Add any credible failure path to risks with a mitigation or an early warning signal.

Reviewing someone’s memo

Report, in order:

1. Can you state the decision, recommendation and cost from the first five lines? If not, rewrite the opening.
2. Is “do nothing” present and costed?
3. Are criteria explicit, and does the recommendation follow from them?
4. Is the strongest alternative described fairly?
5. Are numbers sourced? Are any claims unsupported?
6. Are reversibility and “what would change our mind” stated?
7. Length: cut anything the decider does not need to decide.

Give specific rewrites, not general advice.

After the decision

Record the outcome in the memo header (decided, by whom, date, option chosen) and in a decision log so it is not reopened without new information:

| Date | Decision | Decider | Option chosen | Memo link | Revisit if |
|---|---|---|---|---|---|

Circulating the memo or decision to a wider audience is the user’s call; draft the announcement but do not send it.

Gotchas

• Writing the memo to justify a decision already made, with straw-man alternatives. Reviewers notice, and trust erodes.
• Mixing several decisions in one memo. Split them, or sequence them explicitly.
• Burying the cost in the appendix.
• No deadline, so the decision drifts while the cost of waiting grows unstated.
• Treating every decision as one-way. Most are reversible; say so and decide faster.

Output

The memo (one-pager or narrative), a short list of open questions or missing data, and, for a review, a prioritised list of rewrites with suggested text.