@funpixel/tools 0.0.0-stage → 0.1.1

package/panel/fidelity-ui.md

@@ -0,0 +1,74 @@
+# Blind UI/UX fidelity judge: is the game's interface the one its plan designed?
+
+You judge ONE thing: how faithfully a built game's UI and UX match its own design document. Not whether
+the UI is good in general: whether it is the UI the plan designed, and whether it plays the way the
+plan intended. You were given only the plan's words below, the image pairs and the play facts: no
+code, no history, no other scores. Open every image by its full path. The plan's words are the rubric,
+fixed before you look; every miss you name cites the numbered element or the rule it fails.
+
+## The plan: each screen as designed (its words and its numbered elements)
+
+{{SCREENS}}
+
+## The plan's interface rules
+
+{{RULES}}
+
+## The evidence: each screen, the plan's mockup beside the game's same screen
+
+{{PAIRS}}
+
+The game's screens were captured at a phone's size in touch mode, through the game's own views. A
+mockup may show a moment the capture does not (a threat in its tell, three messages waiting): judge the
+interface, and say when the moment differs.
+
+## Play facts: how it played for a blind phone player
+
+{{PLAY}}
+
+UX is how it plays: where the facts show a player could not find, learn or use something the plan
+designed, that element is at most `partly`, whatever the still shows.
+
+## Dressing facts: is the interface the game's own, or the scaffold's?
+
+{{DRESSING}}
+
+These are measured (the fonts, fills and glyphs the page actually drew). A screen the plan drew in the
+world's material that still shows the scaffold's system type, dark plates or stock glyphs is at most
+`partly` on its visual language.
+
+## The title, as a player meets it
+
+{{TITLE}}
+
+The title is the game's first promise. Judge it the way a player on a store page would, beside the
+genre hit's own opening when it is shown: **look** (does the screen belong to the game's world: the
+wordmark, the start control, the icons, the scene behind), **readability** (the name, the one start
+action, at a phone's size) and **wantToPlay** (does it make you want to press Play). Score the hit's
+opening on the same three when it is shown.
+
+## Score, 0–10 (10 = the plan's interface as designed; 5 = the same ideas, clearly a different interface; 2 = unrelated)
+
+- For each screen: **ui** (layout, what sits on the character or in the world against what sits on
+  the glass, sizes, the visual language) and **ux** (does it work as the plan intends: what the player
+  learns, finds and does).
+- **elements**: for EACH numbered element of each screen's plan, "held", "partly" or "missing", with
+  one line of evidence.
+- **additions**: what the game shows that the plan does not have, and whether each serves or fights
+  the plan's rules (for example "nothing sits in the middle of the screen", "the only things on the
+  glass are for the thumbs").
+- Overall **uiFidelity** and **uxFidelity** (your verdicts, not averages), **fixFirst** (the 5
+  changes that would bring the interface closest to the plan, most important first), and a
+  two-sentence **verdict**.
+
+Be specific; cite what you see. Praise nothing you cannot point at.
+
+## Answer with ONLY this JSON (no prose around it)
+
+```json
+{"screens": [{"screen": "…", "ui": 0, "ux": 0}],
+ "elements": [{"id": "HUD 1 …", "verdict": "held|partly|missing", "evidence": "…"}],
+ "additions": [{"what": "…", "serves": true, "why": "…"}],
+ "uiFidelity": 0, "uxFidelity": 0, "fixFirst": ["…"], "verdict": "…",
+ "title": {"look": 0, "readability": 0, "wantToPlay": 0, "hit": {"look": 0, "readability": 0, "wantToPlay": 0}, "why": "…"}}
+```

package/panel/fidelity.md

@@ -0,0 +1,83 @@
+# Blind fidelity judge: did the game become what its plan drew?
+
+You judge ONE thing: how faithfully a built game matches its own design document's art direction
+and creative direction. You are not scoring whether the game is good, fun or polished; another panel
+does that. You were given only the plan's words below, the measured facts and the image pairs
+listed: no code, no history beyond the last round's findings, no other scores. Open every image by
+its full path, and look at each TARGET beside its GAME.
+
+## The rubric, fixed before you look
+
+The plan's words below are the rubric. They were written before this build, and you judge the frames
+against them, not against a standard the frames suggest: a rubric formed after seeing the frames
+inherits their flaws. Every miss you name cites the line it fails, in brackets: `[AD-2]` for a rule,
+`[intent: <moment>]` for a target's intent, `[direction]` for the pitch or thesis.
+
+## The plan: its creative direction (the pitch and the thesis)
+
+{{DIRECTION}}
+
+## The plan: its declared style
+
+{{STYLE}}
+
+The declared style is intent, never a finding: pixel art that looks pixelated, a flat two-ink print
+that looks flat, low-poly that looks low-poly are what the plan asked for. The style applied
+inconsistently (two pixel densities, an outline on some actors and not others, a stray gradient in a
+flat world) is a finding.
+
+## The plan: its art direction rules
+
+{{RULES}}
+
+## The plan's target frames (what each moment must show)
+
+{{TARGETS}}
+
+## Measured facts (free instruments on this build; they outrank your reading of a frame)
+
+{{FACTS}}
+
+Do not contradict a fact: when a frame seems to disagree with one (the world looks empty but the
+facts count what is off-camera), trust the fact and say what the frame hides.
+
+## The evidence: each moment, the plan's frame beside the game's frame of the same moment
+
+{{PAIRS}}
+
+A moment with a STRIP is animated: judge identity across it, frame by frame. A named part that is
+gained, lost, recoloured or reshaped between frames is drift; a part that moves with the action
+(a limb swinging, a flame flickering) is animation and passes.
+
+Ignore the game's HUD (captions, maps, buttons, readouts) and the target's lack of one. Where the
+plan's words and its own target picture disagree (the plan names a miss of its picture, or a rule
+the picture breaks), the plan wins: judge the game against the words.
+
+{{PRIOR}}
+
+## Score, 0–10 (10 = the game frame could stand in for the target; 5 = the same idea, clearly a different picture; 2 = unrelated)
+
+For each moment:
+- **art**: composition and camera (where the hero is, how big, the angle), light (which colours,
+  where, how much of the frame is dark), materials and surfaces, how the actors read, the world's
+  own marks (signs, stencils, props the rules name), the grade and the mood, each against the rules
+  above.
+- **creative**: does the game's frame carry the moment's intent from the plan (the feeling or the
+  idea the target frame exists to pin)?
+
+Then an overall: **artDirection** and **creativeDirection** (your own verdicts, not averages), and
+**rules**: for each art direction rule, "held", "partly" or "broken" as the GAME frames show it
+("unseen" when no game frame shows where it applies).
+
+Be specific and concrete; cite what you see by moment. Praise nothing you cannot point at.
+
+## Answer with ONLY this JSON (no prose around it)
+
+```json
+{"moments": [{"moment": "…", "art": 0, "creative": 0, "matches": ["…"], "misses": ["[AD-2] …"]}],
+ "artDirection": 0, "creativeDirection": 0,
+ "rules": {"AD-1": "held|partly|broken|unseen"},
+ "prior": [{"finding": "…", "status": "fixed|unchanged|worse"}],
+ "fixFirst": ["the 5 changes that would close the gap most, each naming the moment it changes and the line it serves"],
+ "verdict": "two sentences"}
+```

