Donchitos/Claude-Code-Game-Studios

Agent skills in the GitHub repository Donchitos/Claude-Code-Game-Studios, each with its code score out of 100.

Turn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.

Repository score

67 / 100 C

Skills

78

Verified

0

Average skill score

62

GitHub stars

38,623

License

MIT

Open Donchitos/Claude-Code-Game-Studios on GitHub

78 skills in this repository

1. story-done

   Closes a finished story: verifies each acceptance criterion, checks for design or ADR deviations and updates its status. Use when the user says a story is done, finished or ready…

   78B
2. code-review

   Architectural review of written code: coding standards, SOLID, testability, performance.

   75B
3. design-review

   Reviews one design document for completeness, internal consistency, implementability, and design standards. Before handing to programmers.

   75B
4. story-readiness

   Checks whether a story is ready to implement: clear acceptance criteria, no open questions, valid ADR and dependencies. Use when the user asks if a story, or the sprint's stories,…

   72B
5. team-release

   Orchestrate the release team — release-manager, qa-lead, devops-engineer, producer — to execute a release from candidate to deployment.

   72B
6. ux-review

   Validate a UX spec, HUD design or pattern library — accessibility, GDD alignment, readiness. APPROVED / NOT ASSESSED / NEEDS REVISION / MAJOR REVISION NEEDED.

   72B
7. setup-engine

   Sets up and pins the engine version: web for a new project unless Godot, Unity or Unreal is named. Use to choose or upgrade it.

   71B
8. vertical-slice

   Pre-production validation — end-to-end build to confirm the full loop is achievable before committing to Production. After GDDs, architecture, UX specs.

   70B
9. create-control-manifest

   Builds a short list of must-do and never-do coding rules per system from accepted ADRs. Use when the user wants programmer rules or a cheat sheet from the ADRs, or needs it regene…

   69C
10. gate-check

    Ready to advance between development stages? PASS/CONCERNS/NOT ASSESSED/FAIL with blockers and required artifacts. 'Can we move to production?'

    69C
11. hotfix

    Emergency fix bypassing normal sprint process — hotfix branch, approvals tracked, backport verified, full audit trail.

    69C
12. propagate-design-change

    Finds architecture decisions (ADRs) made stale by a changed GDD and walks through resolving each. Use when the user changed a number or rule in a GDD and asks which ADRs or archit…

    69C
13. write-changelog

    Writes a changelog from git commits and sprint data. Use for an internal or player-facing one.

    69C
14. balance-check

    Find balance outliers, broken progressions, degenerate strategies, economy imbalances in formulas and data. 'Check game balance'.

    68C
15. project-stage-detect

    Analyze project state, detect stage, identify gaps, recommend next steps. 'Where are we in development?'

    68C
16. create-epics

    Turns the GDDs and architecture into epics, one per architectural module. Use when the user wants to break the game into epics or plan the work before writing stories. Not for spl…

    67C
17. launch-checklist

    Launch readiness across every department: code, content, store, marketing, community, infrastructure, legal, go/no-go sign-offs.

    67C
18. next-step

    Names the one next step: make a game, change it after play, grow it, or the next studio-mode step. Use when asked what to do next, or stuck.

    67C
19. project-settings

    Shows or changes a project setting and where its value comes from. Use to check or set one.

    67C
20. release-checklist

    Pre-release checklist — build verification, certification requirements, store metadata, launch readiness.

    67C
21. team-polish

    Orchestrate the polish team — performance-analyst, technical-artist, sound-designer, qa-tester — to optimize and harden a feature or area.

    67C
22. architecture-review

    Traceability matrix mapping GDD requirements to ADRs. Finds gaps, cross-ADR conflicts, engine compatibility. PASS/CONCERNS/NOT ASSESSED/FAIL.

    66C
23. asset-audit

    Audit assets against naming conventions, file size budgets, format standards. Finds orphaned assets, missing references.

    66C
