mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-06-27 13:01:50 +00:00
7d08e396e3
* Add UPGRADING.md migration guide and link from README Covers v0.1→v0.2 upgrade with three strategies (git merge, cherry-pick, manual copy), file safety categories, and post-upgrade verification steps. Structured to support future version sections. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Rename /design-systems to /map-systems + /design-system and fix all references Split the monolithic /design-systems skill into two focused skills: - /map-systems: systems decomposition and index creation - /design-system: guided section-by-section GDD authoring Updated all cross-references across 14 files: README, UPGRADING, WORKFLOW-GUIDE, quick-start, skills-reference, game-concept template, systems-index template, brainstorm, design-review, gate-check, project-stage-detect, setup-engine, and start skills. Fixed skill counts from 36 to 37 everywhere. Added /map-systems and /design-system to quick-start Paths A and B workflows. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Fix cross-reference gaps, broken hooks, and stale workflow chains - Fix log-agent.sh parsing agent_type instead of agent_name (always logged "unknown") - Fix GDD status lifecycle: design-system now writes Approved/Designed/In Review - Clean up settings.local.json vestigial Bash grants from development - Delete orphaned docs marked for removal in UPGRADING.md - Add /design-system to next-steps in /start, /brainstorm, /setup-engine - Fix WORKFLOW-GUIDE: add /map-systems + /design-system to Appendix C Workflow 1 - Fix invalid /map-systems map argument in WORKFLOW-GUIDE Step 2.1 - Update map-systems frontmatter to document [system-name] argument - Update commit hook to validate all 8 required GDD sections (was 5) - Update README template count 28 → 29, add 5 missing templates to quick-start Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Add custom status line with 7-stage production pipeline Introduces a status line showing context %, model name, and production stage at a glance. Aligns gate-check and project-stage-detect to a unified 7-stage model (Concept → Systems Design → Technical Setup → Pre-Production → Production → Polish → Release). Stage is determined by explicit override (production/stage.txt) or auto-detected from project artifacts. Epic/Feature/Task breadcrumb appears conditionally in Production+ stages via a structured STATUS block in active.md. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Add v0.2→v0.3 upgrade guide and PR validation test suite - UPGRADING.md: add v0.2.0→v0.3.0 section documenting breaking rename of /design-systems→/map-systems, new /design-system skill, statusline.sh, gate-check stage advancement, and safe-to-overwrite file list Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
3.2 KiB
3.2 KiB
name, description, argument-hint, user-invocable, allowed-tools
| name | description | argument-hint | user-invocable | allowed-tools |
|---|---|---|---|---|
| design-review | Reviews a game design document for completeness, internal consistency, implementability, and adherence to project design standards. Run this before handing a design document to programmers. | [path-to-design-doc] | true | Read, Glob, Grep |
When this skill is invoked:
-
Read the target design document in full.
-
Read the master 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). -
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)
-
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)?
-
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?
-
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?
-
Output the review in this format:
## Design Review: [Document Title]
### Completeness: [X/8 sections present]
[List missing sections]
### Consistency Issues
[List any internal or cross-system contradictions]
### Implementability Concerns
[List any vague or unimplementable sections]
### Balance Concerns
[List any obvious balance risks]
### Recommendations
[Prioritized list of improvements]
### Verdict: [APPROVED / NEEDS REVISION / MAJOR REVISION NEEDED]
- Contextual next step recommendations:
- If the document being reviewed is
game-concept.mdorgame-pillars.md:- Check if
design/gdd/systems-index.mdexists - If it does NOT exist, add to Recommendations:
"This concept is ready for systems decomposition. Run
/map-systemsto break it down into individual systems with dependencies and priorities, then write per-system GDDs."
- Check if
- 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.
- If the document being reviewed is