patch-notes skill

!bash "${CLAUDESKILLDIR}/../../hooks/yaml-helper.sh" resolve_config --keys automation

Automation mode: Resolve modes.automation (project.local.yaml → project.yaml → default collaborative). Every AskUserQuestion call and every file write follows .claude/docs/automation-modes.md (collaborative asks always · guided major-only · autonomous logs and proceeds; automationalwaysask categories always prompt).

Provenance check — before reading any history

Confirm the history you are about to read belongs to THIS game. Run this before Phase 2 and stop if it fails.

1. Sample the recent log: git log --oneline -20.
2. Classify every commit in the range, one at a time, into exactly one of:

art, audio, UI, a bug in any of those.

• Game — changes the game the player plays: mechanics, content, balance,

subjects naming skills, hooks, agents, the test plan, CI, the framework's own docs. Excluded from player-facing notes, but not a reason to stop.

• Framework / maintenance — changes CCGS itself or the project's tooling:

not one to write player copy from.

• Unclear — treat as framework. A commit you cannot confidently place is

1. Then decide from the counts:

of how many you used, so the reader can see the filter ran.

• At least one Game commit → proceed, using only those. Say how many

• Zero Game commits → stop, using the message below.

**Filter per commit; do not stop on a repo that merely contains maintenance

work.** Every project built on this framework accumulates commits touching

hooks, CI and skills — the game repo is the framework repo. An earlier

version of this check listed "subjects naming the framework, its skills, hooks,

agents or test plan" as a hard STOP, which fires on virtually every real

project and contradicted its own step 2 whenever a history was mostly the

game's. The danger was never that such commits exist; it is that they get

rendered as player-facing copy. Excluding them addresses that exactly, and

a repo-level stop does not.

Corroborate before you proceed, cheaply: the Game commits should name systems that appear in design/ and src/. If they name a product those directories never mention, that is the real wrong-history signal — stop.

If no commit in the range is this game's, say so and stop:

"The git history in this repo does not appear to belong to [game]. The recent

commits describe [what they actually describe]. I cannot generate release notes

from it — point me at the right history, or supply the change list directly."

Why this is a hard stop, not a warning. This exact failure is real, not hypothetical: a batch of framework-internal commits produced player-facing copy reading "Fixed an issue where progress from your last session could be lost on launch" — a session-hook timeout rendered as a gameplay fix for a game with no save system. It was fluent, plausible, and entirely false. A reader cannot tell the difference; only this check can.

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

If no changelog data is available (neither production/releases/[version]/changelog.md nor a docs/CHANGELOG.md entry for this version exists, and git log is empty or unavailable):

"No changelog data found for [version]. Run /changelog [version] first to generate the

internal changelog, then re-run /patch-notes [version]."

Verdict: BLOCKED — stop here without generating notes.

Phase 2b: Detect Tone Guide and Template

Tone guide detection — before drafting notes, check for writing style guidance:

fields or sections.

1. Check .claude/docs/technical-preferences.md for any "tone", "voice", or "style"

them to the language and framing of the generated notes.

1. Check docs/PATCH-NOTES-STYLE.md if it exists.
2. Check design/community/tone-guide.md if it exists.
3. If any source contains tone/voice/style instructions, extract them and apply

player-friendly, non-technical language; enthusiastic but not hyperbolic; focus on what the player experiences, not what the developer changed.

1. If no tone guidance is found anywhere, default to:

Template detection — check whether a patch notes template exists:

instead of the built-in style templates (Brief / Detailed / Full). Fill in the template's sections with the categorized data.

1. Glob for docs/patch-notes-template.md and .claude/docs/templates/patch-notes-template.md.
2. If found at either location, read it and use it as the output structure for Phase 4

1. If not found, use the built-in style templates as defined in Phase 4.

Phase 3: Categorize and Translate

Categorize all changes into player-facing categories:

• New Content: new features, maps, characters, items, modes
• Gameplay Changes: balance adjustments, mechanic changes, progression changes
• Quality of Life: UI improvements, convenience features, accessibility
• Bug Fixes: grouped by system (combat, UI, networking, etc.)
• Performance: optimization improvements players might notice
• Known Issues: transparency about unresolved problems

Translate developer language to player language:

• "Refactored damage calculation pipeline" → "Improved hit detection accuracy"
• "Fixed null reference in inventory manager" → "Fixed a crash when opening inventory"
• "Reduced GC allocations in combat loop" → "Improved combat performance"
• Remove purely internal changes that don't affect players
• Preserve specific numbers for balance changes (damage: 50 → 45)

Phase 4: Generate Patch Notes

Brief Style

# Patch [Version] — [Title]

**New**
- [Feature 1]
- [Feature 2]

**Changes**
- [Balance/mechanic change with before → after values]

**Fixes**
- [Bug fix 1]
- [Bug fix 2]

**Known Issues**
- [Issue 1]

Detailed Style