exec-brief git:20260925.a486f3fA

Immutable. This exact content never changes and is served at /api/v1/blob/53e0a2d41aca5b5f.

---
name: exec-brief
description: Boil a long email thread, chat, status report or document down to what a senior reader needs — one bottom-line sentence, at most three points, and the one thing you need from them — ready to paste into Outlook or Teams. Use when the user has to brief a manager, director or exec, asks for "the short version", a BLUF, a TL;DR for their boss, or wants to know what to send upward from a thread they've been copied on. Not a summary: it cuts everything that doesn't change what the reader does, and it never firms up a date, a figure or a cause the source leaves open.
---

# Exec brief

A long thread already contains the news. It is buried under chronology, who-said-what, an
argument that got settled, and a cheerful last message. This digs it out and writes it the way
a director reads: one sentence, three points, one ask.

**The product is the cut.** Anyone can summarise. Returning forty words and leaving out thirty
true things is the hard part, and the only reason someone uses this instead of forwarding the
thread. **Its twin is fidelity:** the brief goes upward with the sender's name on it, so a
"likely" that becomes "will" is a promise they never made.

## Workflow

### 1. Take the source as given

A pasted email thread, Teams chat, status report, memo or document — or a file (`.txt`,
`.md`, `.eml`, `.docx`, `.pdf`). Threads arrive reverse-chronological, with quoted replies
repeating earlier messages and signatures in between. Read them oldest first, once each.

Number the messages or sections as you read them (`M1…`, `§2 ¶3`) — the trace needs the
locator.

**Ask nothing unless genuinely blocked.** At most two questions, and only these:
- Several unrelated subjects, none dominant → *"This covers X, Y and Z — which one is the
  brief about?"*
- The source is clearly truncated → say so, ask whether to proceed on the partial.

Never ask about audience, tone or length. The reader is one level up by default. Draft first.

### 2. Find the latest true state

Read `references/what-to-keep.md` and apply it. Before choosing anything, establish **the
state as of the last message**: a later figure supersedes an earlier estimate, a reversed
decision is gone, a settled argument is settled. The brief reports where things stand, never
how they got there.

### 3. Choose the BLUF, the ask, then the points — in that order

The reference carries the BLUF test, the ranked keep tests, the always-cut table, the
refuse-to-say table and the closed list of `Check before sending` triggers. Those are the
skill; do not improvise them.

- **BLUF** — the one sentence the reader needs if they read nothing else. Bad news leads.
- **Ask** — what the reader must do, with the date the source gives. If the source asks them
  nothing, the answer is *No ask — for information.* Never manufacture one.
- **Points** — at most three, each earning its place by changing what the reader would do or
  say. A point that restates the BLUF or the ask is cut.

### 4. Write it and stop

```markdown
**The Leeds switchover is likely to slip three weeks to 16 Mar, and releasing £22k from contingency needs your sign-off by Wed 11 Feb.**

- P1 The new date holds only if the second load test passes on 3 Mar — the supplier won't commit before then.
- P2 £22k covers 11 extra supplier days at £2,000/day; no other budget line moves.
- P3 Without sign-off by 11 Feb the supplier releases our March slot; the next one is May.

**Ask:** Approve the £22k contingency release by Wed 11 Feb.

**Check before sending:** M9 puts the switchover weekend on 21–22 Mar, which doesn't fit a 16 Mar date — confirm with Amir.

Ask "where does P2 come from?" or "why did you leave out X?" to see the source behind any line.
```

(Invented example. The source's reasons, history and side topics are all absent — that is the
product, not an omission to apologise for.)

- **BLUF** in bold, ≤ 30 words. **Points** `P1–P3`, ≤ 25 words each. **Ask** one action.
- `Check before sending` appears **only** when a trigger in the reference fires; otherwise the
  line is omitted entirely.
- The fixed trace line ends the output, and nothing follows it.

Output lands in chat as copyable markdown. Write a file only if asked. No subject line, no
greeting, no sign-off unless asked — the user pastes this into their own message.

## Rules

- **The cut is the product.** No background paragraph, no chronology, no "context", no list
  of who was involved, no closing offer. If it doesn't change what the reader does, it isn't
  in the brief.
- **Three points is a ceiling, not a target.** Two true points beat three with padding. A
  source with one piece of news gets a BLUF, an ask and no points.
- **Never firm anything up.** Keep the source's certainty word-for-word in spirit: *likely*,
  *if*, *subject to*, *estimate*, *target* survive into the brief. A condition on a date
  travels with the date.
- **Never soften or bury bad news.** If the thread's news is a slip, an overspend or a
  failure, the BLUF says so first — however upbeat the last message is.
- **Never supply a cause.** Causes come from the source, attributed. A cause someone
  *guessed* in the thread is not a cause; leave it out or call it a guess. *"Root cause not
  yet known"* is a legitimate point when the reader will ask.
- **Figures as the source states them** — its latest version, its precision, its unit. No
  rounding that changes what a reader would repeat. No figure the source doesn't contain.
- **Never invent an ask, an owner or a deadline.** *No ask — for information.* is a complete
  answer. A request that needs a date the source doesn't give keeps "no date given".
- **Don't take sides in a settled argument.** Resolved blame, disagreements and rejected
  options are history. A rejected option returns only if the reader would otherwise propose
  it — and then as rejected, with the reason the source gives.
- **Short source, short brief.** If the source is already under about 80 words, return a
  BLUF and the ask, no points. The brief must never be longer than the source.

## Tracing

A brief is short by construction, so every doubt is about what it left out or how it phrased
what it kept. Read `references/tracing.md` before answering any follow-up: it carries the
handles (`BLUF`, `P1–P3`, `Ask`, `Check`), the fixed closing line, the trace block (*Source ·
Why it made the cut · Fidelity · What would change it*), the omission block, and the questions
to expect — *"why did you leave out X?"*, *"you made it sound worse than it is"*, *"the thread
said £15k"*, *"why is that the ask?"*, and above all *"why did it slip?"* — which gets only
what the source states, quoted, or *"the thread doesn't say."*

A trace re-reads the source and **corrects the brief**: a point that doesn't survive is
replaced, a firmed-up date gets its condition back, a missed ask is added — each said first.