patch-notes
Skill1 starsChanged 8 months agoMITView on GitHub
Generate player-facing patch notes from git history, sprint data, and internal changelogs. Translates developer language into clear, engaging player communication.
12 other projects use a version of this, 8 of them edited.
Adopted by
Most recently taken up by
- striderZA/OpenCodeGameStudiosedited, first seen Nov 4, 2026
- Donchitos/Claude-Code-Game-Studiosedited, first seen Oct 19, 2026
- venus2099/codex-game-studiosedited, first seen Oct 17, 2026
- HunLuanZhiZhu/Game-Studios-Pluginedited, first seen Oct 5, 2026
- dawn840705/claude-code-studiosedited, first seen Aug 28, 2026
- dawn840705/codex-code-studiosedited, first seen Aug 28, 2026
Other versions12 projects use a version of this.
Word for word · 1
- CoralGame/Claude-Code-Game-Studios★ 19100% same
Edited · 8
- Donchitos/Claude-Code-Game-Studios★ 27k27% same
- striderZA/OpenCodeGameStudios★ 11849% same
- dawn840705/codex-code-studios★ 1743% same
- lilangMax/ClaudeCodeGameStudios★ 849% same
- hongyuanc/codex-game-studios★ 536% same
- dawn840705/claude-code-studios★ 144% same
- HunLuanZhiZhu/Game-Studios-Plugin★ 149% same
- venus2099/codex-game-studios★ 127% same
Wrote their own version · 3
- pixel-cellar/Claude-Code-Game-Studios★ 324same name
- cenconq25/claude-code-app-studio★ 40same name
- CodePhobiia/claude-roblox-game-studio★ 9same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository37 other files it gives its agents.
- AGENTS.mdAGENTS.md
- architecture-decisionSkill
- asset-auditSkill
- balance-checkSkill
- brainstormSkill
- bug-reportSkill
- changelogSkill
- code-reviewSkill
- design-reviewSkill
- design-systemSkill
- estimateSkill
- gate-checkSkill
- hotfixSkill
- launch-checklistSkill
- localizeSkill
- map-systemsSkill
- milestone-reviewSkill
- onboardSkill
- perf-profileSkill
- playtest-reportSkill
- project-stage-detectSkill
- prototypeSkill
- release-checklistSkill
- retrospectiveSkill
- reverse-documentSkill
- scope-checkSkill
- setup-engineSkill
- sprint-planSkill
- startSkill
- team-audioSkill
- team-combatSkill
- team-levelSkill
- team-narrativeSkill
- team-polishSkill
- team-releaseSkill
- team-uiSkill
- tech-debtSkill
The file
We split this skill into the rules it gives an agent
9 rules. 5 are common, 1 is distinctive, and 3 are very specific to this project.
5
Common
Most of the 10 edited versions we read keep these.
1
Distinctive
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 9
When this skill is invoked:
- Very specific: line 17
Read the internal changelog at production/releases/[version]/changelog.md if it exists
- Common: line 18
Run git log between the previous release tag and current tag/HEAD
- Very specific: line 19
Read sprint retrospectives in production/sprints/ for context
- Very specific: line 20
Read any balance change documents in design/balance/
- Common: line 21
Read bug fix records from QA if available
- Common: line 35
Remove purely internal changes that don't affect players
- Common: line 110
No internal jargon (replace technical terms with player-friendly language)
- Common: line 111
No references to internal systems, tickets, or sprint numbers
“Common” is measured: kept by at least 6 in 10 of the 10 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
When this skill is invoked:
- Parse the 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.
- Gather change data from multiple sources:
- Read the internal changelog at
production/releases/[version]/changelog.mdif it exists - Run
git logbetween the previous release tag and current tag/HEAD - Read sprint retrospectives in
production/sprints/for context - Read any balance change documents in
design/balance/ - Read bug fix records from QA if available
- Read the internal changelog at
- 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)
- Generate the patch notes using the appropriate style:
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
# Patch [Version] — [Title]
*[Date]*
## Highlights
[1-2 sentence summary of the most exciting changes]
## New Content
### [Feature Name]
[2-3 sentences describing the feature and why players should be excited]
## Gameplay Changes
### Balance
| Change | Before | After | Reason |
| ---- | ---- | ---- | ---- |
| [Item/ability] | [old value] | [new value] | [brief rationale] |
### Mechanics
- **[Change]**: [explanation of what changed and why]
## Quality of Life
- [Improvement with context]
## Bug Fixes
### Combat
- Fixed [description of what players experienced]
### UI
- Fixed [description]
### Networking
- Fixed [description]
## Performance
- [Improvement players will notice]
## Known Issues
- [Issue and workaround if available]Full Style
Includes everything from Detailed, plus:
## Developer Commentary
### [Topic]
> [Developer insight into a major change — why it was made, what was considered,
> what the team learned. Written in first-person team voice.]- Review the output for:
- 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)
- Save the patch notes to
production/releases/[version]/patch-notes.md, creating the directory if needed. - Output to the user: the complete patch notes, the file path, a count of changes by category, and any internal changes that were excluded (for review).
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

