Recurring Status Report
Produce a recurring (weekly/biweekly) status report by gathering signals from the team's tools and writing a tight, skimmable update for stakeholders. Scopes the report template and the exact data sources FIRST (sections, audience, reporting window, RAG/health convention), then a developer gathers the raw signals from issue trackers, PRs, metrics, and notes into a facts file, then a copywriter writes the polished report strictly from those gathered facts. Scoping the template before gathering is what keeps every recurring issue consistent and prevents the model from padding with prose. Use for weekly status updates, sprint reports, project health reports, stakeholder updates, and exec summaries.
Steps
Entry step: scope. Each step names the specialist role it wants; the full working prompt is expandable.
- Scope the reportplannerentry
lock the template, sources, window, and health convention
Show working prompt
Define the report contract BEFORE gathering anything. (1) Lock the section template — e.g. Headline / Health (RAG: Green-Amber-Red with the rule for each color) / Shipped this period / In progress / Blockers & risks / Next period / Metrics. (2) Name the EXACT data sources for each section (which repo, which board, which metric dashboard, which notes file) so gathering is unambiguous. (3) Set the reporting window (the date range this issue covers) and the audience (exec vs team — drives length and jargon). (4) Set length targets per section (e.g. Blockers ≤ 3 bullets). Write an acceptance-criteria checklist ('every section from the template is present', 'health has a justifying one-liner', 'every claim traces to a gathered fact', 'covers only the reporting window', 'skimmable in under two minutes') plus the template + source map to notes/scope.md via write_task_note AND the produces path. - Gather signalsdeveloper
pull raw facts from each named source into a facts file
Show working prompt
Collect the raw material for each section from the sources named in scope. For each source pull the items inside the reporting window only: merged PRs / closed issues (shipped), open in-progress items, anything labelled blocked or at-risk, and the current value (and prior value if available) for each tracked metric. Record everything as a flat, attributed list in notes/gather.md — one bullet per fact, each tagged with its source and the template section it feeds — NOT prose. Do not editorialize or summarize here; capturing accurate raw facts is the whole job. If a source is empty or unreachable, note that explicitly rather than guessing. Write the facts file via write_task_note and end with a per-section fact count.
- Write the reportcopywriter
compose the polished report from gathered facts
Show working prompt
Write report.md following the locked template exactly, using ONLY facts from notes/gather.md. Lead with a one-sentence headline and the health RAG plus its justifying one-liner. Turn the gathered bullets into tight, scannable prose — short bullets over paragraphs, numbers where they exist, and a stated next step for every blocker. Respect the per-section length caps; cut, don't pad. Every claim must trace to a gathered fact — invent nothing. End with the Next-period section as concrete intended outcomes. On a loop-back, fix only the sections the reviewer flagged. Write the report path and a confirmation that all template sections are present to notes via write_task_note.
- Evaluatereviewer
Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.
Show working prompt
QA report.md against the locked criteria. (1) Confirm every template section from notes/scope.md is present and in order; FAIL on any missing section. (2) Confirm the health RAG has a justifying one-liner consistent with the gathered blockers/metrics. (3) Trace 4-5 specific claims back to notes/gather.md; FAIL any claim with no supporting fact. (4) Check the window: nothing reported outside the locked date range. (5) Check skimmability and length caps — short bullets, no padding, readable in under two minutes. Write PASS/FAIL per criterion with the specific offending lines. Then route — this is the whole point of the loop: - **Every criterion PASSES →** call `advance_task_step({ ref, stepId: "evaluate", next: "finish" })`. - **Any criterion FAILS →** write the specific gaps to notes, then call `advance_task_step({ ref, stepId: "evaluate", next: "write" })` to loop back. The builder fixes exactly those gaps. Never route to `finish` while any criterion is unmet. The build phase's completion gate already blocked a grossly-incomplete deliverable; your job is the judgment an automated check cannot make (does it actually work, read well, look right). After ~3 unproductive loops, stop and report DONE_WITH_CONCERNS so the user can step in. - Finishdeveloper
All acceptance criteria met. Stamp a short summary and report DONE.
Show working prompt
Every acceptance criterion passed. Write a one-paragraph DONE summary to task notes via `write_task_note`: what was built, the deliverable path(s), and a one-line confirmation that each criterion is met. Then report DONE.
Triggers
Phrases that suggest this craftbook to a crew.
- weekly status report
- project update
- sprint report
- status update
- stakeholder report
Source
View this craftbook on GitHub · MIT license