status-update-writer

Purpose

Turn raw, informal development notes (a scratch list of what got done, blockers, half-finished thoughts) into a clear, professional status update suitable for sharing with a team or stakeholder.

When to Use

• Writing a daily/weekly status update from rough notes.
• Converting a stream-of-consciousness list of "did X, working on Y, blocked on Z" into something shareable.
• Standardizing status update format across a team.

What to Analyze / Do

1. Separate signal from noise — not every micro-task belongs in a status update; group related work into meaningful lines (5 small bug fixes on the same feature become one line, not five).
2. Organize into clear sections — typically: Done (this period) / In Progress / Blocked / Next. Adapt if the team has an existing format.
3. Make blockers actionable — a blocker should say what's blocking it and, if known, what's needed to unblock (whose input, what decision).
4. Match tone to audience — a team-internal update can be more technical/terse; a cross-functional or leadership-facing update needs less jargon and more "why it matters."
5. Flag risk/timeline impact explicitly — if something is at risk of slipping, say so plainly rather than burying it in neutral-sounding language.

Output Format

• Sections: Done / In Progress / Blocked / Next (or the team's existing convention).
• Each line: concise, specific, outcome-oriented ("Shipped X" not "worked on X" when it's actually done).
• Blockers called out with what's needed to resolve them.
• Optional one-line summary at the top if the update is long enough to benefit from a TL;DR.

Avoid

• Padding the update with vague activity ("worked on various things") instead of concrete outcomes.
• Burying a real risk or slip in neutral language that reads as "everything's fine."
• Listing every micro-task individually when they'd read better grouped under one outcome-level line.