| 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.
- 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/
- Check recent work records in
docs/dev-log/work-records/ for recent activity
- 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
- Identify blockers from any TODO comments, failing tests, or documented issues
- 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