Drafting for Readers
Overview
Every piece of business writing exists to save the reader time. Draft with the reader's payoff in view, not your own process. For status updates or leadership updates specifically, use the team-communications skill instead — it already owns that format.
Iron Imperative
Before writing, ask: what does the reader need to decide or do, and what's the fastest path to it? Treat their time as more valuable than yours.
ROAM
Reader, Objective, Audience-knowledge, Message — infer before drafting. Tier by container (see containers.md):
- Full block (RFC, postmortem, report, press release): write all four out.
- One line (email, escalation, review & feedback, blog): infer, state in one line.
- Silent (standup, social): infer, don't surface.
- Any tier: if reader or objective can't be inferred, ask — don't assume.
Point, support it, then stop
State the point first. Support it. Stop. Don't restate the point, and don't add a closing summary paragraph the reader didn't ask for.
Never invent specificity
If a name, cause, commitment, or reviewed-content detail isn't in your source material, don't manufacture one. Flag it explicitly — a bracketed placeholder, an inline "to be confirmed" — for:
- people you weren't given names for
- causes or attribution you weren't given a reason for
- commitments made on someone else's behalf
- claims of having reviewed content you weren't shown
This applies in long-form writing too: an invented project-phase breakdown or impact figure is exactly as fabricated as an invented name, even though it reads as narrative.
See containers.md for the recipe per document type.
1---2name: drafting-for-readers3description: Use when drafting any business document for an engineering-management audience — reports, RFCs, ADRs, design docs, postmortems, review feedback, emails, escalations, standup or daily/cadence updates, blog posts, social posts, or press releases — before or while writing the first draft. Not for status/leadership updates — use team-communications for those.4---56# Drafting for Readers78## Overview9Every piece of business writing exists to save the reader time. Draft with the reader's payoff in view, not your own process. For status updates or leadership updates specifically, use the `team-communications` skill instead — it already owns that format.1011## Iron Imperative12Before writing, ask: what does the reader need to decide or do, and what's the fastest path to it? Treat their time as more valuable than yours.1314## ROAM15Reader, Objective, Audience-knowledge, Message — infer before drafting. Tier by container (see `containers.md`):16- **Full block** (RFC, postmortem, report, press release): write all four out.17- **One line** (email, escalation, review & feedback, blog): infer, state in one line.18- **Silent** (standup, social): infer, don't surface.19- **Any tier:** if reader or objective can't be inferred, ask — don't assume.2021## Point, support it, then stop22State the point first. Support it. Stop. Don't restate the point, and don't add a closing summary paragraph the reader didn't ask for.2324## Never invent specificity25If a name, cause, commitment, or reviewed-content detail isn't in your source material, don't manufacture one. Flag it explicitly — a bracketed placeholder, an inline "to be confirmed" — for:26- **people** you weren't given names for27- **causes or attribution** you weren't given a reason for28- **commitments made on someone else's behalf**29- **claims of having reviewed content you weren't shown**3031This applies in long-form writing too: an invented project-phase breakdown or impact figure is exactly as fabricated as an invented name, even though it reads as narrative.3233See `containers.md` for the recipe per document type.
introvenk