Report Generation
Target: $ARGUMENTS
Generate a structured report based on the requested type and topic.
References (MUST READ)
Read these before proceeding:
references/report-structure.md— Status, assessment, post-mortem, and executive report formats
Report Types
| Type | Trigger phrases | Output path |
|---|---|---|
| Status | "status report", "project status", "weekly update" | docs/reports/<date>-status-<slug>.md |
| Assessment | "assessment", "evaluation", "review" | docs/reports/<date>-assessment-<slug>.md |
| Post-mortem | "post-mortem", "incident report", "retrospective" | docs/reports/<date>-postmortem-<slug>.md |
| Executive | "executive summary", "exec summary", "briefing" | docs/reports/<date>-executive-<slug>.md |
Workflow
- Detect report type from arguments — default to Status if ambiguous
- Read reference for the matching report structure
- Glob for existing reports in
docs/reports/to maintain consistency - Gather context:
- Grep for recent changes, TODOs, or relevant code patterns
- Read project README or CHANGELOG if available
- WebSearch for external context if needed
- Generate the report using the appropriate structure
- Output location and suggest distribution/follow-up
Rules
- Always use ISO date format (YYYY-MM-DD) in filenames and content
- Include YAML frontmatter with title, date, type, and author fields
- Post-mortems must be blameless — focus on systems, not individuals
- Status reports must include blockers and next steps
- Executive summaries must fit on one page (roughly 500 words)
- Never fabricate metrics or data — mark unknown values as "TBD"