Brainstorm

This skill explores a game concept through open-ended designer interview. Spawn gat-designer for design reasoning and gat-artist for visual direction. Pick questions from the angle table below — follow the conversation, not a script.

Phase 1: Resolve Mode

• If argument is discuss → Mode: discuss (no files written, exploration only)
• If argument is a hint or empty → Mode: design (produces foundational design docs and global art direction)

Check whether gat/overview/game.md, gat/overview/systems-index.md, or gat/overview/art-direction.md already exist. If so, note them — the interview may refine or replace existing decisions instead of starting from scratch.

Phase 2: The Interview

Core Rules

• One question at a time. Never batch. Wait for the answer before the next question.
• Provide a recommended answer with each question. Explain the design reasoning.
• Prefer open-ended questions. Let the user type free-form responses. Reserve AskUserQuestion (multiple-choice) for when you are presenting concrete solution options and need the user to pick one. Most of the interview should be dialogue, not forms.
• Pick angles, don't follow steps. Use the angle table as a menu. Jump to whatever dimension is most useful next — chase what's interesting or ambiguous.
• If a question can be answered by reading existing design files, read them instead of asking.
• Spawn gat-designer when you need a design reasoning pass: drafting a core loop, proposing systems, evaluating a trade-off, or checking consistency.
• Spawn gat-artist when visual identity needs synthesis: art references, palette, readability, asset groups, production standards, or conflicts between style and gameplay clarity.

Drilling into Vague Ideas

When the user has a fuzzy idea — about the whole game or a single system — your job is to make it concrete through relentless, curious questioning. This is the core of the interview.

How to drill:

• When the user says something vague ("combat should feel impactful"), ask what specifically makes it impactful — is it animation, sound, damage numbers, controller rumble, enemy reaction, time-to-kill? Keep asking until the abstraction bottoms out in concrete mechanics.
• When the user proposes a system, ask about its boundaries. What does it NOT do? What system owns the adjacent responsibility? A system without edges is still fuzzy.
• When the user describes a player experience ("I want the player to feel lost"), ask what the game does to create that feeling. What does the player see, hear, and do? What information is withheld? What mechanics produce the emotion?
• When the user references another game ("like Dark Souls but..."), isolate what exactly they want to keep and what they want to change. The reference is a shortcut — unpack it.
• Ask about edge cases and failure states. What happens when the player ignores the system? What happens when they optimize it to the extreme? The answers reveal whether the system is understood or still hazy.
• Ask about the player's moment-to-moment decisions. If the user can't describe what choices the player makes inside the system, the system isn't clear yet.
• If an answer opens three new questions, pick the most foundational one first. Resolve dependencies before details.

Signals that something is still vague and needs more drilling:

• The user uses abstract adjectives without mechanics behind them ("fun", "smooth", "deep", "cool")
• A system is named but its inputs, outputs, and rules are undefined
• Two systems have overlapping or unclear boundaries
• The user can describe what the system IS but not what the player DOES in it
• Numbers are absent where they matter (how many? how long? how much?)

Seed Extraction

If a concept hint was provided, first spawn gat-designer to extract what the hint already answers. Briefly summarize what's established so the user can confirm or correct before diving in. Skip if no hint.

Interview Angles

Pick questions from any angle below. There is no fixed order — follow the thread that matters most at each moment. The table is a palette, not a checklist.

Navigating the Interview

• Start where the energy is. If the user leads with a mechanic, start at Systems. If they describe a feeling, start at Target Feeling. If they mention a reference game, start at Genre & Style.
• Drill, don't move on. When the user gives a vague or high-level answer, stay on that thread. Ask the follow-up that forces them to be specific. See "Drilling into Vague Ideas" above — this is where most of the value comes from.
• Dive when something is interesting. A throwaway answer about "the world is post-apocalyptic" might open a rich thread about Narrative & World, Economy (scarcity), or Fantasy & Role. Follow it.
• Ask open-ended, resolve with options. Most questions should be free-form dialogue — the user types their thoughts. Use AskUserQuestion only when you have 2-3 concrete design proposals and need the user to choose among them (e.g. picking a core loop direction, choosing between two system architectures).
• Spawn gat-designer mid-interview when you need to synthesize answers into a concrete proposal (core loop draft, system list, trade-off analysis). Present what the agent returns, then ask about it.
• Spawn gat-artist mid-interview when the visual identity is too vague or conflicting. Ask for a concise art-direction proposal: references, palette, shape language, readability priorities, asset groups, and production limits. Present the proposal, then ask the user what to keep or change.
• Loop back naturally. If a later answer contradicts an earlier assumption, point it out and resolve the tension. Don't pretend consistency exists when it doesn't.
• Know when to stop. The interview has covered enough when:
  • The core loop is clear and the user can describe it in their own words
  • The system list is named with rough dependencies
  • The global visual direction has references, palette or mood, readability priorities, and asset group strategy
  • Scope boundaries are set
  • The user starts repeating themselves rather than adding new information

Phase 3: Write or Summarize

If Mode is design

Before writing, summarize what's been decided across gameplay, systems, scope, and visual direction. Ask:

"Ready to write the design docs?" Options: Yes, write them / Let me keep discussing

If yes, read templates:

• .claude/docs/templates/design/game-overview.md
• .claude/docs/templates/design/systems-index.md
• .claude/docs/templates/design/global-art.md

