Writes a clear weekly status update from a messy list of what happened, tuned for your boss or your team.
What it does
You did a week of work and now you have to explain it to someone who has eight other updates open. Writing it takes forty minutes because you keep rereading your own notes trying to work out what counts.
With this skill active, the assistant sorts your pile into what shipped, what is still moving and what is stuck, then does the part that makes the difference: it turns activity into outcomes. "Worked on the signup page" becomes "signup page is live, drop-off fell from 31% to 22%". It also sizes the update to whoever is reading it, since a manager needs to know what to expect next week and an executive needs one number and one thing they can unblock, from exactly the same facts.
Anything you are stuck on comes back written as a request with a name and a date attached, and nothing gets padded or quietly inflated.
You end up with a one-minute update in a named format, sized for its reader, with blockers written as specific asks.
When to reach for it
Use it for the update you write on a schedule: the weekly report to your manager, a team update, a project note to leadership, or a written standup.
Skip it when there is genuinely nothing to report - it will tell you to write the quiet week honestly rather than stretching three items into six, and you can do that in one line yourself. It also will not invent a metric you do not have.
---
name: status-report-writer
description: Turns a messy pile of what happened into a status update sized for its reader - a manager, the team, or senior leadership - using a named format such as Progress/Plans/Problems or Done/Doing/Blocked. Converts activity into results, writes blockers as specific asks, and never inflates. Use for weekly updates, project updates, standups and leadership reports.
license: Apache-2.0
metadata:
source: anthropics/skills
---
# Status Report Writer
You write the update that actually gets read. Your reader has eight of these open and forty seconds for yours, and they are looking for two things: is this on track, and does anything need me.
## Workflow
1. **Take the four inputs:** the raw pile, the reader, the period, and anything they are stuck on.
2. **Pick the format.** Four named ones below. Say which you picked.
3. **Sort the pile** into shipped, in flight, and stuck. Discard the rest.
4. **Convert activity into results.** This is where most of the value is added.
5. **Set the altitude** to match the reader. Same facts, different grain.
6. **Write blockers as asks:** what is stuck, what you need, from whom, by when.
7. **Lead with the most important item,** not the first one on the list.
8. **Cut to reading time.** Forty to sixty seconds, out loud.
```text
Status update checklist
[ ] Four inputs: raw pile, reader, period, blockers
[ ] Format chosen and named
[ ] Every line converted from activity to result
[ ] Altitude matches the reader - no task detail in a leadership update
[ ] Most important item is first, not chronologically first
[ ] Each blocker names the ask, the person, and the date
[ ] Anything that slipped is stated plainly with one line of cause
[ ] No invented numbers; missing metrics left out rather than guessed
[ ] Reads aloud in under 60 seconds
```
## Step 1: the four inputs
- **The raw pile.** Whatever they have: a scratch list, chat messages, commits, a calendar. Messy is expected.
- **The reader.** Manager, the team, or senior leadership. Ask if they do not say, because it changes everything below.
- **The period.** This week, this sprint, this month. Progress and problems look backwards; plans look forwards by the same span.
- **What they are stuck on.** People consistently under-report this, so ask directly rather than waiting for it to appear in the pile.
## Step 2: the four formats
Pick one, name it, and keep it stable week to week. Readers learn a format and then skim it, which is the whole point.
| Format | Shape | Use it when |
|---|---|---|
| Progress / Plans / Problems | Three sections: what happened, what is next, what is in the way | A recurring team or company update to people with some context, read in under a minute |
| Done / Doing / Blocked | Three lists of items | An individual's weekly update to a manager who tracks specific work |
| Leadership update | One-line status verdict, then results, risks, decisions needed | Senior readers who need to act or reassure, not to follow along |
| Standup note | Yesterday, today, blockers. Three lines | A daily written standup for a team already in context |
Progress/Plans/Problems is the workhorse for team updates: it forces a forward-looking section, which the other formats leave optional and people then skip.
If a workplace already has a house format, use theirs. A familiar shape beats a better one.
## Step 3: sorting the pile
Three buckets, and be ruthless with the fourth:
- **Shipped.** Finished, live, merged, sent, signed. Someone else can see it.
- **In flight.** Started, not finished. Needs a state and an expected finish.
- **Stuck.** Waiting on a person, a decision, a dependency, or an answer.
- **Discard.** Meetings attended, emails answered, routine maintenance, anything with no outcome attached. Attending a meeting is not progress.
## Step 4: activity into results
The single biggest improvement available. Activity says what you touched; a result says what is now true.
| Activity | Result |
|---|---|
| "Worked on the signup page" | "Signup page is live; drop-off fell from 31% to 22%" |
| "Had meetings about pricing" | "Pricing is agreed at three tiers; the page goes up Thursday" |
| "Looked into the export bug" | "Export bug traced to the row limit; fix is a day's work, scheduled" |
| "Continued the migration" | "Read replicas done and verified; writes are two weeks out" |
| "Onboarded the new starter" | "New starter is taking their own tickets from Monday" |
If a line cannot be turned into a result, it usually belongs in the discard bucket or in the in-flight section with an honest state attached.
## Step 5: altitude
Altitude is how granular the items are, and it should track the reader's distance from the work. The same week produces three legitimately different updates.
| Reader | Altitude | Example line |
|---|---|---|
| Team | Task level. Names, hand-offs, who to ask | "Rosa has the analytics pull; Dev picks up the flow once it lands" |
| Manager | Outcome level. What moved, what is at risk | "Signup rework is live; drop-off down 9 points. Mobile numbers still missing" |
| Leadership | Impact level. Numbers, risks, decisions needed | "Signup conversion up 9 points. One risk: no mobile data yet, which affects the Q3 forecast" |
The failure mode is task detail sent upward. A VP reading "refactored the validation module" learns nothing they can act on, and the update trains them to skim the next one.
The reverse failure is real too: a team update pitched at impact level leaves everyone unsure who is doing what tomorrow.
The larger the group the update covers, the coarser every line should be. A six-person team reports features; a department reports outcomes; a company reports hires, revenue and launches.
## Step 6: blockers as asks
A blocker with no ask attached is a complaint, and readers skip it. Four parts, one line:
> **Contract review** - stuck with Legal since 3 Aug. Need sign-off to send to the client. Chasing Nadia, need it by Friday or the client call moves.
- **What is stuck**, in the reader's terms.
- **What you need**, specifically. A decision, a person, an approval, a number.
- **Who from.** Name them.
- **By when,** and what happens if it misses.
If nothing is blocked, write "No blockers" and stop. A padded blockers section teaches the reader that the section is noise.
## Step 7: the honesty pass
- Something slipped: say it slipped, give the new date, one line of cause, no defensiveness. "Migration moved to 14 March; vendor API access came two weeks late."
- A number you do not have: leave it out and say the number is missing. Never estimate a metric into an update; it becomes a fact by the second forward.
- A quiet week: report the quiet week. Inflating three items into six is obvious to anyone who reads these regularly, and it costs you the credibility you need on the week something is genuinely wrong.
- Bad news goes near the top. Bad news found at the bottom reads as concealment.
## Example
**Raw pile:** "fixed 3 bugs, still waiting on legal for the contract, started the onboarding flow, drop-off numbers came back better after the signup change."
**Reader:** manager. **Period:** this week. **Format:** Done / Doing / Blocked.
> **Status: on track, one item waiting on Legal.**
>
> **Done**
> - Signup rework is live. Drop-off fell from 31% to 22% in the first full week.
> - Three reported bugs fixed and released.
>
> **Doing**
> - Onboarding flow started. On track to finish next week.
>
> **Blocked**
> - Contract review with Legal since 3 Aug. I need sign-off before it goes to the client. Chasing Nadia; if it misses Friday, the client call moves to the following week.
The same week, for leadership:
> **Signup: on track.** Conversion up 9 points after the signup rework, measured over the first full week. Onboarding is next. One risk: the client contract has been with Legal for eight days and is holding a client call.
Note what disappeared going upward: the three bugs, the name Nadia, and the word "started". What survived is the number, the risk, and the thing a senior reader could unblock with one message.
## Rules
- Results, not activity. "Shipped the signup page" beats "worked on signup".
- Never invent a number, a percentage, or a completion state.
- Do not inflate a quiet week, and do not bury a bad one.
- Blockers name a person and a date, or they are not blockers.
- Keep the format stable week to week. Consistency is what makes an update skimmable.
- No jargon the reader would not use themselves, and no internal project code names in an upward update.
- One minute maximum. If it runs long, cut items rather than shortening every line into fragments.
## Edge cases
- **The pile is empty or nearly so.** Ask three questions: what shipped, what moved, what is stuck. If the honest answer is a quiet week, write the quiet week and say why in one line.
- **Everything slipped.** Lead with the status verdict, give the single most important cause, and state what changes next week. A recovery plan in one line is worth more than five paragraphs of explanation.
- **The update covers other people's work.** Attribute it. Take credit only for what the user did, and check names before an update goes upward.
- **The reader has already heard some of it.** Mark it: "as flagged Tuesday". Repeating news as new is how readers stop trusting the top line.
- **Sensitive material.** Someone's performance, a resignation not yet announced, a customer about to churn. Keep it out of a written update that gets forwarded, and tell the user to raise it in person instead.
- **The user wants to hide something.** Write the honest version, and say once, plainly, that it will surface anyway and lands better now than in three weeks.
- **Multiple audiences, one update.** Write for the most senior reader and add a detail section below the fold for the team, rather than averaging the altitude into something that serves neither.
- **A metric moved but not because of you.** Say so. Claiming an unrelated improvement is the fastest way to lose a reader who knows the cause.
## Files
- `references/examples.md` - three complete runs: one messy week written for a manager and then for leadership from identical input, a team-level Progress/Plans/Problems update, and a week where most things slipped. Read the first one to see altitude change without the facts changing.
- `references/formats.md` - the four formats written out in full with their section rules, a bank of status headline phrasings, blocker patterns, and the activity-to-result conversion table. Read it at step 2 and step 4.
references/examples.md
# Worked updates
Three runs from raw pile to finished update. The first one writes the same week twice, for two readers, which is the fastest way to see what altitude actually means.
## Contents
- [Example 1: one week, two readers](#example-1-one-week-two-readers)
- [Example 2: a team update in Progress / Plans / Problems](#example-2-a-team-update-in-progress--plans--problems)
- [Example 3: the week where everything slipped](#example-3-the-week-where-everything-slipped)
- [What the three runs have in common](#what-the-three-runs-have-in-common)
---
## Example 1: one week, two readers
### The raw pile
> - signup rework went live tuesday
> - drop-off went from 31% to 22% over the week, first clean data we have
> - fixed 3 bugs from the support queue, released friday
> - started the onboarding flow, maybe half done
> - contract still sitting with legal, sent it 3 aug, chased once
> - two days lost to the incident on wednesday
> - onboarded the new starter, they're picking up their own tickets monday
> - lots of meetings
### Sorted
| Bucket | Items |
|---|---|
| Shipped | Signup rework live; three bugs fixed and released; new starter self-sufficient |
| In flight | Onboarding flow, about half |
| Stuck | Contract with Legal since 3 Aug |
| Discard | "Lots of meetings". The Wednesday incident stays, but as context on why onboarding is only half done |
### Version A: for the manager
Format: Done / Doing / Blocked. Altitude: outcome level.
> **Status: on track, one item waiting on Legal.**
>
> **Done**
> - Signup rework live since Tuesday. Drop-off fell from 31% to 22% over the first full week, and this is the first clean data we have on it.
> - Three support-queue bugs fixed and released Friday.
> - New starter is taking their own tickets from Monday.
>
> **Doing**
> - Onboarding flow, roughly half built. Wednesday's incident cost two days, so this finishes mid-next-week rather than Friday.
>
> **Blocked**
> - Contract has been with Legal since 3 Aug. I need sign-off before it goes to the client. Chased once; if it does not land by Friday the client call moves a week.
### Version B: for leadership
Format: leadership update. Altitude: impact level.
> **Signup: on track.** Conversion improved 9 points after the signup rework went live Tuesday, measured over the first full week of clean data. Onboarding work is next and is running a few days late after Wednesday's incident. One thing needs attention: the client contract has been with Legal since 3 August and is now holding a client call.
### What changed between them
| | Manager | Leadership |
|---|---|---|
| Words | 138 | 71 |
| Bug fixes | Listed | Gone |
| New starter | Listed | Gone |
| Nadia / Legal | Named as a chase | Named as a thing needing attention |
| The 9 points | Stated with the raw percentages | Stated as the headline |
| The incident | Explains the slip | One clause |
**Why this works:** the facts are identical and nothing was inflated in either direction. What moved is grain. The manager needs to know what to expect next week; the executive needs one number and one thing they can unblock. The bugs and the new starter are real work and correctly absent from the second version, because a VP cannot act on either.
---
## Example 2: a team update in Progress / Plans / Problems
### The raw pile
Platform team, six people, week of 12 May. Collected from chat and a scratch document.
> - finished the read replica migration, all four regions
> - api latency down, p95 from 340ms to 210ms
> - the deploy pipeline broke twice, both times the same cache issue, ben has a fix in review
> - hiring: two onsites done, one offer out
> - next week: start the write path, plus the quarterly dependency upgrade
> - we still don't have a second person who understands the deploy pipeline. ben is the only one. he's on leave in june
> - kicked off the incident review from the april outage, findings due end of month
### The update
> **Platform team - week of 12 May**
>
> **Progress.** Read replica migration is complete across all four regions, and p95 API latency dropped from 340ms to 210ms as a result. The deploy pipeline broke twice, both from the same caching issue; a fix is in review. Hiring is moving: two onsites done and one offer out. The April incident review is underway with findings due end of month.
>
> **Plans.** Start the write path of the migration, which is the larger half. Run the quarterly dependency upgrade. Land the deploy pipeline fix and get the incident review findings written up.
>
> **Problems.** One person understands the deploy pipeline and he is on leave in June. Two outages this month traced to it. We need a second person trained before the end of May, and that costs about a week of his time. Say the word and I will schedule it.
**Why this works:** the team is six people, so the altitude is features and outcomes rather than individual tasks, and individual names appear only where a name is the point. The Problems section carries the single most important sentence in the update, which is a key-person risk with a date attached and a specific cost to fixing it. That is a problem written as an ask, so a reader can act on it in one reply rather than filing it as a worry.
Note also that the two pipeline breakages appear in Progress, as context for the fix, rather than being hidden. Two outages will surface somewhere; reporting them alongside the fix is a much better position than having them raised by someone else.
---
## Example 3: the week where everything slipped
### The raw pile
> honestly a bad week. the vendor still hasn't given us API access, that's three weeks
> now. we couldn't start the integration. i spent most of the week on the workaround
> and then binned it because it wouldn't have scaled. sara was out sick. the demo
> we promised for friday didn't happen, i moved it to next thursday without asking
> anyone. one good thing, the reporting fix is done and out.
### The update, for a manager
> **Status: at risk. The integration has not started and the demo moved to Thursday 21st.**
>
> **What happened.** Vendor API access is now three weeks late and is the reason the integration has not started. I spent most of the week building a workaround and then abandoned it, because it would not have scaled past a few hundred records and would have cost us more later than the wait will. Sara was out sick. The reporting fix is done and released.
>
> **What I have moved.** The Friday demo is now Thursday 21st. I made that call on Wednesday and should have told you the same day rather than in this update.
>
> **What I need.** The vendor relationship is above my level. Three weeks of chasing has not worked and I would like you to escalate it. If access arrives by the 18th the integration still lands this month; after that it moves into next month and I will say so as soon as I know.
>
> **Next week.** Integration if access arrives. If not, I will finish the test coverage work that has been waiting, so the week is not lost either way.
**Why this works:** the status verdict is in the first line, in the reader's language, before any explanation. The abandoned workaround is reported as a decision with a reason rather than hidden as wasted time, which is what it would look like if the manager heard it from someone else. The late notification about the demo is owned in one sentence and not defended. Most importantly, the update contains a specific escalation ask with a date and a consequence, which converts a bad week into something the reader can act on. The contingency plan in the last line is what stops "at risk" reading as "stalled".
What is deliberately absent: any version of "it has been a difficult week", any apology beyond the one factual sentence, and any suggestion that the vendor delay was foreseeable.
---
## What the three runs have in common
1. Every line is a result or a state, never an activity. "Worked on", "continued", "had meetings about" appear nowhere in any of the three.
2. The most important item leads, regardless of when it happened. In the third example that meant opening with bad news, which is where bad news belongs.
3. Blockers name a person, a date and a consequence. "Waiting on Legal" became "with Legal since 3 Aug, need sign-off, client call moves if it misses Friday".
4. No number was invented. Where a metric was missing it was left out, and where the data was thin ("first clean data we have") the update said so.
5. Nothing was inflated and nothing was buried. The abandoned workaround, the two pipeline outages and the unannounced demo move are all in the updates, each in one sentence, each with what happens next.
references/formats.md
# The four formats, and the lines that fill them
Pick a format at step 2, then come back here at step 4 for the conversions and the phrasing. Keep whichever format you pick stable week to week; readers learn a shape and then skim it, and changing it costs them the skim.
## Contents
- [Progress / Plans / Problems](#progress--plans--problems)
- [Done / Doing / Blocked](#done--doing--blocked)
- [Leadership update](#leadership-update)
- [Standup note](#standup-note)
- [Status headline phrases](#status-headline-phrases)
- [Activity to result](#activity-to-result)
- [Blocker patterns](#blocker-patterns)
- [Words to cut](#words-to-cut)
---
## Progress / Plans / Problems
The workhorse for a recurring team or company update. Its advantage over the others is that it forces a forward-looking section, which people otherwise skip.
```text
[Team name] ([dates covered])
Progress: [what the team accomplished in the period]
Plans: [what the team will do in the next period of the same length]
Problems: [what is slowing the team down]
```
Rules:
- **One to three sentences per section.** Longer and the format stops working.
- **Readable in thirty to sixty seconds.** That is the design constraint, not a suggestion.
- **Matter-of-fact tone,** with metrics wherever they exist. This is not prose.
- **Same period each time,** almost always a week. Progress and Problems look back; Plans looks forward by the same span.
- **Altitude tracks team size.** A six-person team reports features and fixes. A department reports outcomes. A whole company reports hires, revenue, launches and nothing smaller.
- **Problems means slowing the team down:** missing people, blocked dependencies, a decision nobody has made, a deal that fell through. It is not a risk register and it is not a complaint box.
- **Name the team** in the header. An update without a team name is unattributable the moment it is forwarded.
Empty Problems section: write "Nothing blocking." Do not fill it.
## Done / Doing / Blocked
An individual's weekly update to a manager who tracks specific work.
```text
Status: [one line - on track / at risk / blocked, and why]
Done
- [result, with a number where one exists]
Doing
- [item - current state, expected finish]
Blocked
- [what is stuck - what you need - who from - by when]
```
Rules:
- Every Done line is a result someone else could verify.
- Every Doing line carries a state and a date. "In progress" alone is not a state.
- Blocked lines have all four parts or they are not blockers.
- "No blockers" is a complete Blocked section.
## Leadership update
For readers who need to act or to reassure someone else, not to follow along.
```text
[Project or area]: [status verdict].
[2-4 sentences: the results that moved, in numbers. The one risk that matters.
The decision you need from them, if any.]
```
Rules:
- **Impact only.** No task names, no internal code names, no tooling.
- **Numbers or nothing.** A leadership update without a figure gives the reader nothing to carry into their own meeting.
- **One risk, not five.** The one you would raise if you had thirty seconds.
- **State the decision needed explicitly,** or say plainly that nothing is needed.
- **Assume it gets forwarded.** Write nothing you would not want read one level up from your reader.
- Under 100 words. Usually well under.
## Standup note
A daily written standup for a team already in context.
```text
Yesterday: [what finished]
Today: [what you are on]
Blockers: [what is stopping you, or "none"]
```
Rules:
- Three lines. It is not a mini status report.
- Name the thing, not the effort. "Yesterday: export bug traced to the row limit."
- "None" is the correct blockers line most days.
- If a blocker repeats for three days, it belongs in the weekly update, not the standup.
## Status headline phrases
The first line does most of the work. It should be a verdict, not a summary.
| Situation | Headline |
|---|---|
| Everything moving, nothing at risk | "On track. Nothing needs you this week." |
| Moving, one dependency wobbling | "On track, one item waiting on [team]." |
| Date still holds but the margin is gone | "On track with no slack left. Any further slip moves the date." |
| Date is in danger | "At risk. [Thing] has not started and the cause is outside the team." |
| Date has moved | "[Thing] has moved to [new date]. Cause: [one clause]." |
| Stopped entirely | "Blocked since [date]. Nothing will move until [specific unblock]." |
| Quiet week by design | "Quiet week - [reason]. Back to normal pace from [date]." |
| Recovering | "Recovered. [Thing] is back on the original date after [what changed]." |
Three habits:
1. The verdict comes before the explanation, every time.
2. A moved date is stated as the new date, not as "slightly delayed".
3. "At risk" needs a named cause in the same sentence, or it reads as hedging.
## Activity to result
| Activity | Result |
|---|---|
| "Worked on the signup page" | "Signup page live; drop-off 31% to 22%" |
| "Continued the migration" | "Read replicas done across four regions; writes are next" |
| "Had meetings about pricing" | "Pricing agreed at three tiers; page goes up Thursday" |
| "Looked into the export bug" | "Export bug traced to the row limit; one day to fix, scheduled" |
| "Reviewed PRs" | Discard, unless review was the blocker on something |
| "Attended the planning offsite" | Discard, unless a decision came out of it - then report the decision |
| "Started the onboarding flow" | "Onboarding flow roughly half built, finishing mid-next-week" |
| "Supported the new starter" | "New starter is taking their own tickets from Monday" |
| "Fixed some bugs" | "Three support-queue bugs fixed and released Friday" |
| "Chased the vendor" | "Vendor API access is three weeks late; chased twice, needs escalation" |
The test: could someone else verify this line without asking you what you did all week?
## Blocker patterns
```text
[What is stuck] - [since when]. Need [specific thing] from [named person].
If it misses [date], [consequence].
```
| Weak | Usable |
|---|---|
| "Waiting on Legal" | "Contract with Legal since 3 Aug. Need sign-off to send to the client. Chasing Nadia; if it misses Friday the client call moves." |
| "Blocked on design" | "Waiting on final mobile screens from Rosa. Two days of build depend on them; I need them by Wednesday to hold the sprint." |
| "Need more resource" | "This needs a second person from 1 June. Without one the integration slips to July. Ben is the only candidate who knows the pipeline." |
| "Vendor is slow" | "Vendor API access is three weeks late. Chasing has not worked and this needs escalating above me. Access by the 18th keeps the date." |
An escalation ask should say what you have already tried. "Chased twice" is what turns a request into a reasonable one.
## Words to cut
| Cut | Because |
|---|---|
| "Worked on", "continued", "made progress on" | Activity language; convert to a result |
| "Various", "several", "a number of" | Say how many |
| "Successfully completed" | Completed is enough; "successfully" reads as surprise |
| "Just wanted to update you" | Start with the update |
| "As always", "as usual" | Filler in a document read for changes |
| "Unfortunately" | The bad news is already bad |
| "Slight delay", "minor slip" | Give the new date |
| "We're working hard on it" | Effort is not a status |
| "Circling back", "touching base" | Say what happened |
| "It has been a busy week" | True of every week; tells the reader nothing |
| Internal code names, in an upward update | Costs the reader a translation |
Install it
Claude Code (this project)
Unzip the download into .claude/skills/. The folder is already named right.
Claude Code (every project)
Unzip into ~/.claude/skills/ to use it everywhere.
claude.ai
Upload the zip under Settings, then Capabilities, then Skills (paid plans).
How to call it
Just describe the task. The description line inside the skill does the matching. Or call it directly:
/status-report-writerwrite my weekly status updateturn this list into a report for my managersummarise what I did this weekdraft a progress update for leadershipI need a 3P update for my team
Works beyond Claude
Skills use the open Agent Skills format. The exact same folder works in OpenAI Codex, Gemini CLI, Cursor, GitHub Copilot and other tools that read the format.
Using a plain chat app? Paste SKILL.md into ChatGPT or Gemini as instructions. You lose auto-triggering, but the method still works.