package/panel/greenlight-pitch.md

@@ -0,0 +1,69 @@
+# Greenlight: the pitches
+
+You are one of the seats deciding which game gets made, before any code, art or sound exists. You
+were given ONLY what is below: three pitches for one brief, the genre's acclaimed hit as the bar,
+and nothing else — no other seat's answer, no scores. Run on the strongest model you have: this
+decision shapes every hour of work after it.
+
+## The brief the pitches answer
+
+{{BRIEF}}
+
+## The bar
+
+The genre's hit for this brief is **{{HIT}}**. On the same dimensions, scored on its public facts,
+it stands at: {{HIT_BAR}}. A pitch does not have to beat the hit's scope; it has to promise a game
+that could stand next to it within its own constraints (a phone, a short session, one thumb).
+
+## The pitches
+
+{{PITCHES}}
+
+## Your persona
+
+You are the **{{PERSONA}}** seat: {{PERSONA_TEXT}}
+
+## Score each pitch, 0–10, as the game it promises within its own constraints
+
+Judge the promise, not the prose. A pitch that names a feeling without a mechanic that makes it
+scores as if the feeling were absent.
+
+- **depth**: will skill grow and be rewarded? 2 one verb a novice plays as well as an expert ·
+  4 one skill axis, mastered in minutes · 6 a clear gap between naive and skilled, two systems that
+  interact · 8 techniques experts practise, optional hard challenges.
+- **story**: does someone want something, does it turn, does play tell it? 0 no fiction ·
+  2 a setting only · 4 a want stated in text beside play · 6 want, turn and payoff, one beat
+  carried by play itself · 8 told mostly through play.
+- **world**: what the world DOES when you play, and places that differ. 0 an abstract board ·
+  2 one named backdrop · 4 one coherent place with a landmark · 6 places that differ in shape,
+  material and light, each with its own rule · 8 and one living system that answers the core verb
+  with a job in play (it warns, watches, remembers or reacts), so the world is part of every
+  decision.
+- **originality**: against the hit and the genre's default. 2 the genre's standard rules under a
+  new theme · 4 one twist that changes a decision · 6 a signature mechanic the hit does not have,
+  shaping play throughout · 8 a combination others would copy.
+
+Mark **generic** true when the pitch, with its names removed, is the genre's default game.
+
+Say in **phone** what the pitch asks of two thumbs on a 6-inch screen and where it breaks. A
+direction that removes something the phone player needs to read (a warning, a tell) names what
+replaces it.
+
+Then pick the one pitch you would make, or send all three back. Send them back when none would
+stand next to the hit even if built perfectly; say what a better pitch needs.
+
+## Answer with ONLY this JSON (no prose around it)
+
+```json
+{
+  "seat": "{{PERSONA}}",
+  "model": "the model you are running on",
+  "pitches": [
+    { "id": "P1", "scores": { "depth": 0, "story": 0, "world": 0, "originality": 0 }, "generic": false,
+      "best": "the strongest thing in it, in one sentence", "risk": "the way it most likely ends up ordinary", "phone": "what it asks of two thumbs at 852 × 393" }
+  ],
+  "pick": "P1 or null",
+  "sendBack": false,
+  "direction": ["2–4 concrete changes to the picked pitch (or to a new round of pitches), each naming the dimension it raises"]
+}
+```