Step 1 — Spawn gat-designer to write both foundational design files in one pass:

• gat/overview/game.md
• gat/overview/systems-index.md

Pass all interview answers, the confirmed system list with dependencies, and the game overview and systems index templates.

Instruct the designer to populate the Key Design Decisions section in game.md: record each foundational choice as a short paragraph, and add a Why: note when the rationale or rejected alternatives need to be stated — drawing from the interview's tension-resolution moments.

Step 2 — Spawn gat-artist to write the global art direction:

• gat/overview/art-direction.md

Pass all interview answers, gat/overview/game.md, gat/overview/systems-index.md, the confirmed visual identity decisions, and the global-art template. The artist should establish the shared visual identity, references, palette, readability rules, asset groups, production standards, and constraints for later system art docs.

If Mode is discuss

Summarize what was decided and what remains open. No files written.

Suggest:

• /gat-brainstorm (without discuss) to turn this discussion into foundational design docs and global art direction
• /gat-story if the game needs narrative (after foundational design docs exist)
• /gat-milestone to plan milestone slices (after foundational design docs, and narrative if needed, exist)

Phase 4: Hand Off

Summarize what was created or discussed.

If design docs were written, suggest next steps:

• /gat-story if the game needs story, lore, worldbuilding, characters, quests, dialogue, or authored narrative content
• /gat-milestone to break the game into milestone slices (milestone planning runs BEFORE per-system design; do NOT run /gat-design directly from here)

Design

This skill designs a single system within a specific milestone, after /gat-brainstorm (overview) and /gat-milestone (milestone plan) are done. For story, worldbuilding, characters, quests, dialogue, or authored narrative content, delegate to /gat-story. For the initial concept interview, delegate to /gat-brainstorm.

The milestone argument is mandatory. If it is omitted, the skill stops and asks the user to specify a milestone — no inference, default, or fallback.

Phase 1: Resolve Mode

Check existing files:

• If gat/overview/game.md or gat/overview/systems-index.md missing → hand off: tell the user to run /gat-brainstorm [hint] first. Stop.
• If gat/overview/art-direction.md missing → hand off: tell the user to run /gat-brainstorm [hint] to establish global art direction. Stop.
• If gat/milestone/milestone.md missing → hand off: tell the user to run /gat-milestone first. Stop.
• If no milestone argument provided → STOP. Tell the user a milestone is required and show the milestones listed in gat/milestone/milestone.md. Do NOT infer or default one. Do NOT write any files.
• If the milestone argument does not match any milestone directory under gat/milestone/ (i.e., no m{N}-<name>/m{N}-brief.md exists) → STOP. Tell the user the milestone was not found and list the valid milestones.

Then resolve sub-mode:

