written-communication

Original source / Raw SKILL.md

---
name: "written-communication"
description: "Draft and edit high-signal written artifacts and produce a Written Communication Pack (brief, outline, draft email/memo/doc, canonical doc option, quality gate). Use for writing, written communication, memo, email, doc, async update, rewrite for clarity. Category: Communication."
---

# Written Communication

## Scope

**Covers**
- Turning messy notes into a clear **email, memo, doc, or async update**
- Making the **“how”** explicit (what happens next, by whom, by when)
- Editing for **clarity at scale** (scanability, definitions, single source of truth)
- Creating/maintaining a **canonical doc** for an ongoing project

**When to use**
- “Draft an email to stakeholders explaining a change and what I need from them.”
- “Turn these bullets into a 1-page memo with a recommendation and next steps.”
- “Rewrite this doc to be clearer, shorter, and more actionable.”
- “Create a canonical doc as the source of truth for this project.”

**When NOT to use**
- You need **marketing/brand copy** (landing pages, ads) more than internal/executive clarity.
- You need a full product spec/PRD from scratch (use `writing-prds` or `writing-specs-designs`).
- You’re writing **legal/HR/regulated** communications without expert review.
- The real issue is alignment via facilitation (you may need a meeting/offsite plan, not a rewrite).

## Inputs

**Minimum required**
- Artifact type + channel (email / memo / doc / status update; where it will live)
- Audience (roles/seniority) + what they care about
- Goal + ask (inform/align/decide; what you want the reader to do, by when)
- Key context (facts, constraints, timeline, links) + what must be avoided (sensitivities)
- Source material (notes, existing draft, Slack threads, etc.)

**Missing-info strategy**
- Ask up to 5 questions from [references/INTAKE.md](references/INTAKE.md) (3–5 at a time), then proceed.
- If critical info remains missing, make explicit assumptions and offer 2–3 options (structure/tone/ask).

## Outputs (deliverables)

Produce a **Written Communication Pack** in Markdown (in-chat; or as files if requested):

1) **Message brief** (audience, goal, ask, constraints)
2) **Outline** (TL;DR + key points + “how/next steps”)
3) **Draft artifact** (email/memo/doc/status update) in final-ready format
4) **Canonical doc skeleton** (optional; when the project needs a single source of truth)
5) **Risks / Open questions / Next steps** (always)

Templates: [references/TEMPLATES.md](references/TEMPLATES.md)  
Expanded guidance: [references/WORKFLOW.md](references/WORKFLOW.md)

## Workflow (8 steps)

### 1) Intake + choose the lightest artifact
- **Inputs:** user request + [references/INTAKE.md](references/INTAKE.md).
- **Actions:** Clarify the channel and pick the smallest artifact that works (email vs memo vs doc vs status update vs canonical doc).
- **Outputs:** Message brief (draft) + artifact selection.
- **Checks:** You can answer: “Who is this for, and what should they do after reading?”

### 2) Lock the reader outcome + ask (one sentence)
- **Inputs:** brief.
- **Actions:** Write one sentence: “After reading, the audience will ____.” Make the ask explicit (decision/options, approval, feedback, or FYI) and include a deadline if relevant.
- **Outputs:** Outcome/ask line + decision/feedback request.
- **Checks:** The ask is unambiguous and doesn’t require a meeting to interpret.

### 3) Convert “what/why” into “how” (actionable next steps)
- **Inputs:** source material + outcome/ask.
- **Actions:** Identify the 3–7 concrete steps, responsibilities, and dependencies. If proposing a change, include what changes, what stays the same, and what happens next.
- **Outputs:** “How / Next steps” bullets (owner + date where possible).
- **Checks:** A reader could execute without asking “so what do you want me to do?”

### 4) Structure for skim (clarity at scale)
- **Inputs:** brief + next steps.
- **Actions:** Create a TL;DR, then headings in the order readers scan: Ask → Context → Details → Next steps. Use bullets, short paragraphs, and explicit labels.
- **Outputs:** Outline with headings.
- **Checks:** A skim-reader can capture the point in < 60 seconds.

### 5) Draft the artifact (write to be forwarded)
- **Inputs:** outline + templates.
- **Actions:** Draft in plain language; avoid jargon; put key numbers and decisions in writing. If this is ongoing work, link to (or create) the canonical doc.
- **Outputs:** Draft email/memo/doc/status update.
- **Checks:** The draft is safe to forward; it stands alone without verbal context.

