minhln1234/claude-cowork-game-studio/ccgs-map-systems

Cowork Adaptation Notes (read first)

Converted from Claude Code Game Studios (github.com/Donchitos/Claude-Code-Game-Studios) for Claude Cowork. Apply these substitutions when following the instructions below:

1. Agents: Named agents (e.g. game-designer, unity-specialist) are not Cowork subagents. When told to "spawn an agent via Task", read the matching file in this skill's bundled roles/ folder and either (a) launch a general-purpose subagent via the Agent tool with that role file's content prepended to the brief, or (b) adopt the role inline and continue. If a role file is not bundled, adopt the role inline from its name.
2. Project paths: design/, docs/, production/, src/ live in the user's connected project folder. Create them there as needed. Bundled reference docs are in this skill's refs/ and templates/ folders.
3. Slash commands: /skill-name means "the ccgs-skill-name skill". Installed set: start, brainstorm, map-systems, design-system, consistency-check, create-architecture, create-epics, create-stories, story-readiness, sprint-plan, dev-story, code-review, story-done, propagate-design-change, reverse-document. If a referenced skill is NOT in this set, tell the user it isn't installed and offer to do the equivalent steps manually.
4. Hooks: Claude Code hooks do not run in Cowork. Do their checks manually: validate JSON files you write, follow naming conventions, no hardcoded magic numbers, and update production/session-state/active.md at the start and end of each work session.
5. Engine: This project targets Unity (C#). Ignore Godot and Unreal routing rows.
6. Review mode: If production/review-mode.txt doesn't exist in the project folder, default to lean.

When this skill is invoked:

Parse Arguments

Two modes:

• No argument: /map-systems — Run the full decomposition workflow (Phases 1-5)

to create or update the systems index.

• `next`: /map-systems next — Pick the highest-priority undesigned system

from the index and hand off to /design-system (Phase 6).

Also resolve the review mode (once, store for all gate spawns this run):

1. If --review [full|lean|solo] was passed → use that
2. Else read production/review-mode.txt → use that value
3. Else → default to lean

See refs/director-gates.md for the full check pattern.

Phase 1: Read Concept (Required Context)

Read the game concept and any existing design work. This provides the raw material for systems decomposition.

Required:

• Read design/gdd/game-concept.md — fail with a clear message if missing:

> "No game concept found at design/gdd/game-concept.md. Run /brainstorm first > to create one, then come back to decompose it into systems."

Optional (read if they exist):

• Read design/gdd/game-pillars.md — pillars constrain priority and scope
• Read design/gdd/systems-index.md — if exists, resume from where it left off

(update, don't recreate from scratch)

• Glob design/gdd/*.md — check which system GDDs already exist

If the systems index already exists:

• Read it and present current status to the user
• Use AskUserQuestion to ask:

"The systems index already exists with [N] systems ([M] designed, [K] not started). What would you like to do?"

• Options: "Update the index with new systems", "Design the next undesigned system",

"Review and revise priorities"

Phase 2: Systems Enumeration (Collaborative)

Extract and identify all systems the game needs. This is the creative core of the skill — it requires human judgment because concept docs rarely enumerate every system explicitly.

Step 2a: Extract Explicit Systems

Scan the game concept for directly mentioned systems and mechanics:

• Core Mechanics section (most explicit)
• Core Loop section (implies what systems drive each loop tier)
• Technical Considerations section (networking, procedural generation, etc.)
• MVP Definition section (required features = required systems)

Step 2b: Identify Implicit Systems

For each explicit system, identify the hidden systems it implies. Games always need more systems than the concept doc mentions. Use this inference pattern:

• "Inventory" implies: item database, equipment slots, weight/capacity rules,

inventory UI, item serialization for save/load

• "Combat" implies: damage calculation, health system, hit detection, status effects,

enemy AI, combat UI (health bars, damage numbers), death/respawn

• "Open world" implies: streaming/chunking, LOD system, fast travel, map/minimap,

point of interest tracking, world state persistence

• "Multiplayer" implies: networking layer, lobby/matchmaking, state synchronization,

anti-cheat, network UI (ping, player list)

• "Crafting" implies: recipe database, ingredient gathering, crafting UI,

success/failure mechanics, recipe discovery/learning

• "Dialogue" implies: dialogue tree system, dialogue UI, choice tracking, NPC

state management, localization hooks

• "Progression" implies: XP system, level-up mechanics, skill tree, unlock

tracking, progression UI, progression save data

Explain in conversation text why each implicit system is needed (with examples).

Step 2c: User Review

Present the enumeration organized by category. For each system, show:

• Name
• Category
• Brief description (1 sentence)
• Whether it was explicit (from concept) or implicit (inferred)

Then use AskUserQuestion to capture feedback:

• "Are there systems missing from this list?"
• "Should any of these be combined or split?"
• "Are there systems listed that this game does NOT need?"

Iterate until the user approves the enumeration.

Phase 3: Dependency Mapping (Collaborative)

For each system, determine what it depends on. A system "depends on" another if it cannot function without that other system existing first.

Step 3a: Map Dependencies

For each system, list its dependencies. Use these dependency heuristics:

• Input/output dependencies: System A produces data System B needs
• Structural dependencies: System A provides the framework System B plugs into
• UI dependencies: Every gameplay system has a corresponding UI system that

depends on it (but UI is designed after the gameplay system)

Step 3b: Sort by Dependency Order

Arrange systems into layers:

1. Foundation: Systems with zero dependencies (designed and built first)
2. Core: Systems depending only on Foundation systems
3. Feature: Systems depending on Core systems
4. Presentation: UI and feedback systems that wrap gameplay systems
5. Polish: Meta-systems, tutorials, analytics, accessibility

Step 3c: Detect Circular Dependencies

Check for cycles in the dependency graph. If found:

• Highlight them to the user
• Propose resolutions (interface abstraction, simultaneous design, breaking the

cycle by defining a contract between the two systems)

Step 3d: Present to User

Show the dependency map as a layered list. Highlight:

• Any circular dependencies
• Any "bottleneck" systems (many others depend on them — these are high-risk)
• Any systems with no dependents (leaf nodes — lower risk, can be designed late)

Use AskUserQuestion to ask: "Does this dependency ordering look right? Any dependencies I'm missing or that should be removed?"

Review mode check — apply before spawning TD-SYSTEM-BOUNDARY:

• solo → skip. Note: "TD-SYSTEM-BOUNDARY skipped — Solo mode." Proceed to priority assignment.
• lean → skip (not a PHASE-GATE). Note: "TD-SYSTEM-BOUNDARY skipped — Lean mode." Proceed to priority assignment.
• full → spawn as normal.

After dependency mapping is approved, spawn `technical-director` via Task using gate TD-SYSTEM-BOUNDARY (`refs/director-gates.md`) before proceeding to priority assignment.

Pass: the dependency map summary, layer assignments, bottleneck systems list, any circular dependency resolutions.

Present the assessment. If REJECT, revise the system boundaries with the user before moving to priority assignment. If CONCERNS, note them inline in the systems index and continue.

Phase 4: Priority Assignment (Collaborative)

Assign each system to a priority tier based on what milestone it's needed for.

Step 4a: Auto-Assign Based on Concept

Use these heuristics for initial assignment:

• MVP: Systems mentioned in the concept's "Required for MVP" section, plus their

Foundation-layer dependencies

• Vertical Slice: Systems needed for a complete experience in one area
• Alpha: All remaining gameplay systems
• Full Vision: Polish, meta, and nice-to-have systems

Step 4b: User Review

Present the priority assignments in a table. For each tier, explain why systems were placed there.

Use AskUserQuestion to ask: "Do these priority assignments match your vision? Which systems should be higher or lower priority?"

Explain reasoning in conversation: "I placed [system] in MVP because the core loop requires it — without [system], the 30-second loop can't function."

"Why" column guidance: When explaining why each system was placed in a priority tier, mix technical necessity with player-experience reasoning. Do not use purely technical justifications like "Combat needs damage math" — connect to player experience where relevant. Examples of good "Why" entries:

• "Required for the core loop — without it, placement decisions have no consequence (Pillar 2: Placement is the Puzzle)"
• "Ballista's punch-through identity is established here — this stat definition is what makes it feel different from Archer"
• "Foundation for all economy decisions — players must understand upgrade costs to make meaningful placement choices"

Pure technical necessity ("X depends on Y") is insufficient alone when the system directly shapes player experience.

Review mode check — apply before spawning PR-SCOPE:

• solo → skip. Note: "PR-SCOPE skipped — Solo mode." Proceed to writing the systems index.
• lean → skip (not a PHASE-GATE). Note: "PR-SCOPE skipped — Lean mode." Proceed to writing the systems index.
• full → spawn as normal.

After priorities are approved, spawn `producer` via Task using gate PR-SCOPE (`refs/director-gates.md`) before writing the index.

Pass: total system count per milestone tier, estimated implementation volume per tier (system count × average complexity), team size, stated project timeline.

Present the assessment. If UNREALISTIC, offer to revise priority tier assignments before writing the index. If CONCERNS, note them and continue.

Step 4c: Determine Design Order

Combine dependency sort + priority tier to produce the final design order:

1. MVP Foundation systems first
2. MVP Core systems second
3. MVP Feature systems third
4. Vertical Slice Foundation/Core systems
5. ...and so on

This is the order the team should write GDDs in.

Phase 5: Create Systems Index (Write)

Step 5a: Draft the Document

Using the template at templates/systems-index.md, populate the systems index with all data from Phases 2-4:

• Fill the enumeration table
• Fill the dependency map
• Fill the recommended design order
• Fill the high-risk systems
• Fill progress tracker (all systems "Not Started" initially, unless GDDs already exist)

Step 5b: Approval

Present a summary of the document:

• Total systems count by category
• MVP system count
• First 3 systems in the design order
• Any high-risk items

Ask: "May I write the systems index to design/gdd/systems-index.md?"

Wait for approval. Write the file only after "yes."

Review mode check — apply before spawning CD-SYSTEMS:

• solo → skip. Note: "CD-SYSTEMS skipped — Solo mode." Proceed to Phase 7 next steps.
• lean → skip (not a PHASE-GATE). Note: "CD-SYSTEMS skipped — Lean mode." Proceed to Phase 7 next steps.
• full → spawn as normal.

After the systems index is written, spawn `creative-director` via Task using gate CD-SYSTEMS (`refs/director-gates.md`).