--- name: paprika-make description: Builds what the person asks for in three.js, React Three Fiber or WebGL with the paprika3d tools - a game, a 3D scene or a picture rebuilt in 3D, an interactive or educational piece, a product viewer or configurator, a portfolio or scroll site, a simulation, a shader demo. It opens with a short brief (what it is, what it must have, the pictures to work from) written to BRIEF.md, then builds start to finish. Use on /paprika-make , "make me a 3D ...", "build a three.js ...", or any request for a new 3D page. --- # Make a three.js page ## The brief The work goes in this order, and no page or script file is written before the brief file exists: 1. **The questions** (below), the first call a batch ("The first batch"). 2. **The references**: the person's own pictures or a reference subagent's picks ("Finding pictures"), and on a yes, the study and web assets subagents ("Study references"). 3. **The sheets**: `LOOK.md` always, `CHARACTERS.md` when there are characters or key props, `DESIGN.md` for a game, and the picture sheets, written from the tagged references, the study notes and the answers (`${CLAUDE_PLUGIN_ROOT}/skills/paprika-make/sheets.md`, read whole but its last part, "When it applies", whose sections are read when their case comes), then the picking round for the key assets. 4. **The brief file**, `BRIEF.md` (`paprika-loop/PROMPT.md` in a loop), written from the answers, the kept pictures and the sheets with no more questions. 5. **The build.** A few questions turn the request into `BRIEF.md`, the file the build is checked against. They go one at a time through AskUserQuestion, each after the last answer, as multiple choice drawn from the request. About four are enough, and one the request already answers is skipped. A request that decides everything (what it is, what it must have, its controls or what the visitor does, and its pictures), or a person who says to just build it, gets no questions; a request that leaves any of these open gets a question on each. A session whose tools do not include AskUserQuestion (a loop's builder or judge, a plain `claude -p`) has no person in it: it writes the brief from the words it has and asks nothing (sheets.md, "With no person"). When AskUserQuestion is there, a person is there to answer it, also in the session that starts a `paprika-loop`. 1. **What it is**, since the kind decides what a viewer judges the page by and what the next question asks: a game; a 3D scene (a place, or a picture rebuilt in 3D); a site, product viewer or configurator; an interactive piece (educational, a simulation, a shader demo). 2. **What that kind needs:** | Kind | Asked | |---|---| | Game | the mechanics, the controls, how it is won and lost, the games or things that inspire it | | 3D scene | which pictures, a 1:1 match or inspiration, one view or a space to move around in | | Site, viewer or configurator | the product or content, and what the visitor does | | Interactive piece | the concept or what is simulated, who it is for, and what the person controls | 3. **References**: pictures, links or things they like, each with its role (layout, style, mechanics, mood) and whether to match it or take it as inspiration. A reference is inspiration unless the person says match: people who meant a picture as inspiration pushed back hardest when the page was held to it as a target. 4. **The rest**: what it must have, what to avoid, and anything the person already knows they want. The questions name no device the request does not. 5. **For a game, up to two design decisions** the request leaves open and that change what the game is (tone, the progression shape, the win condition), after the rest, both in one call (`sheets.md`, "DESIGN.md"). **The tool's limits.** One AskUserQuestion call takes at most four questions, each with two to four options; the tool adds a typed answer ("Other") to every question, so no option says "type it". More than four questions go in the next call, and a question never has one option (sheets.md, "Question edge cases"). **A one-line request** (one line, no pictures or design doc) takes the quick path, about four AskUserQuestion calls in all: the first batch; the picks to keep; what its kind needs and the rest, up to four questions in one call; for a game, the design decisions, with the key when there is one to choose. It has no picking round and no soft ask: each key item takes its recommended free source, logged `picked by builder` in CHARACTERS.md; nothing paid is used unasked. **The first batch.** Before it, one `sheet` call with `check: true` names the image and 3D keys this machine has (never a value) and the sources line. The first AskUserQuestion call holds four questions, each with its recommended option first, less any the request or an earlier BRIEF.md answers: - **What it is** (above), its four kinds as the options. - **The web search**: *"Also search the web, YouTube included, for study references and free models? They stay on your machine and are never published."* Yes / No, yes first. - **Picture sheets**: *"Want picture sheets? An image model draws a look board (the colours, light and mood of the whole thing in one picture) and front, side and back views of up to four characters from your references, and the build is held to them. It uses your own image model key."* Yes / No, Yes first when the check found a key. Yes's description names that key ("with your key") or says a key is needed; No's says LOOK.png (the references cropped side by side with their sampled colours) is made free either way. Dropped when the check says `Remembered:` (logged `yes (remembered)`) or BRIEF.md says `Picture sheets: no`. On a yes, read sheets.md's "After a yes to picture sheets" before the next call. - **The asset style**: *"What kind of models? (or type another, such as a mix)"*: low-poly, stylized or toon, realistic PBR, voxel or PS1, recommended from the person's pictures, else the request's words; its description is the check's sources line. **Finding pictures.** When the request and the first answer name no pictures, a reference subagent starts right then: the Agent tool, `model: "sonnet"`, `run_in_background: true`, with the prompt `Read ${CLAUDE_PLUGIN_ROOT}/skills/paprika-make/refs.md and do what it says. The thing: . Folder: `. Its picks are drawn on one picture by one `sheet` call with no provider (`pictures` each pick with `label` " · ", `title` "Reference picks", `out` `refs/candidates/picks.png`), opened in the system viewer in one command (`open` on macOS, `xdg-open` on Linux, `start` on Windows) and named in the reply. One AskUserQuestion call asks which to keep, multiSelect, its text *"The numbered picks are open in your image viewer (refs/candidates/picks.png)."*, one option per pick, labelled with its number, described by what it shows, its licence and its source site in words that work without the picture (more than four picks, or one: sheets.md, "Question edge cases"). The kept ones become `refs/01.`, `refs/02.`, ...; the rest and `refs/candidates/` are deleted. **Study references.** On the yes, right after the first batch, two subagents start as the reference subagent does: `Read ${CLAUDE_PLUGIN_ROOT}/skills/paprika-make/study.md and do what it says. The thing: . Folder: ` and `Read ${CLAUDE_PLUGIN_ROOT}/skills/paprika-make/assets.md and do what it says. The items: . Style: . Folder: `. The items are what the request names or plainly needs: the player or hero, the named characters, creatures, vehicles and props. `sheets.md`'s "What the sheets never do" holds for every file this skill writes. Their replies, a key item added later, or no Agent tool: sheets.md, "The subagents". **`BRIEF.md`** is short, sits at the project root, and its path is shown to the person: ```markdown # ## What it is ## Must have 1. <each thing the page must have: what the build is checked against, and what a paprika-loop judge scores> ## References refs/01.jpg · <layout | style | mechanics | mood> · <inspiration | match> · <source URL> ## Inspirations and notes ## Sheets LOOK.md · CHARACTERS.md · DESIGN.md · refs/sheets/LOOK.png Web study: yes (asked) · Picture sheets: yes, no key yet (asked) · Asset style: low-poly (asked) ## Left to the builder <the choices the brief leaves open: yours to make, and named in the reply> ``` The Must have list gets one line per sheet: "Looks as LOOK.md says: its Checks hold", "The fox courier matches CHARACTERS.md: silhouette and colours", and for a game "Plays as DESIGN.md's Core loop and Controls say". **The first version is written from BRIEF.md and the sheets**: LOOK.md's palette hexes and camera as written, each CHARACTERS.md Source line deciding where its thing comes from (a `pick`, a web file, a generation job, or `model_run`), and DESIGN.md's Controls and Core loop what `interact` plays. A key thing the picking round did not cover gets `sheets.md`'s soft ask before it is built in code, and `model_run`'s `searched` logs why a thing is built in code ("by design: terrain"). **Write the page whole and make this first version as impressive as you can: interesting, detailed, creative.** Take risks in the code. The paprika3d tools are good at finding and fixing what breaks, so a bold first build that needs polishing beats a safe one that needs growing. Run and polish it once it exists. ## What helps - **Shapes that work with the tools**: a plain page (one file, an import map, no build), React Three Fiber under vite when React is asked for, Rapier when the page needs physics. `${CLAUDE_PLUGIN_ROOT}/skills/threejs-game/templates/` (`plain.html`, `r3f.tsx`, `rapier.ts`) shows each working with the `window.__game` convention. A site (a portfolio, landing or scroll story) is a plain page with the camera driven by the window's scroll (`references/configurator.md` covers viewers and configurators; the `scroll` step of `interact` and the `scroll` look drive a scroll page). - **A scene from pictures**: `${CLAUDE_PLUGIN_ROOT}/skills/paprika-loop/builder-scene.md` holds the method (`reference` crops and samples, `refs/cameras.json`, `picture()` from `fx.js`). - **`${CLAUDE_PLUGIN_ROOT}/skills/threejs-game/SKILL.md`** says what each tool shows and holds the rules the tools rely on (the `window.__game` convention, time, randomness, names). - **What a finished page has usually been through**: for a game, each control the brief names played with `interact` and the `opening` look, and each button or menu the page shows clicked once with `interact` (a mouse step at its box from the look's `HTML over the canvas:` line); for a site or configurator, the `scroll` look when it scrolls, `perf` with `budget: "site"`, `model_audit` on each model file, and the `viewports` look when the brief names phones or tablets; for a simulation or demo, a `sheet` look over time and `perf`. For every page, the last look's picture against the brief's Must have list; a `Lighting:` or `Surfaces:` line names something a viewer sees. - **A model the brief names**: `model_audit` reports its size and triangles, the `open` reply says whether it loaded, and a model at the wrong scale shows in `look`'s "Never visible" line. - **Ready-made assets**: `asset_search` finds models (57,732, CC BY or CC0), PBR textures and HDRIs (CC0) in a hosted library, and puts the one picked into the project with its loading code and its credit line; `geo.js` and `fx.js` are the options with nothing to download. ## The critic Once the page runs and has a look, start a critic: the Agent tool, `model: "opus"`, in the foreground, with the prompt `Read ${CLAUDE_PLUGIN_ROOT}/skills/paprika-make/critic.md and do what it says. The request: <BRIEF.md's What it is and Must have list>. The look: <LOOK.md's Checks>. The boards: <refs/sheets/*.png>. The sources: <CHARACTERS.md's Source lines, and paprika3d/sourcing.json's lines>. The pictures: <paths>` (a line with nothing behind it is left out). The paths are the newest look pictures, `ls -t paprika3d/runs/*/look-*.png | grep -v -e -ids -e -diff | head -6`. The glitches and gaps the critic lists are closed one at a time, the way `${CLAUDE_PLUGIN_ROOT}/skills/threejs-game/references/lighting.md` closes a fault line (zoom, one change, look again); what to improve beyond that list comes from the brief and your own picture of the page (the scene, the HUD, menus and text a viewer reads, and each feature the brief names), worked out in your head before you look, not read off the pictures. ## The watermark Every script and page this skill writes carries `// Made with paprika3d · https://paprika3d.com` as its first line (a `.js`, `.ts`, `.tsx`, `.jsx` or `.mjs` file; the second, under a `#!` line), or `<!-- Made with paprika3d · https://paprika3d.com -->` right after `<!doctype html>` (an HTML page). The files the plugin copies in (`geo.js`, `fx.js`, `three-runtime.js`, `game-state.js`, `physics-worker.js`) and everything in `node_modules` are left as they are. ## The reply Four short lines: how to run the page, what it does, what to try next, and that the brief is `BRIEF.md`, so a change to it and a new ask changes course. After the quick path, one line more: each key item's source can be changed in CHARACTERS.md. No summary of the work. Once per session, and not in a session with no person in it, one short last line: "Want a public paprika3d.app link? Say publish." Publish only on a yes, through the paprika-publish skill.