Status Updates skill for Claude Code
Readers know where it stands in 30 seconds. Claude writes status updates from facts, not memory. It pulls merged PRs, tracker milestones, and metrics, sets red, amber, or green against written criteria, leads with a bottom line and the ask, reports progress against planned dates, lists risks with owners and mitigations, and cuts activity that does not change the reader's picture. Bad news surfaces the week it is known.
- name
status-updates - size182 lines · ≈1,700 tokens
- files1
- licenseMIT
- updated
What Claude sees before loading it
This description is the only part of the skill that sits in context all the time. Claude reads it to decide when to load the full playbook below.
description: Writes weekly status updates, project reports, and executive summaries - bottom line first, red/amber/green status with explicit criteria, progress against milestones rather than activity lists, risks with impact, owner, and mitigation, concrete asks with deadlines, metrics with trends, and a consistent template - drafted from issue trackers, merged pull requests, and meeting notes. Use when writing a weekly update, sprint or project status report, a stakeholder or leadership summary, a monthly program review, or when updates are long, ignored, or surprise people with late bad news.Try asking
- Draft this week's status update for the payments migration from the merged PRs and Jira
- Turn this long project report into a five-line executive summary for leadership
- Set up a weekly update template with clear red, amber, green criteria for our program
Use it when
- Writing a weekly team update or project status report
- Summarizing a project for executives or stakeholders
- Updates are long, ignored, or hide bad news until late
- Standardizing reporting across several projects
Skip it when
- You are writing up an incident after it happened — use postmortems
- You are writing release notes for users — use changelog-release-notes
How to check the result
A reader outside the team can state the status, the main change, and their action after reading only the first three lines, and every number traces to a source.
The common mistake it prevents
Reporting green with a list of worrying notes underneath, so the slip arrives as a surprise when it finally turns red.
A status update works when a busy reader learns in 30 seconds whether the project is on track, what changed since last time, and what they need to do, and when bad news shows up the first week it is known rather than the week it lands. A list of everything the team touched is an activity log, not a status.
Ground rules
- Bottom line up front: status, the one-sentence why, and any ask, in the first three lines.
- Report against the plan (milestones, dates, metrics), not against effort.
- Status color has written criteria. Amber is not a mood.
- Bad news early, with a plan. A project that goes from green to red in one week was amber and nobody said so.
- Every ask names a person, a decision or action, and a date.
- Same template, same day, every time. Readers learn where to look.
Pick the format
| Audience | Format | Length |
|---|---|---|
| Own team | Weekly update: done, next, blocked | 5-15 bullets |
| Cross-functional stakeholders | Project status: status, milestones, risks, asks | Half a page |
| Executives | Executive summary: status, decision needed, impact, 3 bullets of context | 5-8 lines |
| Monthly or quarterly review | Program report: outcomes vs goals, metrics trend, top risks, next period | 1-2 pages |
When one update serves several audiences, put the executive summary first and the detail below a clear divider.
Workflow
- [ ] 1. Gather facts: tracker, merged PRs, metrics, notes, last update
- [ ] 2. Compare against the plan; decide status color by the criteria
- [ ] 3. Write the bottom line
- [ ] 4. Write milestones/progress, then risks, then asks
- [ ] 5. Cut activity that does not change the reader's picture
- [ ] 6. Check numbers, dates, links, and names
- [ ] 7. Send on schedule; track asks and risks to next update1. Gather facts
Pull, do not recall:
git log --since="1 week ago" --merges --pretty="%h %s (%an)" origin/main
gh pr list --state merged --search "merged:>=$(date -v-7d +%F)" --json number,title,authorPlus: tracker queries for the milestone (closed vs open, moved dates), dashboards for the
project metrics, decisions from meeting notes, and the previous update (to report what
changed and close out last week’s asks). On Linux use date -d '7 days ago' +%F.
2. Status criteria
Define once per project and include a link in every update:
| Status | Criteria |
|---|---|
| Green | Next milestone on track for its date; no unmitigated high risk |
| Amber | Next milestone at risk (up to ~1-2 weeks slip) or a high risk without a confirmed mitigation; recoverable within the team |
| Red | Milestone will slip beyond tolerance, scope must change, or help is needed from outside the team |
Report the change too: “Amber (was Green)”. Never hold a red status back for one more week to try to fix it quietly.
3. Bottom line
Status: Amber (was Green). Payments migration launch moves from Oct 28 to Nov 4
because the bank sandbox outage cost 4 days of testing. Ask: Priya to approve the
revised cutover window by Thursday.One to three sentences: color, the most important change and its cause, the ask.
4. Body
Progress against milestones:
| Milestone | Date (planned -> current) | Status | Note |
|---|---|---|---|
| Sandbox certification | Oct 14 -> Oct 18 | Done | Passed 212/212 cases |
| Shadow traffic 10% | Oct 21 | On track | Running since Oct 17, error parity 99.98% |
| Cutover | Oct 28 -> Nov 4 | At risk | Depends on revised window approval |Risks:
| Risk | Impact if it happens | Likelihood | Mitigation | Owner |
|---|---|---|---|---|
| Bank changes API before cutover | 1-2 week slip | Low | Contract test runs nightly against sandbox | Sam |
| On-call coverage gap during cutover week | Slower incident response | Medium | Swap requested with platform team | Lee |Asks:
- **Priya**: approve the Nov 4 02:00-04:00 UTC cutover window **by Thu Oct 23**.
- **Platform team**: confirm on-call swap for Nov 3-5 **by Fri Oct 24**.Metrics (when the project has them): current value, target, and trend since last update, e.g. “p95 checkout latency 410 ms (target 350 ms, last week 460 ms)”.
For the team weekly format, three headings suffice: Shipped (outcomes, with links), Next (commitments for the coming week), Blocked / needs help.
5. Cut
Remove items that do not change the reader’s picture of progress, risk, or required action. Translate activity into outcomes:
| Activity (cut or rewrite) | Outcome |
|---|---|
| “Had several meetings with the data team” | “Agreed schema with data team; migration script unblocked” |
| “Worked on performance” | “p95 latency down from 460 to 410 ms after query caching” |
| “Fixed bugs” | “Closed 9 of 12 launch-blocking bugs; 3 remain, all with owners” |
Use plain words and spell out acronyms for readers outside the team. Use prose-editing
for a deeper edit pass when an update has grown long.
6. Check
- Every date has a day and month; time zones where it matters.
- Every number is from a source and comparable to last week’s.
- Every link opens for the audience (permissions).
- Names and ownership are current; asks are addressed to people who will see the update.
7. Send and follow through
- Same channel, same day and time each week; subject line includes project, date, and
status:
[Payments migration] Oct 20 - Amber. - Start the next update by closing last week’s asks and risks: resolved, still open, or escalated.
- If an ask goes unanswered twice, escalate it in the bottom line.
Executive summary template
**<Project>: <Status> (was <Status>)** - <date>
**Bottom line:** <one sentence on where it stands and why>
**Decision needed:** <what, from whom, by when> (or "None this week")
**Impact:** <customer, revenue, or date impact in numbers>
- <Most important progress, one line>
- <Top risk and mitigation, one line>
- <What happens next and when, one line>
Detail: <link>Gotchas
- Watermelon status (green outside, red inside): green with a list of worrying notes. If the notes worry you, the status is amber.
- Updates that change format every week force readers to hunt; keep the template.
- Burying the ask in paragraph four means nobody acts on it.
- Percent-complete numbers without a definition (“80% done”) mislead; report milestones and remaining work instead.
- Naming individuals for failures in a broad update damages trust; describe the problem and the fix.
Output contract
Subject: [<Project>] <Date> - <Status>
Bottom line (1-3 sentences, includes ask)
Milestones table (planned -> current date, status, note)
Risks table (impact, likelihood, mitigation, owner)
Asks (person, action, deadline)
Metrics (value, target, trend) - optional
Since last update: asks closed/open, status change reasonAbout this skill
Written and maintained by the Claude Skills editors to the same editorial standard as every skill in the directory: a selective trigger, a real workflow, known pitfalls and a verification step. First published , last updated . MIT licensed.