ksh999000/Claude-Code-Game-Studios
1
0
Fork 0
mirror of https://github.com/Donchitos/Claude-Code-Game-Studios.git synced 2026-06-27 04:51:46 +00:00
Code Issues Packages Projects Releases Wiki Activity

Release v0.4.0: /consistency-check, skill fixes, genre-agnostic agents

Browse Source 
New skill: /consistency-check — cross-GDD entity registry scanner
New registries: design/registry/entities.yaml, docs/registry/architecture.yaml
Skill fixes: no-arg guards, verdict keywords, AskUserQuestion gates on all team-* skills
Agent fixes: genre-agnostic language in game-designer, systems-designer, economy-designer, live-ops-designer
Docs: skill/template counts corrected, stale references cleaned up

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
Donchitos
2026-03-27 20:06:33 +11:00
parent 04ed5d5c36
commit 6c041ac1be
108 changed files with 2745 additions and 1005 deletions
Download Patch File Download Diff File Expand all files Collapse all files

92
.claude/skills/changelog/SKILL.md
View File

@@ -10,38 +10,43 @@ context: |
model: haiku
---
When this skill is invoked:
## Phase 1: Parse Arguments
1. **Read the argument** for the target version or sprint number. If a version
is given, use the corresponding git tag. If a sprint number is given, use
the sprint date range.
Read the argument for the target version or sprint number. If a version is given, use the corresponding git tag. If a sprint number is given, use the sprint date range.
1b. **Check git availability** — Verify the repository is initialized:
- Run `git rev-parse --is-inside-work-tree` to confirm git is available
- If not a git repo, inform the user and abort gracefully
Verify the repository is initialized: run `git rev-parse --is-inside-work-tree` to confirm git is available. If not a git repo, inform the user and abort gracefully.
2. **Read the git log** since the last tag or release:
```
git log --oneline [last-tag]..HEAD
```
If no tags exist, read the full log or a reasonable recent range (last 100
commits).
---
3. **Read sprint reports** from `production/sprints/` for the relevant period
to understand planned work and context behind changes.
## Phase 2: Gather Change Data
4. **Read completed design documents** from `design/gdd/` for any new features
that were implemented during this period.
Read the git log since the last tag or release:
5. **Categorize every change** into one of these categories:
- **New Features**: Entirely new gameplay systems, modes, or content
- **Improvements**: Enhancements to existing features, UX improvements,
performance gains
- **Bug Fixes**: Corrections to broken behavior
- **Balance Changes**: Tuning of gameplay values, difficulty, economy
- **Known Issues**: Issues the team is aware of but have not yet resolved
```
git log --oneline [last-tag]..HEAD
```
6. **Generate the INTERNAL changelog** (full technical detail):
If no tags exist, read the full log or a reasonable recent range (last 100 commits).
Read sprint reports from `production/sprints/` for the relevant period to understand planned work and context behind changes.
Read completed design documents from `design/gdd/` for any new features implemented during this period.
---
## Phase 3: Categorize Changes
Categorize every change into one of these categories:
- **New Features**: Entirely new gameplay systems, modes, or content
- **Improvements**: Enhancements to existing features, UX improvements, performance gains
- **Bug Fixes**: Corrections to broken behavior
- **Balance Changes**: Tuning of gameplay values, difficulty, economy
- **Known Issues**: Issues the team is aware of but have not yet resolved
---
## Phase 4: Generate Internal Changelog
```markdown
# Internal Changelog: [Version]
@@ -84,7 +89,9 @@ Commits: [Count] ([first-hash]..[last-hash])
- Lines removed: [N]
```
7. **Generate the PLAYER-FACING changelog** (friendly, non-technical):
---
## Phase 5: Generate Player-Facing Changelog
```markdown
# What is New in [Version]
@@ -116,19 +123,28 @@ Thank you for playing! Your feedback helps us make the game better.
Report issues at [link].
```
8. **Output both changelogs** to the user. The internal changelog is the
primary working document. The player-facing changelog is ready for
community posting after review.
---
## Phase 6: Output
Output both changelogs to the user. The internal changelog is the primary working document. The player-facing changelog is ready for community posting after review.
This skill is read-only — it outputs to conversation but does not write files. To save the output, copy it manually or use `/patch-notes` which includes a save step.
Verdict: **COMPLETE** — changelog generated.
---
## Phase 7: Next Steps
- Use `/patch-notes [version]` to generate a styled, saved version for public release.
- Use `/release-checklist` before publishing the changelog externally.
### Guidelines
- Never expose internal code references, file paths, or developer names in
the player-facing changelog
- Never expose internal code references, file paths, or developer names in the player-facing changelog
- Group related changes together rather than listing individual commits
- If a commit message is unclear, check the associated files and sprint data
for context
- Balance changes should always include the design reasoning, not just the
numbers
- Known issues should be honest -- players appreciate transparency
- If the git history is messy (merge commits, reverts, fixup commits), clean
up the narrative rather than listing every commit literally
- If a commit message is unclear, check the associated files and sprint data for context
- Balance changes should always include the design reasoning, not just the numbers
- Known issues should be honest — players appreciate transparency
- If the git history is messy (merge commits, reverts, fixup commits), clean up the narrative rather than listing every commit literally