status_updates v1.0.0

name: "status_updates" description: "Write async status updates people actually read — Done/Doing/Next/Blocked structure, health headline first, one screen. Use when reporting project progress, writing a weekly standup post, or replacing a status round that would otherwise happen in a meeting." metadata: { "includeInPrompt": true }

Status Updates

Purpose

Teach an agent to write a short async status update that tells the reader the project's health in 30 seconds and carries enough detail to unblock work in 2 minutes.

Workflow

1. Open with the health headline. One line: project name, date, and a Green / Yellow / Red verdict with the single reason driving it. If nothing changed since last time, say so immediately ("No change since [date] — all green") so readers can stop there with confidence.
2. Report Done: what shipped or finished. Outcomes, not activity. "Payment retries are live" beats "worked on retries." Name each item in one line; 3–5 items is plenty — if you have more, you are listing tasks, not status.
3. Report Doing: what's in flight right now. One line per item with where it stands (e.g. "in review," "70% built," "testing"). Skip anything unchanged since last update — silence on an item means "same as last time" only if you said that in step 1.
4. Report Next: what's coming in the next period. Only items you actually intend to touch. This is a commitment list; keep it short enough that missing one is an event worth explaining next time.
5. Name Blockers with the ask attached. Every blocker gets three parts: what is stuck, who can unstuck it, and what decision or action you need from them. "Blocked on legal" is noise; "Need legal's sign-off on the refund wording by Friday to ship — ask: 10-minute review of the draft" is signal.
6. Tailor the depth to the audience. Execs get outcomes, risks, and the ask; drop implementation detail they can't act on. Peers get enough working detail to unblock or parallelize — link to the doc, PR, or thread instead of pasting it.
7. Fit it on one screen. If the update scrolls past what fits on a phone, cut: move deep detail behind links, drop unchanged items, or split into a summary + appendix.

Output Contract

A complete status update contains:

• Health line: Project — [date] — 🟢/🟡/🔴 + one-line reason
• Done (3–5 max, outcomes not activity)
• Doing (in-flight items with current state)
• Next (short commitment list for the coming period)
• Blocked (each blocker: what's stuck → who can fix it → the specific ask + deadline)
• Needs-a-decision section when a choice is pending — same format as a blocker, just framed as a decision
• Links instead of pasted detail for anything longer than a line

Operating Rules

1. Lead with the verdict, never bury it. If the reader only sees the first line, they should know whether to worry.
2. Every blocker ships with an owner and a concrete ask — no orphan blockers, no "blocked on X" with no next step.
3. Report outcomes, not effort. "Testing" is activity; "3 of 5 test suites pass" is status.
4. Default to weekly. Shorten the cadence when the project is red or near a deadline; lengthen it when work is stable and green — the risk of the project sets the rhythm, not a calendar rule.
5. One project per update. If two projects share a message, give each its own health line.
6. Say what changed, skip what didn't. Repetition trains readers to skim everything, including the parts that matter.
7. This skill reports progress on work. It is not a decision document (that's writing-briefs) and not a record of a meeting that happened (that's meeting-notes). Keep decisions and discussion trails in those forms, referenced by link.

Example (fictional)

> Payments retry — 2026-09-22 — 🟡 Yellow: staging flake is the only thing between us and launch > > Done > - Retries live behind the feature flag in prod (flag at 0%) > - Merchant refund endpoint passing all contract tests > > Doing > - Investigating the staging webhook flake (reproduces 1 in 20 runs) — debugging with the platform team > > Next > - Flip flag to 5% traffic Thursday if staging is clean > - Write the merchant-facing changelog entry > > Blocked > - Need infra to bump the staging queue's memory limit — ask: approve the 2 GB increase (thread) so we can rule out resource starvation by EOD Wednesday