Weekly Status Report
Synthesize a week of scattered raw inputs into one scannable, audience-ready status report.
Report only what the inputs support — never invent accomplishments, metrics, or dates, and
never upgrade routine work into a highlight without evidence of impact.
Steps
- Get the raw material. Accept pasted notes, forwarded emails, task-tool exports, meeting
notes, and last week's report if available. Ask for: report period, the user's role, the
audience (manager / leadership / client), and any required template.
- Classify every item, citing the input it came from:
- Highlights — only items with stated impact (shipped, resolved, approved, measured).
- Progress — grouped by project/workstream, with % or state only if the inputs give it.
- Blockers & risks — each with severity (High/Medium/Low) and what unblocks it. If the
inputs don't support a severity, ask rather than guess.
- Next week — priorities, deadlines, dependencies.
- Render the report under one page: HIGHLIGHTS (3–5) → PROGRESS → BLOCKERS & RISKS (table:
Item | Severity | Status | Needed) → NEXT WEEK → optional NOTES/FYI. Bold key items.
- Verify before presenting: every claim traces to a line of input; anything the user's raw
notes mention that was dropped is listed back ("omitted: …") so nothing disappears
silently. If last week's report was provided, note carryover items explicitly.
- Offer audience variants from the same material on request (3-bullet skip-level version,
client-toned version, team-detail version) — same facts, different framing.
Constraints
- The user reviews and sends the report themselves; never deliver it anywhere.
- No metric appears unless it is in the inputs verbatim; flag wanted-but-missing metrics.
- If the inputs are thinner than ~5 items, say so and produce a short-form update instead of
padding a full template.
Full walkthrough, examples, and variations: recipes/Recipe-002-Weekly-Status-Report-Generation.md.
1---2name: weekly-status-report3description: Turn scattered weekly updates (notes, emails, task exports, meeting notes) into a structured status report with highlights, progress, severity-rated blockers, and next-week priorities. Use when the user says "write my status report", "weekly update", "summarize my week for my manager", or pastes a raw dump of what happened this week.4---5
6# Weekly Status Report
7
8Synthesize a week of scattered raw inputs into one scannable, audience-ready status report.
9Report only what the inputs support — never invent accomplishments, metrics, or dates, and
10never upgrade routine work into a highlight without evidence of impact.
11
12## Steps
13
141. Get the raw material. Accept pasted notes, forwarded emails, task-tool exports, meeting
15 notes, and last week's report if available. Ask for: report period, the user's role, the
16 audience (manager / leadership / client), and any required template.
172. Classify every item, citing the input it came from:
18 - **Highlights** — only items with stated impact (shipped, resolved, approved, measured).
19 - **Progress** — grouped by project/workstream, with % or state only if the inputs give it.
20 - **Blockers & risks** — each with severity (High/Medium/Low) and what unblocks it. If the
21 inputs don't support a severity, ask rather than guess.
22 - **Next week** — priorities, deadlines, dependencies.
233. Render the report under one page: HIGHLIGHTS (3–5) → PROGRESS → BLOCKERS & RISKS (table:
24 `Item | Severity | Status | Needed`) → NEXT WEEK → optional NOTES/FYI. Bold key items.
254. Verify before presenting: every claim traces to a line of input; anything the user's raw
26 notes mention that was dropped is listed back ("omitted: …") so nothing disappears
27 silently. If last week's report was provided, note carryover items explicitly.
285. Offer audience variants from the same material on request (3-bullet skip-level version,
29 client-toned version, team-detail version) — same facts, different framing.
30
31## Constraints
32
33- The user reviews and sends the report themselves; never deliver it anywhere.
34- No metric appears unless it is in the inputs verbatim; flag wanted-but-missing metrics.
35- If the inputs are thinner than ~5 items, say so and produce a short-form update instead of
36 padding a full template.
37
38Full walkthrough, examples, and variations: `recipes/Recipe-002-Weekly-Status-Report-Generation.md`.
gabrielmoreira