patch-notes

Phase 1: Parse Arguments

• version: the release version to generate notes for (e.g., 1.2.0)
• --style: output style — brief (bullet points), detailed (with context), full (with developer commentary). Default: detailed.

If no version is provided, ask the user before proceeding.

Phase 2: Gather Change Data

• Read the internal changelog at production/releases/[version]/changelog.md if it exists
• Also check docs/CHANGELOG.md for the relevant version entry
• Run git log between the previous release tag and current tag/HEAD as a fallback
• Read sprint retrospectives in production/sprints/ for context
• Read any balance change documents in design/balance/
• Read bug fix records from QA if available