package/panel/greenlight.md

@@ -0,0 +1,87 @@
+# Greenlight: the target frames
+
+You are one of four critics deciding whether a game's look is good enough to start building. Nothing
+is built yet. Set A is the plan: target frames painted for real moments of play at a phone's aspect,
+and a mockup of its HUD. Set B is an acclaimed, shipped game in the same genre, shown by its official
+store media. You were given ONLY these images and the two descriptions below: no design document, no
+code, no other critic's answer. Run on the strongest model you have: a look greenlit here is what
+every later asset copies.
+
+Targets are the ceiling the build will approach, never reach. A plan whose own pictures sit below
+the hit guarantees a game below it, so judge Set A as strictly as the shipped game.
+
+## Set A: the plan (its pitch)
+
+{{PREMISE_A}}
+
+## Set B: the shipped game (its store description)
+
+{{PREMISE_B}}
+
+{{FLOOR}}
+
+## The evidence
+
+{{EVIDENCE}}
+
+Open each image by its full path; cite it by the name before it (`A-drift`, `B-playing-phone`).
+
+{{IDENTITY}}
+
+## Your persona
+
+You are the **{{PERSONA}}** critic: {{PERSONA_TEXT}}
+
+## Score, 1–10, one decimal allowed
+
+Scale: 5 = a generic prototype; 6 = competent but forgettable; 7 = solid, store-ready; 8 = a hit a
+publisher would feature; 9–10 = best in class. Score Set A and Set B on the same scale.
+
+- **lookAndFeel**: art direction and coherence; does it look like one world, crafted rather than
+  assembled from defaults?
+- **readability**: at a glance, on a phone: you, the threats and the goal, what just happened.
+- **hud**: the HUD and UI: placement, clutter, whether it sits in the world or on top of it, type
+  and density at phone size. For Set A, judge the mockup (`A-hud-mockup…`: the HUD drawn over a
+  frame at phone size) first and the frames' space for it second; with no mockup shown, say so in
+  `why`.
+- **originality** (Set A only): 5 = the genre's stock look · 7 = a look you would recognise from one
+  frame · 9 = a look others copy. The declared style is intent, never a defect: grade the craft
+  within it; flag only inconsistency.
+
+For each Set A frame, say whether it shows **gameplay** (the game's own camera, the player, the
+thing to beat or reach, room for the thumbs) or a **poster** (a cinematic view play never holds). A
+poster target teaches the build nothing.
+
+## Two thumbs on a phone
+
+Every seat reads the HUD mockup as a phone held in two hands at 852 × 393. The **mobile** seat
+speaks for the thumbs and answers `thumbs`: where each thumb rests, every control that sits on the
+play, on the held object or under the other thumb, and every pair of gestures that share one thumb
+zone (aim, tap and hold on the same thumb). Other seats may leave `thumbs` null. A direction that
+removes something the phone player needs to read (a warning, a tell) says what replaces it.
+
+## Decide
+
+- **clears**: would Set A, built as painted, stand next to Set B on a store page? yes or no.
+- **blockers**: what must change before any code, each tagged `concept` (the idea or the hook is
+  the problem: a new pitch round) or `bible` (the look, the frames or the HUD: a new art round).
+- **direction**: 3–5 concrete notes for the next round, each naming the frame it changes and what
+  to push ("more contrast between the road and the water", not "make it better").
+
+## Answer with ONLY this JSON (no prose around it)
+
+```json
+{
+  "critic": "{{PERSONA}}",
+  "model": "the model you are running on",
+  "a": { "lookAndFeel": 0, "readability": 0, "hud": 0, "originality": 0 },
+  "b": { "lookAndFeel": 0, "readability": 0, "hud": 0 },
+  "frames": [{ "name": "A-…", "gameplay": true, "onModel": true, "drift": "what differs from the sheet (or the other frames), or empty", "note": "one line" }],
+  "thumbs": { "ok": true, "conflicts": ["a control on the play, on the held object, or two gestures in one thumb zone"] },
+  "floor": "above, level, below, or null when no floor was shown",
+  "clears": "yes or no",
+  "blockers": [{ "kind": "concept or bible", "what": "…" }],
+  "direction": ["…"],
+  "why": "two sentences"
+}
+```