• If a system (or hint) argument is also provided → Mode: system (design that one system in the milestone)
• If only a milestone argument is provided → Mode: continue (auto-fill all systems in that milestone's brief that are not yet designed). Continue is scoped to that milestone only — it does NOT cross into other milestones.

Phase 2: Execute

Read templates:

• .claude/docs/templates/design/system-gdd.md
• .claude/docs/templates/design/system-art.md
• .claude/docs/templates/design/content-data.md

Read context:

• gat/overview/game.md, gat/overview/systems-index.md, gat/overview/art-direction.md
• the target milestone's m{N}-brief.md (for scope, in-scope systems, and the progress tracker)
• relevant gat/narrative/*.md when narrative context affects the system
• existing system docs under gat/milestone/m{N}-<name>/<system>/ if present

Also read existing gat/narrative/*.md when present and pass relevant narrative context to spawned agents. Do not create or rewrite narrative docs here; use /gat-story for that.

Continue mode (/gat-design {milestone})

For each system listed in the milestone's m{N}-brief.md that is not yet designed (progress row Pending), in the brief's order:

1. Spawn gat-designer → gat/milestone/m{N}-<name>/<system>/<system>-gdd-m{N}.md
2. If the system needs content data, spawn gat-designer → gat/milestone/m{N}-<name>/<system>/<system>-data-m{N}.md
3. Spawn gat-artist → gat/milestone/m{N}-<name>/<system>/<system>-art-m{N}.md
4. Update that system's progress row in m{N}-brief.md to Designed.

Do NOT design systems belonging to other milestones.

System mode (/gat-design {milestone} {system | hint})

Step 1 — Spawn gat-designer → gat/milestone/m{N}-<name>/<system>/<system>-gdd-m{N}.md

• Pass gat/overview/game.md, gat/overview/systems-index.md, the milestone's m{N}-brief.md, system-gdd template
• Pass existing system GDD if present (e.g., an earlier milestone's version of the same system, for reference — a later milestone may redefine it differently)

Step 2 — Content Fill (for systems with high content volume, within this milestone's scope)

If the system requires substantial content data, spawn gat-designer to write gat/milestone/m{N}-<name>/<system>/<system>-data-m{N}.md:

• Pass the system GDD, gat/overview/game.md, gat/overview/systems-index.md, the milestone brief, content-data template
• Pass existing content doc if present
• The content doc fills specific instances, parameters, sequences, and groups for THIS milestone — the data that instantiates the rules defined in the milestone's system GDD

A system needs a content-data doc when its GDD defines data structures that need many concrete instances (e.g. an enemy GDD defines enemy attributes → content doc fills the specific enemies in scope for this milestone).

Systems that are purely mechanical (e.g. input, tbs-scoring) typically do NOT need content-data docs — their parameters fit within the GDD itself.

Step 3 — Spawn gat-artist → gat/milestone/m{N}-<name>/<system>/<system>-art-m{N}.md:

• Pass gat/overview/game.md, gat/overview/art-direction.md, the milestone's system GDD, the content-data doc (if it exists), the milestone brief, system-art template
• Pass existing system art doc if present

Step 4 — Update Progress

After writing a system's docs, update that system's row in the milestone's m{N}-brief.md progress tracker (System | GDD | Art | Data | Status) to mark GDD/Art/Data paths filled and Status Designed. If this was the first system designed in the milestone, also set the milestone status from planned to designing (in both the brief and gat/milestone/milestone.md).

Phase 3: Review

Summarize what was created or updated for the system(s) in the milestone.

Use AskUserQuestion:

• Design another system in this milestone → Run /gat-design <milestone> <system>
• Continue remaining systems in this milestone → Run /gat-design <milestone>
• Stop here (hand the milestone to engineering when all its systems are Designed)

Milestone

This skill plans milestone slices BEFORE per-system design and creates:

• gat/milestone/milestone.md — the ordered milestone roadmap with status
• gat/milestone/m{N}-<name>/ — per-milestone directory skeletons
• gat/milestone/m{N}-<name>/m{N}-brief.md — milestone brief skeletons (all systems Pending, status planned)

It does NOT require any system GDD to exist. It does not create task lists, technical designs, prompt packs, or implementation files. Those belong to the downstream engineering workflow.

Phase 1: Validate Inputs

Fail if any of these are missing:

• gat/overview/game.md
• gat/overview/systems-index.md
• gat/overview/art-direction.md

Do NOT fail when no system GDDs exist. Planning runs before design; the systems index's priorities and dependencies are sufficient input for slicing.

Read:

• gat/overview/game.md
• gat/overview/systems-index.md
• gat/overview/art-direction.md
• all existing gat/narrative/*.md (used to inform milestone boundaries)
• .claude/docs/templates/plan/milestone.md
• .claude/docs/templates/plan/m-brief.md
• gat/milestone/milestone.md if it already exists
• existing gat/milestone/m{N}-<name>/m{N}-brief.md files if any milestones are already planned

Phase 2: Hand Off To The Planner

Spawn gat-planner agent with all read content plus:

• instruction to write or update gat/milestone/milestone.md as an ordered set of milestone slices (M01, M02, ...) with a status column (planned -> designing -> designed -> building -> built)
• instruction to create a directory gat/milestone/m{N}-<name>/ for each planned milestone
• instruction to author an m{N}-brief.md skeleton (template: .claude/docs/templates/plan/m-brief.md) for each milestone, listing every in-scope system with status Pending and the milestone status planned
• instruction NOT to write system GDDs, content-data docs, art docs, task lists, technical designs, prompt packs, or code
• planning focus from argument if provided

The planner should:

• choose a small set of meaningful milestones that can be handed off one stage at a time
• give each milestone a clear goal, player-facing outcome, and named system set
• define what is in scope and explicitly out of scope for each milestone
• use the systems index priorities + dependencies + narrative structure to slice; it does not need per-system rule detail
• include overview, narrative (scoped range), and content context needed by a downstream engineering workflow
• avoid technical architecture, file plans, coding tasks, and implementation sequencing
• set each new milestone's status to planned

Phase 3: Review

Summarize how many milestones were planned, which comes first, and which directories/briefs were created.

Use AskUserQuestion:

• Start designing the first milestone (Recommended) → Tell the user to run /gat-design <first-milestone> <system> or /gat-design <first-milestone> (continue)
• Stop here

Story

This skill explores and documents a game's narrative through open-ended writer interview. Spawn gat-writer for narrative reasoning. Spawn gat-designer or gat-artist only when story choices need design-system or visual-direction checks. Pick questions from the angle table below — follow the conversation, not a script.

Phase 1: Resolve Mode

• If argument is discuss → Mode: discuss (no files written, exploration only)
• If argument is a hint or empty → Mode: story (produces narrative docs under gat/narrative/)

Check whether these files exist:

• gat/overview/game.md
• gat/overview/systems-index.md
• gat/overview/art-direction.md
• gat/narrative/story.md
• gat/narrative/world.md
• gat/narrative/characters.md
• gat/narrative/quests.md
• gat/narrative/dialogue.md

If foundational overview docs exist, read them before asking questions that they already answer. If they are missing, proceed only with high-level narrative brainstorming and note that final narrative docs may need revision after /gat-brainstorm establishes the game overview and systems.

Phase 2: The Interview

Core Rules

• One question at a time. Never batch. Wait for the answer before the next question.
• Provide a recommended answer with each question. Explain the narrative reasoning.
• Prefer open-ended questions. Let the user type free-form responses. Reserve AskUserQuestion for concrete options where the user needs to choose.
• Pick angles, don't follow steps. Use the angle table as a menu. Jump to whatever dimension is most useful next.
• If a question can be answered by reading existing files, read them instead of asking.
• Spawn gat-writer when you need narrative synthesis: premise, tone, character arcs, world logic, quest structure, dialogue voice, or consistency checks.
• Spawn gat-designer when narrative choices affect mechanics, system ownership, progression, player agency, or content volume.
• Spawn gat-artist when narrative choices affect visual identity, character/world art hooks, readability, motifs, or asset groups.

Drilling into Vague Narrative Ideas

When the user has a fuzzy story idea, make it playable and specific through curious questioning.

How to drill:

• When the user says the story should feel a certain way, ask what event, character choice, or player action creates that feeling.
• When the user mentions lore, ask how the player encounters it: dialogue, quest, item text, environment, UI, systemic event, or cutscene.
• When a character is named, ask what they want, what blocks them, how they pressure the player, and whether they change.
• When the user references another work, isolate what to borrow: structure, tone, world texture, relationship dynamic, mystery shape, or dialogue style.
• When a branching idea appears, ask how many branches must be produced and whether consequences are cosmetic, systemic, or story-changing.
• When a world fact appears, ask what it causes in daily life, factions, resources, locations, or mechanics.
• If an answer opens three new questions, resolve the one that most affects player role, stakes, or content scope first.

Signals that something is still vague and needs more drilling:

• The user uses abstract story adjectives without concrete beats behind them ("dark", "emotional", "epic", "mysterious", "cozy")
• The protagonist, antagonist, or player role lacks motivation
• The world has lore but no player-facing delivery method
• The story can be summarized but not played
• Branching is proposed without content-budget boundaries
• Tone conflicts with gameplay, art direction, or target audience

Seed Extraction

If a concept hint was provided, first spawn gat-writer to extract what the hint already answers. Briefly summarize what's established so the user can confirm or correct before diving in. Skip if no hint.

Interview Angles

Pick questions from any angle below. There is no fixed order — follow the thread that matters most at each moment. The table is a palette, not a checklist.

Navigating the Interview

• Start where the energy is. If the user leads with a character, start there. If they lead with setting, start with world rules. If they lead with mechanics, start with player role and story delivery.
• Drill, don't move on. When the answer is abstract, ask the follow-up that turns it into a beat, role, rule, or delivery method.
• Ask open-ended, resolve with options. Most questions should be dialogue. Use AskUserQuestion only when choosing among concrete narrative proposals.
• Spawn gat-writer mid-interview when you need a concise story proposal, character arc set, quest structure, or consistency pass. Present the result, then ask what to keep or change.
• Loop back naturally. If a later answer contradicts an earlier canon point, point it out and resolve the tension.
• Know when to stop. The interview has covered enough when:
  • The player role, premise, conflict, stakes, tone, and theme are clear
  • The story delivery method is known
  • The world has enough rules and locations for the game's scope
  • Major characters or factions have motivations and functions
  • Narrative content volume is bounded
  • The user starts repeating themselves rather than adding new information

Phase 3: Write or Summarize

If Mode is story

Before writing, summarize what's been decided across premise, world, characters, structure, delivery, scope, and open questions. Ask:

"Ready to write the narrative docs?" Options: Yes, write them / Let me keep discussing

If yes, read the relevant templates:

• .claude/docs/templates/design/narrative-story.md
• .claude/docs/templates/design/narrative-world.md
• .claude/docs/templates/design/narrative-characters.md
• .claude/docs/templates/design/narrative-quests.md
• .claude/docs/templates/design/narrative-dialogue.md

Spawn gat-writer to write the narrative docs under gat/narrative/.

Always write or update:

• gat/narrative/story.md

Write or update these only when the game needs them:

• gat/narrative/world.md for setting rules, factions, locations, culture, or environmental storytelling
• gat/narrative/characters.md for named cast, factions-as-characters, voice, arcs, or relationships
• gat/narrative/quests.md for authored missions, story objectives, progression beats, or branching consequences
• gat/narrative/dialogue.md for conversations, barks, VO, UI narrative text, or reusable voice rules

Pass all interview answers, existing overview/narrative files, and the selected templates. Instruct the writer to preserve template metadata and source-reference sections, mark uncertain material as open questions, and keep outputs concise.

If Mode is discuss

Summarize what was decided and what remains open. No files written.

Suggest:

• /gat-story (without discuss) to turn this discussion into narrative docs
• /gat-milestone to plan milestone slices after overview (and narrative, if needed) are ready

Phase 4: Hand Off

Summarize what was created or discussed.

If narrative docs were written, suggest next steps:

• /gat-milestone to plan milestone slices (milestone planning runs BEFORE per-system design; do NOT run /gat-design directly from here)
• If story revealed or changed systems, update gat/overview/systems-index.md (via /gat-brainstorm or directly) before planning milestones

Workflow Start

This skill is the workflow router for the simplified project. Because milestones can be in progress at different stages at the same time, it outputs a status panel (not a single command) and recommends the earliest actionable step.

Read only gat/ paths. Do not read or consider legacy design/ or production/ paths.

Phase 1: Inspect State

Check for these files (all under gat/):

• gat/overview/game.md
• gat/overview/systems-index.md
• gat/overview/art-direction.md
• gat/narrative/*.md
• gat/milestone/milestone.md
• each gat/milestone/m{N}-<name>/m{N}-brief.md
• each system's docs under gat/milestone/m{N}-<name>/<system>/

Phase 2: Derive Per-Milestone Stage

For each milestone that has an m{N}-brief.md, derive its stage from filesystem state:

• planned — brief exists, all systems Pending (no GDDs on disk)
• designing — at least one system designed but not all
• designed — every in-scope system's GDD (and art/data where required) is on disk
• building / built — user-set only; GAT cannot observe engineering. Read the status field from m{N}-brief.md if the user has advanced it past designed.

If the brief's status field disagrees with filesystem state, trust the brief's status only when it is building or built (engineering stages GAT can't derive); otherwise derive from files.

Phase 3: Status Panel

Report a short factual summary:

GAT Status:

Overview:
  gat/overview/game.md          [present | missing]
  gat/overview/systems-index.md [present | missing]
  gat/overview/art-direction.md [present | missing]

Narrative:
  gat/narrative/*.md            [N docs | missing]

Milestones (from gat/milestone/milestone.md):
  M1 <name>   [planned | designing | designed | building | built]  (K/N systems designed)
  M2 <name>   [planned | designing | designed | building | built]  (K/N systems designed)
  ...

Phase 4: Route

Use earliest-first priority to pick the primary recommendation, and list other valid actions:

1. If gat/overview/game.md, gat/overview/systems-index.md, or gat/overview/art-direction.md is missing: recommend /gat-brainstorm (with optional hint). This is the earliest step.
2. Else if the game needs narrative (per overview/user goal) and gat/narrative/story.md does not exist: recommend /gat-story.
3. Else if gat/milestone/milestone.md is missing: recommend /gat-milestone.
4. Else if the earliest milestone with unwritten systems exists: recommend /gat-design <that milestone> (continue) or /gat-design <that milestone> <system>.
5. Else if the earliest milestone is fully designed but no later milestone needs design: state that the milestone is ready for engineering handoff (the user runs their downstream engineering workflow on that milestone directory).
6. Otherwise: state that GAT pre-production is complete for all planned milestones and tell the user to hand milestones one at a time to their downstream engineering workflow.

Always also list other valid actions (e.g., "M1 ready for engineering; M2 designing — run /gat-design m2-<name> to continue M2").

Phase 5: Hand Off

End with one short line telling the user which command to run next (the primary recommendation), plus any alternative actions.

Animation Shader Skill

Domain knowledge reference for animation-style shaders (Toon Shaders). Contains preset styles, feature lists, and reference mappings for popular shader libraries.

[!NOTE] This skill contains domain knowledge only, not a workflow. Pair it with a workflow skill (e.g., OpenSpec, SpecKit) or an agent's plan mode for structured design flow.

Usage Modes

With Workflow Skill (Recommended)

When used with a workflow skill (e.g., OpenSpec, SpecKit) or in the plan mode of an agent, this skill serves as a domain knowledge plugin:

• During requirements/spec phases: Use the Presents section to identify the target style and map user requests to concrete feature sets
• During design/planning phases: Use the Feature List to look up all relevant references/ documents for each feature
• Key rule: For each identified feature, read ALL reference files listed — do not select just one

Knowledge Mode (Query)

When user requests to query knowledge for animation shaders, this skill provides preset styles and feature-to-reference mappings based on the task.

Presents

Use these presets when the user is unsure about specific features or wants a quick starting point for a specific style.

1. Basic Anime

• Description: The standard, clean anime look. Efficient, readable, and widely used.
• Features: Base Color / Main Texture, 3-Tone Shading (Double Shade), Outline (Inverted Hull).
• Use Case: General avatars, NPCs, standard anime characters, performance-critical scenes.

2. Advanced Illustration

• Description: A high-quality, detailed look with rich lighting, material definition, and depth.
• Features: Base Color / Main Texture, Layered Textures, 3-Tone Shading (Double Shade), Alpha Mask,Outline (Inverted Hull), Rim Light, MatCap (Material Capture), Specular / HighColor, Shadow Ramp.
• Use Case: Main characters, close-ups, high-fidelity VRChat avatars, cinematic cutscenes.

3. Stylized Sketch

• Description: Mimics hand-drawn art, manga, or pencil sketches with a rougher, artistic feel.
• Features: Color Adjustments (Desaturated), Sketchy Outline, Hatching, Halftone Overlay, Sketch / Paper Overlay.
• Use Case: Flashbacks, artistic indie games, unique aesthetic styles, manga adaptations.

4. Cyber / VFX

• Description: High-tech, glowing, and dynamic style with motion and reactivity.
• Features: Base Color / Main Texture (Dark), Emission / Glow, AudioLink, Dissolve, Vertex Manipulation (Glitch), Rim Light.
• Use Case: Sci-fi characters, powered-up states, music visualizers, holographic effects.

5. Semi-Realistic Toon

• Description: Blends anime aesthetics with realistic material properties for a modern, high-fidelity look.
• Features: PBR (Metallic/Smoothness), Normal Map, Shadow Ramp, Subsurface Scattering (SSS), Outline (Inverted Hull).
• Use Case: Modern action RPGs, high-end cinematic characters, "Genshin-like" but more detailed.

6. Retro 90s Anime

• Description: Recreates the look of classic cel animation from the 90s.
• Features: Color Adjustments (High Saturation, Posterization), 3-Tone Shading (Double Shade), Outline (Inverted Hull), Film Grain.
• Use Case: Nostalgic projects, retro-style games, lo-fi aesthetics.

7. Oil Painting / Artistic

• Description: Simulates traditional media like oil painting or watercolor.
• Features: Brush Stroke Textures, Distorted UVs, Sketch / Paper Overlay, Smudged Shadows, Sketchy Outline.
• Use Case: Storybook visuals, artistic showcases, dream sequences.

8. Flat Pop Art

• Description: A bold, graphic style with minimal shading and vibrant colors.
• Features: Base Color / Main Texture (Unlit), Outline (Inverted Hull), Halftone Overlay, Stencil Patterns.
• Use Case: UI characters, music videos, stylized indie games.

Feature List

A comprehensive list of features available across the supported shaders, organized by category.

1. Core Shading & Coloring

• Base Color / Main Texture: The primary color and texture of the model. (All)
  • references/lilToon/Details/01_Base_Main.md
  • references/PoiyomiShaders/Details/01_Base_Main.md
  • references/ToonShadingCollection/Details/03_Diffuse.md
• Color Adjustments: Adjusts Hue, Saturation, Brightness, or applies Posterization to the final color. (Poiyomi, SToon, lilToon)
  • references/lilToon/Details/01_Base_Main.md
  • references/PoiyomiShaders/Details/01_Base_Main.md
• 3-Tone Shading (Double Shade): Defines shadows using two distinct shades (1st and 2nd) for a traditional anime look. (lilToon, Poiyomi, UTS2)
  • references/lilToon/Details/02_Lighting_Shadows.md
  • references/PoiyomiShaders/Details/02_Lighting_Shadows.md
  • references/UnityChanToonShaderVer2/Details/01_DoubleShade.md
  • references/ToonShadingCollection/Details/09_Lighting_Shadows.md
• Shadow Ramp: Uses a gradient texture to control the falloff and color of shadows, allowing for soft or stylized transitions. (SToon, Poiyomi, RToon)
  • references/PoiyomiShaders/Details/02_Lighting_Shadows.md
• Shadow Texture (ShadowT): Applies a pattern (like hatching or halftone) specifically within the shadowed areas. (RToon, SToon)
  • references/RToon/Details/02_ShadowT.md
• Shading Grade Map: Controls the shadow threshold per-pixel using a grayscale map, allowing for organic shadow shapes. (UTS2)
  • references/UnityChanToonShaderVer2/Details/02_ShadingGradeMap.md
• Position Maps: Fixes shadows to specific areas (e.g., under the chin) regardless of lighting direction. (UTS2)
  • references/UnityChanToonShaderVer2/Details/01_DoubleShade.md
• Ambient Occlusion (AO): Adds soft shadows in crevices and corners to increase depth. (Poiyomi, SToon, lilToon)
  • references/lilToon/Details/02_Lighting_Shadows.md
  • references/PoiyomiShaders/Details/02_Lighting_Shadows.md
• Cell Shading / Hard Shading: Uses hard cutoffs for shadows to create a cel-shaded look. (RToon, SToon)
  • references/RToon/Details/01_Core_Shading.md
  • references/SToon/Details/01_Core_Shading.md
• Diffuse Warp: Distorts the shading terminator for irregular, hand-drawn shadow edges. (SToon)
  • references/SToon/Details/05_Artistic_Controls.md
• Normal Map: Adds surface detail and depth without changing geometry. (All)
  • references/PoiyomiShaders/Details/01_Base_Main.md
• Detail Maps: Adds high-frequency surface details using secondary textures. (Poiyomi, lilToon)
  • references/PoiyomiShaders/Details/02_Lighting_Shadows.md
• Layered Textures: Allows stacking multiple texture layers with blending modes for complex surface details. (lilToon, Poiyomi)
  • references/lilToon/Details/01_Base_Main.md
• Decals: Applies sticker-like textures on top of the main surface with independent transforms. (Poiyomi, lilToon)
  • references/lilToon/Details/01_Base_Main.md
• Alpha Mask: Controls transparency or restricts features to specific areas using a mask texture. (lilToon, Poiyomi)
  • references/lilToon/Details/01_Base_Main.md
• RGB Masking: Re-colors specific parts of the mesh using RGBA masks. (Poiyomi)
  • references/PoiyomiShaders/Details/01_Base_Main.md
• Triplanar Mapping: Applies textures based on world space, useful for models without proper UVs. (RToon, SToon)
  • references/RToon/Details/06_Advanced_Features.md

2. Surface & Reflections

• Specular / HighColor: Adds stylized highlights to the surface, often with masking or cartoon shapes. (All)
  • references/lilToon/Details/03_Surface_Reflections.md
  • references/PoiyomiShaders/Details/03_Surface_Reflections.md
  • references/ToonShadingCollection/Details/04_Specular.md
  • references/SToon/Details/04_Specular_Rim.md
  • references/RToon/Details/05_Gloss_Rim.md
• MatCap (Material Capture): Simulates complex lighting and reflections (like metal or hair sheen) using a sphere texture. (All)
  • references/RToon/Details/04_MatCap_Reflection.md
  • references/lilToon/Details/03_Surface_Reflections.md
  • references/PoiyomiShaders/Details/03_Surface_Reflections.md
  • references/UnityChanToonShaderVer2/Details/04_SpecialFeatures.md
• Camera Rolling Stabilizer: Keeps MatCap reflections upright even when the camera tilts. (UTS2)
  • references/UnityChanToonShaderVer2/Details/04_SpecialFeatures.md
• Rim Light: Adds a highlight to the edges of the model based on the viewing angle (Fresnel effect). (All)
  • references/RToon/Details/05_Gloss_Rim.md
  • references/SToon/Details/04_Specular_Rim.md
  • references/lilToon/Details/03_Surface_Reflections.md
  • references/PoiyomiShaders/Details/03_Surface_Reflections.md
• Backlight: Simulates light coming from behind the object, enhancing the silhouette or adding a rim on the shadowed side. (lilToon, SToon, UTS2)
  • references/lilToon/Details/02_Lighting_Shadows.md
  • references/SToon/Details/04_Specular_Rim.md
• Shadow Rim / Antipodean Rim: Adds a rim light specifically to the shadowed side of the object. (UTS2)
  • references/UnityChanToonShaderVer2/Details/04_SpecialFeatures.md
• Side Shine: Adds a specific highlight on the side of the object to increase volume. (SToon)
  • references/SToon/Details/04_Specular_Rim.md
• Anisotropy: Specialized highlights for hair or brushed metal surfaces. (lilToon, Poiyomi, SToon)
  • references/lilToon/Details/03_Surface_Reflections.md
  • references/PoiyomiShaders/Details/03_Surface_Reflections.md
  • references/ToonShadingCollection/Details/04_Specular.md
• Clear Coat: Adds an extra glossy layer on top of the material for a varnished look. (Poiyomi)
  • references/PoiyomiShaders/Details/03_Surface_Reflections.md
• Faked Reflection: Uses a static texture for reflections instead of a probe for stylized control. (RToon)
  • references/RToon/Details/04_MatCap_Reflection.md
• Environment / Reflections: Configures environment reflections using Cubemaps or Reflection Probes. (All)
  • references/ToonShadingCollection/Details/05_Environment.md
• Iridescence / Color Shift: Changes color based on viewing angle or time. (UTS2, Poiyomi)
  • references/UnityChanToonShaderVer2/Details/04_SpecialFeatures.md
• Subsurface Scattering (SSS): Simulates light penetrating translucent surfaces like skin. (Poiyomi)
  • references/PoiyomiShaders/Details/02_Lighting_Shadows.md

3. Outline & Edge Detection

• Outline (Inverted Hull): Creates outlines by extruding back-facing vertices; widely used for character outlines. (All)
  • references/lilToon/Details/08_Outline.md
  • references/PoiyomiShaders/Details/05_Outline.md
  • references/RToon/Details/03_Outline.md
  • references/UnityChanToonShaderVer2/Details/03_Outline.md
  • references/ToonShadingCollection/Details/02_Outline.md
• Stylized Outline: Noise, Sketchy, Hand-drawn look.
  • references/SToon/Details/02_Outline.md
  • references/RToon/Details/03_Outline.md
• Baked Normal Outline: Uses a smooth normal map for outlines to prevent breaks on hard edges. (UTS2)
  • references/UnityChanToonShaderVer2/Details/03_Outline.md

4. Special Effects & VFX

• Emission / Glow: Makes specific parts of the model glow, often with animation support. (lilToon, Poiyomi, UTS2)
  • references/lilToon/Details/04_Special_Effects.md
  • references/PoiyomiShaders/Details/04_Special_Effects.md
  • references/UnityChanToonShaderVer2/Details/04_SpecialFeatures.md
• Dissolve: Gradually makes the model transparent using a noise pattern, often with a glowing edge. (lilToon, Poiyomi)
  • references/PoiyomiShaders/Details/04_Special_Effects.md
  • references/lilToon/Details/04_Special_Effects.md
• Halftone Overlay: Applies a comic-book style dot pattern over the model. (SToon)
  • references/SToon/Details/03_Overlays.md
  • references/ToonShadingCollection/Details/08_PostProcessing.md
• Hatching: Uses line patterns for shading instead of solid colors, often with multiple layers. (SToon, RToon)
  • references/SToon/Details/03_Overlays.md
• Sketch / Paper Overlay: Applies paper textures or sketch lines for a hand-drawn look. (SToon)
  • references/SToon/Details/03_Overlays.md
• Glitter: Adds procedural sparkling effects to the surface. (lilToon)
  • references/lilToon/Details/04_Special_Effects.md
• AudioLink: Reacts to music/audio for dynamic effects like pulsing emission, color shifts, or vertex glitching. (lilToon, Poiyomi)
  • references/lilToon/Details/05_Advanced.md
  • references/PoiyomiShaders/Details/04_Special_Effects.md
• Parallax Occlusion: Simulates depth in textures by offsetting UVs based on view angle. (lilToon)
  • references/lilToon/Details/04_Special_Effects.md
• Vertex Manipulation: Deforms the mesh geometry (e.g., glitching, rounding, scaling). (Poiyomi, SToon)
  • references/PoiyomiShaders/Details/01_Base_Main.md
• Animation & Motion: Techniques for UV animation, vertex animation, and smear frames. (ToonShadingCollection)
  • references/ToonShadingCollection/Details/10_Animation_VFX.md
• Refraction / Gem: Simulates light bending through transparent materials like gems or eyes. (lilToon)
  • references/lilToon/Details/07_Variant_Features.md
• UV Animation: Scrolls or rotates textures for effects like flowing water or tech interfaces. (SToon, lilToon, UTS2)
  • references/lilToon/Details/01_Base_Main.md
  • references/SToon/Details/05_Artistic_Controls.md

5. Advanced & Pipeline

• Culling / Stencil / Clipping: Controls face culling and stencil buffer operations for advanced rendering effects. (lilToon, UTS2)
  • references/lilToon/Details/05_Advanced.md
  • references/UnityChanToonShaderVer2/Details/04_SpecialFeatures.md
• Stencil Masking: Uses the stencil buffer for effects like "eyebrows visible through hair". (lilToon, UTS2)
  • references/UnityChanToonShaderVer2/Details/04_SpecialFeatures.md
• Back Face Rendering: Dedicated settings for rendering the back side of polygons. (Poiyomi)
  • references/lilToon/Details/01_Base_Main.md
• Distance Fade / Near Fade: Fades the object or outline based on camera distance to prevent view blocking. (lilToon, RToon, UTS2)
  • references/RToon/Details/06_Advanced_Features.md
• Tessellation: Dynamically subdivides geometry for smoother curves. (lilToon)
  • references/lilToon/Details/07_Variant_Features.md
• Variants & Optimization: Guidelines for using shader variants (Lite, Multi) and optimizing models. (lilToon, ToonShadingCollection)
  • references/lilToon/Details/06_Variants.md
  • references/ToonShadingCollection/Details/11_Modeling_Pipeline.md
• Art Styles & Theory: Analysis of different art styles and PBR stylization techniques. (ToonShadingCollection)
  • references/ToonShadingCollection/Details/01_ArtStyles.md
  • references/ToonShadingCollection/Details/06_PBR_Stylization.md

6. Special Objects (Material Specific)

• Hair (Angel Ring): Creates a fixed highlight halo on hair. (UTS2)
  • references/UnityChanToonShaderVer2/Details/04_SpecialFeatures.md
  • references/ToonShadingCollection/Details/04_Specular.md
• Eyes: Specialized rendering for eyes including parallax, refraction, and stencil masking. (lilToon, UTS2)
  • references/lilToon/Details/07_Variant_Features.md
  • references/ToonShadingCollection/Details/07_Stylized_Features.md
• Skin: Simulates subsurface scattering and soft shading for skin. (Poiyomi, UTS2)
  • references/PoiyomiShaders/Details/02_Lighting_Shadows.md
  • references/ToonShadingCollection/Details/07_Stylized_Features.md
• Fur: Simulates fur using multi-layer rendering. (lilToon)
  • references/lilToon/Details/07_Variant_Features.md

Details Features Document

• references/lilToon/Features.md
• references/PoiyomiShaders/Features.md
• references/SToon/Features.md
• references/RToon/Features.md
• references/UnityChanToonShaderVer2/Features.md
• references/ToonShadingCollection/Features.md

Game Architect Skill

Game architecture domain knowledge reference. Provides paradigm selection, system design references for game project architecture.

[!NOTE] This skill contains domain knowledge only, not a workflow. Pair it with a workflow skill (e.g., OpenSpec, SpecKit) or an agent's plan mode for structured design flow.

Usage Modes

With Workflow Skill (Recommended)

When used with a workflow skill (e.g., OpenSpec, SpecKit) or in the plan mode of an agent, this skill serves as a domain knowledge plugin:

• During requirements/spec phases: Consult the Paradigm Selection Guide and System-Specific References to inform architectural decisions
• During design/planning phases: Use the Reference Lookup Guide below to read relevant references/ documents

Knowledge Mode (Query)

When user requests to query knowledge for game architecture, this skill provides a reference lookup guide to relevant references/ documents based on the task.

Reference Lookup Guide

When designing game architecture, read the relevant references/ documents based on the task:

Architecture References

• For physical architecture design, see the Physical Architecture References table below.
• For system-specific design, see the System-Specific References table below.
• For multiplayer system design, see the Multiplayer References table below.

Note : Only read the multiplayer references when multiplayer is needed.

Physical Architecture References

System-Specific References

Multiplayer References

Paradigm Selection Guide

Mixing Paradigms

Most projects mix paradigms:

1. Macro Consistency: All modules follow the same Module Management Framework.
2. Domain for Core Entities & Rules: Use DDD for systems with high rule complexity, rich domain concepts, and many distinct entities (e.g., Combat Actors, Damage Formulas, AI Decision).
3. Data for Content, Flow & State: Use Data-Driven for expandable content (Quests, Level Design), flow orchestration (Tutorial, Skill Execution, Narrative), and simple data management (Inventory, Shop).
4. Hybrid Paradigms:
   • 4.1 Entities as Data: Domain Entities naturally hold both data (fields) and behavior (methods). Design entities to be serialization-friendly (use IDs, keep state as plain fields) so they serve both roles without a separate data layer.
   • 4.2 Flow + Domain: Use data-driven flow to orchestrate the sequence/pipeline, domain logic to handle rules at each step. E.g., Skill System: flow drives cast→channel→apply, domain handles damage calc and buff interactions.
   • 4.3 Separate Data/Domain Layers: Only when edit-time and runtime representations truly diverge. Use a Bake/Compile step to bridge them. E.g., visual node-graph editors, compiled assets.
5. Paradigm Interchangeability: Many systems can be validly implemented with either paradigm. E.g., Actor inheritance hierarchy (Domain) ↔ ECS components + systems (Data-Driven); Buff objects with encapsulated rules (Domain) ↔ Tag + Effect data entries resolved by a generic pipeline (Data-Driven). See Selection Criteria table above for trade-off signals.
6. Integration: Application Layer bridges different paradigms.

Selection Criteria

When both DDD and Data-Driven fit, use these signals: