@funpixel/tools 0.0.0-stage → 0.1.1

package/plugins/robin/claude/skills/world-and-story/references/world-kit.md

@@ -0,0 +1,154 @@
+# A world from a kit: scatter, landmarks, the route
+
+Working code, checked in a scratch scaffold on pixi.js 8.21 and three 0.170 (captured and profiled
+at 844×390). Take what helps; change the numbers to the place.
+
+## The kit
+
+Six to twelve pieces in one style carry a whole area. Ways to get them:
+
+| Piece | Tool | Note |
+|---|---|---|
+| 2D props (rock, bush, lamp, crate, fence) | `generate_sprite`, one call per piece with the same style words | a style lock keeps them one family (skill `fp:art`) |
+| A state variant (lamp lit/unlit, bridge broken/mended) | `edit_image` on the accepted sprite | the same drawing changed, so the swap reads as the world changing |
+| Ground and paths | `generate_image` texture or strip (`funtools gen texture`) | seamless tiles under the scatter; the scatter hides the grid |
+| Characters that move | `generate_spritesheet` | idle and walk from one base |
+| 3D props | code-built (below), `generate_3d_model`, or `find_material` type `model` (Poly Haven, CC0) | instance anything placed more than a few times |
+| Sky | `generate_skybox`, or a Poly Haven HDRI via `get_material` | the sky sets the time of day and the palette |
+| A set with a plan | `build_level` (skill `fp:3d`) | interiors, a village square, anything with doors |
+
+## Scatter by rule
+
+Seeded dart-throwing with spacing: denser at the edges, sparse in the open, a clear route and a
+ring around each landmark, jittered scale, flip and tint. Engine-free.
+
+```ts
+// Dress a place from a kit: seeded, spaced, denser at the edges, the path kept clear.
+// Engine-free: it returns placements; Pixi or Three draws them.
+
+export interface Piece { name: string; radius: number; weight: number; zones?: Zone[] }
+export type Zone = 'edge' | 'field' | 'path-side' | 'landmark';
+export interface Placement { piece: string; x: number; y: number; scale: number; flip: boolean; tint: number; zone: Zone }
+export interface Area {
+  w: number; h: number;
+  /** The walkable route as points; pieces keep `clear` away from it, `path-side` pieces hug it. */
+  path: Array<[number, number]>; clear: number;
+  /** Landmarks already placed (a tower, a tree): scatter leaves a ring around each. */
+  landmarks: Array<{ x: number; y: number; r: number }>;
+}
+
+export function rng(seed: number) {
+  return () => { seed = (seed + 0x6d2b79f5) | 0; let t = Math.imul(seed ^ (seed >>> 15), 1 | seed); t ^= t + Math.imul(t ^ (t >>> 7), 61 | t); return ((t ^ (t >>> 14)) >>> 0) / 4294967296; };
+}
+
+const distToPath = (x: number, y: number, path: Area['path']) => {
+  let best = Infinity;
+  for (let i = 1; i < path.length; i++) {
+    const [ax, ay] = path[i - 1], [bx, by] = path[i], dx = bx - ax, dy = by - ay;
+    const k = Math.max(0, Math.min(1, ((x - ax) * dx + (y - ay) * dy) / (dx * dx + dy * dy || 1)));
+    best = Math.min(best, Math.hypot(x - ax - k * dx, y - ay - k * dy));
+  }
+  return best;
+};
+
+/** Where a point sits: near an edge, beside the path, or in the open field. */
+function zoneOf(x: number, y: number, a: Area): Zone | null {
+  const d = distToPath(x, y, a.path);
+  if (d < a.clear) return null;                                  // the route stays readable
+  if (a.landmarks.some((l) => Math.hypot(x - l.x, y - l.y) < l.r)) return null; // landmarks breathe
+  if (d < a.clear * 1.8) return 'path-side';
+  const edge = Math.min(x, y, a.w - x, a.h - y);
+  return edge < Math.min(a.w, a.h) * 0.14 ? 'edge' : 'field';
+}
+
+/** Dart-throwing with spacing: `tries` candidates, each kept only if no neighbour is closer than the sum of radii. */
+export function scatter(kit: Piece[], a: Area, seed: number, tries = 1500, density: Record<Zone, number> = { edge: 1, 'path-side': 0.6, field: 0.25, landmark: 0 }): Placement[] {
+  const r = rng(seed), out: Placement[] = [], total = kit.reduce((s, p) => s + p.weight, 0);
+  for (let i = 0; i < tries; i++) {
+    const x = r() * a.w, y = r() * a.h, zone = zoneOf(x, y, a);
+    if (!zone || r() > density[zone]) continue;
+    let pick = r() * total, piece = kit[0];
+    for (const p of kit) { pick -= p.weight; if (pick <= 0) { piece = p; break; } }
+    if (piece.zones && !piece.zones.includes(zone)) continue;
+    const scale = 0.8 + r() * 0.45;
+    if (out.some((o) => Math.hypot(o.x - x, o.y - y) < (kit.find((k) => k.name === o.piece)!.radius * o.scale + piece.radius * scale) * 0.9)) continue;
+    const warm = Math.round(235 + r() * 20);                     // a small tint jitter breaks the copy-paste look
+    out.push({ piece: piece.name, x, y, scale, flip: r() < 0.5, tint: (warm << 16) | (Math.round(240 + r() * 15) << 8) | 235, zone });
+  }
+  return out.sort((p, q) => p.y - q.y);                          // back to front for a 2D side or top view
+}
+```
+
+Pixi: draw the placements back to front (they come sorted by y), with the flip and tint.
+
+```ts
+for (const p of scatter(KIT, { w, h, path, clear: 30, landmarks: [tower] }, 42)) {
+  const s = new Sprite({ texture: kitTextures[p.piece], anchor: { x: 0.5, y: 1 } });
+  s.position.set(p.x, p.y); s.scale.set(p.flip ? -p.scale : p.scale, p.scale); s.tint = p.tint;
+  world.addChild(s);
+}
+```
+
+Measured in the lab: about 280 pieces on an 844×390 view drew in 3 draw calls (Pixi batches
+sprites and graphics that share a texture), JS work under 0.5 ms a frame. Put every kit piece on
+one atlas (`npx @funpixel/tools optimize pack-atlas`) so they keep batching.
+
+Three: one `InstancedMesh` per piece kind, so a few hundred props cost a few draw calls.
+
+```ts
+/** Scatter on the XZ plane (area units = metres), one draw call per piece kind. */
+export function dressGround(scene: THREE.Scene, size: number, path: Array<[number, number]>, landmark: THREE.Vector3, seed: number) {
+  const toArea = (x: number, z: number): [number, number] => [x + size / 2, z + size / 2];
+  const placed = scatter(KIT, { w: size, h: size, path: path.map(([x, z]) => toArea(x, z)), clear: 1.6, landmarks: [{ x: landmark.x + size / 2, y: landmark.z + size / 2, r: 4 }] }, seed, 4000);
+  const m = new THREE.Matrix4(), q = new THREE.Quaternion();
+  for (const piece of KIT) {
+    const mine = placed.filter((p) => p.piece === piece.name);
+    const [geo, mat] = GEO[piece.name];
+    const mesh = new THREE.InstancedMesh(geo, mat, mine.length);
+    mesh.name = 'kit-' + piece.name;
+    mine.forEach((p, i) => {
+      q.setFromAxisAngle(new THREE.Vector3(0, 1, 0), (p.x * 13.7) % (Math.PI * 2));
+      mesh.setMatrixAt(i, m.compose(new THREE.Vector3(p.x - size / 2, 0, p.y - size / 2), q, new THREE.Vector3(p.scale, p.scale, p.scale)));
+      mesh.setColorAt(i, new THREE.Color(p.tint));
+    });
+    scene.add(mesh);
+  }
+  return placed.length;
+}
+```
+
+Measured in the lab: 621 instances across the kit and trees, 16 draw calls, 17,640 triangles.
+
+## Landmarks and the route
+
+- One landmark tall enough to see from most of the map, with its own silhouette and light (a
+  tower, a great tree). Place it first; the scatter leaves room around it.
+- The route is the brightest, least cluttered band. In 2D a path texture or a stroked spline
+  (`Graphics.stroke({ width, cap: 'round', join: 'round' })`); in 3D a lighter ground strip.
+- Two or three districts, each with one colour and one material: the orchard is warm and round,
+  the quarry grey and angular. A player should know where they are from one frame.
+- Depth in 2D: two or three parallax layers (far hills move at 0.2–0.4 of the camera, near props
+  at 1.0), the far ones lighter and bluer; in 3D, fog in the sky's colour (skill `fp:art`).
+
+## Contact and life
+
+- A soft shadow under anything standing on the ground (a blurred dark ellipse in 2D; a blob
+  texture or a shadow map in 3D) glues it to the place.
+- Small ambient motion sells a place: grass sway (a sine on rotation with a per-piece phase),
+  drifting particles (pollen, fireflies, dust), water shimmer, smoke. Keep it low contrast so the
+  player and threats stay the clearest things on screen. Respect `prefers-reduced-motion`.
+- Wildlife that reacts (birds that lift off as you pass) is cheap and reads as a living world.
+
+## A minimap, cheaply
+
+A round mask over a small render of the world's layout: in 2D, draw the route and landmarks into a
+`Graphics` in a corner at 1/20 scale with the player as an arrow; in 3D, a top-down orthographic
+camera into a small `WebGLRenderTarget` shown on a plane, or a 2D canvas that draws the same
+positions. Keep it off the thumbs' zones (skill `fp:mobile-ui`).
+
+## Checking a place
+
+- Capture the play view at phone size and ask: can I see the landmark, the route and the goal?
+- `npx @funpixel/tools look --read` for whether the player and threats stand out from the ground.
+- `npx @funpixel/tools profile --views playing` before and after dressing; the draw calls and
+  object count say what the kit costs.

