Writing briefings

A briefing brings people up to speed, once, on something that happened or is proposed: "here's what we did, what we decided, and what we need from you." It is longer than a chat message and shorter than a report, dated, and read once. After its date it is history: we don't keep it up to date. If people will come back to it to do something, write a guide instead, and let the briefing link to it.

These are patterns that have worked, not rules; use judgment. The shared principles, how to sound like a person and how to make one with AI are in Writing for the team.

What works

• Lead with the point and the ask. A TL;DR of three to five lines that works on its own, then what you need from the reader, or "nothing needed".
• Proposal or situation first. Say what we propose or what has changed before the background. Leave task lists out; link the tracker.
• About five minutes to read, roughly 500 to 800 words. Detail goes behind links.
• Mostly prose. A briefing rarely needs a diagram. Use a picture only when it carries the argument, such as an overview of how the parts fit, not to decorate.
• Date the status. Say "as of" for anything that will change, and check it against the live source before sending.
• One topic. Two topics are two briefings.

Where it goes

briefings/YYYY-MM-DD-<slug>.md, listed on the briefings page. Examples: CRM vision, portfolio.

Skeleton

---
title: "<Topic>"   # no "Briefing:" prefix; the listing already says so
date: YYYY-MM-DD   # drives sorting on the Briefings page
author: <name>
status: draft
---

# <Topic>

## TL;DR
<3–5 lines: what this is, where it stands, what's next.>

## What I need from you
- <ask, or "Nothing needed; for information.">

## <The problem / why>
## <The plan or vision>
## Where it stands (as of <date>)
## What's next
## Open questions
## More detail
- <links to project record, source docs, trackers>