agentleFS
scotidevscotidev/GameDevStudio/.agents/skills/patch-notes/SKILL.md

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

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
  1. Distinctive:

    When this skill is invoked:

    line 9
  2. Very specific:

    Read the internal changelog at production/releases/[version]/changelog.md if it exists

    line 17
  3. Common:

    Run git log between the previous release tag and current tag/HEAD

    line 18
  4. Very specific:

    Read sprint retrospectives in production/sprints/ for context

    line 19
  5. Very specific:

    Read any balance change documents in design/balance/

    line 20
  6. Common:

    Read bug fix records from QA if available

    line 21
  7. Common:

    Remove purely internal changes that don't affect players

    line 35
  8. Common:

    No internal jargon (replace technical terms with player-friendly language)

    line 110
  9. Common:

    No references to internal systems, tickets, or sprint numbers

    line 111

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

When this skill is invoked:

  1. 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.
  2. Gather change data from multiple sources:
    • Read the internal changelog at production/releases/[version]/changelog.md if it exists
    • Run git log between 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
  3. 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
  4. 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)
  5. 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.]
  1. 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)
  2. Save the patch notes to production/releases/[version]/patch-notes.md, creating the directory if needed.
  3. 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).

Download now (ZIP)

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.