package/plugins/robin/mcp-servers.json

@@ -0,0 +1,25 @@
+[
+  {
+    "id": "2BD21E87-2E73-5394-A9D6-AA32951E780C",
+    "name": "funtools",
+    "transport": {
+      "local": {
+        "command": "funtools",
+        "arguments": [
+          "mcp"
+        ]
+      }
+    },
+    "isEnabled": true
+  },
+  {
+    "id": "3A6AE192-EDEB-5DF3-BA9F-D06A09ABCF0C",
+    "name": "Funpixel",
+    "transport": {
+      "remote": {
+        "url": "https://api.funpixel.ai/mcp"
+      }
+    },
+    "isEnabled": true
+  }
+]

package/plugins/robin/plugin.json

@@ -0,0 +1,20 @@
+{
+  "id": "fp",
+  "name": "Funpixel GDK",
+  "version": "0.1.0",
+  "summary": "Use Funpixel asset tools, game skills and optional studio workflows in your agent. Build, verify and publish browser games with advisory hooks and project-controlled review.",
+  "tools": [
+    "funpixel",
+    "funtools"
+  ],
+  "skills": "skills",
+  "servers": [
+    {
+      "name": "funtools",
+      "command": "funtools",
+      "arguments": [
+        "mcp"
+      ]
+    }
+  ]
+}

