---
title: "Narrative decision memo writer"
type: "skill"
url: "https://useaiblocks.com/skills/narrative-decision-memo-writer"
updated: "2026-10-28"
first_published: "2026-10-25"
job: "Write down how work gets done"
tested: true
licence: "MIT"
source: "https://github.com/magnus919/agent-skills/tree/92c327e525da69c9ad3812fd223a1770e977c2e3/amazon-memo"
instructions: "https://useaiblocks.com/skills/narrative-decision-memo-writer/SKILL.md"
---

# Narrative decision memo writer

> Turn a decision and your evidence into a clear memo with options, costs, risks and a review plan, as a decision narrative, a PR/FAQ or a short brief.

Share the decision, the reader, your evidence and your limits. The skill picks a short brief, a full narrative or a future-product question document. You get connected prose that keeps choices, costs, risks and gaps in view. It is adapted from a public MIT-licensed source on Amazon-style writing, not official Amazon templates.

Free skill for the job "Write down how work gets done" · Level: intermediate · Thinking: high · Tested · Updated 2026-10-28

## Links

- Page: https://useaiblocks.com/skills/narrative-decision-memo-writer
- Instructions (SKILL.md): https://useaiblocks.com/skills/narrative-decision-memo-writer/SKILL.md
- All files (zip): https://useaiblocks.com/skills/narrative-decision-memo-writer.zip
- JSON version: https://useaiblocks.com/skills/narrative-decision-memo-writer.json
- In your AI: connect https://useaiblocks.com/mcp and ask "Use AI Blocks to get narrative-decision-memo-writer"

## What it does

It routes your request to one of three forms. A decision narrative fits a strategy, spending or staffing choice. A PR/FAQ fits a new product or service, written backwards from the customer's gain to the hard questions. A short brief fits a narrow question with little context. It adds the one sentence on why it chose that form. This copy is under the MIT licence (the LICENSE.md file in this item), written by Magnus Hedemark.

## What you give it

- The reader and the person who will decide.
- The decision to make and the deadline.
- Your evidence, with where it came from.
- The options, including doing nothing.
- Known costs and limits (optional).
- Your own draft to revise (optional).

## What you get

- A decision memo or short brief in connected prose.
- A one-sentence reason for the form it chose.
- A list of assumptions and evidence gaps.
- A small test with an owner and review date, when evidence is thin.
- A review plan with the decision owner and the questions to settle.
- Sections you can expect: summary, options, costs, risks, gaps and review plan.

## Example: what goes in and what comes out

### What goes in

- The reader and the decision owner
- The decision to make, and the deadline
- Your evidence, with sources and dates
- The options you see, including doing nothing
- Known costs and limits (optional)

### Before you start

- A chat AI that can read the skill's reference and template files

### What comes out

- **Form choice**: One sentence on which form fits: short decision brief, decision narrative, or PR/FAQ, and why.
- **Memo or brief**: The problem, the baseline, the options, the proposal, costs and risks, written as connected prose. Parts by form: the decision narrative has all of these plus next checkpoint and evidence appendix; the PR/FAQ has a future press release, customer FAQ and internal FAQ; the short brief has ask and owner, context, options, recommendation and next step.
- **Assumptions and evidence gaps**: What is fact, what is assumed, and what is missing, with how each gap affects the decision.
- **Test or checkpoint**: When evidence is thin, a small proposed test with scope, owner, review date and what to inspect.
- **Review plan**: The decision owner, how the memo will be read, the questions to settle, and where the outcome is kept.
- **Revision notes**: For a revision, a short list of what changed in the reasoning and why.

## Use it when

- You must ask a leader to choose between two or more options.
- You have notes and data but no clear written case.
- A draft memo reads flat or mechanical and needs better reasoning.
- You want a plan for how a team will read and decide on it.

## Skip it when

- You need an architecture decision record or an incident write-up: use the Decision record writer for an architecture decision, or the Incident postmortem writer for an outage.
- You need setup steps, runbooks or instructions: use the Incident runbook writer or the Developer docs writer, or write the steps as a plain checklist.
- You still do not know if customers want it: do the problem and demand research first, because a polished memo cannot supply missing evidence.

## How to use it

1. Download the skill folder. Your AI needs to read its reference and template files. Or paste the instructions into a chat.
2. Tell your AI the reader, the decision owner and the deadline. A good first message puts it all in one go, for example "Memo for the leadership team. Owner is the head of operations. Decision needed by Friday. Should we move support to a new help desk tool? My evidence is below."
3. Paste your evidence and options. Say which are facts and which are guesses.
4. Read the form choice first. Ask for a different form if it misses.
5. Check the gaps list. Fill what you can, or keep the proposed test.
6. Ask for the review plan, then send the memo yourself. The skill does not send or schedule anything.
7. Once the decision is made, file the memo where your team keeps decisions, and put the review date from the plan in your calendar. If the decision is later reversed, add a short note to the memo saying what changed and why.

