Project Status Report

What this does

Pulls scattered updates from the week into a one-page status report a sponsor can read in two minutes: where the project stands, what moved, what's coming, what's worrying and what needs a decision. You stop rewriting the same email three ways.

What you give it

• The raw material - update emails, task board exports or screenshots, stand-up notes, anything current, pasted or attached
• The previous status report, so movement can be shown (optional but recommended)
• The reporting period and audience - sponsor, steering committee or client (optional - you'll be asked if it's unclear)
• Your view on the overall RAG status, if you've already formed one (optional)

How it does the work

1. Read all the source material before writing anything.
2. Ask up to 3 short questions if essentials are missing - the reporting period, the audience, or whether a known problem is safe to name in writing. Then proceed with what you have.
3. Sort every scrap of input into five buckets: done this period, in progress, coming next, risks and issues, decisions needed. Discard duplicates and chatter.
4. Compare against the previous report if provided. What was "coming up" last time and didn't happen matters - name it plainly, don't bury it.
5. Set the overall RAG status from the evidence. Green means on track; Amber means at risk but recoverable within the team; Red means intervention needed. If the user gave a rating, use it - but if the evidence points the other way, say so before drafting and let them decide.
6. Track risk and issue movement, not just existence: new, worsening, improving, closed. A risk that's sat unchanged for three reports deserves a note.
7. Write the decisions-needed section as asks, not observations - who needs to decide what, by when. Missing dates or owners get [to confirm].
8. Draft the report using the output layout. One page. If it runs longer, cut detail from "progress", never from "risks" or "decisions needed".
9. Do a client-readiness pass: no blame, no names attached to failures, no internal shorthand. The report can be forwarded anywhere without edits.
10. Show the draft and flag anything you rated differently from the user's inputs.

Output layout

# Status Report - [Project name]

**Period:** [date] to [date]
**Prepared for:** [audience]
**Overall status:** [Green / Amber / Red] - [one line on why]

## Summary
[Two or three sentences: the state of the project in plain words.]

## Progress this period
- [What was completed or moved forward]
- [Item]

## Coming up
- [What's planned for next period]
- [Item]

## Risks and issues
| Item | Type | Movement | Status | Action |
|------|------|----------|--------|--------|
| [Risk or issue] | [Risk / Issue] | [New / Worsening / Improving / Closed] | [R / A / G] | [What's being done] |

## Decisions needed
| Decision | Who decides | Needed by |
|----------|-------------|-----------|
| [The ask, stated plainly] | [Name or role] | [Date or [to confirm]] |

## Notes
[Anything else the reader must know, or remove this section.]

Rules

• Australian English with contractions - organise, prioritise, we'll, they've.
• Never invent progress, percentages, dates or metrics. If the source doesn't say it, it's [to confirm].
• Bad news goes in plainly and early. A report that hides an issue is worse than no report.
• No jargon, no acronyms the audience might not know - expand on first use.
• One page is the contract. Detail lives in the source material, not the report.
• RAG ratings must trace to evidence in the inputs. If you can't justify a Green, it isn't one.
• This skill reports status. It doesn't write recovery plans - if the user needs one, say so and offer to help separately.