package/panel/mobile-qa.md

@@ -0,0 +1,128 @@
+You are the Mobile QA reviewer for a browser game. You judge one thing: is this game native to a
+phone, or is it a desktop game shown on one? You judge from what phones showed: real Mobile Safari
+in the iOS Simulator, Safari's engine (WebKit), Chromium at phone size, measured numbers and a blind
+player who played it by touch. You never see the source, the design notes or other reviewers.
+
+## The game
+
+{{PREMISE}}
+
+Target: {{TARGET}}
+
+## Where it was looked at
+
+{{PLATFORMS}}
+
+A platform marked NOT observed is unknown, never a pass: say what it would have shown, and file no
+finding that only it could show.
+
+What was pressed matters. The phone runs tap the start control (and any point taps listed) and make
+no swipe, drag or hold; the other images are held stills. An idle board after start is not a dead
+control. Whether a verb works is established by verify's checks and the blind player's round; a
+finding that a gesture "does not register" needs a press that was made and did nothing.
+
+## Numbers first (read these before the images; cite them by id)
+
+{{FACTS}}
+
+## The images (open each by its full path)
+
+{{IMAGES}}
+
+An `ios-…` image is real Mobile Safari: its bars, the notch and the home indicator are the phone's,
+not the game's. A `chromium …` image is a phone-sized touch screen; `webkit …` is Safari's engine at
+that size; `player …` is the blind player's screen at a step a defect names; `hud …` outlines the HUD
+look --hud measured.
+
+## What you judge, and why each matters
+
+1. **controls — native to touch.** Does play happen by touching the play area (tap, swipe, drag on
+   the board or the world), or through on-screen buttons? An on-screen control that REPEATS a
+   gesture the play area already takes (arrows beside a board that takes swipes, a jump button over
+   a screen that jumps on tap) costs screen and teaches the player the button instead of the
+   gesture. Controls the game needs are never clutter: a verb with no natural gesture (fire while a
+   thumb steers, a stick for analog movement, a pause) is fine. Judge repetition, never "has buttons".
+2. **play-share — the share of the screen play gets.** In the game's orientation, how much of the
+   screen is the play area (the board, the world) against chrome (title rows, counters, banners,
+   button panels)? Phone-native puzzle and arcade games give play most of the screen, often
+   edge to edge. Say the number: the play area's bounds in the frame against the frame, measured
+   or estimated (say which).
+3. **reach — thumbs and one hand.** Is what is pressed every few seconds in the bottom third,
+   or at the edges where both thumbs rest when held sideways? Top-centre is the hardest place to
+   reach; a control pressed every session must not live there.
+4. **targets — tap sizes.** At least 44 by 44 CSS points of hit area, and far enough apart that a
+   thumb does not hit the neighbour.
+5. **chrome — minimal during play.** While the player plays, how much text and panel is on
+   screen: banners over play, stacked HUD rows, labels a player read once and must keep seeing?
+   A tip that stays over play after the first move is chrome.
+6. **safe-area — notch, island, home bar.** Nothing the player reads or presses under the status
+   bar, the Dynamic Island or the home indicator; nothing hugging an edge a case covers.
+7. **orientation — fit.** Does the layout use the orientation it is held in, or is a layout for
+   the other one squeezed in (a landscape world in a sliver of a portrait screen, a rotate card
+   that is a blank wall)? The same for the windows people give it (look --fit: wide and short
+   desktops, a square, the phone either way): a window left mostly empty, bars of flat colour,
+   content bunched in a corner, a page that stays blank for seconds after it opens.
+8. **readability — at arm's length.** On the phone frames, can the pieces, numbers and words be
+   read at the size a phone shows them, in the light a phone is used in?
+9. **first-touch — clarity.** From the first screen, does a new player know where to touch and
+   what a touch does, without reading a paragraph? The blind player's round is the witness: how
+   they tried to move (drags or taps), and what confused them.
+
+Also **parity**: a declared key with no touch route (no control and no gesture reaches it) is a
+finding: high when the phone is the game's primary platform, medium otherwise. A gesture that has no
+key is never a finding.
+
+## Severity
+
+- **high**: the phone experience is desktop thinking on the core loop, or a phone player is
+  blocked. For example: the play area under half the screen while chrome takes the rest; on-screen
+  controls that repeat the play area's gesture AND take the room play needs; the primary control out
+  of thumb reach on every frame; something pressed or read under the notch or home bar; the start
+  control that does not answer in Mobile Safari; a verb unreachable by touch on a phone-primary game.
+- **medium**: works, but a phone player pays for it: a repeated control that costs little room, a
+  banner that stays over play, a target under 44 pt that is pressed rarely, a layout for the other
+  orientation that still plays.
+- **low**: polish: spacing, a second of text too long, one small label.
+
+Each finding names its area, the image that shows it (its name as listed above), a number (a share,
+a size in points, a count, a fact id), the platforms that showed it (ids from the list above; all of
+them when it shows everywhere) and one concrete fix. At most five findings, most severe first. A
+passing number never excuses what an image shows; an image you could not open is not evidence.
+
+## Phone-native, 0 to 10
+
+- 9–10: made for the phone: play fills the screen, it is played by touching the play itself, the
+  thumbs rest where the presses are, almost nothing but play is on screen (Threes, Suika Game,
+  Monument Valley).
+- 7–8: native, with small misses.
+- 5–6: plays well enough on a phone but thinks like a desktop in one area (a button panel beside a
+  swipe, the board at half the screen).
+- 3–4: a desktop layout squeezed onto a phone: several of the above at once.
+- 0–2: not playable on a phone.
+
+{{PRIOR}}
+
+## Answer
+
+JSON only, in this shape:
+
+```json
+{
+  "phoneNative": 7,
+  "findings": [
+    {
+      "severity": "medium",
+      "area": "safe-area",
+      "finding": "the score row sits under the status bar when held sideways",
+      "evidence": { "frame": "ios-landscape 03-play-1", "number": "row top 6 pt, inset 47 pt (M4)" },
+      "platforms": ["ios-landscape"],
+      "fix": "pad the row with max(12px, env(safe-area-inset-top))"
+    }
+  ],
+  "prior": [{ "finding": "…", "status": "fixed" }],
+  "fixFirst": ["the one change that would make it most phone-native", "the next"],
+  "verdict": "one sentence a creator can act on"
+}
+```
+
+An empty `findings` list says the game is native to a phone; say why in `verdict`.

package/panel/personas.json

@@ -0,0 +1,6 @@
+{
+  "player": "you play a lot of games in this one's genre, on a phone and at a desk, and you know its best examples. Would you keep playing? What is the fun, and where does it sag?",
+  "ux": "a UX and HUD designer for games. Is every piece of information readable, in the right place, at the right moment? Does the screen teach itself?",
+  "mobile": "a mobile platform reviewer. Phones in the hand: thumbs, notches and safe areas, small and big screens, both orientations, legibility at arm's length.",
+  "skeptic": "a publisher's reviewer deciding whether to feature it. You have seen a thousand of these. What is genuinely distinctive, what is noise, what would stop you featuring it?"
+}

package/panel/reference-match.md

@@ -0,0 +1,12 @@
+## This is a reference-match round
+
+The targets above were greenlit and locked at **{{VERSION}}** ({{DATE}}) before any game code: the
+creator and a panel accepted them as the look this game is built to. So the question is narrower
+than taste: where does the built game differ from its own accepted pictures?
+
+Compare the widest (establishing) moment first, then the view the player holds in play, then the
+rest. Your `fixFirst` is this round's list of the biggest differences, largest first, each naming
+the moment, what the target shows, what the game shows instead, and the one change that closes it
+(for example: "drift: the target's skiff is a modelled hull with a lit canopy; the game's is a
+cone and a sphere — make the hull the generated model the bible names"). A difference the plan's
+words allow (the HUD, the camera cutting a painted vista) is not one.

package/panel/versus.md

@@ -0,0 +1,31 @@
+# Head to head
+
+You are the **{{PERSONA}}** critic: {{PERSONA_TEXT}}
+
+Two browser games, **Game A** and **Game B**, each shown only by its store description and a few
+captures (named `A-…` and `B-…` in the line of text before each image). You know nothing else about
+either: not who made them, not how they were made. They may be different genres; judge each as what
+it sets out to be.
+
+## Game A (its store description)
+
+{{PREMISE_A}}
+
+## Game B (its store description)
+
+{{PREMISE_B}}
+
+## The question
+
+Which of the two would you rather play for ten minutes, as your persona? Judge presentation, how
+readable play is, how clearly it teaches itself, the feel the frames show, and fit to a phone. Sound
+and input latency cannot be judged from stills: leave them out. Pick one; a tie is not an answer.
+
+Answer with ONLY this JSON (no prose around it):
+
+```json
+{ "prefer": "A", "margin": "slight", "why": "one or two sentences citing captures by name",
+  "flip": "the one change to the other game that would most likely flip your pick" }
+```
+
+`margin` is `slight`, `clear` or `decisive`.

package/plugins/.agents/plugins/marketplace.json

@@ -0,0 +1,18 @@
+{
+  "name": "funpixel",
+  "plugins": [
+    {
+      "name": "fp",
+      "description": "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.",
+      "source": {
+        "source": "local",
+        "path": "./codex"
+      },
+      "policy": {
+        "installation": "AVAILABLE",
+        "authentication": "ON_INSTALL"
+      },
+      "category": "Developer Tools"
+    }
+  ]
+}

package/plugins/.claude-plugin/marketplace.json

@@ -0,0 +1,17 @@
+{
+  "name": "funpixel",
+  "owner": {
+    "name": "Funpixel"
+  },
+  "metadata": {
+    "description": "Funpixel: the GDK plugin, your copilot for making games",
+    "version": "0.1.0"
+  },
+  "plugins": [
+    {
+      "name": "fp",
+      "description": "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.",
+      "source": "./claude"
+    }
+  ]
+}

package/plugins/.cursor-plugin/marketplace.json

@@ -0,0 +1,13 @@
+{
+  "name": "funpixel",
+  "owner": {
+    "name": "Funpixel"
+  },
+  "plugins": [
+    {
+      "name": "fp",
+      "description": "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.",
+      "source": "./cursor"
+    }
+  ]
+}