### 6) “Letter to yourself” clarity pass (then rewrite for the audience)
- **Inputs:** draft.
- **Actions:** If the content is fuzzy, write a quick internal version (“what am I actually saying?”), then rewrite in the audience’s language and incentives.
- **Outputs:** Clarified rewrite with cleaner logic.
- **Checks:** The message has a single through-line; no contradictions or buried ledes.

### 7) Canonical doc check (single source of truth)
- **Inputs:** draft + project context.
- **Actions:** If readers will keep asking “where is the latest?”, create/update a canonical doc (links, owners, last updated, decisions, next update cadence).
- **Outputs:** Canonical doc skeleton or link section.
- **Checks:** There is one obvious place to find the current state and decisions.

### 8) Quality gate + finalize
- **Inputs:** full pack.
- **Actions:** Run [references/CHECKLISTS.md](references/CHECKLISTS.md) and score with [references/RUBRIC.md](references/RUBRIC.md). Add Risks/Open questions/Next steps.
- **Outputs:** Final Written Communication Pack.
- **Checks:** Clarity, actionability, and ownership meet the bar (≥ 3 on each rubric dimension).

## Quality gate (required)
- Use [references/CHECKLISTS.md](references/CHECKLISTS.md) and [references/RUBRIC.md](references/RUBRIC.md).
- Always include: **Risks**, **Open questions**, **Next steps**.

## Examples

**Example 1 (stakeholder email):** “Draft an email to exec stakeholders: the launch is slipping 2 weeks; we need approval to cut scope and a decision by Friday.”  
Expected: TL;DR + explicit ask/options + what changes + next steps with owners.

**Example 2 (project memo + canonical doc):** “Turn these notes into a 1-page memo that aligns the team on the new onboarding approach, and create a canonical doc outline for ongoing updates.”  
Expected: memo with recommendation + tradeoffs + next steps, plus a source-of-truth doc skeleton.

**Boundary example:** “Write a legal/HR disciplinary notice.”  
Response: decline to fabricate legal/HR guidance; request expert review; offer to help with neutral structure, tone, and clarity if the user provides approved language.


---

## Referenced Files

> The following files are referenced in this skill and included for context.

### references/INTAKE.md

```markdown
# Intake (Question Bank)

Ask **up to 5 questions at a time**, then proceed. If answers remain missing, state assumptions explicitly and offer 2–3 options.

## Minimum set (use first)
1) What are we writing (email/memo/doc/status update) and where will it live (Slack, email, Notion, Google Doc)?
2) Who is the audience (roles/seniority) and what do they care about (time, risk, cost, quality, morale)?
3) What is the goal and the **ask** (inform/align/decide)? What should the reader do, by when?
4) What are the key facts that must be included (timeline, decision, constraints, numbers, links)? What must be avoided (sensitivities, legal/HR constraints, confidential info)?
5) Constraints: length, tone (direct vs warm), formatting, deadline, and any “must-include” sections.

## Helpful follow-ups (pick what’s relevant)

### If it’s a decision request
- What decision options are on the table (A/B/C) and what’s your recommendation?
- What tradeoffs matter (speed vs quality, cost vs scope, risk vs upside)?
- What happens if we don’t decide by the deadline?

### If it’s a status update
- What changed since last update (progress, metrics, decisions)?
- What’s blocked and what are you doing about it?
- What are the explicit asks (who, what, by when)?
- When is the next update, and where is the canonical doc?

### If it’s a rewrite/edit request
- What must be preserved (facts, tone, intent)? What should change (shorter, more direct, more persuasive)?
- Target reading time / length (e.g., “< 2 minutes”, “< 300 words”)?
- Any example you want to match (a prior email, style guide)?

### If it’s an ongoing project
- Do we have a **single source of truth** doc? If not, where should it live and who owns updates?
- What links must be included (PRD/spec, tracker, decision log, dashboard)?


```

### references/TEMPLATES.md

