feat: add game development preset with 3 new roles and game-design module

Game Designer, Level Designer, and Game Artist roles for game development
workflows. game-design module with GDD template, shared/role-specific skills,
and CEO fallback. build-game preset with 5-milestone inline goal (Concept →
Prototype → Vertical Slice → Production → Polish & Ship) and 15 issues
covering the full game development lifecycle.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Author: lx-0

CHANGELOG.md

@@ -2,6 +2,18 @@
 
 All notable changes to Clipper are documented here.
 
+## [0.3.10] — 2026-03-14
+
+### Added
+
+- **Game development preset** (`build-game`) — Build a game from idea to playable release. Composes game-design, tech-stack, github-repo, backlog, auto-assign, and stall-detection. Includes Game Designer and Game Artist roles. 5-milestone inline goal (Concept → Prototype → Vertical Slice → Production → Polish & Ship) with 15 issues covering GDD creation, engine setup, art pipeline, playtesting, and distribution.
+- **3 new roles:**
+    - **Game Designer** (`product` division) — Owns the GDD, core mechanics, progression, difficulty curves, and balancing. Gets a role-specific `game-design` skill with deep mechanic design, balancing workflows, and design experiment methodology.
+    - **Level Designer** (`product` division) — Owns level layout, pacing, difficulty curves, environmental storytelling, and spatial progression.
+    - **Game Artist** (`design` division) — Owns visual art production: sprites, textures, tilesets, UI elements. Creates assets using AI image generation, code-based approaches (SVG, procedural), and asset pipeline tools.
+- **`game-design` module** — Game Design Document creation and ongoing mechanic design/balancing. `game-design` capability (owners: game-designer → engineer → ceo). Ships a GDD template (`docs/gdd-template.md`) covering concept, core mechanic, game loop, progression, controls, art/audio direction, and tuning parameters.
+- **Content audit issue** added to `website-relaunch` module — Agent-executed crawl of the current website's content as intake for the redesign, covering content types, key messages, quality, media assets, SEO, and migration strategy.
+
 ## [0.3.9] — 2026-03-14
 
 ### Added

README.md

@@ -110,7 +110,7 @@ $ clipper --api
 | `--project <name>` | Project name | company name |
 | `--project-description <desc>` | Project description | _(wizard prompt)_ |
 | `--repo <url>` | GitHub repository URL | _(wizard prompt)_ |
-| `--preset <name>` | Preset: `fast`, `quality`, `rad`, `startup`, `research`, `full`, `secure`, `gtm`, `content`, `repo-maintenance` | _(wizard prompt)_ |
+| `--preset <name>` | Preset: `fast`, `quality`, `rad`, `startup`, `research`, `full`, `secure`, `gtm`, `content`, `repo-maintenance`, `build-game` | _(wizard prompt)_ |
 | `--modules <a,b,c>` | Comma-separated module names (merged with preset) | _(wizard prompt)_ |
 | `--roles <a,b>` | Comma-separated extra role names (merged with preset) | _(wizard prompt)_ |
 
@@ -256,6 +256,7 @@ Start with CEO + Engineer. Everything works. Add specialists and responsibilitie
 | `issue-triage` | Product Owner &rarr; Engineer | CEO | triage |
 | `dependency-audit` | DevOps &rarr; Security Engineer | Engineer | dependency-management |
 | `release-process` | DevOps &rarr; Engineer | CEO | release-management |
+| `game-design` | Game Designer &rarr; Engineer | CEO | game-design |
 | `stall-detection` | CEO (always) | — | stall-detection |
 | `vision-workshop` | CEO (always) | — | vision-workshop |
 
@@ -282,6 +283,7 @@ Start with CEO + Engineer. Everything works. Add specialists and responsibilitie
 | **`build-api`** | build-api, github-repo, backlog, auto-assign, ci-cd, stall-detection | Build a REST/GraphQL API from scratch |
 | **`website-relaunch`** | website-relaunch, github-repo, pr-review, backlog, auto-assign, stall-detection + UI Designer + PO | Relaunch a website with external design assets |
 | **`repo-maintenance`** | triage, codebase-onboarding, dependency-management, release-management, github-repo, pr-review, backlog, auto-assign, stall-detection + Code Reviewer + PO | Maintain an existing repository |
+| **`build-game`** | game-design, tech-stack, github-repo, backlog, auto-assign, stall-detection + Game Designer + Game Artist | Build a game from idea to release |
 
 > **`fast`** is for a single engineer — multiple engineers without review will cause conflicts.
 >
