1. A fully scaffolded game project with clean architecture
2. Pixel art sprites — recognizable characters, enemies, and items (optional, replaces geometric shapes)
3. Visual polish — gradients, particles, transitions, juice
4. A 50 FPS promo video — autonomous gameplay capture, mobile portrait, ready for social media
5. Chiptune music and retro sound effects (no audio files needed)
6. Live deployment to GitHub Pages with a public URL
7. Monetization via Play.fun — points tracking, leaderboards, wallet connect, and a play.fun URL to share on Moltbook
8. Future changes auto-deploy on

   git push

1. Set up the project (template copy, npm install, dev server)
2. Create and track pipeline tasks using

   TaskCreate

   /

   TaskUpdate

3. Delegate each code-writing step to a

   Task

   subagent
4. Run the Verification Protocol (build + visual review + autofix) after each code-modifying step
5. Report results to the user between steps

• Step 0: Parse arguments, create todo list
• Step 1 (infrastructure only): Copy template, npm install, playwright install, start dev server
• Verification protocol orchestration (launch QA subagent, read text result, launch autofix if needed)
• Step 4 (deploy): Interactive auth requires user back-and-forth

Task

• Step 1 (game implementation): Transform template into the actual game concept
• Step 1.5: Pixel art sprites and backgrounds
• Step 2: Visual polish
• Step 2.5: Promo video capture
• Step 3: Audio integration

browser_navigate

1. Run:

   claude mcp add playwright npx @playwright/mcp@latest

2. Tell the user: "Playwright MCP has been added. Please restart Claude Code for it to take effect, then tell me to continue."
3. Wait for user to restart and confirm. Do not proceed until MCP tools are available.

Task

You are the QA subagent for the game creation pipeline.

Project path:

<project-dir>

Dev server port:

<port>

Step being verified:

<step name>

Run these phases in order. Stop early if a phase fails critically (build or runtime).

Phase 1 — Build Check

bash

cd <project-dir> && npm run build

If the build fails, report FAIL immediately with the error output.

Phase 2 — Runtime Check

bash

cd <project-dir> && node scripts/verify-runtime.mjs

If the runtime check fails, report FAIL immediately with the error details.

Phase 3 — Gameplay Verification

bash

cd <project-dir> && node scripts/iterate-client.js \
  --url http://localhost:<port> \
  --actions-file scripts/example-actions.json \
  --iterations 3 --screenshot-dir output/iterate

After running, read the state JSON files (

output/iterate/state-*.json

) and error files (

output/iterate/errors-*.json

):

• Scoring: At least one state file should show

  score > 0

• Death: At least one state file should show

  mode: "game_over"

  . Mark as SKIPPED (not FAIL) if game_over is not reached — some games have multi-life systems or random hazard spawns that make death unreliable in short iterate runs. Death SKIPPED is acceptable and does not block the pipeline.
• Errors: No critical errors in error files

Skip this phase if

scripts/iterate-client.js

is not present.

Phase 4 — Architecture Validation

bash

cd <project-dir> && node scripts/validate-architecture.mjs

Report any warnings but don't fail on architecture issues alone.

Phase 5 — Visual Review via Playwright MCP Use Playwright MCP to visually review the game. If MCP tools are not available, fall back to reading iterate screenshots from

output/iterate/

.

With MCP:

1. browser_navigate

   to

   http://localhost:<port>

2. browser_wait_for

   — wait 2 seconds for the game to load

3. browser_take_screenshot

   — save as

   output/qa-gameplay.png

4. Assess: Are entities visible? Is the game rendering correctly?
5. Check safe zone: Is any UI hidden behind the top ~8% (Play.fun widget area)?
6. Check entity sizing: Is the main character large enough (12–15% screen width for character games)?
7. Wait for game over (or navigate to it),

   browser_take_screenshot

   — save as

   output/qa-gameover.png

8. Check buttons: Are button labels visible? Blank rectangles = broken button pattern.
9. Check mute button: Is there a mute toggle visible? If not, flag as ISSUE.

Screenshot timeout: If

browser_take_screenshot

hangs for more than 10 seconds (can happen with continuous WebGL animations), cancel and proceed with code review instead. Do not let a screenshot hang block the entire QA phase.

Note on iterate screenshots: The iterate-client uses

canvas.toDataURL()

which returns blank/black images when Phaser uses WebGL with

preserveDrawingBuffer: false

. Always prefer Playwright MCP viewport screenshots (

browser_take_screenshot

) over iterate screenshots for visual review.

Without MCP (fallback):

1. Read the iterate screenshots from

   output/iterate/shot-*.png

   (may be black if WebGL — this is expected)
2. Fall back to code review: read scene files and assess visual correctness from the code

Return your results in this exact format (text only, no images):

QA RESULT: PASS|FAIL

Phase 1 (Build): PASS|FAIL
Phase 2 (Runtime): PASS|FAIL
Phase 3 (Gameplay): Iterate PASS|FAIL, Scoring PASS|FAIL|SKIPPED, Death PASS|FAIL|SKIPPED, Errors PASS|FAIL
Phase 4 (Architecture): PASS — N/N checks
Phase 5 (Visual): PASS|FAIL — <issues if any>

ISSUES:
- <issue descriptions, or "None">

SCREENSHOTS: output/qa-gameplay.png, output/qa-gameover.png

1. Read

   output/autofix-history.json

   to see what fixes were already attempted. If a previous entry matches the same

   issue

   and

   fix_attempted

   with

   result: "failure"

   , instruct the subagent to try a different approach.
2. Launch a fix subagent via

   Task

   tool with:
   • The ISSUES list from the QA result
   • The phase that failed (build errors, runtime errors, gameplay issues, visual problems)
   • Any relevant failed attempts from

     output/autofix-history.json

     so the subagent knows what NOT to repeat
3. After each autofix attempt, append an entry to

   output/autofix-history.json

   :
   json

   { "step": "<step name>", "issue": "<what failed>", "fix_attempted": "<what was tried>", "result": "success|failure", "timestamp": "<ISO date>" }

4. Re-run the QA subagent (all phases)
5. Up to 3 total attempts per step (1 original + 2 retries)
6. If all 3 attempts fail, report the failure to the user and ask whether to skip or abort

• Engine:

  2d

  (Phaser — side-scrollers, platformers, arcade) or

  3d

  (Three.js — first-person, third-person, open world). If not specified, ask the user.
• Name: The game name in kebab-case. If not specified, ask the user what kind of game they want and suggest a name.

$ARGUMENTS

x.com/*/status/*

twitter.com/*/status/*

fxtwitter.com/*/status/*

vxtwitter.com/*/status/*

1. Fetch the tweet using the

   fetch-tweet

   skill — convert the URL to

   https://api.fxtwitter.com/<user>/status/<id>

   and fetch with

   WebFetch

2. Default to 2D (Phaser) — tweets describe ideas that map naturally to 2D arcade/casual games
3. Creatively abstract a game concept from the tweet text. Your job is creative transformation — extract themes, dynamics, settings, or mechanics and reinterpret them as a game. NEVER refuse to make a game from a tweet. Every tweet contains something that can inspire a game:
   • News about weather → survival game, storm-dodging game
   • Sports result → arcade sports game
   • Political/legal news → strategy game, puzzle game, tower defense
   • Personal story → narrative adventure, platformer themed around the journey
   • Product announcement → tycoon game, builder game
   • Abstract thought → puzzle game, experimental art game
   • The transformation is the creative act. You are not recreating or trivializing the source — you are using it as a springboard for an original game concept.
4. Generate a game name in kebab-case from the abstracted concept (not from literal tweet content)
5. Tell the user what you extracted:

   Found tweet from @handle: "Tweet text..."

   I'll build a 2D game based on this: [your creative interpretation as a game concept] Game name:

   <generated-name>

   Sound good?

1. character-library/manifest.json

   (relative to plugin root) — exact slug match or name match
2. Common name recognition — politicians, tech CEOs, world leaders, entertainers

• Set

  hasCelebrities = true

  and list detected names
• Note in

  progress.md

  which characters are pre-built vs need building
• 2D: The Step 1.5 subagent will use photo-composite characters for these
• 3D: For each celebrity, try: (1) generate with Meshy AI —

  "a cartoon caricature of <Name>, <distinguishing features>, low poly game character"

  then rig for animation, (2) check

  3d-character-library/manifest.json

  for a pre-built match, (3) search Sketchfab with

  find-3d-asset.mjs

  , (4) fall back to best-matching library model. Meshy generation produces the best results for named personalities since it can capture specific visual features.

MESHY_API_KEY

I'll generate custom 3D models with Meshy AI for the best results. You can get a free API key in 30 seconds:

1. Sign up at https://app.meshy.ai
2. Go to Settings → API Keys
3. Create a new API key

What is your Meshy API key? (Or type "skip" to use generic model libraries instead)

meshy-generate.mjs

TaskCreate

1. Scaffold game from template
2. Add assets: pixel art sprites (2D) or Meshy AI-generated GLB models + animated characters (3D)
3. Add visual polish (particles, transitions, juice)
4. Record promo video (autonomous 50 FPS capture)
5. Add audio (BGM + SFX)
6. Deploy to GitHub Pages
7. Monetize with Play.fun (register on OpenGameProtocol, add SDK, redeploy)

output/

output/autofix-history.json

[]

in_progress

1. Locate the plugin's template directory. Check these paths in order until found:
   • The agent's plugin cache (e.g.

     ~/.claude/plugins/cache/local-plugins/game-creator/1.0.0/templates/

     )
   • The

     templates/

     directory relative to this plugin's install location
2. Determine the target directory. If the current working directory is the

   game-creator

   plugin repository (check for

   CLAUDE.md

   mentioning "game-creator" or

   .claude-plugin/plugin.json

   ), create the game inside

   examples/

   (e.g.,

   examples/<game-name>/

   ). Otherwise, create it in the current working directory (

   <game-name>/

   ).
3. Copy the entire template directory to the target:
   • 2D: copy

     templates/phaser-2d/

     →

     <target-dir>/

   • 3D: copy

     templates/threejs-3d/

     →

     <target-dir>/

4. Update

   package.json

   — set

   "name"

   to the game name
5. Update

   <title>

   in

   index.html

   to a human-readable version of the game name
6. Verify Node.js/npm availability: Run

   node --version && npm --version

   to confirm Node.js and npm are installed and accessible. If they fail (e.g., nvm lazy-loading), try sourcing nvm:

   export NVM_DIR="$HOME/.nvm" && source "$NVM_DIR/nvm.sh"

   then retry. If Node.js is not installed at all, tell the user they need to install it before continuing.
7. Run

   npm install

   in the new project directory
8. Install Playwright and Chromium — Playwright is required for runtime verification and the iterate loop:
   1. Check if Playwright is available:

      npx playwright --version

   2. If that fails, check

      node_modules/.bin/playwright --version

   3. If neither works, run

      npm install -D @playwright/test

      explicitly
   4. Then install the browser binary:

      npx playwright install chromium

   5. Verify success; if it fails, warn and continue (build verification still works, but runtime/iterate checks will be skipped)
9. Verify template scripts exist — The template ships with

   scripts/verify-runtime.mjs

   ,

   scripts/iterate-client.js

   , and

   scripts/example-actions.json

   . Confirm they are present. The

   verify

   and

   iterate

   npm scripts are already in

   package.json

   from the template.
10. Start the dev server — Before running

    npm run dev

    , check if the configured port (in

    vite.config.js

    ) is already in use:

    lsof -i :<port> -t

    . If occupied, update

    vite.config.js

    to use the next available port (try 3001, 3002, etc.). Then start the dev server in the background and confirm it responds. Keep it running throughout the pipeline. Note the actual port number — pass it to

    scripts/verify-runtime.mjs

    via the

    PORT

    env variable in subsequent runs.

Task

You are implementing Step 1 (Scaffold) of the game creation pipeline.

Project path:

<project-dir>

Engine:

<2d|3d>

Game concept:

<user's game description>

Skill to load:

phaser

(2D) or

threejs-game

(3D)

Core loop first — implement in this order:

1. Input (touch + keyboard from the start — never keyboard-only)
2. Player movement / core mechanic
3. Fail condition (death, collision, timer)
4. Scoring
5. Restart flow (GameState.reset() → clean slate)

Keep scope small: 1 scene, 1 mechanic, 1 fail condition. Wire spectacle EventBus hooks alongside the core loop — they are scaffolding, not polish.

Transform the template into the game concept:

• Rename entities, scenes/systems, and events to match the concept
• Implement core gameplay mechanics
• Wire up EventBus events, GameState fields, and Constants values
• Ensure all modules communicate only through EventBus
• All magic numbers go in Constants.js
• No title screen — the template boots directly into gameplay. Do not create a MenuScene or title screen. Only add one if the user explicitly asks.
• No in-game score HUD — the Play.fun widget displays score in a deadzone at the top of the game. Do not create a UIScene or HUD overlay for score display.
• Mobile-first input: Choose the best mobile input scheme for the game concept (tap zones, virtual joystick, gyroscope tilt, swipe). Implement touch + keyboard from the start — never keyboard-only. Use the unified analog InputSystem pattern (moveX/moveZ) so game logic is input-source-agnostic.
• Force portrait for vertical games: For dodgers, runners, collectors, and endless fallers, set

  FORCE_PORTRAIT = true

  in Constants.js. This locks portrait layout on desktop (pillarboxed with black bars via

  Scale.FIT + CENTER_BOTH

  ). Use fixed design dimensions (540×960), not conditional

  _isPortrait ? 540 : 960

  .
• Visible touch indicators required: Always render semi-transparent arrow buttons (or direction indicators) on touch-capable devices. Use capability detection (

  ('ontouchstart' in window) || (navigator.maxTouchPoints > 0)

  ), NOT OS detection (

  device.os.android || device.os.iOS

  ). Enable pointer events (pointerdown/pointermove/pointerup) on ALL devices — never gate behind

  isMobile

  . Use

  TOUCH

  constants from Constants.js for sizing.
• Minimum 7–8% canvas width for collectibles/hazards: Items smaller than 7% of

  GAME.WIDTH

  become unrecognizable blobs on phone screens. Size attacks at ~9%, power-ups at ~7%, player character at 12–15%.
• Wire spectacle events: emit

  SPECTACLE_ENTRANCE

  in

  create()

  ,

  SPECTACLE_ACTION

  on every player input,

  SPECTACLE_HIT

  on score/destroy,

  SPECTACLE_COMBO

  on consecutive hits (pass

  { combo }

  ),

  SPECTACLE_STREAK

  at milestones (5, 10, 25 — pass

  { streak }

  ),

  SPECTACLE_NEAR_MISS

  on close calls

Visual identity — push the pose:

• If the player character represents a real person or brand, build visual recognition into the entity from the start. Don't use generic circles/rectangles as placeholders — use descriptive colors, proportions, and features that communicate identity even before pixel art is added.
• Named opponents/NPCs must have visual presence on screen — never text-only. At minimum use distinct colored shapes that suggest the brand. Better: simple character forms with recognizable features.
• Collectibles and hazards must be visually self-explanatory. Avoid abstract concepts ("imagination blocks", "creativity sparks"). Use concrete objects players instantly recognize (polaroids, trophies, lightning bolts, money bags, etc.).
• Think: "Could someone screenshot this and immediately know what the game is about?"
• NEVER use a single letter (C, G, O) as a character's visual identity
• NEVER differentiate two characters only by fill color — they must have distinct silhouettes and features
• When a company is featured (OpenAI, Anthropic, xAI, etc.), use the CEO as the character: Altman for OpenAI, Amodei for Anthropic, Musk for xAI, Zuckerberg for Meta, Nadella for Microsoft, Pichai for Google, Huang for NVIDIA
• Add entrance sequence in

  create()

  : player starts off-screen, tweens into position with

  Bounce.easeOut

  , landing shake + particle burst
• Add combo tracking to GameState:

  combo

  (current streak, resets on miss),

  bestCombo

  (session high), both reset in

  reset()

• Ensure restart is clean — test mentally that 3 restarts in a row would work identically
• Add

  isMuted

  to GameState for mute support

CRITICAL — Preserve the button pattern:

• The template's

  GameOverScene.js

  contains a working

  createButton()

  helper (Container + Graphics + Text). Do NOT rewrite this method. Keep it intact or copy it into any new scenes that need buttons. The correct z-order is: Graphics first (background), Text second (label), Container interactive. If you put Graphics on top of Text, the text becomes invisible. If you make the Graphics interactive instead of the Container, hover/press states break.

Character & entity sizing:

• Character WIDTH from

  GAME.WIDTH * ratio

  , HEIGHT from

  WIDTH * SPRITE_ASPECT

  (where

  const SPRITE_ASPECT = 1.5

  for 200×300 spritesheets). Never define character HEIGHT as

  GAME.HEIGHT * ratio

  — on mobile portrait,

  GAME.HEIGHT

  is much larger than

  GAME.WIDTH

  , squishing characters.
• For character-driven games (named personalities, mascots, famous figures): make the main character prominent —

  GAME.WIDTH * 0.12

  to

  GAME.WIDTH * 0.15

  (12–15% of screen width). Use caricature proportions (large head = 40–50% of sprite height, exaggerate distinguishing features) for personality games.
• Non-character entities (projectiles, collectibles, squares) can use

  GAME.WIDTH * ratio

  for both dimensions since they have no intrinsic aspect ratio to preserve.

Play.fun safe zone:

• Import

  SAFE_ZONE

  from

  Constants.js

  . All UI text, buttons, and interactive elements (title text, score panels, restart buttons) must be positioned below

  SAFE_ZONE.TOP

  . The Play.fun SDK renders a 75px widget bar at the top of the viewport (z-index 9999). Use

  safeTop + usableH * ratio

  for proportional positioning within the usable area (where

  usableH = GAME.HEIGHT - SAFE_ZONE.TOP

  ).

Generate game-specific test actions: After implementing the core loop, overwrite

scripts/example-actions.json

with actions tailored to this game. Requirements:

• Use the game's actual input keys (e.g., ArrowLeft/ArrowRight for dodger, space for flappy, w/a/s/d for top-down)
• Include enough gameplay to score at least 1 point
• Include a long idle period (60+ frames with no input) to let the fail condition trigger
• Total should be at least 150 frames of gameplay

Example for a dodge game (arrow keys):

json

[
  {"buttons":["ArrowRight"],"frames":20},
  {"buttons":["ArrowLeft"],"frames":20},
  {"buttons":["ArrowRight"],"frames":15},
  {"buttons":[],"frames":10},
  {"buttons":["ArrowLeft"],"frames":20},
  {"buttons":[],"frames":80}
]

Example for a platformer (space to jump):

json

[
  {"buttons":["space"],"frames":4},
  {"buttons":[],"frames":25},
  {"buttons":["space"],"frames":4},
  {"buttons":[],"frames":25},
  {"buttons":["space"],"frames":4},
  {"buttons":[],"frames":80}
]

Before returning, write

<project-dir>/design-brief.md

:

# Design Brief
## Concept
One-line game concept.
## Core Mechanics
For each mechanic:
- **Name**: what it does
- **State field**: which GameState field it affects
- **Expected magnitude**: how much/fast it should change (e.g., "reaches 50-70% of max within the round duration without player input")
## Win/Lose Conditions
- How the player wins
- How the player loses
- Confirm both outcomes are realistically achievable with the current Constants.js values
## Entity Interactions
For each visible entity (enemies, projectiles, collectibles, environmental objects):
- **Name**: what it is
- **Visual identity**: what it should LOOK like and why (reference real logos, people, objects — not abstract concepts)
- **Distinguishing feature**: the ONE exaggerated feature visible at thumbnail size (e.g., "curly dark hair + glasses" for Amodei, "leather jacket" for Jensen Huang)
- **Real image asset**: logo URL to download, or "pixel art" if no real image applies
- **Behavior**: what it does (moves, falls, spawns, etc.)
- **Player interaction**: how the player interacts with it (dodge, collect, tap, block, or "none — background/decoration")
- **AI/opponent interaction**: how the opponent interacts with it, if applicable

For named people: describe hair, glasses, facial hair, clothing. For companies: specify logo to download. NEVER use a letter or text label as visual identity.

## Expression Map

For each personality character, map game events to expressions:

### Player: [Name]
| Game Event | Expression | Why |
|---|---|---|
| Idle/default | normal | Resting state |
| Score point / collect item | happy | Positive reinforcement |
| Take damage / lose life | angry | Visceral reaction |
| Power-up / special event | surprised | Excitement |
| Win / game over (high score) | happy | Celebration |
| Lose / game over (low score) | angry | Defeat |

### Opponent: [Name]
| Game Event | Expression | Why |
|---|---|---|
| Idle/default | normal | Resting state |
| Player scores | angry | Frustrated at losing |
| Opponent scores | happy | Gloating |
| Near-miss / close call | surprised | Tension |

Do NOT start a dev server or run builds — the orchestrator handles that.

progress.md

• Read

  src/core/EventBus.js

  for the event list
• Read

  src/core/Constants.js

  for the key sections (GAME, PLAYER, ENEMY, etc.)
• List files in

  src/entities/

  for entity names
• Read

  src/core/GameState.js

  for state fields

progress.md

undefined

• Name: [game name from project]
• Engine: Phaser 3 / Three.js
• Description: [from user's original prompt]

• Entities: [list entity names from src/entities/]
• Events: [list event names from EventBus.js]
• Constants keys: [top-level sections from Constants.js, e.g. GAME, PLAYER, ENEMY, COLORS]
• Scoring system: [how points are earned, from GameState + scene logic]
• Fail condition: [what ends the game]
• Input scheme: [keyboard/mouse/touch controls implemented]

• [any notable decisions or issues from scaffolding]

**Tell the user:**
> Your game is scaffolded and running! Here's how it's organized:
> - `src/core/Constants.js` — all game settings (speed, colors, sizes)
> - `src/core/EventBus.js` — how parts of the game talk to each other
> - `src/core/GameState.js` — tracks score, lives, etc.
> - **Mobile controls are built in** — works on phone (touch/tilt) and desktop (keyboard)
>
> **Next up: pixel art.** I'll create custom pixel art sprites for every character, enemy, item, and background tile — all generated as code, no image files needed. Then I'll add visual polish on top.

Mark task 1 as `completed`.

**Wait for user confirmation before proceeding.**

in_progress

design-brief.md

character-library/manifest.json

• Check

  character-library/manifest.json

  relative to the plugin install directory
• Check common plugin cache paths (e.g.,

  ~/.claude/plugins/cache/local-plugins/game-creator/*/character-library/

  )

