docs-create-status-report

name	Docs: Create Status Report
description	{{ 𝚫𝚫𝚫 }} Create a status report that knows what you've done since the last one
when_to_use	When you need a periodic progress update for someone non-technical or semi-technical — checks in at a cadence, so read the previous report first.
model	haiku
disable-model-invocation	true
allowed-tools	["Read","Glob","Grep","Write","Bash(git:*)","Bash(python3:*)","Bash(~/.claude/library/scripts/git-doc-history.sh:*)"]
effort	low

Component	Description	Example
PROJECT-REPORT-NUMBER	3-digit incrementing number across all reports	001, 002, 015
YY-MM-DD-HHMM	Date and time (24hr)	26-01-13-1430
RECENT	Most significant change, max 3 words, kebab-case	csv-parser-complete

To determine PROJECT-REPORT-NUMBER, check existing reports in the output directory.

1. Read the roadmap — python3 "$HOME"/.claude/library/scripts/roadmap.py stats when a rich roadmap exists (check with roadmap.py detect), otherwise the newest file in docs/roadmaps/
2. Check recent work records in docs/dev-log/work-records/ for recent activity
3. Review git history in one command: "$HOME"/.claude/library/scripts/git-doc-history.sh {previous-report-path} . — commits, file changes and diff stat since the last report; accurate numbers, not estimates
4. Identify blockers from any TODO comments, failing tests, or documented issues
5. Read the previous status report in docs/dev-log/status-reports/ to understand what was last reported as completed, in progress, and upcoming

Report should exactly mirror template structure.

• Audience: One dev, one non-dev - explain capabilities, not implementation
• Section 1 (What Happened): 2-3 sentences, big picture narrative
• Section 2 (Shipped): 3-5 concrete deliverables described by what they do
• Section 3 (Currently Working On): Honest about current state, no percentages
• Section 4 (Up Next): 2-4 items, acknowledge uncertainty
• Section 5 (Worth Remembering): Include meaningful context - decisions, dead ends, learnings
• Group related work (e.g. "CSV parser with validation and tests")
• Avoid jargon - explain technical terms when used (e.g. "API endpoints (web addresses the app uses)")
• No sub-bullets or nested lists
• Use British English