Trigger

Activate when the user asks to "write a status update", "weekly update", "stakeholder update", "write a project update", or "status report".

Behavior

Step 1: Gather Context

Ask:

What project or initiative is this for?
What happened this week? (Paste notes, Slack messages, whatever you have — the messier the better)
Who is the audience? (CEO, VP Eng, cross-functional team, skip-level, board)
Is there bad news? (If so, I'll help you frame it with a mitigation plan)

If the user pastes raw notes, Slack threads, or bullet points, extract and structure the information directly. Never ask the user to organize it first.

Step 2: Write the Update

Follow this exact structure:

TL;DR (2 sentences max) The entire update if they read nothing else. Lead with the single most important thing. Bad news goes here, not buried below.

Status: [pick one]

On Track — shipping on schedule, no blockers
At Risk — potential issues that need visibility, with mitigation plan
Blocked — cannot proceed without a decision or action from someone specific

Progress This Week

What actually shipped or completed — never what was "worked on"
Be specific: "Shipped new onboarding flow to 10% of users" not "Made progress on onboarding"
Include links to PRs, docs, demos, or dashboards when provided
Call out milestones explicitly

Next Week

What's planned, with owners where known
Highlight dependencies on other teams or decisions
If something needs to happen by a specific date, make the deadline visible

Risks & Blockers

Every risk gets: description, likelihood, impact, mitigation plan
Every blocker gets: what's blocked, who can unblock it, by when
If there are none, write "None currently." Never fabricate risks to fill the section

Decisions Needed (include only if applicable)

State exactly what needs to be decided
Who needs to decide it
By when
Enough context for the reader to decide without scheduling a meeting
Always include a recommendation: "I recommend Option A because..."

Metrics (include only if applicable and the user provides data)

Key metric: current value vs. target, trend (up/down/flat), brief interpretation
Only include metrics that tell a story

Step 3: Tone Calibration

Adjust content and depth based on audience:

Audience	Focus On	Leave Out
CEO / C-suite	Outcomes, metrics, strategic implications	Implementation details, technical decisions
VP / Director	Progress against milestones, risks, resource needs	Code-level details, day-to-day tasks
Cross-functional	Dependencies, timeline impacts, what they need to know	Internal team dynamics, technical debt
Engineering lead	Technical blockers, architecture decisions, velocity	Business context they already know
Skip-level	Your team's impact, growth, wins	Minutiae that your direct manager handles
Board	Metrics, trajectory, market context	Everything operational

Formatting Rules

Total update: under 200 words. Longer means too much detail for the audience.
No filler. "We continued to make progress on..." — state what was done.
Bad news goes above the fold, not buried at the bottom. Always pair bad news with a mitigation plan.
Active voice. "Team shipped the migration" not "The migration was completed."
Use parallel structure in bullet points. Start each with a verb.

Good vs. Bad Examples

Bad Update (vague, buries bad news, no actions)

Subject: Weekly Update - Auth Project

Hi team,

This week we continued working on the authentication project. The team
has been making good progress and we're feeling positive about the
direction. We had some productive discussions about the technical
approach and are aligned on next steps.

We're also looking into some issues that came up during testing but
nothing major. The team is working hard and we expect to have more
updates next week.

On track for launch, will keep you posted.

Thanks,
Sarah

What's wrong: No specifics anywhere. "Some issues" is hiding something. "Making good progress" could mean anything. No metrics, no dates, no owners. Reader learns nothing.

Good Update (specific, honest, actionable)

TL;DR: Auth migration is at risk. We found a session handling bug
that affects 12% of users on mobile. Fix is in progress — ETA Thursday.
Launch pushed from March 7 to March 14.

Status: AT RISK

Progress This Week:
- Shipped auth migration to 40% of web users (up from 10% last week)
- Error rate holding at 0.3% — within our 1% threshold
- Completed load testing: system handles 5x current peak traffic

Next Week:
- Fix mobile session bug (owner: Jake, ETA Thursday)
- Expand to 100% of web users if mobile fix validates (owner: Sarah)
- Begin mobile rollout at 10% by Friday (owner: Sarah)

Risks & Blockers:
- RISK: Mobile session bug could have deeper root cause than initial
  diagnosis suggests. Likelihood: Medium. Impact: Additional 1-week
  delay. Mitigation: Jake is pairing with platform team on diagnosis.
  If not resolved by Thursday, we'll ship web-only and decouple mobile.
- BLOCKER: Need QA sign-off on load test results before expanding
  beyond 40%. Owner: Maria. Need by: Tuesday EOD.

Decision Needed:
Should we launch web-only on March 10 if the mobile bug isn't fixed,
or hold everything for March 14? I recommend launching web-only —
88% of auth traffic is web, and decoupling de-risks the mobile fix.
Need a decision from @VP-Eng by Wednesday.

What's different: Specific numbers everywhere. Bad news is in the TL;DR, not hidden. Every risk has a mitigation. The decision request includes a recommendation with reasoning.

Bad Metrics Section

Metrics:
- Users: going well
- Revenue: looking good
- NPS: stable

Good Metrics Section

Metrics:
- WAU: 142K (target: 150K) — flat for 3 weeks. Investigating whether
  the new onboarding friction is suppressing activation.
- Revenue: $1.2M MRR (+4% MoM) — on track for Q1 target of $1.3M
- NPS: 34 (down from 38 last month) — correlated with auth migration
  complaints. Expect recovery after bug fixes ship.

Common Mistakes to Avoid

Hiding bad news at the bottom. If your launch date slipped, that is the TL;DR, not a footnote. Stakeholders lose trust when they discover you buried the lead.

Confusing activity with progress. "Had 6 meetings about the migration" is activity. "Migrated 40% of users with 0.3% error rate" is progress. Report outcomes, not effort.

Using weasel words. "Roughly on track," "mostly done," "some concerns" — these signal uncertainty, not status. Be precise. If unknown, say "investigating, will update by [date]."

Including everything. A status update is not a diary. Only include what matters to THIS audience at THIS level. Your VP does not need to know about a refactored utility function.

No action items. Every update must make clear what you need from the reader. If nothing, say so. But most "nothing needed" updates are missing something.

Adapting by Cadence

The default format above is weekly. For other cadences, adjust scope and depth:

Daily Standup / Async Daily

3 lines max: What shipped yesterday. What's happening today. Any blockers.
Skip metrics, risks section, and decisions unless something changed today.
Format: Plain text, no headers. This should fit in a Slack message.

Yesterday: Shipped auth migration to 40% of web users
Today: Running load tests, expanding to 60% if results hold
Blocked: Waiting on QA sign-off from Maria (need by EOD)

Monthly Update

Same structure as weekly but zoom out: progress against monthly goals, not daily tasks.
Add a "Month in Review" summary: 3-5 biggest accomplishments as a bulleted list.
Include metric trends (not just snapshots): "WAU grew from 130K to 142K (+9%)"
Add a "Next Month Preview" section with key milestones and dates.
Target: 300-500 words.

Quarterly Business Review (QBR)

Lead with OKR scorecard: each KR with target vs. actual and red/yellow/green status.
Include a "Key Decisions Made" section — what big bets were placed and early results.
Add a "Lessons Learned" section: 2-3 things that would change if you could rerun the quarter.
Forward-looking: next quarter's top 3 priorities with success criteria.
Target: 500-800 words. Use tables for OKR scorecards and metric summaries.

When the user doesn't specify cadence, default to weekly. If they mention "monthly," "quarterly," "QBR," or "daily," switch to the matching format.

Anti-Patterns

Never fabricate progress. If the user's raw notes are thin, the update stays thin. Never pad.
Never hide bad news. Surface it early, with a plan. PMs who hide bad news lose trust fast.
Never include items that fail the "so what?" test. If cutting a bullet changes nothing for the reader, cut it.
Never use passive voice to avoid ownership. "The deadline was missed" becomes "We missed the deadline because X. Here is the recovery plan."
Never send an update that requires a follow-up meeting to understand. The update must stand alone.
Never include risks without mitigation plans. An unmitigated risk is just anxiety.

Rules

Never fabricate progress or inflate status. If behind, say so with a plan.
Never hide bad news. Surface it early, pair it with mitigation. Stakeholders handle bad news. They cannot handle surprises.
Every item must pass the "so what?" test. If it does not matter to this audience, cut it.
Always include a recommendation with decisions. Never make the reader do the analysis. "I recommend X because Y. Need sign-off by Z."
Match depth to audience. Board updates have no technical details. Eng lead updates have no business platitudes.

Status Update Writer