manifest.json

mkdir -p <project-dir>/public/assets/characters/<slug>/
cp <plugin-root>/character-library/characters/<slug>/sprites/* \
   <project-dir>/public/assets/characters/<slug>/

• normal:

  "<Name> portrait photo"

  or

  "<Name> face"

  — neutral expression
• happy:

  "<Name> smiling"

  or

  "<Name> laughing"

• angry:

  "<Name> angry"

  or

  "<Name> serious stern"

• surprised:

  "<Name> surprised"

  or

  "<Name> shocked"

crop-head.mjs

normal.jpg

happy.jpg

<project-dir>/public/assets/characters/<slug>/raw/

node <plugin-root>/scripts/build-character.mjs "<Name>" \
  <project-dir>/public/assets/characters/<slug>/ --skip-find

• Download whatever was found to

  raw/

  (e.g., only

  normal.png

  and

  happy.png

  )
• Duplicate the best image (prefer normal) into the missing expression slots:
  bash

  cp raw/normal.png raw/angry.png    # fill missing with normal
  cp raw/normal.png raw/surprised.png

• Run

  build-character.mjs

  as above — all 4 raw slots are filled, pipeline produces a 4-frame spritesheet
• Result: 4-frame spritesheet where some expressions share the same face. Functional — the expression system still works, just with less visual variety.

• Use the single successful image for all 4 expression slots
• Run

  build-character.mjs

  — produces a spritesheet where all 4 frames are identical
• Result: Character is recognizable but has no expression changes. Still photo-composite, still works with the expression wiring (just no visible change).

• Fall back to the Personality Character (Caricature) archetype from the

  game-assets

  skill — 32x48 pixel art grid at scale 4
• Note in

  progress.md

  :

  "<Name>: pixel art fallback — no photo-composite available"

• The subagent will create pixel art with recognizable features (hair, glasses, clothing) per the game-assets sprite design rules
• Result: No photo-composite, but the character is still visually distinct via pixel art caricature.

progress.md

undefined

• trump: Tier 1 (pre-built, 4 expressions)
• karpathy: Tier 3 (1 image found, duplicated to 4 slots)
• some-ceo: Tier 5 (pixel art fallback)

**5. Pass to subagent**: the list of character slugs, which tier each resolved to, and how many unique expressions each has. The subagent needs this to know whether to wire full expression changes or skip expression logic for Tier 5 characters.

Launch a `Task` subagent with these instructions:

> You are implementing Step 1.5 (Pixel Art Sprites) of the game creation pipeline.
>
> **Project path**: `<project-dir>`
> **Engine**: 2D (Phaser 3)
> **Skill to load**: `game-assets`
>
> **Read `progress.md`** at the project root before starting. It describes the game's entities, events, constants, and scoring system from Step 1.
>
> **Character library sprites are already copied** to `public/assets/characters/<slug>/`. For personality characters, load the spritesheet and wire expression changes per the game-assets skill's "Expression Wiring Pattern". Add `EXPRESSION` and `EXPRESSION_HOLD_MS` to Constants.js. Wire expression changes to EventBus events per the Expression Map in `design-brief.md`.
>
> Follow the game-assets skill fully for non-personality entities:
> 1. Read all entity files (`src/entities/`) to find `generateTexture()` / `fillCircle()` calls
> 2. Choose the palette that matches the game's theme (DARK, BRIGHT, or RETRO)
> 3. Create `src/core/PixelRenderer.js` — the `renderPixelArt()` + `renderSpriteSheet()` utilities
> 4. Create `src/sprites/palette.js` with the chosen palette
> 5. Create sprite data files (`player.js`, `enemies.js`, `items.js`, `projectiles.js`) with pixel matrices
> 6. Create `src/sprites/tiles.js` with background tiles (ground variants, decorative elements)
> 7. Create or update the background system to use tiled pixel art instead of flat colors/grids
> 8. Update entity constructors to use pixel art instead of geometric shapes
> 9. Add Phaser animations for entities with multiple frames
> 10. Adjust physics bodies for new sprite dimensions
>
> **Character prominence**: If the game features a real person or named personality, use the Personality Character (Caricature) archetype — 32x48 grid at scale 4 (renders to 128x192px, ~35% of canvas height). The character must be the visually dominant element on screen. Supporting entities stay at Medium (16x16) or Small (12x12) to create clear visual hierarchy.
>
> **Push the pose — thematic expressiveness:**
> - Sprites must visually embody who/what they represent. A sprite for "Grok AI" should look like Grok (logo features, brand colors, xAI aesthetic) — not a generic robot or colored circle.
> - For real people: exaggerate their most recognizable features (signature hairstyle, glasses, facial hair, clothing). Recognition IS the meme hook.
> - For brands/products: incorporate logo shapes, brand colors, and distinctive visual elements into the sprite design.
> - For game objects: make them instantly recognizable. A "power-up" should look like the specific thing it represents in the theme, not a generic star or diamond.
> - Opponents should be visually distinct from each other — different colors, shapes, sizes, and personality. A player should tell them apart at a glance.
>
> **Self-audit before returning** — check every personality sprite against these:
> - Does each sprite have distinct hair (not a solid-color dome)?
> - Does each sprite have facial features beyond just eyes (glasses, facial hair, or clothing details if applicable)?
> - Would two character sprites look different if rendered in the same color?
> - Is any `scene.add.text()` being used as the primary identifier? If so, remove it and add physical features instead.
> - Does the head region (rows 0-28) use at least 4 distinct palette indices?
> - For brand entities: was a real logo downloaded and loaded? If not, why?
>
> **After completing your work**, append a `## Step 1.5: Assets` section to `progress.md` with: palette used, sprites created, any dimension changes to entities.
>
> Do NOT run builds — the orchestrator handles verification.

**After 2D subagent returns**, run the Verification Protocol.

---

1. Read

   design-brief.md

   to identify all characters (player + opponents/NPCs) and their names/descriptions.
2. For EACH humanoid character, run the full generate→rig pipeline as ONE atomic step:

undefined

After this completes you have 3 files per character:
- `<slug>.glb` — rigged model with skeleton (use `loadAnimatedModel()` + `SkeletonUtils.clone()`)
- `<slug>-walk.glb` — walking animation (auto-downloaded)
- `<slug>-run.glb` — running animation (auto-downloaded)

**NEVER generate humanoid characters without rigging.** Static models require hacky programmatic animation that looks artificial.

For named personalities, be specific: `"a cartoon caricature of Trump, blonde hair, suit, red tie, low poly game character, full body"`.

For multiple characters, generate each with a distinct description for visual variety. Run generate→rig in parallel for different characters to save time.

**Tier 2 — Pre-built in `3d-character-library/`** (Meshy unavailable): Check `manifest.json` for a name/theme match. Copy the GLB:
```bash
cp <plugin-root>/3d-character-library/models/<model>.glb \
   <project-dir>/public/assets/models/<slug>.glb

find-3d-asset.mjs

node <plugin-root>/scripts/find-3d-asset.mjs \
  --query "<character name> animated character" \
  --max-faces 10000 --list-only

3d-character-library/

• Soldier — action/military/default human
• Xbot — sci-fi/tech/futuristic
• RobotExpressive — cartoon/casual/fun (most animations)
• Fox — nature/animal

design-brief.md

undefined

• knight (player): Tier 1 — Meshy AI generated + rigged (idle/walk/run)
• goblin (enemy): Tier 1 — Meshy AI generated + rigged (idle/walk/run)

• tree: Meshy AI generated (static prop)
• barrel: Meshy AI generated (static prop)
• house: Poly Haven fallback (CC0)

**Launch a `Task` subagent with these instructions:**

> You are implementing Step 1.5 (3D Assets) of the game creation pipeline.
>
> **Project path**: `<project-dir>`
> **Engine**: 3D (Three.js)
> **Skill to load**: `game-3d-assets` and `meshyai`
>
> **Read `progress.md`** at the project root before starting. It lists generated/downloaded models and the character details.
>
> **Rigged character GLBs + animation GLBs are already in** `public/assets/models/`. Set up the character controller:
>
> 1. Create `src/level/AssetLoader.js` — **CRITICAL: use `SkeletonUtils.clone()` for rigged models** (regular `.clone()` breaks skeleton bindings → T-pose). Import from `three/addons/utils/SkeletonUtils.js`.
> 2. Add `MODELS` config to `Constants.js` with: `path` (rigged GLB), `walkPath`, `runPath`, `scale`, `rotationY` per model. **Start with `rotationY: Math.PI`** — most Meshy models face +Z and need flipping.
> 3. For each rigged model:
>    - Load with `loadAnimatedModel()`, create `AnimationMixer`
>    - Load walk/run animation GLBs separately, register their clips as mixer actions
>    - Log all clip names: `console.log('Clips:', clips.map(c => c.name))`
>    - Store mixer and actions in entity's `userData`
>    - Call `mixer.update(delta)` every frame
>    - Use `fadeToAction()` pattern for smooth transitions
> 4. For static models (ring, props): use `loadModel()` (regular clone)
> 5. **Orientation & scale verification (MANDATORY):**
>    - After loading each model, log its bounding box size
>    - Compute auto-scale to fit target height and container bounds
>    - Align feet to floor: `position.y = -box.min.y`
>    - **Characters must face each other / the correct direction** — adjust `rotationY` in Constants
>    - **Characters must fit inside their environment** (ring, arena, platform)
>    - Position characters close enough to interact (punch range, not across the arena)
> 6. Add primitive fallback in `.catch()` for every model load
>
> **After completing your work**, append a `## Step 1.5: 3D Assets` section to `progress.md` with: models used (Meshy-generated vs library), scale/orientation adjustments, verified facing directions.
>
> Do NOT run builds — the orchestrator handles verification.

**After 3D subagent returns**, run the Verification Protocol.

---

**Tell the user (2D):**
> Your game now has pixel art sprites and backgrounds! Every character, enemy, item, and background tile has a distinct visual identity. Here's what was created:
> - `src/core/PixelRenderer.js` — rendering engine
> - `src/sprites/` — all sprite data, palettes, and background tiles

**Tell the user (3D):**
> Your game now has custom 3D models! Characters were generated with Meshy AI (or sourced from the model library), rigged, and animated with walk/run/idle. Props and scenery are loaded from GLB files. Here's what was created:
> - `src/level/AssetLoader.js` — model loader with SkeletonUtils
> - `public/assets/models/` — Meshy-generated and/or library GLB models
> - OrbitControls camera with WASD movement

> **Next up: visual polish.** I'll add particles, screen transitions, and juice effects. Ready?

Mark task 2 as `completed`.

**Wait for user confirmation before proceeding.**

in_progress

Task

You are implementing Step 2 (Visual Design — Spectacle-First) of the game creation pipeline.

Project path:

<project-dir>

Engine:

<2d|3d>

Skill to load:

game-designer

Read

progress.md

at the project root before starting. It describes the game's entities, events, constants, and what previous steps have done.

Apply the game-designer skill with spectacle as the top priority. Work in this order:

1. Opening Moment (CRITICAL — this determines promo clip success):

• Entrance flash:

  cameras.main.flash(300)

  on scene start
• Player slam-in: player starts off-screen, tweens in with

  Bounce.easeOut

  , landing shake (0.012) + particle burst (20 particles)
• Ambient particles active from frame 1 (drifting motes, dust, sparkles)
• Optional flavor text (e.g., "GO!", "DODGE!") — only when it naturally fits the game's vibe
• Verify: the first 3 seconds have zero static frames

2. Every-Action Effects (wire to SPECTACLE_ events from Step 1):*

• Particle burst (12-20 particles) on

  SPECTACLE_ACTION

  and

  SPECTACLE_HIT

• Floating score text (28px, scale 1.8,

  Elastic.easeOut

  ) on

  SCORE_CHANGED

• Background pulse (additive blend, alpha 0.15) on

  SCORE_CHANGED

• Persistent player trail (particle emitter following player,

  blendMode: ADD

  )
• Screen shake (0.008-0.015) on hits

3. Combo & Streak System (wire to SPECTACLE_COMBO / SPECTACLE_STREAK):

• Combo counter text that scales with combo count (32px base, +4px per combo)
• Streak milestone announcements at 5x, 10x, 25x (full-screen text slam + 40-particle burst)
• Hit freeze frame (60ms physics pause) on destruction events
• Shake intensity scales with combo (0.008 + combo * 0.002, capped at 0.025)

4. Standard Design Audit:

• Full 10-area audit (background, palette, animations, particles, transitions, typography, game feel, game over, character prominence, first impression / viral appeal)
• Every area must score 4 or higher — improve any that fall below
• First Impression / Viral Appeal is the most critical category

5. Intensity Calibration:

• Particle bursts: 12-30 per event (never fewer than 10)
• Screen shake: 0.008 (light) to 0.025 (heavy)
• Floating text: 28px minimum, starting scale 1.8
• Flash overlays: alpha 0.3-0.5
• All new values go in Constants.js, use EventBus for triggering effects
• Don't alter gameplay mechanics

After completing your work, append a

## Step 2: Design

section to

progress.md

with: improvements applied, new effects added, any color or layout changes.

Do NOT run builds — the orchestrator handles verification.

Your game looks much better now! Here's what changed: [summarize changes]

Next up: promo video. I'll autonomously record a 50 FPS gameplay clip in mobile portrait — ready for social media. Then we'll add music and sound effects.

completed

in_progress

ffmpeg -version | head -1

FFmpeg is not installed. Skipping promo video. Install it with

brew install ffmpeg

(macOS) or

apt install ffmpeg

(Linux), then run

/game-creator:promo-video

later.

completed

cp <plugin-root>/skills/promo-video/scripts/convert-highfps.sh <project-dir>/scripts/
chmod +x <project-dir>/scripts/convert-highfps.sh

Task

You are implementing Step 2.5 (Promo Video) of the game creation pipeline.

Project path:

<project-dir>

Dev server port:

<port>

Skill to load:

promo-video

Read

progress.md

and the following source files to understand the game:

• src/scenes/GameScene.js

  — find the death/failure method(s) to patch out

• src/core/EventBus.js

  — understand event flow

• src/core/Constants.js

  — check input keys, game dimensions

• src/main.js

  — verify

  __GAME__

  and

  __GAME_STATE__

  are exposed

Create

scripts/capture-promo.mjs

following the

promo-video

skill template. You MUST adapt these game-specific parts:

1. Death patching — identify ALL code paths that lead to game over and monkey-patch them. Search for

   triggerGameOver

   ,

   gameOver

   ,

   takeDamage

   ,

   playerDied

   ,

   onPlayerHit

   , or any method that sets

   gameState.gameOver = true

   . Patch every one.
2. Input sequence — determine the actual input keys from the game's input handling (look for

   createCursorKeys()

   ,

   addKeys()

   ,

   input.on('pointerdown')

   , etc.). Generate a

   generateInputSequence(totalMs)

   function that produces natural-looking gameplay for this specific game type:
   • Dodger (left/right): Alternating holds with variable timing, occasional double-taps
   • Platformer (jump): Rhythmic taps with varying gaps
   • Shooter (move + fire): Interleaved movement and fire inputs
   • Top-down (WASD): Figure-eight or sweep patterns
3. Entrance pause — include a 1-2s pause at the start so the entrance animation plays (this is the visual hook).
4. Viewport — always

   { width: 1080, height: 1920 }

   (9:16 mobile portrait) unless the game is desktop-only landscape.
5. Duration — 13s of game-time by default. For slower-paced games (puzzle, strategy), use 8-10s.

Config: The script must accept

--port

,

--duration

, and

--output-dir

CLI args with sensible defaults.

Do NOT run the capture — just create the script. The orchestrator runs it.

undefined

**Verify the output:**
1. Check `output/promo.mp4` exists and is non-empty
2. Verify duration is approximately `DESIRED_GAME_DURATION / 1000` seconds
3. Verify frame rate is 50 FPS

If capture fails (Playwright error, timeout, etc.), warn the user and skip — the promo video is a nice-to-have, not a blocker.

**Extract a thumbnail** for the user to preview:
```bash
ffmpeg -y -ss 5 -i output/promo.mp4 -frames:v 1 -update 1 output/promo-thumbnail.jpg

Promo video recorded! 50 FPS, mobile portrait (1080x1920).

File:

output/promo.mp4

([duration]s, [size])

This was captured autonomously — the game ran at 0.5x, recorded at 25 FPS, then FFmpeg sped it up to 50 FPS. Death was patched out so it shows continuous gameplay.

Next up: music and sound effects. Ready?

completed

in_progress

Task

You are implementing Step 3 (Audio) of the game creation pipeline.

Project path:

<project-dir>

Engine:

<2d|3d>

Skill to load:

game-audio

Read

progress.md

at the project root before starting. It describes the game's entities, events, constants, and what previous steps have done.

Apply the game-audio skill:

1. Audit the game: check for

   @strudel/web

   , read EventBus events, read all scenes
2. Install

   @strudel/web

   if needed
3. Create

   src/audio/AudioManager.js

   ,

   music.js

   ,

   sfx.js

   ,

   AudioBridge.js

4. Add audio events to EventBus.js (including

   AUDIO_TOGGLE_MUTE

   )
5. Wire audio into main.js and all scenes
6. Important: Use explicit imports from

   @strudel/web

   (

   import { stack, note, s } from '@strudel/web'

   ) — do NOT rely on global registration
7. Mute toggle: Wire

   AUDIO_TOGGLE_MUTE

   to

   gameState.game.isMuted

   . Add M key shortcut and a speaker icon UI button. See the

   mute-button

   rule and the game-audio skill "Mute Button" section for requirements and drawing code.

After completing your work, append a

## Step 3: Audio

section to

progress.md

with: BGM patterns added, SFX event mappings, mute wiring confirmation.

Do NOT run builds — the orchestrator handles verification.

Your game now has music and sound effects! Click/tap once to activate audio, then you'll hear the music. Note: Strudel is AGPL-3.0, so your project needs a compatible open source license.

Next up: deploy to the web. I'll help you set up GitHub Pages so your game gets a public URL. Future changes auto-deploy when you push. Ready?

completed

gh auth status

gh

You need the GitHub CLI to deploy. Install it with:

• macOS:

  brew install gh

• Linux:

  sudo apt install gh

  or see https://cli.github.com

Once installed, run

gh auth login

and follow the prompts, then tell me when you're ready.

gh

You need to log in to GitHub. Run this command and follow the prompts:

gh auth login

Choose "GitHub.com", "HTTPS", and authenticate via browser. Tell me when you're done.

gh auth status

deploy

package.json

{
  "scripts": {
    "deploy": "npm run build && npx gh-pages -d dist"
  }
}

Your game is live!

URL:

https://<username>.github.io/<game-name>/

How auto-deploy works: Whenever you make changes, just run:

npm run deploy

Or if you're working with me, I'll commit your changes and run deploy for you.

Next up: monetization. I'll register your game on Play.fun (OpenGameProtocol), add the points SDK, and redeploy. Players earn rewards, you get a play.fun URL to share on Moltbook. Ready?

completed

node skills/playdotfun/scripts/playfun-auth.js status

node skills/playdotfun/scripts/playfun-auth.js callback &

To register your game on Play.fun, you need to log in once. Open this URL in your browser: https://app.play.fun/skills-auth?callback=http://localhost:9876/callback

Log in with your Play.fun account. Credentials are saved locally. Tell me when you're done.

playfun-auth.js status

https://<username>.github.io/<game-name>/

package.json

src/core/Constants.js

playdotfun

POST https://api.play.fun/games

{
  "name": "<game-name>",
  "description": "<game-description>",
  "gameUrl": "<deployed-url>",
  "platform": "web",
  "isHTMLGame": true,
  "iframable": true,
  "maxScorePerSession": <based on game scoring>,
  "maxSessionsPerDay": 50,
  "maxCumulativePointsPerDay": <reasonable daily cap>
}

• Casual clicker/idle:

  maxScorePerSession: 100-500

• Skill-based arcade (flappy bird, runners):

  maxScorePerSession: 500-2000

• Competitive/complex:

  maxScorePerSession: 1000-5000

Your game is monetized on Play.fun!

Play:

<game-url>

Play.fun:

https://play.fun/games/<game-uuid>

The Play.fun widget is now live — players see points, leaderboard, and wallet connect. Points are buffered during gameplay and saved on game over.

Share on Moltbook: Post your game URL to moltbook.com — 770K+ agents ready to play and upvote.

completed

Your game has been through the full pipeline! Here's what you have:

• Scaffolded architecture — clean, modular code structure
• Pixel art sprites — recognizable characters (if chosen) or clean geometric shapes
• Visual polish — gradients, particles, transitions, juice
• Promo video — 50 FPS gameplay footage in mobile portrait (

  output/promo.mp4

  )
• Music and SFX — chiptune background music and retro sound effects
• Quality assured — each step verified with build, runtime, and visual review
• Live on the web — deployed to GitHub Pages with a public URL
• Monetized on Play.fun — points tracking, leaderboards, and wallet connect

Share your play.fun URL on Moltbook to reach 770K+ agents on the agent internet. Post your promo video to TikTok, Reels, or X to drive traffic.

What's next?

• Add new gameplay features:

  /game-creator:add-feature [describe what you want]

• Upgrade to pixel art (if using shapes):

  /game-creator:add-assets

• Re-record promo video:

  /game-creator:record-promo

• Launch a playcoin for your game (token rewards for players)
• Keep iterating! Run any step again:

  /game-creator:design-game

  ,

  /game-creator:add-audio

• Redeploy after changes:

  npm run deploy