Release Notes

FRB1 Release Notes

Drafts the release notes markdown from git history since the previous release. Does not bump versions, trigger workflows, or publish the release — that's [[release]]. Only writes the draft.

Modeled on the Gum repo's gum-monthly-release skill (same hybrid curated + full changelog format, same fan-out-to-avoid-summarization fix), adapted for one structural difference: FRB1's history is not PR-only. A recent 3.5-month window had 88 commits but only 16 carried a (#N) PR suffix — the rest are direct commits, mostly by vchelaru. So commits, not PRs, are the canonical unit here; PR numbers are used opportunistically for the ~15-20% that have one, not as the primary iteration axis.

Ask first, don't guess

Same collaboration stance as Gum's skill: when categorization, intent, or which commits belong together is unclear, stop and ask, or drop it in ## Open Questions. Don't invent user-impact descriptions from a one-line commit message.

Step 1: Front-loaded questions

Ask up front, one message, numbered:

1. Release tag. Recent convention: Release_<Month>_<DD>_<YYYY> (e.g. Release_September_23_2025) — some older tags drop the Release_ prefix, ignore those as precedent.
2. Previous-release boundary. Propose the most recent tag from gh release list --repo vchelaru/FlatRedBall --limit 5 and confirm. Cross-check it: if a newer published release exists between the proposed boundary and main, flag it before proceeding (using a stale boundary double-counts commits already shipped).
3. Breaking changes this release? If yes, get the explanation now (no separate migration-doc convention confirmed for FRB1 yet — ask the user how they want it described, don't assume a doc URL pattern exists).

Step 2: Gather commits

The canonical set is every commit between the boundary tag and main, not a PR search:

git fetch origin --tags -q
git log --no-merges <prev-tag>..origin/NetStandard --format="%H|%an|%s"

For the ~15-20% of subjects ending in (#N), that's a real PR — gh pr view N --repo vchelaru/FlatRedBall --json title,body,author,files gets richer context if the subject alone is too sparse. For the rest, there is no PR to look up; read the commit itself (git show <hash>) for diff context when the subject line alone doesn't say enough.

Chores are always omitted, no confirmation needed. A commit with no end-user-visible effect — repo hygiene/dead-code deletion, CI-only changes, test-only additions, doc/process-only edits (including changes to this repo's own skills/CLAUDE.md) — never appears in the public notes and never goes in Open Questions. Judgment calls about what counts as user-facing (ambiguous scope, disputed categorization, a commit that's arguably both) still go in Open Questions — this only covers the clear-chore case.

Step 3: Fan out per-commit-batch expansion to parallel subagents

Same structural fix as Gum's skill, adapted to commits: the main agent never reads the full commit list itself. Batch the canonical commit set into groups of ~8-10, spawn one subagent per batch in parallel, each returning finished user-impact bullets for its batch.

The FRB1-specific judgment call, different from Gum's PRs-only case: since commits (not PRs) are the unit, a run of several small sequential commits often builds one feature incrementally (e.g. "First pass at collision fixes" → "Improved camera controlling entity to properly use padding..." → "Handle passing back and forth now works"). The subagent should consolidate adjacent same-theme commits into one bullet when they clearly form a single unit of work, and keep them separate when they're genuinely distinct changes that happen to be adjacent in history. This cuts both ways versus Gum's rule (which only ever expands a roll-up PR into more bullets, never consolidates) — judge each batch on its own merits.

Subagent prompt should cover: the batch's commit hashes+subjects+authors, instruction to run git show <hash> for any commit whose subject doesn't already say what changed, the consolidate-vs-separate judgment above, and the same user-impact-first clarity bar as Step 5 below. Tell the subagent to mark clear chores (see Step 2) with an empty bullet — those get dropped silently, not routed to Open Questions. Return one JSON object per resulting bullet: { "commits": ["<hash>", ...], "author": "name", "section": "...", "bullet": "...", "confidence": "high"|"medium"|"low", "note": "..." }.