@@ -312,6 +314,8 @@ Start with CEO + Engineer. Everything works. Add specialists and responsibilitie
 
 **repo-maintenance** — Custodial maintenance for existing repositories. Agents review and merge open PRs, triage inbound GitHub issues, audit codebase health, manage dependencies, and handle releases. Code Reviewer for PR quality gates, Product Owner for issue triage and backlog. Inline goal bootstraps the team through repo onboarding, process setup, initial sweep, and steady-state maintenance.
 
+**build-game** — Game development from idea to playable release. Game Designer owns the GDD, mechanics, and balancing. Game Artist generates sprites, textures, and tilesets via AI image generation and code-based approaches. Inline goal with 5 milestones: concept (GDD + engine + art style), prototype (core loop + placeholder art + first playtest), vertical slice (one polished level), production (all content), polish & ship (balancing + distribution). Works for any genre.
+
 </details>
 
 <br>
@@ -335,6 +339,7 @@ Start with CEO + Engineer. Everything works. Add specialists and responsibilitie
 | **`accessibility`** | WCAG 2.2 compliance audit and remediation | Primary owner runs audit |
 | **`website-relaunch`** | Website relaunch: audit, design ingestion, implementation, migration | Engineer audits + analyzes designs |
 | **`launch-mvp`** | MVP lifecycle: scope, build core feature, deploy, iterate from feedback | CEO scopes, Engineer builds |
+| **`game-design`** | Game Design Document, core mechanics, progression, balancing | Primary owner creates GDD |
 
 ### Maintenance & Operations
 
@@ -543,6 +548,14 @@ Release lifecycle: semantic versioning, changelog generation, git tagging, GitHu
 - **Fallback:** Engineer documents current process and sets up basic semver
 - **Output:** `docs/RELEASE-PROCESS.md`
 
+#### game-design
+
+Game Design Document creation and ongoing mechanic design, progression, and balancing. Ships a GDD template covering concept, core mechanic, three-layer game loop, progression, win/lose, controls, art/audio direction, and tuning parameters. Game Designer gets a deep role-specific skill with balancing workflows and design experiments.
+
+- **Capability:** `game-design` — owners: `game-designer` &rarr; `engineer` &rarr; `ceo`
+- **Fallback:** CEO writes minimal GDD with concept and core mechanic only
+- **Doc:** `docs/gdd-template.md`
+
 #### stall-detection
 
 Detects issues stuck in `in_progress` or `in_review` with no recent activity. Nudges the assigned agent, escalates to the board if nudging doesn't help.
@@ -571,6 +584,9 @@ Every company starts with **CEO** and **Engineer** (base roles). These optional
 | **Technical Writer** | `general` | CEO | Takes over documentation, adds doc review pass |
 | **Security Engineer** | `general` | CEO | Takes over security-audit, adds security review pass |
 | **Customer Success** | `general` | CEO | Takes over competitive-intel customer analysis |
+| **Game Designer** | `pm` | CEO | Takes over game-design from Engineer, playtesting focus |
+| **Level Designer** | `pm` | CEO | Takes over level-specific design from Game Designer |
+| **Game Artist** | `designer` | CEO | Takes over art asset creation from Engineer |
 
 <details>
 <summary><strong>Role details</strong></summary>
@@ -623,6 +639,18 @@ Owns threat modeling, security code reviews, OWASP compliance, and secure coding
 
 Owns customer health monitoring, feedback synthesis, churn prevention, and competitive intelligence from the customer perspective. Empathy-driven, data-backed.
 
+#### Game Designer
+
+Owns the Game Design Document, core mechanics, game loop, progression systems, difficulty curves, and balancing. Defines what the game is and how it plays. Runs design experiments and iterates based on playtest data.
+
+#### Level Designer
+
+Owns level layout, pacing, difficulty curves, environmental storytelling, and spatial progression. Translates game design into playable spaces and encounters.
+
+#### Game Artist
+
+Owns visual art production: sprites, textures, tilesets, UI elements, and visual effects. Creates assets using AI image generation tools, code-based approaches (SVG, procedural generation, pixel art scripts), and asset pipeline tools.
+
 </details>
 
 <br>

templates/modules/game-design/agents/ceo/skills/game-design.fallback.md

@@ -0,0 +1,17 @@
+# Skill: Game Design (Fallback)
+
+The Game Designer or Engineer primarily owns the game design. You are the fallback — step in only if they are absent or haven't started.
+
+## Game Design (Fallback)
+
+1. If no `docs/GDD.md` exists and no one else has started:
+   - Write a minimal Game Design Document covering: concept pitch, core mechanic, basic game loop, target platform
+   - List obvious design questions that need answers (progression, win conditions, art style)
+   - Mark the document as **provisional** — it needs a thorough design review
+2. If the Game Designer or Engineer is active, skip this entirely.
+
+## Rules
+
+- This is a safety net. Define the basics so the team has direction.
+- Skip detailed mechanics, balancing, and progression — those need dedicated design work.
+- Don't make art direction decisions — leave those to the Game Artist or Game Designer.

templates/modules/game-design/agents/game-designer/skills/game-design.md

@@ -0,0 +1,51 @@
+# Skill: Game Design (Game Designer)
+
+You are the primary owner of the game design. This is your core responsibility.
+
+## Game Design Document
+
+Create and maintain `docs/GDD.md` as the single source of truth. Cover every section thoroughly:
+
+1. **Concept** — One-paragraph pitch. Genre, theme, target platform, target audience. What makes this game unique?
+2. **Core mechanic** — The central verb. Define precisely: input → action → feedback → consequence. What makes it feel good?
+3. **Game loop** — Three layers:
+   - **Moment-to-moment** — The 5-second loop. What creates flow state?
+   - **Session loop** — The 15-minute loop. What gives structure and pacing?
+   - **Meta loop** — The multi-session loop. What creates "one more run" compulsion?
+4. **Mechanics catalog** — Every mechanic in the game: name, description, when introduced, interactions with other mechanics.
+5. **Progression** — Difficulty curve design. What gates progress? Skill gates vs content gates. Unlock schedule.
+6. **Economy** (if applicable) — Resources, currencies, costs, rewards, drop rates. The flow of value.
+7. **Win/lose conditions** — Session end conditions. Game end conditions. Fail states and recovery.
+8. **Controls** — Input mapping per platform. Responsiveness targets (input lag, animation cancel windows).
+9. **Game feel** — Coyote time, input buffering, screen shake, hit stop, juice. The invisible design.
+10. **Art direction** — Visual style, reference games, color language (what colors mean in gameplay), silhouette readability.
+11. **Audio direction** — Music style, SFX for feedback loops, adaptive audio triggers.
+12. **Tuning parameters** — Every balance-relevant value as a named parameter:
+    - Format: `parameter_name: default_value (range: min–max) — what it affects`
+    - Group by system: player, enemies, economy, progression
+
+## Balancing
+
+After each playtest round:
+
+1. Read `docs/PLAYTEST-RESULTS.md` (if it exists).
+2. Identify the top 3 balance issues by player impact.
+3. Adjust tuning parameters with clear rationale.
+4. Update the GDD with new values.
+5. Create issues for parameter changes that need engineering implementation.
+
+## Design Experiments
+
+When a mechanic is uncertain:
+
+1. Define two variants with specific parameter differences.
+2. Create a playtest issue specifying what to compare and how to measure.
+3. After results, commit to one direction and document why.
+
+## Rules
+
+- Fun is measurable. "Players quit at level 3" is data. "The game needs to be more fun" is not actionable.
+- Design the minimum viable game first. Scope down ruthlessly. What's the smallest thing that's fun to play?
+- The GDD is alive. Update it every heartbeat if needed. A stale GDD is worse than no GDD.
+- Tuning values are never final. Document your reasoning so future changes have context.
+- Playtest early, playtest often. Paper design only gets you so far.

templates/modules/game-design/docs/gdd-template.md

@@ -0,0 +1,72 @@
+# Game Design Document
+
+## Concept
+
+**Title:** [Working title]
+**Genre:** [e.g., Platformer, Roguelike, Puzzle, Tower Defense]
+**Platform:** [e.g., Web (HTML5), Desktop, Mobile]
+**Target audience:** [e.g., Casual players, Speedrunners, Strategy fans]
+**Pitch:** [One paragraph: what is this game and why is it fun?]
+
+## Core Mechanic
+
+[The one thing the player does most. Describe the full loop: input → action → feedback → consequence.]
+
+## Game Loop
+
+### Moment-to-moment (5 seconds)
+[What does the player do every few seconds?]
+
+### Session loop (15 minutes)
+[What does a single play session look like? How does it start, flow, and end?]
+
+### Meta loop (multi-session)
+[What brings the player back? Progression, unlocks, story, scores?]
+
+## Mechanics
+
+| Mechanic | Description | Introduced | Interacts with |
+| :------- | :---------- | :--------- | :------------- |
+| | | | |
+
+## Progression
+
+[How does difficulty increase? What gates progress? Skill vs content gates. Unlock schedule.]
+
+## Win / Lose
+
+[How does a session end? How does the overall game end? Fail states and recovery.]
+
+## Controls
+
+| Action | Keyboard | Gamepad | Touch |
+| :----- | :------- | :------ | :---- |
+| | | | |
+
+## Art Direction
+
+**Style:** [e.g., Pixel art 16x16, Low-poly, Hand-drawn]
+**Color language:** [What colors mean in gameplay — player, enemy, pickup, hazard, neutral]
+**References:** [Games or art that capture the target aesthetic]
+
+## Audio Direction
+
+**Music:** [Style, mood, adaptive triggers]
+**SFX:** [Key sounds: player actions, feedback, UI]
+
+## Tuning Parameters
+
+### Player
+| Parameter | Default | Range | Affects |
+| :-------- | :------ | :---- | :------ |
+| | | | |
+
+### Enemies
+| Parameter | Default | Range | Affects |
+| :-------- | :------ | :---- | :------ |
+| | | | |
+
+### Economy
+| Parameter | Default | Range | Affects |
+| :-------- | :------ | :---- | :------ |
+| | | | |

templates/modules/game-design/module.meta.json

@@ -0,0 +1,17 @@
+{
+  "name": "game-design",
+  "capabilities": [
+    {
+      "skill": "game-design",
+      "owners": ["game-designer", "engineer", "ceo"],
+      "fallbackSkill": "game-design.fallback"
+    }
+  ],
+  "tasks": [
+    {
+      "title": "Create Game Design Document",
+      "assignTo": "capability:game-design",
+      "description": "Define the game's core design: genre, core mechanic, game loop, progression system, win/lose conditions, control scheme, and target audience. Document everything in docs/GDD.md. This is the single source of truth for what the game is."
+    }
+  ]
+}

templates/modules/game-design/skills/game-design.md

@@ -0,0 +1,41 @@
+# Skill: Game Design
+
+You own the Game Design Document (GDD) and the ongoing design of the game's mechanics, systems, and player experience.
+
+## Game Design Document
+
+Create and maintain `docs/GDD.md` as the single source of truth. It must cover:
+
+1. **Concept** — One-paragraph pitch. Genre, theme, target platform, target audience.
+2. **Core mechanic** — The one thing the player does most. Define it precisely: input → action → feedback → consequence.
+3. **Game loop** — Three layers:
+   - **Moment-to-moment** — What happens every few seconds (jump, shoot, match, place)
+   - **Session loop** — What a single play session looks like (level, round, run, match)
+   - **Meta loop** — What keeps players coming back (progression, unlocks, story, leaderboards)
+4. **Progression** — How difficulty and complexity increase. What gates progress. What the player earns.
+5. **Win/lose conditions** — How does a session end? How does the overall game end? Is there permadeath, lives, continues?
+6. **Controls** — Input scheme for each platform. Keep it simple — if it needs a tutorial, simplify.
+7. **Art direction** — Visual style (pixel art, low-poly, hand-drawn, etc.), color palette guidance, reference games/art.
+8. **Audio direction** — Music style, SFX approach, adaptive audio (if any).
+9. **Tuning parameters** — List every value that affects balance as a named parameter with default:
+   - Player speed, jump height, health, damage, cooldowns
+   - Enemy stats, spawn rates, AI behavior thresholds
+   - Economy values: costs, rewards, drop rates
+
+## Ongoing Design Work
+
+On each heartbeat when `docs/GDD.md` exists:
+
+1. Review recent playtesting feedback (if `docs/PLAYTEST-RESULTS.md` exists).
+2. Identify mechanics that aren't working — not fun, confusing, or broken.
+3. Propose design changes with clear rationale: what's wrong, what to try, expected impact.
+4. Update tuning parameters based on playtest data.
+5. Create issues for new mechanics, balancing passes, or design experiments.
+
+## Rules
+
+- The GDD is a living document. Update it as the design evolves — don't let it get stale.
+- Every mechanic must pass the "why is this fun?" test. If you can't answer, cut it.
+- Design for the minimum viable game first. What's the smallest version that's fun?
+- Tuning values must be parameterized, never hardcoded. Document them in the GDD with ranges.
+- When in doubt, prototype and playtest. Don't design in a vacuum.