24. create-stories

    Breaks one epic into implementable stories with acceptance criteria. Use when the user wants stories for an epic or the next batch of work to build. Not for turning the whole desi…

    66C
25. scope-check

    Scope creep check — current scope versus the original plan. Flags additions, quantifies bloat, recommends cuts. 'Any scope creep?' Finishing a game from its brief is /cut's.

    66C
26. start

    Guides a first-time user through onboarding and picks the right workflow. Use when the user is new, just cloned or installed the studio, has no idea or engine yet, asks where to b…

    66C
27. dev-story

    Implements one story in code with tests, following its ADRs. Use when the user says to build, implement or start working on a story. Not for checking readiness beforehand or closi…

    65C
28. sprint-status

    Fast, concise sprint snapshot — burndown and emerging risks for situational awareness. 'How is the sprint going?'

    65C
29. art-bible

    Author the Art Bible — visual identity gating asset production. Run before /map-systems.

    64C
30. consistency-check

    Scan GDDs against the entity registry for cross-document conflicts. Grep-first approach targets conflicting sections, different stats.

    64C
31. reverse-document

    Writes missing design or architecture docs, or a game's brief, from code. Use when code or prototypes have no docs.

    64C
32. prototype

    Asks a few questions, writes a one-page brief, builds a playable browser game as one HTML folder it plays and screenshots; with an engine set, a throwaway engine or paper prototyp…

    63C
33. skill-improve

    Improve a skill via a test-fix-retest loop — static checks, targeted fixes, keep or revert on score change.

    63C
34. team-combat

    Orchestrate the combat team — game-designer, gameplay-programmer, ai-programmer, technical-artist, sound-designer, qa-tester — design through implement and validate.

    63C
35. team-ui

    Orchestrate the UI team through the UX pipeline — authoring, visual design, implementation, review, polish. Uses /ux-design, /ux-review, studio templates.

    63C
36. team-narrative

    Orchestrate the narrative team — narrative-director, writer, world-builder, level-designer — for story, world lore, narrative-driven levels.

    62C
37. ux-design

    Section-by-section UX spec authoring for a screen, flow or HUD. Reads the player journey to provide context; also project-wide accessibility.

    62C
38. asset-spec

    Per-asset visual specs plus AI generation prompts from GDDs and character profiles. After the art bible.

    61C
39. bug-triage

    Re-evaluate open bugs — priority vs severity, assign to sprints, surface systemic trends. Run when the count grows.

    61C
40. day-one-patch

    Day-one launch patch — focused fix for known issues found after gold master. Mini-sprint with QA gate and rollback.

    61C
41. milestone-review

    Milestone progress review — completeness, quality metrics, risk, go/no-go recommendation. At checkpoints or before a deadline.

    61C
42. patch-notes

    Player-facing patch notes from git history and changelogs. Translates developer language into player communication.

    61C
43. regression-suite

    Map test coverage to GDD critical paths, find fixed bugs lacking regression tests, flag drift from new features.

    61C
44. retrospective

    Sprint or milestone retrospective from completed work, velocity, blockers. Actionable insights for the next iteration.

    61C
45. review-all-gdds

    Holistic cross-GDD review — contradictions between systems, dominant strategies, economic imbalance, cognitive overload, pillar drift.

    61C
46. security-audit

    Security audit — save tampering, cheat vectors, network exploits, data exposure, input validation. Before public or multiplayer release.

    61C
47. skill-test

    Validate skill files for structural compliance and behavioral correctness. Four modes: static linter, spec, category rubric, audit.

    61C
48. soak-test

    Soak test protocol for extended play — what to observe and log for slow leaks, fatigue, late-appearing edge cases.

    61C
49. team-qa

    Orchestrate the QA team through a full testing cycle — qa-lead strategy and test plan, qa-tester case writing, execution, sign-off.

    61C
50. architecture-decision

    Create an ADR documenting a technical decision: context, alternatives considered, consequences.

    60C
51. content-audit

    Audit GDD content counts against what's implemented — planned vs built.

    60C
52. cut

    Proposes cuts and a polish list to finish the game from its brief and what is built; the person picks each cut. A game to sell also gets a release date and a feature freeze. Use w…

    60C
53. onboard

    Onboarding doc for a new contributor or agent — project state, conventions, priorities relevant to the specified role.

    60C
54. design-system

    Section-by-section GDD authoring for one system — walks through each required section, cross-references dependencies.

    59C
55. team-audio

    Orchestrate the audio team — audio-director, sound-designer, technical-artist, gameplay-programmer — direction through implementation.

    59C
56. team-level

    Orchestrate the level team — level-designer, narrative-director, world-builder, art-director, systems-designer, qa-tester — for complete area creation.

    59C
57. team-live-ops

    Orchestrate the live-ops team — live-ops-designer, economy-designer, analytics-engineer, community-manager, writer — for a season or live event.

    59C
58. estimate

    Estimate task effort from complexity, dependencies, velocity, risk. Structured estimate with confidence levels.

    58C
59. perf-profile

    Performance profiling — find bottlenecks, measure against budgets, produce ranked optimization recommendations.

    58C
60. localize

    Localization pipeline — find hardcoded strings, extract string tables, cultural review, VO, RTL, enforce string freeze.

    57C
61. sprint-plan

    New or updated sprint plan from the current milestone, completed work, and available capacity.

    57C
62. playtest-report

    Structured playtest report template, or turn existing playtest notes into structured feedback.

    56C
63. qa-plan

    QA test plan for a sprint — classifies stories by Logic/Integration/Visual/UI, covers automated tests, manual cases, smoke scope.

    56C
64. quick-design

    Lightweight spec for small changes — tuning adjustments, minor mechanics. Embeds directly into stories; skips full GDD.

    56C
65. test-helpers

    Generate engine-specific test helper libraries — assertion utilities, factory functions, mocks in the engine's test folder. Reduces boilerplate.

    56C
66. test-setup

    Sets up the test framework and CI: tests/ directory, engine runner, GitHub Actions workflow. Use once, before the first sprint.

    56C
67. create-architecture

    Author the architecture blueprint before code is written. Validates decisions against the pinned engine, flags knowledge gaps.

    55C
68. smoke-check

    Critical-path smoke gate before QA hand-off — runs the automated suite. A failed check means the build is not QA-ready.

    55C
69. brainstorm

    Guides the user through finding and choosing a game concept. Use when the user wants game ideas, a new concept, a game jam idea, or to explore other directions, including dropping…

    54D
70. bug-report

    Structured bug report from a description, or analyze code for potential bugs. Reproduction steps, severity.

    53D
71. adopt

    Brownfield audit — do existing artifacts actually work? Numbered migration plan. Unlike /project-stage-detect, checks compliance not existence.

    52D
72. tech-debt

    Track, categorize and prioritize technical debt across the codebase — scans for debt indicators, maintains a register.

    52D
73. changelog

    Old name of /write-changelog. Prints one line, then runs /write-changelog.

    51D
74. map-systems

    Decompose a concept into individual systems, map dependencies, prioritize design order, create the systems index.

    51D
75. test-evidence-review

    Quality review of test files and evidence — goes beyond existence, evaluates assertion coverage. ADEQUATE/INCOMPLETE/MISSING/NOT ASSESSED per story.

    51D
76. test-flakiness

    Find flaky tests from CI logs — aggregates pass rates, spots intermittent failures, recommends quarantine. After multiple runs.

    51D
77. help

    Old name of /next-step. Prints one line, then runs /next-step.

    49D
78. settings

    Old name of /project-settings. Prints one line, then runs /project-settings.

    49D

Scores come from a snapshot of 300 public GitHub repositories taken on 12 November 2026. Every score is the result of fixed checks run by code; no AI is involved. How scoring works.