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

! bash "${CLAUDE SKILL DIR}/../../hooks/yaml helper.sh" resolve config keys review mode,automation,workflow,docs.density,project.stage Resolved above — use as is; review overrides review mode . No block → defaults in .claude/docs/config resolution.md . Map Systems 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). See .claude/docs/director gates.md for the full check pattern. Individual gate definitions live in .claude/docs/director gates/[gate id].md — the spawned agent reads its own gate file; do not read it in the parent session. Every AskUserQuestion call follows .claude/docs/automation modes.md (collaborative asks always · guided major only · autonomous logs and proceeds; automation always ask categories always prompt). In collaborative mode the system list, dependency, priority and write approvals are separate questions: each waits for its answer before the next step runs. docs.density — it controls per section depth , where workflow controls which sections exist. modes.rigor sets both together; set docs.density explicitly to vary depth alone: terse (the default, via rigor: minimal ) = one line system descriptions; balanced = a brief paragraph per system + dependency notes ( rigor: standard ); thorough = full system by system rationale + relationship analysis. Apply it to every section you author. Where the per system prose goes. templates/systems index.md 's Systems Enumeration is a fixed column table with no description column, so at balanced and thorough the prose belongs in Overview — one short paragraph per system at balanced , plus relationship analysis at thorough — and in the Dependency Map layer notes. Do not add a column to the enumeration table — it is a fixed contract in .claude/docs/templates/systems index.md , and its consumers ( /design system §6 and §7, /create epics ) are written against the columns it defines. Widening it is a schema change, not a formatting choice. How the consumers actually read it. Nothing parses this table positionally. The two scripts that mention systems index.md ( gdd structure check.sh:51 , review scope.sh:40 ) match it by filename in a case statement and parse no columns at all; the two skills key on the Category column by name ( design system:229 , :780 ). So Category is the column that must never be renamed or dropped, and the table stays a fixed contract because every consumer is written against the set of columns the template defines. At terse , the table plus a one paragraph Overview is the whole output. workflow (see .claude/docs/workflow modes.md ): full / standard — required before /design system (systems must be mapped before per system GDDs are authored). minimal — not required (the game brief replaces the systems index). Can still be run voluntarily. Phase 1: Read Concept (Required Context) Read the game concept and any existing design work. This provides the raw material for systems decomposition. Read each doc by section: find the headings you need with the Grep tool (pattern ^ , content mode) and Read those ranges with offset and limit. Required: Read design/gdd/game concept.md (at minimal , read design/game brief.md instead) — fail with a clear message if neither is found : "No game concept found. 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?" At collaborative — iterate until the user approves the enumeration. At guided — ask once, apply the answer, and proceed; do not loop. At autonomous — do not ask. Record the enumeration and its inferred systems via log decision and proceed. 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 Agent using gate TD SYSTEM BOUNDARY ( .claude/docs/director gates/td system boundary.md ) before proceeding to priority assignment. Pass: the dependency graph (each system → what it depends on), layer assignments, bottleneck systems, and any circular dependencies with their proposed resolutions. Present the assessment. If REJECT, revise the system boundaries with the user, show the revised dependency map, and only then move to priority assignment. If CONCERNS, note them inline in the systems index and continue. If NOT ASSESSED [missing input], it is not an APPROVE: name what was missing, then supply it and re run the gate, or continue with TD SYSTEM BOUNDARY: NOT ASSESSED — [input] noted in the index draft. 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." How to phrase the reasoning — this governs what you say , not a column you write. Neither table has a Why column: Systems Enumeration is / Name / Category / Priority / Status / Design Doc / Depends On , and Recommended Design Order is Order / System / Priority / Layer / Agent(s) / Est. Effort . The rationale lives in the conversation above and, for anything the user should still see after the session, in the index's Overview paragraph. Do not invent a column for it. Mix technical necessity with player experience reasoning. A purely technical justification — "the damage system needs damage math" — is insufficient on its own when the system directly shapes what the player feels. Good reasoning names both, and cites the pillar it serves: "Required for the core loop — without it the player's main choice has no consequence (Pillar [N]: [pillar name])" "This is where [system]'s identity is established — the stat definitions here are what make it feel different from [the sibling system]" "Foundation for every later economy decision — the player must understand costs before any of the choices built on top of it mean anything" Fill the brackets from this project. The bracketed slots are not decoration. Reasoning copied from another game's worked example carries that game's vocabulary instead of this one's. Review mode check — apply before spawning PR SCOPE: solo → skip. Note: "PR SCOPE skipped — Solo mode." Proceed to Step 4c. lean → skip (not a PHASE GAT

map-systems