• 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

  .

• 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

production/releases/[version]/changelog.md

docs/CHANGELOG.md

"No changelog data found for [version]. Run

/changelog [version]

first to generate the internal changelog, then re-run

/patch-notes [version]

."

1. Check

   .claude/docs/technical-preferences.md

   for any "tone", "voice", or "style" fields or sections.
2. Check

   docs/PATCH-NOTES-STYLE.md

   if it exists.
3. Check

   design/community/tone-guide.md

   if it exists.
4. If any source contains tone/voice/style instructions, extract them and apply them to the language and framing of the generated notes.
5. If no tone guidance is found anywhere, default to: player-friendly, non-technical language; enthusiastic but not hyperbolic; focus on what the player experiences, not what the developer changed.

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 instead of the built-in style templates (Brief / Detailed / Full). Fill in the template's sections with the categorized data.
3. If not found, use the built-in style templates as defined in Phase 4.

• 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

• "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)

• [Feature 1]
• [Feature 2]

• [Balance/mechanic change with before → after values]

• [Bug fix 1]
• [Bug fix 2]

• [Issue 1]

undefined

• [Change]: [explanation of what changed and why]

• [Improvement with context]

• Fixed [description of what players experienced]

• Fixed [description]

• Fixed [description]

• [Improvement players will notice]

• [Issue and workaround if available]

undefined

[Developer insight into a major change — why it was made, what was considered, what the team learned. Written in first-person team voice.]

---

• No internal jargon (replace technical terms with player-friendly language)
• No references to internal systems, tickets, or sprint numbers
• Balance changes include before/after values
• Bug fixes describe the player experience, not the technical cause
• Tone matches the game's voice (adjust formality based on game style)

• Run

  /release-checklist

  to verify all other release gates are met before publishing.
• Share the patch notes draft with the community-manager for tone review before posting publicly.