FREESKILL v1.0UPDATED 2026-08

Weekly Status Updates

A status update that reports effort instead of position can remain green until the delivery date moves. This playbook reports position against plan, defines what each status owes the reader, and checks the draft before circulation.

A weekly status update gives stakeholders one reliable account of the project across email, Slack, or Microsoft Teams. It states what the project is for, whether delivery remains on schedule, and which risks or dependencies could change that.

Write the overview for a reader arriving cold. Do not assume last week’s message is open or that everyone in the channel remembers the context. Restate the project’s purpose each week instead of allowing the overview to shrink into shorthand.

Color is the fastest signal and often the first thing a reader acts on. It is also the part most likely to be wrong in one direction: green. Green means the full delivery path is on schedule, including dependencies. A team cannot call a project green when its own work is on time but a critical dependency has no committed date.

When evidence is incomplete, mark the status as at risk and state what is unknown. This gives dependent teams time to plan around the uncertainty before a date moves.

Green is a claim about dependencies too.

SIGNALS YOU NEED THIS

Your updates read as busy right up until the date is missed.

A project is green for six weeks and then red in one.

Nobody can tell from the update what would have to change to fix it.

REPLACES

Activity logs sent as status, verbal check-ins, and the green that nobody stress-tested.

PAIRS WITH

4 Blocker Business Reviews, The 3Ps Framework, and Successful Meetings.

0 of 4 steps complete

STEP 01Make the call first

Run the status call before writing the body, and do it silently. The color decides what the rest of the update has to carry. Calling the status first reduces the risk that the body is written to justify a preferred color. The call appears in the update; the working does not.

Write the overview from scratch, two or three lines, for a reader with
no background. Every week. Do not shorten it because the project is
well known by now: the audience is the stakeholder who missed a month.

**[Green / Yellow / Red / Complete / Complete late / Did not meet].**
[the goal, with its date. "Deliver the new pricing plans by 09/30/2026."]

[Where we stand, as of mm/dd/yyyy, in one or two sentences with the number.]

STEP 02Work the tests in order

Take the first test that fires. Complete and did not meet are decided by the date and the work; green, yellow and red are decided by the schedule and the dependencies. Check dependencies explicitly and separately from the project's own work.

IN ORDER, FIRST ONE THAT FIRES
Complete       every part done. Requires a completion date.
Complete late  done, after the original date. Original stays visible.
Did not meet   the date passed, all or part not achieved. Written DNM.
Red            at least one part will certainly miss the final date.
Yellow         at least one part off schedule, significant risk to the date.
Green          every part on schedule AND every dependency scheduled.

Cannot tell whether a dependency is scheduled? Then it is not scheduled.
Inputs too thin to call it at all? Status: call needed, and name in one
line exactly what has to be known. Do not average the evidence into yellow.

STEP 03Convert effort into position

Worked on, spent time on, and made progress on are not statuses. Each becomes what completed, what stage it reached, or what it is waiting on, with the date. Keep gaps in position. Deleting a line means there is nothing to report; a labeled gap means the answer is not yet known.

- [Highlight] What was completed, with the date it completed.
- [Lowlight] What slipped, stated as its consequence for the goal.

| Milestone | Status | Date |
|---|---|---|
| Completed milestone | Complete | mm/dd/yyyy |
| Next milestone | Not started / In flight / Blocked | Date needed |

Missing owner: Owner: unassigned. Missing number: Figure needed.
Missing link: Link needed. Never infer an owner from a job function.

STEP 04Attach what the color owes

A status without its required date is not finished. Yellow and red carry a revised date, or an explicit note that it is not yet known and what has to happen before one can be set. Complete late still shows the original date. Then check the draft and send: the update begins at the title line and ends at the last link.

Revised date: not yet known. Legal approval of the refund copy must be
received before a revised date can be set.

One sentence of justification names the specific part of the goal that is
off schedule, not the project's general condition.

NOTHING AFTER THE LAST LINK
This is an email someone forwards, and a note attached to the top of it
travels with it. No closing summary, no count of labeled gaps, and no offer
to revise. Prefer periods and colons; avoid improvised double hyphens. Treat
any ASCII-only rule as a technical artifact constraint.

Download the folder into your agent's skills directory. It uses only the material you provide and makes no remote calls.

skills/weekly-status-updates

weekly-status-updates/
├── SKILL.md                     ← the three modes and the guardrails
├── meta.yaml                    ← version, sources, test prompts, changelog
├── LICENSE.md                   ← MIT
├── assets/
│   ├── update-template.md       ← the update shape, written for a phone
│   ├── status-call.md           ← the six tests, worked in order
│   └── draft-check.md           ← the line-by-line check and the verdict
└── references/
    ├── writing-conventions.md   ← numbers, dates, effort versus position
    └── worked-example.md        ← an update where the honest color is worse

INVOKE IT LIKE THIS

"Write this week's status update for the project from these notes."

View source on GitHub Download ZIP v1.0

WORKS WITHClaude Code