```markdown
# Templates (Copy/Paste)

Use these templates to produce the Written Communication Pack deliverables.

## 1) Message brief (context snapshot)
- Artifact type + channel:
- Audience (roles/seniority):
- Goal (inform/align/decide):
- Ask (what should they do, by when):
- Why now (1 sentence):
- Key facts (dates, numbers, constraints):
- Sensitivities / what to avoid:
- Links (canonical doc, tracker, docs):
- Tone + length constraints:

## 2) Outline (default structure)
**TL;DR (2–4 bullets)**
- …

**What’s happening / Context (optional, short)**
- …

**What’s changing (and what’s not)**
- Changing:
- Not changing:

**How this works / Next steps (actionable)**
1) <Owner>: <action> — <due date>
2) <Owner>: <action> — <due date>

**What I need from you (explicit ask)**
- …

**Risks / open questions**
- …

## 3) Email template (stakeholder update + ask)
**Subject:** <clear outcome + topic> (e.g., “Decision needed by Fri: Launch scope change”)

Hi <name/team>,

**TL;DR**
- …

**What’s changing**
- …

**What I need from you (by <DATE>)**
- Decision: <A/B/C> (recommended: <X>)
- OR Feedback: <what kind> (how to respond)

**Next steps**
1) <Owner>: <action> — <date>
2) <Owner>: <action> — <date>

**Links**
- Canonical doc: <link>
- Tracker: <link>

Thanks,  
<name>

## 4) 1-page memo template (recommendation + tradeoffs)
**Title:**  
**Author:**  
**Date:**  
**Audience:**  
**Status:** Draft / Review / Approved

### TL;DR (recommendation)
- Recommendation:
- Decision needed:
- Deadline:

### Context (only what’s necessary)
- …

### Options (A/B/C) + tradeoffs
- Option A:
- Option B:
- Option C:

### Proposed plan (“how”)
1) …
2) …

### Risks / open questions / next steps
**Risks**
- …

**Open questions**
- …

**Next steps**
1) …

## 5) Status update template (weekly async)
**Status:** Green / Yellow / Red  
**This week (wins/progress)**
- …

**Metrics (if applicable)**
- …

**Risks / blockers**
- …

**Asks (who/what/by when)**
- …

**Next week plan**
- …

**Links**
- Canonical doc:
- Tracker:

## 6) Canonical doc template (single source of truth)
**Project:**  
**Owner:**  
**Last updated:**  
**Purpose (1–2 sentences):**

### TL;DR
- Current state:
- Next milestone:
- Top risk:

### Key links
- Tracker:
- Specs/docs:
- Decision log:
- Dashboard:

### Decisions (latest first)
| Date | Decision | Owner | Notes/links |
|---|---|---|---|
|  |  |  |  |

### Next steps (owned)
| Owner | Action | Due | Status |
|---|---|---:|---|
|  |  |  |  |

### Update cadence
- Next update: <date>
- Cadence: weekly / biweekly


```

### references/WORKFLOW.md

```markdown
# Workflow (Expanded)

This file expands the steps from `../SKILL.md` with extra guidance and heuristics.

## Step 1 — Choose the lightest artifact
Default rule: pick the smallest artifact that still achieves the outcome.

Common picks:
- **Email/Slack message:** fast update + clear ask.
- **Memo (1–2 pages):** recommendation + tradeoffs + decision.
- **Doc (longer):** shared context that will be referenced repeatedly.
- **Canonical doc:** ongoing project hub (links + decisions + current state).

Failure mode: writing a long doc when the reader only needed a crisp ask + next steps.

## Step 2 — Lock outcome + ask
Write the “after reading…” sentence and keep it visible while drafting.

Ask patterns:
- **Decision:** “Approve option B by Friday.”
- **Feedback:** “Reply with concerns by EOD Wednesday.”
- **Action:** “Please do X by DATE; I’ll do Y.”
- **FYI:** “No action needed; next update DATE.”

Failure mode: implied asks (readers don’t know what you want).

## Step 3 — Make the “how” concrete (don’t over-explain the premise)
Source insight: readers usually already accept the “what/why”. They need the “how”.

Include:
- What changes vs what stays the same
- Owners (names/roles) and dates
- Dependencies and risks

Failure mode: paragraphs of context with no actionable next steps.

## Step 4 — Structure for skim (clarity at scale)
Defaults that work for most audiences:
- **TL;DR first**
- Headings that match reader questions: “What’s happening?”, “What I need from you”, “Next steps”
- Bullets > paragraphs (especially for steps/asks)

Heuristic: if the reader only reads the TL;DR and headings, they should still act correctly.

## Step 5 — Draft to be forwarded
Write like your message might be forwarded to:
- A new exec who has zero context
- A partner team who is skeptical

Practical rules:
- Avoid “this/that/it” without nouns (“this change” vs “this”)
- Define acronyms on first use
- Put key numbers in writing (dates, scope cuts, thresholds)

## Step 6 — “Letter to yourself” clarity pass
Source insight: writing is a thinking tool. If you’re confused, the reader will be too.

Technique:
1) Write a blunt internal version (“What am I actually trying to say?”).
2) Extract the through-line (problem → decision → next steps).
3) Rewrite for the audience’s incentives and vocabulary.

Failure mode: polishing unclear thinking instead of clarifying it.

## Step 7 — Canonical doc (single source of truth)
Source insight: projects need one canonical place to learn the current state.

Canonical doc should make it easy to answer:
- What’s the latest?
- What decisions have been made?
- What’s next, and who owns it?

Include “last updated” and an update cadence to reduce anxiety and follow-ups.

## Step 8 — Quality gate
Before sending:
- Run [CHECKLISTS.md](CHECKLISTS.md)
- Score [RUBRIC.md](RUBRIC.md)
- Add **Risks / Open questions / Next steps**

Failure mode: sending a draft that creates more meetings and confusion than it prevents.


```

