Release notes composer

When to run

• A release is cut / "draft the notes for 4.2" / recurring per release train

Computer scopes

• Engineering: shipped items in the release window with descriptions and linked tickets
• Support + product: feature requests and tickets linked to shipped items
• Docs: release-notes style guide and past published notes (voice corpus)

Workflow

1. Collect the shipped set for the window; exclude internal-only changes (infra, tests) unless they change customer-observable behavior — then describe the behavior, not the infra.
2. Translate each item to customer impact: what can they do now / what stopped hurting. Ground every claim in the item's actual scope; no aspirational adjectives the diff can't back.
3. Segment: features, improvements, fixes; order by breadth of impact.
4. For items with linked requests, note the loop-closure and draft the "you asked, we shipped" callouts — and generate the list of requesting accounts for CS to notify personally.
5. Match house voice against the style corpus; flag any item needing docs before announce.
6. Deliver draft for PM/PMM approval; on approval, publishing is the human's click.

Guardrails

• Autonomy: L1. Drafts only; nothing publishes itself.
• No feature is announced beyond what shipped — partial rollouts and flags are stated as such.
• Security fixes follow the disclosure guide: acknowledged, never detailed.

Output

Eval fixtures

• Set: 5 sandbox releases (90 items) with gold customer-impact phrasings and 12 items linked to seeded requests; 4 internal-only items that must be excluded; 2 flag-gated partials.
• Rubric: translation quality vs. gold rubric; exclusion correctness; requester list complete; partial-rollout honesty.
• Ship gate: exclusion and requester-list errors 0; overclaim rate 0.