package/plugins/robin/skills/fp-first-look/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: fp-first-look
+description: "Use when the person types /fp-first-look. Make the game's first look from its GDD, the whole game and not a few frames (key art, every screen, the HUD on phone and desktop, a frame per place, the living world, animation, juice, sound and fun), and render a page to show it."
+---
+
+Make the first look for the Funpixel game in this folder, following the `funpixel-gdd` skill and its
+`references/first-look.md`.
+
+1. Read `design/GDD.md` (or `design/README.md`). If there is none, write v0.1 from the skill's
+   template first: the pieces below are briefed from the design's words, so without one they have
+   nothing to agree on. Read its `## Experience` lines too, or offer them if empty (depth, content,
+   replay, story, world, the arc, the signature idea; the skill's `references/experience.md`): the
+   key art and the frames are where a world's places and the signature idea first become pictures.
+2. The order is the flow's: the key art and the hero's reference sheet come first (`npx
+   @funpixel/tools flow` names them, the owner's look, then a first playable). Once the owner has played
+   it, worth: run `npx @funpixel/tools greenlight worth` and show its verdict in the chat before the rest
+   of the art (the idea may shrink, change or be dropped). Run
+   `npx @funpixel/tools firstlook`: the required set for this game (scaled by its tier; places
+   and the living world only for a world game, the reason said), each item a picture or a page shown
+   in the chat and linked from the GDD, and what closes each missing one. A missing item is listed
+   with the plan when it goes to the owner (they drop one in their words: `firstlook skip <item>
+   --by owner "<why>"`). Then plan the pieces, in this order: reference sheets first, one turnaround per recurring
+   design (hero, companion, vehicle, pursuer, the thing carried), each a `ref-*` item with its
+   `pins`, drawn from the best draft you have (a rough frame is fine) and named in `## Identity
+   lock`; then key art (the title moment), four target frames (four rungs of the
+   moment ladder, each a whole frame from the game's camera, each named in the GDD's target-frames
+   table with its moment and intent, so the fidelity seat can later hold the game against it), for a
+   game of several levels a picture per place (`place-*`, the `## Places` rows), the world's kit
+   (`kit-*` sheets of its structures, ground, props and living cast, drawn to the style block and
+   cut into pieces with `npx @funpixel/tools cut` before the slice), the cast on one sheet at one scale,
+   about eight sound cues briefed in the world's own words, and two music clips sharing one
+   identity. Every picture of a recurring design names its sheets in `references`; reuse the style
+   file's words in every picture prompt; name the game's id so its style lock applies.
+3. Estimate before anything is made: `npx @funpixel/tools assets gen --only 'look-*' --dry-run`
+   with the pieces in `assets/assets.json`, or each tool's estimate. These are Funpixel's paid tools:
+   say the total in credits in one line, and above 50 credits wait for the person's yes.
+4. Make them into `design/first-look/` (`keyart`, `frame-…`, `cast`, `sfx/`, `music/`). You cannot
+   listen, so when two sound takes exist, keep the better by measurement and say why.
+5. Draw `design/first-look/hud.html`: one target frame at a phone's size with the HUD and touch
+   controls over it, numbered, with a legend, in each orientation the plan holds, and the same HUD
+   at a desktop's 1280 × 720; then every screen the set names (title as the play world, pause, the
+   end, and past small settings, results, a level select) the same way, each in a `.phone` element
+   with `data-mockup="<screen>"`, so a playtest can hold the game's screens against them. Add the
+   animation board (the hero's key poses per state, the creatures' cycles, the UI's motion), and in
+   the GDD the juice table, the sound list (`## Audio`) and the fun (`## Core loop`, or a `## Fun` of
+   its own: the loop, goals, streaks, the 2–3-minute novelty cadence, and the arc at the game's
+   length; a nugget's is why a second run).
+6. Look at every picture against the AD rules and the sheets: lay the frames side by side and read
+   each recurring design (hair, outfit, silhouette, colours). A frame that breaks a rule or drifts is
+   a finding: fix the words, redraw it to its sheet, keep the before and after, and record it. List
+   what still breaks, kept (the honest breaks).
+7. Render the page: `npx @funpixel/tools gdd page`. Copy the accepted gameplay frame to
+   `design/target.png`.
+8. Write `## First look` into the GDD (what it settled, what changed, the cost), bump it to v0.2
+   and the stage to Greenlight (Style test when the person skips it), then run
+   `npx @funpixel/tools gdd`; the owner judges these frames in the chat, and the rounds build to them.
+   The stage line names where the track is, never the owner's sign-off: their yes is
+   `npx @funpixel/tools flow agree --by owner "<their words>"`.
+9. Hand back: the page's path, the cost, what the look settled, the open questions for the person.

package/plugins/robin/skills/fp-flow/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: fp-flow
+description: "Use when the person types /fp-flow. Resume the Funpixel game's flow — the owner's notes first, then the one next step, round after round of the look-dev loop until the owner's yes or their rounds per session."
+---
+
+Resume this game where its run stands. In the game folder (the one with `funpixel.json`), run
+`npx @funpixel/tools flow`: where the run is (the plan, waiting for the owner, or round N) and the
+ONE next step with its command. Do that step, then run `flow` again.
+
+1. **The owner's words first.** What they said in the chat, or a note they left between sessions (`funtools note`),
+   a change to the plan, an answer: act on it before anything else; the GDD's `## Where we are` says what you did with it.
+2. **The plan is locked once, by the owner.** Before the lock, finish the plan at the game's real
+   size (the brief's path: target frames, the numbers contract, the asset list and its price), then
+   `npx @funpixel/tools flow ask` readies it; show it in the chat (the GDD, its target frames, its
+   price) and wait for their yes, then record it with their words: `flow agree --by owner "<words>"`. You never agree it for them. Waiting on them is a fine place to end the
+   session. After the lock the plan is the job: only the owner relaxes a target, and a departure
+   goes in the plan's "Where the build moved" table, with why.
+3. **Each round is the look-dev loop.** Build; capture at the target moments; set each beside its
+   target (`compare --target`); fix the biggest difference; play it (`play`, `playtest`); repeat
+   until each beat is close. `check` stays green throughout. Close the round: update the GDD's
+   `## Where we are` (each capture beside its target, the gap left, the next step), show the
+   captures in the chat, then `npx @funpixel/tools flow round`. What the whole-game review named as
+   working (the flow's "do not regress" list) stays working: a fix that breaks one is a regression,
+   and `flow` makes putting it back the first step. A critic score under 3 for three playtests is
+   next: a 2 is not a resting place, so raising it is the round's fix until a playtest scores it higher.
+4. **The whole-game look.** The round after the first playable, and every three rounds after
+   (funpixel.json `flow.look_every`), `flow` says the whole-game look is due. Run
+   `npx @funpixel/tools flow look`: it writes a brief; hand it to a fresh agent with only that file
+   (it plays the whole game and answers "would you ship this today?", each defect with a severity and
+   an owner), then run `flow look` again: each defect goes to the lane of its kind, to the owner (ask
+   them in the chat) or to your round. It routes and never vetoes: a "no" stops nothing.
+5. **The locked plan is the go-ahead for its assets: make them.** Before each paid call, say the route, its
+   cost and the free alternative in one line in the chat; the owner can reverse it there. No
+   budget unless the owner sets a cap; out of credits is a pause: say so, they top up, go on.
+6. **Show every step**, in the game's words, never the kit's (no stage numbers, gates or commands
+   unless asked), ending on what comes next. After each asset, build, fix or playtest: two or three
+   lines in the chat with a capture of the build; the key art, the first playable and each chapter
+   are reveals (a clip, the game open, "try this first": `in-the-loop.md`). The owner watches and steers at any time; their message outranks
+   the step you were on. A new direction is a new GDD version they lock again (`flow ask`).
+7. **Judge before the owner sees.** Everything you show them in the chat carries the kit's read (`score`
+   against the targets, the blind player or panel when they ran). Below the bar, the first line
+   says "below the bar: <why>"; a read that never ran is "not judged yet", never a pass.
+8. **A drop is the owner's.** When they say so in the chat, `flow drop --by owner "<their words>"` ends
+   the game. You may recommend it, with the numbers.
+9. **The owner's rounds per session.** After funpixel.json `flow.rounds_per_session` rounds
+   (default 3), hand back in the chat, with the GDD's `## Where we are` current: what plays, how it compares with its targets, the next
+   round. The next session resumes with `/fp:flow`.
+
+The owner follows in the chat: the GDD (`design/GDD.md`, `## Where we are` on top) and the running game,
+side by side with the chat: open it beside the chat where they are: your host's own browser when it has one (Cursor's, Codex's), else `npx @funpixel/tools dev --open` (the system browser, in its own tab).

package/plugins/robin/skills/fp-lanes/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: fp-lanes
+description: "Use when the person types /fp-lanes. Run a Funpixel game's stage as lanes at once — one brief, checkout, spend cap and merge gate per lane, a verifier that did not build it, the owner's picks before a merge."
+---
+
+You are the integrator. The lanes do the building; you plan them, launch them together, and merge
+each one only when its gate says so. Work in the game folder (the one with `funpixel.json`).
+
+1. **Plan.** `npx @funpixel/tools lanes plan` splits the stage the game is at (or `--stage <id>`,
+   or `--lanes play,look,audio`, `room-2`, `rooms`) into lanes and writes each brief under
+   `.funtools/lanes/<id>/brief.md`. Before you plan, turn each open note from the owner into a
+   decision: `npx @funpixel/tools decide --from N<n>`. The briefs it touches then quote their words.
+   A brief is capped at 12,000 characters: past it, what failed before leaves first, then the other
+   lanes' paths, the standing bar, the extra reading, why now and the look's defects, each saying how
+   many it left out; the goal, the checks and the rules never leave.
+2. **Launch them at once.** `npx @funpixel/tools lanes start --all` makes one checkout per lane and
+   prints one line per lane. Send every lane in ONE message, one Agent call each, so they run in
+   parallel: `subagent_type` `fp:lane`, prompt "Read <brief> and do exactly what it says." Never
+   build a lane's work yourself. In Claude Code a lane's write outside the paths it owns is refused
+   as it is made (you are never fenced), except its one line inside a shared list's `fp:union` block.
+3. **Watch.** `npx @funpixel/tools lanes status` shows each lane's state, spend against its cap and
+   time against its box. A lane that is stuck (over its cap, past its box, silent for two
+   checkpoints) needs the owner, not a guess. Show the lane checkpoints in the chat, each with a
+   still, and keep the GDD's `## Where we are` current.
+4. **Verify with another seat.** When a lane hands back and its gate passes, launch a verifier that
+   did not build it: Agent `fp:qa-lead`, prompt "Read .funtools/lanes/<id>/verify.md and do exactly
+   what it says." The kit refuses a verdict from the lane's own builder.
+5. **The owner picks.** A lane that put candidates to the owner (`npx @funpixel/tools pick`) waits
+   for their choice in the chat. Do not answer it for them.
+6. **Merge.** `npx @funpixel/tools lanes merge <id>` refuses until the gate, the verifier and the
+   owner's picks pass, then merges with `--no-ff`, writes the lane's section into
+   `design/MAKING.md` and removes its checkout. Tell the other running lanes to take the landed work
+   first (`npx @funpixel/tools lanes sync <id>`).
+7. **Hand back.** `npx @funpixel/tools lanes report` is the lanes' making-of: what each tried, cost
+   and took, and what is still weak. Then `npx @funpixel/tools flow` names the next round.
+
+Other hosts run the same briefs. Codex: one `codex exec` per lane in its checkout with the same
+line. Cursor: one background agent per checkout. The kit only writes briefs and judges gates.

package/plugins/robin/skills/fp-mobile-qa/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: fp-mobile-qa
+description: "Use when the person types /fp-mobile-qa. Judge whether the Funpixel game in this folder is native to a phone (touch-native controls, the play area's share of the screen, thumb reach, chrome during play, safe areas, orientation, first touch) from real phone evidence, and get its findings ranked with a frame and a number each. Applies nothing."
+---
+
+Look at the game in this folder (the one with `funpixel.json`) the way a phone player meets it. The
+review is a mirror: it changes nothing, and its findings are for the person to pick from.
+
+1. Say in one line what runs: free measurements here (a few minutes; every view captured at both
+   sizes, the phone screens audited, a WebKit phone shot, key parity at phone size, five windows
+   swept with `look --fit` from wide-short desktops to the phone either way), real Mobile
+   Safari when this Mac has baguette (about a minute per orientation), then one Mobile QA seat as an
+   agent on the person's own setup.
+2. On a Mac with baguette (`npx @funpixel/tools doctor` says), build and add `--phone`: it runs
+   `funtools phone` in portrait and landscape first, so the seat sees real Mobile Safari (its bars,
+   the notch, iOS taps). It boots its own simulator and shuts it down. Without it, the seat judges
+   WebKit and Chromium at phone size and says iOS was not observed.
+3. Run `npx @funpixel/tools mobile-qa` (with `--phone` when chosen). It prints the seat's prompt file.
+4. Run the `mobile-qa` agent in the foreground as a fresh agent given only that file's contents; it
+   writes its answer beside the prompt. A seat that sees this conversation or the code judges the
+   intent instead of the phone.
+5. Run `npx @funpixel/tools mobile-qa report` and hand back its findings in order, each with its
+   frame and number, and the phone-native score. What the seat judges and why: skill
+   `funpixel-verify`, `references/mobile-qa.md`.
+6. Ask which to take on. When the phone is the game's primary platform, `"platform": "phone"` in
+   `funpixel.json` metadata says so, and a key no touch reaches ranks high.
+
+`/fp:playtest` runs the same seat with its other seats.

package/plugins/robin/skills/fp-new/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: fp-new
+description: "Use when the person types /fp-new. Start a new Funpixel game from an idea, the way our best games were made: brief back, the first look and a nice first playable the owner steers, the whole game planned around it and locked, then built round after round against the plan's target frames until the owner plays it and says yes."
+---
+
+Start a new Funpixel game from the idea the person gave with this command; with nothing given, ask
+what game they want in a sentence. You are their copilot: you plan the game with them in this chat,
+then build it with them round after round. Ask little and decide well: "you choose" is always an
+answer, and you say why. The path is the brief's (each step's why
+and tools: `funpixel-gdd`'s `references/the-path.md`). The locked plan is the job; how you build
+it is yours.
+
+1. **Brief back, on one screen, with one question.** Turn their sentence into a short brief and
+   show it once, first thing in the reply: title, kind (genre and camera), the verb, the world, the
+   length, how failing works, the look, phone and desktop, each in a line. Under it, your calls in
+   one line each (genre, engine, title, and anything you found on the way). Then the one question:
+   is the brief right? Their yes or their edit starts the work. Everything else is yours to decide
+   and say, never a second question: what they asked for outranks a standing request it
+   contradicts (a one-minute game stays one minute); a folder already there under the game's name
+   is left as it is and the game starts beside it; a file that might be reused is kept as the
+   fallback and a new one is made. A choice only they can make (the one that changes what the game
+   is) may be the question in place of "is it right", with your pick already written in.
+2. **Start.** `npx @funpixel/tools flow start <folder> --idea "<the brief in one line>" --name
+   "<title>"` (add `--framework pixi|three-world|three` when the line doesn't make it clear) creates
+   the game (it runs `npx @funpixel/tools init `, which mints the game's id when an API key is
+   set); `npm install`. If `flow start` or the first paid step says the Funpixel tools cannot be
+   reached or the key is refused, stop there and tell them in one line what to start or sign in to
+   (`npx @funpixel/tools doctor` names it): a game drawn from boxes and spheres in place of its
+   models, sounds and music is not the first playable, and is built only on their yes. Then write
+   the plan's opening from the brief before anything is drawn:
+   the pitch, the loop, the content list at the length they asked for, the look, with no template
+   line left unfilled. `npx @funpixel/tools gdd page` writes it as a page, `design/GDD.html`
+   (every later step keeps it current): show them that page, not a file path, so they read the plan
+   and decide on it while the first pictures are made. Once the game runs, show the game itself:
+   open it beside the chat where they are: your host's own browser when it has one (Cursor's, Codex's), else `npx @funpixel/tools dev --open` (the system browser, in its own tab). Do not call `create_game` as well (it mints a second, empty draft). From then on,
+   `npx @funpixel/tools flow` each turn names the owner's notes first, then the one next step.
+3. **First look, then a first playable** (the game's opening stages; `flow` names each). Make the
+   key art (the game's look in its own light, at the play framing) and the hero's reference sheet;
+   put both in the plan (`## First look`, as their paths) so they appear on its page, show them, and
+   take their words before anything 3D is paid for. Then build a first
+   playable from them, in the game itself, with real assets: the hero (rigged where it moves), the
+   place in the key art's light, the title art, a music loop, the verb's sounds. Size it by the game:
+   a short game about 1 minute (mostly the place, its look and feel, the verb once), a mid game 2 to
+   3, a long game 3 to 5 (the core loop once, a win and a loss). Judge it against the key art
+   (`score --target`, `check --front-door`) before they see it, then show it with captures and the
+   preview link. Reveal it as a moment: a 12-second clip of real play (`reel`), the game open beside
+   the chat, "try this first: …", in the game's words, never the kit's. They play it and say whether it has potential: `npx @funpixel/tools note verdict
+   prototype accept "<their words>"`; "not this" means a new key art, or dropping the idea.
+4. **Plan the whole game around it, at its real size** (skill `funpixel-gdd`), in the chat and the GDD: the
+   genre's best games beside it (what they do, what we take); pillars; the story and how deep it
+   goes; levels and the environment maps; characters and the living world; fun factors and the wow
+   moments; screens and HUD for phone and desktop; the look and its locked style; a numbers contract
+   with tests named after it; and the rest of the first look: target frames for the moments that
+   matter, the screens, the HUD over play, a frame per place. Finish with the asset list: the GDD's `## Asset script`,
+   every piece the game ships (cast, environments, props, title and HUD art, sound, music), made
+   the list with `npx @funpixel/tools assets script --write` and priced with `assets gen --dry-run`.
+   The first look's pictures are its references, never the shipped art. Ask the person the choices a studio lead decides; propose
+   the rest. Size it to the length in the brief, never smaller.
+   Lines in `~/.funpixel/owner.md` are the owner's standing requests: answer the ones that apply in
+   the plan.
+   Notes the owner writes on the plan page (a host that can mark up a page sends them with the part they
+   point at) are their words on the plan: revise `design/GDD.md` there, raise its version, run
+   `npx @funpixel/tools gdd page` so the open page comes back rewritten, and say in one line what changed.
+   Show, mark, revise, apply, as many times as they want before the lock and after it. The owner can
+   also agree to the plan a section at a time; `flow` names the sections still open, and changing an
+   agreed section's words opens it again, so say so when you do.
+   Not sure which skill or command a step needs? `npx @funpixel/tools find "<what you want to do>"`.
+5. **Lock.** `npx @funpixel/tools flow ask` readies the plan and its price; show it in the chat
+   (the GDD, its target frames, the price) and wait for their yes. Record it with their words,
+   `flow agree --by owner "<their words>"`. The lock means "good, let's build, unless I say otherwise":
+   a new direction becomes a new GDD version they lock again. Where the build later has
+   to move, write it in the plan's "Where the build moved" table, with why.
+6. **Sim first**, then **build with the assets as they land**: the rules and numbers as seeded,
+   tested code with bots (`sim`, `test`); generate every planned asset from the locked style (cast,
+   environments, props, screens, HUD art, sound, music) into `public/assets/` while you build
+   (the locked plan is the go-ahead), saying the route and cost of each paid call in one line. Out
+   of credits is a pause: say so; they top up. The slice: the player moves, one verb works, a win and a loss fire, progress
+   shows, keys and touch both work, `npx @funpixel/tools check` exits 0. Keep `dev` or `verify
+   --watch` running from the first edit.
+7. **Each round, the look-dev loop**: capture at the target moments, set each beside its target
+   (`compare --target`), fix the biggest difference, then play it on phone and desktop (`play`, `playtest`). Repeat
+   until each beat is close and you are both confident the game is good; matching the targets is the job, and only the owner relaxes one. Close the
+   round: update the GDD's `## Where we are` (each capture beside its target), show the captures in
+   the chat, then `npx @funpixel/tools flow round`; after their
+   cap of rounds (default 3), hand back and they resume with `/fp:flow`. When `flow` says the
+   whole-game look is due (after the first playable, then every few rounds), run `flow look` and
+   hand its brief to a fresh agent: it routes each defect to an owner and never vetoes.
+8. **Extend** with levels and story; fold a mid-build request into the pillars first.
+9. **Hand back** with an honest verdict: what plays now (keys and touch), how it compares with its
+   targets ("below the bar: <why>" when it is), what is out on purpose, every fallback still in the
+   game, and the next two or three steps. File `report_feedback` (skill `funpixel-feedback`).
+
+Spend is the owner's: never shrink an agreed game to save credits. Only the owner drops a game
+(when they say so in the chat: `flow drop --by owner "<their words>"`); you may recommend it, with the numbers.

package/plugins/robin/skills/fp-playtest/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: fp-playtest
+description: Use when the person types /fp-playtest. Playtest the Funpixel game in this folder between creator rounds (a long blind phone session, the calibrated critic panel, the plan-fidelity and experience seats, a head to head with the genre hit when its evidence is here, and free measurements) and get 3–4 ranked next steps with evidence. Applies nothing.
+---
+
+Playtest the game in this folder (the one with `funpixel.json`). The playtest is a mirror for the
+person: it changes nothing in the game, and its steps are suggestions they pick from.
+
+1. Say in one line what will run and how long it takes: the free measurements (2 to 4 minutes),
+   then 3 critic seats (2 with `--quick`; each re-reads the phone captures), the Mobile QA seat, the fidelity seat when the GDD has target frames, one
+   blind phone round (a ten-minute session; `--quick` plays a short one) and, when the hit's evidence
+   is on this machine, 6 head-to-head calls; then 2 experience seats (1 with `--quick`). All run as
+   agents here on the person's own setup; about 30 to 45 minutes in all. `--quick` is the fast look.
+2. If `.funtools/playtest/premise.txt` is missing, write 4 to 6 neutral sentences there: what the
+   game is and what the player does, as a store page would say it. No intentions, design notes or
+   praise; a seat told why a frame looks as it does scores it kinder.
+3. Run `npx @funpixel/tools playtest` (with `--quick` when asked; add `--phone` on a Mac with
+   baguette, so the Mobile QA seat sees real Mobile Safari in both orientations). It builds, verifies, captures
+   every view at both sizes with moments as strips, audits the phone screens, measures the HUD in
+   play and how the actors stand out from the ground, and profiles, then prints one prompt file per
+   seat. Each prompt carries those numbers as facts F1, F2, … to read before the frames (Scenario's
+   numbers first, then eyes); the report says which facts each seat cited.
+4. Run every seat now, in parallel in the foreground (a background seat answered after a session
+   had already ended, in one game's third session), each as a fresh agent given only the contents of its prompt
+   file: one per `seats/<name>.md`, per `versus/<name>.md` and `fidelity/fidelity.md` when printed (and `fidelity/ui.md` from step 5), each a general-purpose
+   agent (the `critic` agent's own format would override the prompt's), and the `player` agent with
+   `player.md` at phone size. The Mobile QA seat (`mobile/mobile-qa.md`, the `mobile-qa` agent: is
+   it native to a phone, `references/mobile-qa.md` in skill `funpixel-verify`) reads the blind round
+   too, so it runs in step 5. A seat that sees another seat's answer, the code or this conversation
+   drifts toward them, so each gets only its file and writes its own answer file; an answer file
+   written by anyone else is no longer a seat's verdict.
+5. Once the blind round is filed, run `npx @funpixel/tools playtest experience`: the first time, it
+   keeps the steps the blind player played as the saved route (`test/journeys/playtest-route.json`:
+   its steps, viewport and seed) and films it at the plan's timed moments, so later playtests replay
+   the same route with the same camera and compare like with like. It measures depth for free (the
+   content inventory, the pacing of real play, the come-back answer) and prints the experience seats'
+   prompts, the UI fidelity seat's when the GDD has mockups, the Mobile QA seat's with the round
+   added, the fidelity seat's again when it now has played frames, and from the second playtest on,
+   the ledger seat's (`ledger/ledger.md`: last round's blockers, judged fixed, still there or changed, and the
+   do-not-regress list, each judged held, lost or not observed). Run them the same way, each a fresh agent given only its file. What
+   they judge, and why beside the panel: skill `funpixel-verify`, `references/experience.md`.
+6. Run `npx @funpixel/tools playtest report`, then read `.funtools/playtest/<n>/report.md`. After
+   the next steps it shows the do-not-regress list (up to eight things the panel named as working, kept
+   in `.funtools/keep.json`; `playtest keep` lists it), last round's blockers with this round's verdict, and the round history
+   (`.funtools/playtest/history.json`: panel axes, the experience bar, the blind player, minutes of
+   real play, fidelity per moment and the AD lines, every round), with each drop marked. When it
+   opens with "Look at the captures first", open those frames before trusting any score: a view
+   that never reached its beat is scored as the wrong game (one game scored 4.9 on views stuck at
+   the opening shot, 6.55 once they reached their beats). A thing on the list that is lost is a
+   regression: the report leads with it and exits 1, the flow makes putting it back the round's first
+   step, and only the owner takes an item off (`playtest keep --drop K<n> --by owner "<their words>"`).
+   What a great playtest looks like, and
+   the review page the person read: skill `funpixel-verify`, `references/playtest.md`.
+7. Hand back the report's next steps in its order, each with its quote, frame and number, last
+   round's blockers, the round history with its drops (never leave a drop out), any staged frame
+   the played route never reached, and what ran. Ask which to take on; the playtest applies
+   nothing, so the game stays as it was until the person picks.
+8. Last, once: how did the kit do in this playtest and the rounds before it? One `report_feedback`
+   call with the kit verdict (skill `funpixel-feedback`, "The kit verdict"): what helped, what got
+   in the way or was wrong, what was missing, each naming its tool or skill, and one overall line.
+   About the kit, not the game; when the call fails, the same line goes in
+   `.funtools/kit-feedback.jsonl`.
+
+`npx @funpixel/tools playtest status` names any seat still owed. With a Funpixel API key,
+`npx @funpixel/tools playtest --hosted` runs the panel and the blind player as hosted jobs for
+credits instead, quoted first (`--yes` to spend a quote over 50).

package/plugins/robin/skills/fp-publish/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: fp-publish
+description: Use when the person types /fp-publish. Publish the Funpixel game in this folder as a draft, after a fresh passing verify and filed feedback.
+---
+
+Publishing needs a passing `verify.json` for the current files: the server refuses a missing, stale
+or failing one. So run `npm run build && npx @funpixel/tools verify` first, and fix what it names
+(skill `funpixel-verify`) until it exits 0.
+
+Then, following the `funpixel-publish` skill:
+
+1. List what will ship and check it for leaks (keys, local paths, private notes): a published game
+   is public to anyone with the link, and everything outside `.harnessignore` ships.
+2. Publish as a draft: `publish_game` when the Funpixel MCP is connected, otherwise
+   `npx @funpixel/tools publish --name "<title>"` (needs `FUNPIXEL_API_KEY`). The id in
+   `funpixel.json` makes every later publish update the same draft in place; no flag needed.
+3. Load the published URL the way a player does and confirm it renders:
+   `npx @funpixel/tools verify <play url>`. When publish printed no address, its server verify is
+   that check, so a second publish to get an address repeats it (a real Claude Code session did). A publish that
+   succeeded but does not render is its own problem: the same files give the same page, so read the
+   build rather than publishing again.
+4. File `report_feedback` (skill `funpixel-feedback`), then tell the person the draft's link and
+   that sharing it to Community is their choice in the app.

package/plugins/robin/skills/fp-smoke-build/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: fp-smoke-build
+description: Use when the person types /fp-smoke-build. The 10-minute smoke build before any full build — one locked-art picture and one generated 3D model in a bare scene, captured and judged.
+---
+
+Before a full build, prove the kit end to end on this machine and account. In a new, empty folder next to
+the plan (never the game itself), run:
+
+`npx @funpixel/tools smoke-build ../smoke --plan <the folder holding design/plan.md and design/first-look/ref-*.png>`
+
+It runs the shortest path a real build takes: `init --bare`, the plan's locked sheets imported and
+pinned on the game's lock, one world picture and one 3D model through the hosted tools, both placed in
+the scene, then capture, `check --world`, `score --target` against the plan's target frame, and one
+progress card. It costs one picture and one model.
+
+Read the four verdicts (exit 0 pass, 1 fail, 3 error; the record is `.funtools/smoke-build.json`):
+
+1. **a generated 3D model in the world** — a failed model is retried, switched (provider, tier), or put
+   to the person (`progress ask … --kind scope`); it is never drawn in code;
+2. **the locked look** — the picture came back drawn to a locked sheet, and the target score is at the bar;
+3. **no primitives** — the world read holds by name (no boxes, box figures, gliding cut-outs);
+4. **a real card** — the card carries a frame of the build.
+
+Any FAIL means the full build would hand back what the last ones did. Fix the kit or the provider,
+run the smoke again, and only then start the game. Report the four verdicts as they stand.

package/plugins/robin/skills/fp-verify/SKILL.md

@@ -0,0 +1,20 @@
+---
+name: fp-verify
+description: Use when the person types /fp-verify. Build and verify the Funpixel game in this folder, fix what fails, and stop when it passes.
+---
+
+Run `npm run build`, then `npx @funpixel/tools verify` (or `npx @funpixel/tools check`: both and
+the rules suite in one call) in the game folder now (the one with `funpixel.json`). If the Funpixel MCP is connected and the local build cannot run, use `build` then
+`probe` instead.
+
+Then, following the `funpixel-verify` skill:
+
+1. Read the exit code: 0 pass, 1 fail, 2 nothing measured (not a pass), 3 a tool error.
+2. For every FAIL line, fix the cause in the game, rebuild, verify again. A check weakened, or a
+   state field negated to pass it, makes verify report a game that does not exist (the harness
+   learned this on control checks passed by flipping a sign instead of fixing the camera).
+3. Exit 2: declare the missing `__FPX_*` hooks, then verify again.
+4. On exit 0, press the real start control once (the front door) and confirm the play screen:
+   verify enters play through its hooks and skips the title, so a dead Play button still passes it.
+5. Green is where this command ends. Report the verdict, what you fixed, and anything you could
+   not verify.