### references/CHECKLISTS.md

```markdown
# Checklists

Use these before you send or publish written communication.

## Universal checklist (any artifact)
- Audience is clear; the first screen answers “why am I reading this?”
- The ask is explicit (decision/action/feedback/FYI) and includes a deadline if needed
- The “how” is concrete: steps, owners, and dependencies are specified
- TL;DR exists and matches the body (no surprises)
- Scanability: headings, bullets, short paragraphs; no wall-of-text sections
- Terms, acronyms, and dates are unambiguous; key numbers are written down
- Single source of truth is linked (or created) for ongoing work
- Tone is direct and respectful; avoids blame; assumes good intent
- Safety: no secrets, credentials, or unnecessary sensitive/PII details

## Decision request checklist (email/memo)
- Options are stated (A/B/C) with your recommendation and rationale
- Tradeoffs are explicit (what you’re giving up, what you’re protecting)
- The cost of delay is stated (what happens if no decision)
- “If you disagree” path is clear (how to respond, by when)

## Status update checklist
- Status (G/Y/R) is justified with one sentence
- Asks are in a separate section with owner + date
- Blockers include what you’re doing about them (not just “blocked”)
- Next update date/cadence is stated

## Canonical doc checklist
- Owner and last updated are present
- Key links are complete and current
- Decisions are logged and easy to find
- Next steps have owners and dates


```

### references/RUBRIC.md

```markdown
# Rubric (Score 1–5)

Score the Written Communication Pack. Aim for **≥ 3** on every dimension before sending. If any dimension is **≤ 2**, revise.

## 1) Outcome + ask clarity
1 = unclear why the reader should care; ask is implied  
3 = ask is explicit with a clear deadline/response path  
5 = outcome is crisp; decision/action path is effortless for the reader

## 2) “How” specificity (actionability)
1 = mostly context; no concrete steps  
3 = next steps exist with owners and reasonable dates  
5 = highly actionable plan with dependencies, sequencing, and clear ownership

## 3) Structure + scanability (clarity at scale)
1 = hard to skim; walls of text; buried lede  
3 = TL;DR + headings + bullets; easy to follow  
5 = optimized for skim + deep read; information hierarchy is excellent

## 4) Correctness + completeness (given inputs)
1 = missing key facts; likely to confuse or mislead  
3 = includes necessary context, constraints, and links  
5 = accurate, complete, and anticipates key reader questions

## 5) Tone + trust
1 = defensive, blaming, or mismatched to audience  
3 = direct and respectful; appropriate confidence level  
5 = builds trust; acknowledges uncertainty; invites constructive response

## 6) Source of truth + follow-through
1 = no place to find “latest”; follow-ups inevitable  
3 = canonical doc/link and next update cadence exist when needed  
5 = reduces future meetings: decisions, owners, and cadence are crystal clear


```