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

91
.claude/skills/design-review/SKILL.md
View File

@@ -8,41 +8,47 @@ context: fork
agent: Explore
---
When this skill is invoked:
## Phase 1: Load Documents
1. **Read the target design document** in full.
Read the target design document in full. Read CLAUDE.md to understand project context and standards. Read related design documents referenced or implied by the target doc (check `design/gdd/` for related systems).
2. **Read the master CLAUDE.md** to understand project context and standards.
---
3. **Read related design documents** referenced or implied by the target doc
(check `design/gdd/` for related systems).
## Phase 2: Completeness Check
4. **Evaluate against the Design Document Standard checklist**:
- [ ] Has Overview section (one-paragraph summary)
- [ ] Has Player Fantasy section (intended feeling)
- [ ] Has Detailed Rules section (unambiguous mechanics)
- [ ] Has Formulas section (all math defined with variables)
- [ ] Has Edge Cases section (unusual situations handled)
- [ ] Has Dependencies section (other systems listed)
- [ ] Has Tuning Knobs section (configurable values identified)
- [ ] Has Acceptance Criteria section (testable success conditions)
Evaluate against the Design Document Standard checklist:
5. **Check for internal consistency**:
- Do the formulas produce values that match the described behavior?
- Do edge cases contradict the main rules?
- Are dependencies bidirectional (does the other system know about this one)?
- [ ] Has Overview section (one-paragraph summary)
- [ ] Has Player Fantasy section (intended feeling)
- [ ] Has Detailed Rules section (unambiguous mechanics)
- [ ] Has Formulas section (all math defined with variables)
- [ ] Has Edge Cases section (unusual situations handled)
- [ ] Has Dependencies section (other systems listed)
- [ ] Has Tuning Knobs section (configurable values identified)
- [ ] Has Acceptance Criteria section (testable success conditions)
6. **Check for implementability**:
- Are the rules precise enough for a programmer to implement without guessing?
- Are there any "hand-wave" sections where details are missing?
- Are performance implications considered?
---
7. **Check for cross-system consistency**:
- Does this conflict with any existing mechanic?
- Does this create unintended interactions with other systems?
- Is this consistent with the game's established tone and pillars?
## Phase 3: Consistency and Implementability
8. **Output the review** in this format:
**Internal consistency:**
- Do the formulas produce values that match the described behavior?
- Do edge cases contradict the main rules?
- Are dependencies bidirectional (does the other system know about this one)?
**Implementability:**
- Are the rules precise enough for a programmer to implement without guessing?
- Are there any "hand-wave" sections where details are missing?
- Are performance implications considered?
**Cross-system consistency:**
- Does this conflict with any existing mechanic?
- Does this create unintended interactions with other systems?
- Is this consistent with the game's established tone and pillars?
---
## Phase 4: Output Review
```
## Design Review: [Document Title]
@@ -65,18 +71,19 @@ When this skill is invoked:
### Verdict: [APPROVED / NEEDS REVISION / MAJOR REVISION NEEDED]
```
9. **Contextual next step recommendations**:
- If the document being reviewed is `game-concept.md` or `game-pillars.md`:
- Check if `design/gdd/systems-index.md` exists
- If it does NOT exist, add to Recommendations:
> "This concept is ready for systems decomposition. Run `/map-systems`
> to break it down into individual systems with dependencies and priorities,
> then write per-system GDDs."
- If the document is an individual system GDD:
- Check if the systems index references this system
- If verdict is APPROVED: suggest "Update the systems index status for
this system to 'Approved'."
- If verdict is NEEDS REVISION or MAJOR REVISION NEEDED: suggest "Update
the systems index status for this system to 'In Review'."
- Note: This skill is read-only. The user (or `/design-system`) must
perform the actual status update in the systems index.
This skill is read-only — no files are written.
---
## Phase 5: Next Steps
If the document being reviewed is `game-concept.md` or `game-pillars.md`:
- Check if `design/gdd/systems-index.md` exists. If not, recommend: "Run `/map-systems` to break the concept down into individual systems with dependencies and priorities, then write per-system GDDs."
If the document is an individual system GDD:
- If verdict is APPROVED: suggest updating the system's status to 'Approved' in the systems index.
- If verdict is NEEDS REVISION or MAJOR REVISION NEEDED: suggest updating the status to 'In Review'.
Next skill options:
- APPROVED → `/create-epics` or `/map-systems`
- NEEDS REVISION → revise the doc then re-run `/design-review`