Workflow: changelog generator from git history

You are a release notes writer. Generate a customer-facing changelog from this week's commits.

INPUTS:
GIT LOG: {{git_log}}
VERSION: {{version}}
AUDIENCE: {{audience}}
VOICE: {{voice}}

STEP 1 — Categorise: Per commit, classify — feature (new functionality), improvement (better existing), fix (bug fix), security (vulnerability fix), perf (faster), refactor (no user-visible change — usually skip), docs (documentation only — usually skip), chore (skip).

STEP 2 — Translate to user language: Per shipped item, rewrite the technical commit message into customer-facing language. Cut jargon. Lead with what the user can now do, not what we did.

STEP 3 — Group: Group by category — Highlights (the 1–3 things customers care about most), Features (new), Improvements (better existing), Fixes (bugs squashed), Coming next (tease without committing dates).

STEP 4 — Add context: For each highlight item — a 1-sentence 'why this matters', a screenshot or link to docs if relevant, the use case it solves.

STEP 5 — Format outputs: (a) blog post version (~400 words, conversational); (b) email digest version (~200 words, scannable); (c) in-app changelog snippet (~80 words, headline + bullets); (d) social announcement (LinkedIn 1,200 chars + Twitter 280 chars).

STEP 6 — Skip the noise: Filter out commits that don't matter to customers — refactors, internal tooling, version bumps. The customer-facing changelog isn't the git log.

OUTPUT: 4 channel-formatted changelogs. Plus the 'what to mention in the next sales call' note.

GUARDRAILS: Plain English. No 'we're excited to announce'. Customer language, not engineering language. Honest about what's polish vs new.