## What to do next

- [Weekly status update writer](https://useaiblocks.com/prompts/weekly-status-update-writer): Weekly status update writer

## Sources and credits

- From Magnus Hedemark: https://github.com/magnus919/agent-skills/tree/92c327e525da69c9ad3812fd223a1770e977c2e3/amazon-memo, shared under the MIT licence (original name: amazon-memo).
- [amazon-memo skill](https://github.com/magnus919/agent-skills/tree/92c327e525da69c9ad3812fd223a1770e977c2e3/amazon-memo), Magnus Hedemark: Copied under the MIT licence. We gave it a plain name and replaced the source repo's other skill names in When not to use with the AI Blocks items to use instead. We added Before you start and After this sections that link to other AI Blocks steps.

## Instructions (SKILL.md)

## Amazon Memo

Help a reader understand a problem, challenge the reasoning, and make or record a
decision. Narrative means connected reasoning in prose, not decorative storytelling.
Amazon's conventions are a useful starting point; respect the receiving team's own
written culture. These are original scaffolds, not official Amazon templates.

<!-- needs: written by tools/add-needs.mjs for AI Blocks; not part of the original skill. Edit that tool, not this section. -->
### Before you start
Use the material below to do this job. If facts or tool access are missing, explain what you can finish and what must wait.

**What you need** (use your own material or the linked skill):
- **Your question** (yours): the decision or problem, and what a good outcome looks like.

**Makes it better (optional):**
- **Source text** (yours): a long source in full: an article, a video or talk transcript, or notes from a book, with its title, author and link.
- **A document** (yours): a finished document, such as a Word file, a PDF or a page of notes.

How to start:
1. **Look first.** Use what they've already attached, pasted or put in their about-me note. In a coding assistant with file access, look in the project too for these by name.
2. **Check what's missing.** Look for your question, source text, a document. They can attach files, paste the details, or share a file path your assistant can read. Ask only for missing facts that change the result. If they ask you to start with what they have, complete the parts you can and mark the gaps.
3. **Do the job.** Follow the skill below with the facts and tools you have. Mark each gap with `MISSING:` where it belongs and never invent a fact to fill it.

**Tools that do this best:**
- **A chat AI that can read the bundled reference files:** Use the supplied references and templates for the chosen task. Scripts are optional unless that task specifically needs them.
<!-- /needs -->

### When not to use

- Use the Decision record writer for durable architecture decisions and the Incident
  postmortem writer for incident analysis. Add an executive cover memo only when useful;
  retain the underlying artifact's structure and evidence.
- Use the Incident runbook writer or the Developer docs writer for instructions and runbooks.
  General manuscript craft and rendered office files are out of scope for this skill.
- When the missing work is understanding the problem or testing demand, do that research
  first. A polished memo cannot supply that evidence.
- (AI Blocks note: the original named its own repo's skills here, such as `adr-authoring`,
  `incident-learning`, `technical-documentation`, `writers-helper`, `documents`,
  `product-discovery` and `product-methodology`. We replaced them with the AI Blocks items
  above, since those skills are not on this site.)

### Workflow

1. **Establish the reading contract.** Identify the reader, decision or learning
   goal, decision owner, deadline, known local conventions, and meeting length or
   async window. Use supplied context before asking. If a missing detail changes
   the recommendation, ask one focused question; otherwise state a reasonable
   assumption and draft. Do not turn intake into an interview by default.
2. **Choose and explain the form in one sentence.** Respect an explicitly requested
   artifact; explain a mismatch and offer a better fit without silently substituting.
   Use the routing table below. Read [form and length guidance](references/forms-and-length.md)
   when choosing between forms, planning pages, or adapting to another organization.
3. **Build the argument before polishing.** State the customer or stakeholder problem,
   relevant baseline, credible alternatives (including continuing as-is), proposed
   mechanism, costs, risks, uncertainty, and what decision is needed. Separate observed
   facts, assumptions, forecasts, and invented illustration. Keep citations near claims;
   identify missing denominators, dates, costs, or sources instead of inventing them.
   Preserve contradictory findings and explain what they change. With sparse evidence,
   propose a bounded test or conditional decision rather than a confident rollout.
   For a test, specify proposed scope, duration or review date, owner, and outcome
   evidence to inspect. Label unsupplied dates and thresholds as proposals; do not
   leave the checkpoint as an indefinite request for more evidence.
4. **Draft for this audience.** Load only the selected template. Use paragraphs to
   connect evidence to consequences. Use headings, compact tables, lists, charts,
   and appendices when they reduce reader effort; do not turn slides into bullet walls.
   Define specialist terms for unfamiliar readers and retain precise terms for experts.
   Keep decision-critical caveats in the body. Templates are starting points; omit
   irrelevant headings and add what the decision actually needs.
5. **Revise for human reading.** Read [the revision tests](references/readability-review.md)
   for every draft or revision. Run the argument, evidence, paragraph, and read-aloud
   passes. Preserve the writer's voice and legitimate technical language. Revise actual
   reasoning and sentences; do not use banned-word lists, fixed sentence lengths,
   made-up readability scores, or synonym swapping as a substitute for judgment.
6. **Design review and closure.** For a meeting or async review, read
   [reading and decision practices](references/review-practices.md). Name the decision
   owner, reading arrangement, questions to resolve, and where the outcome will live.
   Allow dissent; do not manufacture consensus. Writing a memo does not authorize
   sending it, publishing it, or scheduling a meeting.

### Form routing

| Main reader need | Default form and reason | Load when drafting |
|---|---|---|
| Choose a strategy, resource allocation, staffing plan, or operating change | Decision/strategy narrative: compare choices and consequences | [Narrative template](templates/decision-narrative.md) |
| Explore a future customer experience, product, service, or process | PR/FAQ: work backwards from value to hard feasibility questions | [PR/FAQ template](templates/pr-faq.md) |
| Decide a narrow, bounded question with limited context | Short decision brief: keep decision overhead proportionate | [Brief template](templates/short-brief.md) |
| Inspect operating results, learn from an incident, approve technical design, or execute a procedure | Retain the business-review, incident, design, ADR, or procedure form; add narrative rationale where useful | [Form boundaries](references/forms-and-length.md) |

### Non-negotiable distinctions

- **Six pages is a ceiling, not a requirement.** Amazon's 2024 shareholder letter
  is reported to describe a maximum six-page narrative (the link is in references/sources.md; check it before you quote it); do not pad two pages of substance to six.
  Local rules may differ. No universal font, word count, or heading sequence is established here.
- **A press release is not the whole PR/FAQ.** The future release states customer
  value; customer and internal FAQs test the proposal. Mark all imagined quotes and
  future claims as hypothetical. Never present them as testimony or shipped capability.
- **Page estimates are not pagination.** Markdown cannot prove a rendered page count.
  If actual compliance matters, declare paper size, font, margins, spacing and appendix
  treatment, then render and inspect. Never shrink type or move essential risks out
  of the body to make the count fit. Label unrendered lengths as estimates.
- **Recommendations are not corporate rules.** Read [sources and claim boundaries](references/sources.md)
  when explaining provenance or making claims about a company's practices. Attribute
  practitioner guidance. Independent written cultures are not presumed Amazon adoptions.
- **Persuasiveness must preserve truth.** If asked to make a weak case sound certain,
  strengthen the reasoning and state the gaps. Do not inflate demand, suppress
  counterevidence, invent numbers, or conceal uncertainty.

### Supporting material

Read [synthetic worked examples](references/synthetic-examples.md) when the user
needs an illustration or the draft suffers from inflated claims or abstract prose.
Every example is invented and generic. Do not reuse personal, client, interview,
or confidential material in public examples.

### Completion and exit conditions

Deliver the requested draft or revision, a brief form rationale when relevant,
material assumptions and evidence gaps, and the review/decision arrangement if
requested. Report actual pagination status honestly. For a revision, briefly explain
the substantive changes rather than claiming an objective style score.

Stop when the artifact supports its stated reading and decision goal. If evidence
cannot support the requested conclusion, deliver a qualified draft or an evidence
request with the consequence for the decision. After two non-converging revision
passes, name the unresolved audience or argument choice instead of endlessly polishing.

<!-- next: written by tools/add-needs.mjs for AI Blocks; not part of the original skill. Edit that tool, not this section. -->
### After this
When you've handed it back, suggest what they could do next in one short question. It's a suggestion: if they're done, that's fine. Offer these, and say they can type their own:
- The [Weekly status update writer](https://useaiblocks.com/prompts/weekly-status-update-writer). It takes the document.
If they pick one and that skill is added here, carry straight on with what you just made. If not, give the link and say what to bring.
<!-- /next -->
