Every line you write shows up on screen.

The 60-second version

Skim mode is on. You are seeing the essentials only.

Most of these come from Anthropic's Opus 5.5 prompting guide and frontend-design skill. "Numbers over adjectives" and "Give feedback in physics" are patterns from the community prompts later on this page.

Anatomy of a build brief

The example takes the one-line Halloween diorama request ("rainy night, warm firelight, 1080p, loops for hours") and writes out every decision the short version left to chance. Write the layers in this order: what you are shipping first, how to prove it works last.

One line, one visible change

With every switch off you get what an unspecified prompt tends to produce: soft edges, smooth tweening and a gradient sky. Nothing is wrong with it, it just is not pixel art. Four short lines are the difference.

Playbooks by format

Build one self-contained HTML file (vanilla JS, Canvas 2D, no libraries, no network) showing [subject] as a looping pixel-art animation.

Canvas: draw at [320×180] logical pixels, scale by the largest integer that fits, centred, image-rendering: pixelated. Snap every draw to whole pixels. No gradients or blur. Soft falloff uses 4×4 Bayer dithering.
Palette: [24] fixed colours. Roles: [sky steps], [skin and cloth], [3 bright accent colours], [2 outline darks].
Character: about [24×32 px], built from rects and pixel runs. Pose parameters: [list]. Animate them smoothly, then quantise poses to [10] fps inside a 60 Hz loop.
States: [IDLE 2 s] then [ACTION 1.5 s] then [RESOLVE 1 s], eased between keyframes, looping with no seam.
Particles: one preallocated pool of [300], zero allocation inside the loop, fixed 60 Hz timestep.
Evidence: capture a frame in every state plus the loop point, compare first and last frame, fix shimmer, clipping and pops.
Done when it holds 60 fps on [device] and each state is identifiable in its captured frame at 1×. Reply in two sentences and attach the captures.

Build a complete browser game in one HTML file using [three.js r186 / Canvas 2D]. Inline every library (no CDN at runtime) and generate every model, texture and sound in code. No paid or hosted generators, even if API keys exist.

Fun target: [challenge / discovery / expression / ...] (see Game design).
Core loop: the player [does X] to [achieve Y] while [avoiding Z]. Pacing: the core action repeats every [5 to 30] s, something new appears every [1 to 5] min, pressure starts in the first minute, and the first real decision comes within 30 s.
Controls: [WASD + mouse]. Feel targets: top speed [n], reaches it in [0.4 s], turn inertia [light], jump defined by height [2.2 m] and time to apex [0.4 s], coyote time and jump buffer [100 ms]. Physics on a fixed timestep with interpolated rendering. Input responds within one frame.
Touch, if mobile ships: the same actions as the keyboard, targets of at least 44 px, touch-action set on the canvas only, and input released on pointercancel, lostpointercapture and blur.
Structure: title, play, fail, win, and restart without reload. Score plus one difficulty curve that rises over [3 minutes].
Camera: third-person on a spring arm at [6 m] with a collision cast, never inside walls or below ground, no bob with the walk cycle, shake on a separate layer.
Level: grey blockout first, sized from the controller's metrics (doors at least 2× player width), a critical path with numbered beats, one loop that returns as a shortcut, one landmark visible from most of the path. Art only after the blockout plays well. Audio synthesised, [M] mutes.
Enemies: [state machine / behaviour tree] with a vision cone, hearing and last known position, navmesh or grid A* pathfinding, a visible awareness telegraph before attacking, and a debug overlay on [F1]. All randomness seeded.
Juice, once the loop works: hitstop, trauma-based shake, spring squash, layered hit sounds, all scaled by an intensity value, with a reduce-shake toggle.
Performance: 60 fps on [a named mid-range laptop], drop render scale below 50 fps.
Test hooks: expose window.__GAME_TEST__ with seed(n), setState(name), pause() and hideDebugUi(), so tests reach every state without playing to it.
Evidence: a scripted bot plays [3] seeded runs in Playwright (channel "chromium", one worker). A run passes when it renders over 100 frames, moves the player, raises the score, never goes [5] s without movement or progress, and logs zero console errors. Rerun with a 300 ms reaction delay to check the game stays winnable. Then reach a win and a fail yourself and screenshot every state.
Done when the bot runs pass, every state has a screenshot, and the 10-second screenshot shows the goal, the player and the first threat without any text. Stop after [30] turns and list what is still open.

Make a [15]-second, [1920×1080], [60] fps motion-graphics piece rendered frame by frame from code in [HyperFrames / Remotion / one HTML page with window.seek(t)]. Use only that framework. Deterministic time, no real-time screen capture.

Purpose: [showreel / explainer / lyric video] for [audience]. The single idea it must land: [idea].
Timeline: 0.0 to 2.0 s [hook], 2.0 to 6.0 s [build], 6.0 to 11.0 s [peak], 11.0 to 15.0 s [resolve and end frame]. Cut on a [120] BPM grid (0.5 s).
Style: [2 typefaces], [4 to 6 hex colours], one motion signature ([spring with 8% overshoot]), transition vocabulary: [mask wipes, match cuts, type morphs]. Do not use: [the looks you refuse].
Audio: [supplied track / synthesised hits]. Visual accents land within one frame of their audio events.
Export: every animation is seekable (a paused anime.js or GSAP timeline), nothing reads wall-clock time, and each frame is captured after a seek, then encoded to MP4 (H.264, yuv420p) with FFmpeg.
Evidence: a contact sheet of frames every 0.5 s, a phone-size sheet at 360 px wide, and the frame offset at [listed beats]. Fix and re-render, at most [3] rounds.
Done when the contact sheet reads as a story without sound, every listed beat lands within one frame, and no text is under [36] px tall at 1080p.

Create a looping pixel-art diorama for a [10-hour] lofi video cover. One HTML file, Canvas 2D, no network, no UI or text on screen.

Frame: 320×180 logical, scaled ×6 to exactly 1920×1080, pixelated.
Scene: [location], [weather and time], hero light: [bonfire / lit window / lantern].
Palette: [28] colours split by role: a cold field ([16]) against warm pockets ([12]). Warm areas stay the brightest and highest-contrast.
Ambient layers: [rain in 3 depths], [sparks], [drifting smoke], [flickering light].
Loop: exactly [60] s. Every periodic motion uses a period that divides 60 s ([4, 5, 6, 12, 20 s]) so layers do not visibly sync, yet the loop closes cleanly.
Stability: fixed timestep, pooled particles, zero allocation per frame, flat memory over an hour of fast-forwarded time.
Evidence: compare frame 0 with the final frame, run the fast-forward soak test, capture four frames across the loop, soften any flicker that strobes.
Done when frame 0 and the last frame differ in under [1]% of pixels and memory stays flat through the soak test. Reply briefly and attach the four frames.

Build an interactive 3D [scene] in one HTML file with three.js r186 ([WebGPU renderer and TSL / WebGLRenderer and GLSL]). Inline the library, no CDN and no other runtime network requests.
Assets: [procedural / CC0 from Poly Haven, ambientCG and Kenney, embedded], each logged in ASSET_MANIFEST.json with source and licence.

World: [landmarks, and where each sits relative to the others], with a critical path and sightlines to one main landmark. Everything rests on ground or water. Nothing floats or intersects.
Hero systems, in priority order: 1 [water], 2 [time-of-day lighting], 3 [wind in foliage]. Vegetation and props scattered by seeded Poisson disk sampling, never uniform random. Define each by what I would see, for example "white foam collars on rocks, trailing downstream".
Look: match [the style frame in art-bible.md], checked in greyscale and silhouette at gameplay distance.
Time of day: [dawn, noon, storm, golden hour, night], each with key light, fog and grade.
Camera: [chase / orbit], never below terrain or inside geometry, [drag to orbit, scroll to zoom].
Budget: 60 fps at 1440p on [an M-series laptop], dynamic resolution, a quality tier that drops the costliest effect first.
Evidence: a screenshot matrix of [3 views] × [each time of day]. Read the console, fix artefacts, clipping and floating objects.
Done when every screenshot passes every art-bible check and the console is clean. Reply in two sentences and attach the matrix.

Engines and libraries

Pick by the job

Web or engine? A web library wins when the result must load from a link with no install, sit inside a site, or become a coded video. An engine wins for large content, native performance, console targets or an existing C# or C++ team. Godot 4 web export uses the WebGL 2 Compatibility renderer, needs cross-origin isolation headers for threads, and cannot export C# projects. Unreal has no official web export, only Pixel Streaming from a server.

How the agent drives each one

For real-estate or interior visualisation in Unreal, the seat licence applies, not the game royalty. Defold (free, Lua, a bob.jar CLI with a headless build, and an llms.txt) is a lighter 2D and 3D alternative. Godot, Unity and Bevy have no llms.txt, so have the agent read the docs for your exact version. Confidence: high for versions, licences and commands, which come from official docs, release notes and package registries. Moderate for the "start with" picks, which are practitioner judgement.

What makes an engine agent-friendly

Headless Chromium on a machine with no GPU: WebGPU needs a secure context (localhost counts) and --enable-unsafe-webgpu, which gives a SwiftShader adapter. Since Chrome 139, WebGL no longer falls back to SwiftShader silently, so add --use-angle=swiftshader --enable-unsafe-swiftshader. On a Linux GPU, Chrome documents --headless=new --use-angle=vulkan --enable-features=Vulkan --disable-vulkan-surface --enable-unsafe-webgpu. Keep Playwright's Chromium current, since an old browser build can reject newer three.js WebGPU calls.

Build [game] as a Godot 4.7 project in GDScript. Godot 4 syntax only: @onready, await, CharacterBody2D/3D. Never Godot 3 APIs. If unsure, read the Godot 4.7 docs for that class first.

Scenes and resources stay as text (.tscn, .tres). Keep every tunable number in one resource with an in-game debug panel.
Loop after every change: godot --headless --path . --import, then parse each changed script with -s [script] --check-only, then run the GUT tests from the command line (-gexit and a JUnit XML report). Fix failures before continuing.
Evidence: render [300] frames with Movie Maker (--write-movie captures/frame.png --fixed-fps 30 --quit-after 300. It needs a display, so on a server run it under xvfb-run), build a contact sheet, and check it against the brief.
Export with --export-release "[preset]" and confirm the build starts and reaches the title screen.
If godot-mcp is connected, use it to run the project and read debug output, not to replace the tests.
Done when the tests pass, the contact sheet matches the brief and the export runs.

Build [game] in Unity [6.3 LTS] with URP and the Input System package. No Built-in render pipeline, no UnityEngine.Input calls.

Never hand-edit .unity, .prefab or .meta files. Change scenes and prefabs through the editor: the Unity CLI (unity command, unity eval) or its MCP server (unity mcp).
Put gameplay in plain C# classes that EditMode tests can reach, and keep MonoBehaviours thin.
Loop after every change: unity test (or -batchmode -runTests -testPlatform EditMode, then PlayMode, with -testResults), read the log, fix, repeat.
Evidence: a PlayMode test that loads each scene, plays [10] s of scripted input, and saves screenshots at named moments. Build a contact sheet from them.
Build with a static BuildScript method through -executeMethod or unity build, for [targets].
Done when all tests pass, the screenshots match the brief, and the build launches.

Build [experience] in Unreal Engine 5.8. Gameplay in C++, editor setup in Python scripts saved in the repo, so every step can be rerun. Do not create logic in Blueprints you cannot diff. Thin Blueprint subclasses for designer-facing values only.

Scene edits go through the Unreal MCP plugin on localhost, or through editor Python. The plugin has no authentication, so keep it bound to localhost and off shared networks. Log every MCP action in build-log.md.
Loop after every change: compile, run automation tests with -ExecCmds="Automation RunTest [Project].Smoke;Quit" and -ReportExportPath, read the JSON report, fix.
Evidence: a Python or console script that moves the camera to [named shots] and runs HighResShot at [3840x2160]. Build a contact sheet and compare it with the style frame.
Package with RunUAT BuildCookRun for [Win64] and launch the build once.
Licence note: this is [a game / non-game visualisation]. Record which Unreal licence applies in README.
Done when the tests pass, the shots match the style frame and the packaged build launches.

Game design

Mechanics make dynamics, dynamics make the feeling

The MDA framework (Hunicke, LeBlanc and Zubek) splits a game into mechanics (the rules you write), dynamics (what happens when players meet those rules) and aesthetics (what the player feels). You can only change the mechanics. The player experiences it from the other end. Pick the feeling first, then work backwards.

The eight kinds of fun come from the MDA paper, developed for the GDC Game Design and Tuning Workshop (2001 to 2004): sensation, fantasy, narrative, challenge, fellowship, discovery, expression and submission. The example games are illustrations, not claims about their designers' intent.

Ideas that hold up

The process

1. Experience goalOne sentence on what the player should feel, plus the MDA fun target
2. Core loopVerbs, a goal, an obstacle and a reward, all in one sentence
3. Find the funA grey prototype of the loop only. No menus, no story, no art.
4. Playtest silentlyWatch strangers play without explaining. Note where they hesitate, smile or quit.
5. Tune in a configEvery number in one file with a live panel, changed one at a time
6. Grow systems around the loopProgression, economy and content only once the loop is fun on its own
7. Vertical sliceOne level at final quality: art, audio, juice, UI and performance
8. Content and polishScale up what the slice proved

Where agents help and where they don't

The shelf

Balance checks an agent can run

From Higgsfield's game design system reference, which also asks the agent to say plainly at delivery that feel and delight still need a human to play the game.

Before building [game idea], write design.md (one page), then build three small prototypes of the core loop only.

design.md: the experience goal in one sentence. The fun target from MDA ([challenge / discovery / expression / ...]) and one secondary. The core loop as verbs, goal, obstacle, reward. Three interesting decisions the player makes every minute. What failure looks like and why the player retries. What is out of scope.
Prototypes: three variants that differ in one rule each ([e.g. resource decays / resource is capped / resource is shared]), grey boxes only, every number in config.json with a live tuning panel, restart in under 1 s.
Bots: a random bot and a greedy bot play each variant 200 times. Report win rates, the most-used action, and any strategy that wins more than [70]% of the time.
Stop there. I will playtest and choose a variant before any art, story or menus.

Critique the current build of [game] as a design reviewer, not a coder. Play it through [the test level] with the bot and read design.md first.

Use these lenses from Jesse Schell's The Art of Game Design, and answer each lens's questions with evidence from the build: Essential Experience, Surprise, Fun, Curiosity, Problem Solving, Challenge, Meaningful Choices, Reward, Punishment, Skill vs Chance.
For each lens: one line on what works, one on what fails, and the smallest mechanic change that would fix it.
Then rank the five changes with the biggest expected effect on the fun target in design.md. Do not implement anything yet.

Art direction, reference first

The process

1. Pillars and moodThree words it is, three it is not. "Cosy, handmade, dusk. Not neon, not gritty, not glossy."
2. Reference boardSorted by job: mood, colour, composition, characters, environment, UI
3. Style framesOne to three images of the actual game view, painted or generated, that the build must match
4. Art biblePalette with roles, value structure, shape language, lighting, materials, UI, technical limits
5. Golden sceneBuild one small scene to match the style frame side by side before anything else
6. Lock with checksGreyscale, silhouette and squint tests at gameplay distance on every milestone

The silhouette rule and role-based palettes come from game art-direction skill packs used with Claude Code (AlterLab GameForge, Claude Code Game Studios), which also ask for colour-blind backups on every semantic colour. The reference-image step is the trick GPT-6 Astra testers credited for their best 3D results: generate the reference first, then match it in code. It works just as well with Opus 5.5.

Worked example: "Lantern Hollow"

A small art bible for a cosy night-exploration game, and a style frame drawn from it in SVG. Every choice in the frame traces back to a line on the left.

Lock the style for generated assets

The style formula, key-colour rule and anti-convergence ledger come from Higgsfield's game-stylization and review-rubric references. The board and choosing rules come from Scenario's inspiration skill. All of them work on either generation route.

Before writing any game code, set the art direction for [game] and save it as art-bible.md.

Pillars: it is [three words]. It is not [three words].
Reference board: I attached [images]. Sort them by job (mood, colour, composition, characters, environment, UI) and write one line on what to take from each.
Palette: 5 to 7 colours, each with a role (safe, danger, reward, interactive, background). Plan the value structure first: gameplay objects get the strongest contrast.
Shape language, lighting (key direction, warm or cool, contrast), materials, UI style, and technical limits ([texture size, triangle budget, post effects allowed]).
Style frame: describe [one / two] key shots of the real game view precisely enough to paint or generate. [If I provide images, treat them as the target.]
Golden scene: build one small scene that matches the style frame. Render it next to the frame, plus greyscale, silhouette and blurred versions. List every mismatch and fix it, for up to [3] rounds, before building anything else. Report any mismatch still open.
From now on, every milestone repeats the greyscale and silhouette checks at gameplay distance.

Illustration, SVG and generative art

What separates tasteful from generic

The process

1. BriefSubject, mood, composition, palette with roles, and style described by technique (flat shapes, soft grain, limited palette), never "in the style of" a living artist
2. ThumbnailsThree compositions as simple grey shapes. Pick one.
3. ValuesBlock the chosen one in greys. Check the focal point leads.
4. ColourApply the palette by role
5. DetailOnly at the focal area, then texture and light
6. Look at itRender to PNG (Playwright or resvg), view it next to the brief, list mismatches
7. One change per roundSmall edits keep the rest of the drawing intact

Pick the medium

Model notes. SVG quality rises with effort only up to a point. In Simon Willison's pelican test GPT-6 Astra drew the legs correctly only at max, while Opus 5.5 and Sonnet 5.5 at max ran out of output before drawing anything. Start at high, cap at xhigh, and give the model a render to look at. For generative work, Tyler Hobbs describes palettes as probability distributions and warns that giving each element a random colour gives terrible results.

Draw [subject] as a hand-written SVG, viewBox 0 0 [1200 800], no external references.

Mood: [quiet dusk, a little lonely]. Composition: focal point [the lamp] on the upper-right third, horizon on the lower third, overlapping layers far to near.
Palette, six colours with roles: [#1f2a44 darkest near shapes, #454a6c far sky, #7a5c73 haze, #e8a87c horizon warmth, #f4e3c3 the single brightest accent, #a9554f small detail]. Use nothing else.
Style by technique: flat shapes with curved paths, no outlines, far layers lighter and bluer, one light direction from [left], feTurbulence grain at 8% opacity.
Refuse: purple-pink gradients, black outlines, centred symmetric subject, glow on everything.
Process: first three composition thumbnails as grey shapes, pick the strongest and say why. Then values in greys, then colour, then detail at the focal point only.
After each stage, render to PNG, look at it next to this brief, and list what does not match before continuing, at most [2] fix rounds per stage.
Done when the render passes every line of this brief at full size and at [320] px wide.

Design a set of [12] icons for [product / game UI]: [list].

Write icon-style.md first: 24 × 24 grid with 2 px padding, stroke [1.75] px, round caps and joins, corner radius [2], optical sizes checked at 16, 24 and 48 px, one fill accent colour [#ffc46b] used only for state.
Draw all icons in one pass so they share a style, each as its own SVG with viewBox 0 0 24 24 and currentColor for strokes.
Render a contact sheet at 16, 24 and 48 px on light and dark backgrounds. Check that every icon has a distinct silhouette, similar visual weight and the same stroke width. Fix outliers and re-render, at most [2] rounds. Done when every icon shares the stroke width and every silhouette is distinct at 16 px.

Make a generative artwork in p5.js as one HTML file: [flow-field strokes over a paper texture].

Seeded: the seed is in the URL, and the same seed gives the same image.
Colour: a palette of [5] colours in HSB, chosen as a probability distribution ([55]% dominant, [25]%, [12]%, [6]%, [2]% accent), with small seeded jitter in brightness. Never a uniformly random colour per element.
Composition: an area of calm negative space, density varying across the canvas, no element touching the edge by accident.
Output [3000 × 3000] PNG with a key press.
Evidence: render 24 seeds as a contact sheet. Judge variety and the worst output, not the best. Tune the rules for up to [3] rounds, until the worst of the 24 still meets the composition rules above.

3D assets: build, measure, source

Asset work is where one-shot prompts fail hardest, because detail gets stacked on wrong proportions and the eye forgives drift. The two strongest community pipelines, img2threejs and Majid Manzarpour's blender-game-skills, fix this the same way: a written brief, staged passes, and a gate at every pass.

Which route fits?

The gate ladder

From blender-game-skills: each phase ends with renders from a camera matched to the reference, plus a compare sheet with numbers. Mismatches get written as measurements ("head 12% too tall") and fixed in the build script, never by eye.

1. BriefViews, scale evidence, 8 to 15 proportions to check, what is inferred
2. CalibrateReferences as planes at real scale, a ruler, the game camera
3. BlockoutSilhouette IoU ≥ 0.85, proportions within 5%
4. FormsIoU ≥ 0.90, proportions within 2%
5. TopologyInside the triangle budget, LOD1 and LOD2
6. UVs and bakeMaterial turntable under a moving light
7. RigExtreme-pose sheet, no stray weights
8. Export round tripRe-import into an empty scene, height within 1%

Generated inputs: preflight, orbit views, tileable textures

From Higgsfield's image-to-3D input rules and texture pipeline and Scenario's orbit-views and retexture skills. Generating assets lists the hosted and local picks for the image-to-3D step.

Rebuild the object in the attached reference as a procedural Three.js model: one function that returns a THREE.Group, no mesh or texture files.

Before any code, list the identity-defining details (bevels and rounding, panel seams, fasteners, painted or engraved lines, gloss versus matte zones, wear) and map each one to a real component. Anything the image cannot show is marked inferred.
Build in passes: blockout, structure, form, materials, surface detail, lighting, interaction, optimisation. After each pass, render from a camera matched to the reference and put reference and render side by side in one sheet. Do not start the next pass until silhouette IoU (overlap of the two silhouettes) is at least 0.85 at blockout and 0.90 from forms on, with proportions within 5%.
Derive colours and material classes from the reference pixels, not from memory.
Runtime: named pivots and sockets for anything that moves, a userData.tick for an idle loop, under [8k] triangles, one draw call per material.
Finish with per-region confidence and a list of what was inferred.

Build [asset] in Blender from the attached references as a game-ready asset for [Three.js / Unity / Godot]: about [1.85 m], [3k] triangles, [rigged / static], GLB with LOD0 to LOD2.

Write asset-brief.md first: each view and its camera estimate, the scale evidence, 8 to 15 proportions to check, parts, materials, and what must be inferred. Ask me only what the images cannot tell you.
Model through re-runnable bpy scripts, one per phase. Every constant is a measured value with a comment naming the view it came from, or is marked inferred.
Gate each phase with a compare sheet from a reference-matched camera and at gameplay pixel size: blockout silhouette IoU at least 0.85 with proportions within 5%, forms at least 0.90 within 2%. Nothing gets detail until its silhouette passes.
Measure only from orthographic views. Perspective art is for silhouette and surface.
Export, re-import into an empty scene, and check triangle counts, bones, clips and height (within 1%) against ASSET_MANIFEST.json.
Hand over a report of what matches, what deviates, and what was inferred.

Source assets for [scene] instead of modelling them: [three tree species, a rock set, crates, a grass PBR texture, a sunset HDRI].

Licences: CC0 first (Poly Haven and ambientCG through their public APIs, Kenney, Quaternius, KayKit free packs, Smithsonian items marked CC0). CC-BY only when nothing CC0 fits (Sketchfab with licence slug cc0 or by, Poly Pizza, BlendSwap CC-0 or CC-BY, itch.io packs whose page states CC0 or CC-BY). Blendkit: CC0 assets only, and ask me first. Never NC, ND, Editorial, Sketchfab Standard or Free Standard, Blendkit Royalty Free, CGTrader or TurboSquid free models, Textures.com, or anything without a stated licence.
Read each licence from the asset's own page or API response at download time, never from a site-wide claim. If the field is missing or not on this list, stop and ask.
For every file, record source URL, author, licence and SHA-256 in ASSET_MANIFEST.json, and generate CREDITS.md for anything that needs attribution.
Normalise on import: metres, Y-up, origin at the base, PBR materials, KTX2 textures, meshopt or Draco compression, at most [5k] triangles per prop.
Render a contact sheet of every imported asset under the scene's own lighting and flag any that clash with the art direction: [palette, stylisation level].
If the build must be a single file, embed only what fits a [10 MB] total and build the rest procedurally.

Licences, at a glance

Agents can search these libraries directly through asset MCP servers such as threenative-asset-mcp, which filters by licence tag and hashes every download. Blender MCP can pull Poly Haven HDRIs, textures and models into a live scene, and Sketchfab or Poly Pizza models with a key (its telemetry is on by default, so switch it off). BlendSwap runs an official MCP server. Check each asset's own page before shipping.

Where to look, and how an agent gets in

Skip CGTrader and TurboSquid free models (files must stay protected or in proprietary formats, and bulk downloads are banned), Textures.com (its terms ban AI use, scripted downloads and open-source release), and Objaverse (scraped from Sketchfab, mostly CC-BY with NC mixed in). ShareTextures calls itself CC0 but its own terms forbid automated downloads and redistribution. Blendkit's Royalty Free licence allows use in software only when the asset "cannot be opened or separated by a third party", which rules out web builds. BlenderKit renamed itself Blendkit on 23 June 2026. On itch.io the licence is whatever the creator typed, and creators can edit a page after you download, so save the page and licence text with the file hash. Generative-AI disclosure has been mandatory for asset packs since November 2024, but it is self-declared. Kenney, KayKit and Quaternius also publish there, so prefer their own sites for the same packs. Confidence: high for the licence terms, which come from each site's own pages. Moderate for download limits and catalogue sizes, which change.

Building levels rather than props? The next section covers level design. For a real-world location instead, OpenStreetMap footprints or streamed 3D Tiles (3d-tiles-renderer) are the usual routes, and OpenStreetMap data needs visible attribution.

Generating assets: hosted first, local fallback

Ask before the first generation

Hosted picks, checked 30 Sep 2026

Picks follow Artificial Analysis arena rankings read on 30 Sep 2026 (GPT Image 2.5 first for generation and editing, H3 Max first for image to video, Wan 3.0 first for text to video with audio after Artificial Analysis reset that board on 29 Sep, Lyria above Eleven Music), top3d.ai's blind 3D votes, and each provider's docs. Prices are list prices on the day and move often. Confidence: High for ids and endpoints, Moderate for rankings and for Tripo P2's topology, which a Digital Production review found mostly quads but not always clean edge flow.

Local fallback: best open model per job

Each row leads with the best-quality open-weight model, ranked on Artificial Analysis's open-weights arenas or published benchmarks where they exist. Several of the best carry licence strings, so the next column names the model to ship with at company scale. Internal and research jobs use the first column. Shipped work uses the second.

Log scale of annual company revenue, group-wide. HunyuanVideo-Foley is limited by territory, not revenue, so it is not on the chart. Terms read from each licence file on 30 Sep 2026. Comfy resells a MiniMax licence that covers local H3 use worldwide, from $5k a month. This is a map, not legal advice.

Rankings read on 30 Sep 2026 from Artificial Analysis's open-weights views (image, editing, video, speech), top3d.ai, WildSongBench, and each model's paper. Speech and music arenas have wide error bars, and sound effects have no open arena, so treat those rows as provisional. Moderate. Left out on purpose: FLUX.2 dev and klein 9B, Krea 2 and Ideogram 4 open weights (all below Qwen-Image 2.1 and restricted), LTX-2.x (well behind H3 and paid above $10M), Hunyuan3D 2.1 and RMBG-2.0. If a brief names one, the agent should say why it was skipped and use the pick.

Driving local ComfyUI

Consistency: climb the ladder instead of adding adjectives

1. Text anchorA fixed identity block, plus a per-shot block for what may change
2. Approved referenceOne hero image every variation points to
3. Style referenceA swatch or frame that carries the look
4. Control mapPose, depth (DA3MONO) or edges to hold composition, on the local route
5. Trained LoRAOne per character, plus a separate style LoRA, on the local route

Gates and stop rules

Comparing two models? Pre-register three to five pass or fail criteria, keep prompts and inputs byte-identical with the same output count, and turn prompt expansion off. Seeds do not compare across models. Build a contact sheet in candidate order, then judge each image at full size. The winner holds for this brief only.

The consistency ladder, rubric-first loop, fix routing and stop rules come from the Scenario, fal and Higgsfield skill packs, restated for both routes. Their measured figures come from small samples run by the skill authors.

Generate [asset or set] for [project].

Route: before generating, ask me in one message: which keys are set (OPENROUTER_API_KEY, FAL_KEY, OPENAI_API_KEY, MESHY_API_KEY, TRIPO_API_KEY, checked by name, values never printed), the spend cap for this job, and whether the inputs may leave this machine. If I am not there to answer, use the local route and say so.
Hosted, when a key fits the job and the inputs may leave: use [GPT Image 2.5 Flare / Sunburst for edits / H3 Max for image to video / Tripo P2 for props / ElevenLabs for audio]. Read the provider's model list to confirm the id before the first call. Estimate the cost of each round and stop at the cap. Poll async jobs and never resubmit one whose status is unknown. Keys stay in environment variables, never in files, logs or the build.
Local, otherwise: ComfyUI at http://127.0.0.1:8188 with the best open model for the job, or its ship-with model if this ships: [Qwen-Image 2.1 or 2512 / H3 or Wan 2.2 / TRELLIS.2 / Fish S2 Pro or Chatterbox]. Start from an official template, read /object_info to confirm every node and input, and stop with a download list if a model is missing. No partner or API nodes.
Use: this is [shipped by a company with about $X revenue, sold in (territories) / internal only]. Use only models and plans whose terms allow that, and name the terms you relied on.
Before generating, write the rubric: [3 to 6 pass/fail lines]. Keep the baseline prompt byte-identical across the set and change only the final clause. Anchor every variation to [hero.png]. For video, chain shots from the previous clip's last frame instead.
Batch: [4] per round at draft settings. Judge each output at full size as "index: pass | fail, line". Fix the cheapest way first (inpaint or edit, then code, then the delta clause, then references, then the alternative model), one variable per round.
Stop when a round is clean or after 3 rounds, and report the best result with its remaining flaws.
Log route, provider, model id, version, terms or licence, seed, cost and request id per output in ASSET_MANIFEST.json. Deliver the files, the workflow JSON or request payloads, and a contact sheet.

Level design

The process pros follow

1. Pre-productionGoal, references, a beat list, what the level teaches
2. Layout sketchCritical path, loops, landmarks, gates. Any drawing works.
3. Metrics playgroundA test map of every jump, door, stair and cover size
4. BlockoutGrey primitives on a grid sized to the player, prototype textures
5. Playtest at player speedWalk it with real gravity and collision, never fly the editor camera
6. Diverge and iterateMost blockouts do not survive the first playtest. That is the point.
7. Scripting and lightingEncounters, triggers, then light for wayfinding and mood
8. Art passSwap blocks for kit pieces with the same dimensions

The sequence follows The Level Design Book's process. Its blockout method: sketch a layout, add a ground plane, a player-sized scale figure and walls, playtest, then diverge and repeat. It also notes that art-dependent narrative games (Firewatch, Untitled Goose Game) got more from an art-first vertical slice or location scouting than from a grey blockout.

Principles, as prompt vocabulary

A useful counterweight: The Level Design Book argues against heavy-handed "guiding the player". Too much signposting and breadcrumbing makes a level feel like Disneyland. Aim for a readable space players can learn, not a path they are dragged along.

Starting metrics

Width, wall and grid values come from The Level Design Book. Jump margin is a common practitioner rule. Always confirm by walking the blockout with the real controller.

How an agent should do it

Checks an agent can actually run: pathfinding reachability from start to every beat and the exit, every required jump inside the controller's measured limits, a bot's critical-path time inside the target, no spot on the path without a landmark or next goal in view for more than [20] s, and a list of dead ends that exist on purpose. Pair them with a top-down render with the path drawn on it and a player-eye screenshot at every beat.

To block out in a real editor, use the engine's MCP or CLI route from Engines and libraries.

Design and block out one level for [game] in [Three.js / Godot / Unity]. No art yet: grey primitives only.

Brief first, one page: goal, target play time [6 to 8 min], and five beats: teach [mechanic] safely, develop it, twist it, a breather with a view, a finale. Put the brief in your first update and continue without waiting.
Metrics: read speed, jump height and jump distance from the existing controller and write them to metrics.json. Grid = player width. Doors and corridors at least 2× player width, walls 150 to 200% of player height, jump gaps at most 80% of max, ramps instead of stairs.
Layout as data before geometry: level.json with areas, connections, one lock and key, and at least one loop that returns as a shortcut. One landmark visible from most of the critical path.
Blockout: build from level.json. Colour-code walkable, blocker and interactive surfaces. Grid texture on every surface. Spawn and exit marked.
Verify: pathfinding reaches every beat and the exit, every required jump is inside the measured limits, a bot runs the critical path in [target] s. Render a top-down map with the path drawn, and a player-eye screenshot at each beat. List every dead end and why it exists.
Stop after the blockout. Art comes after I have walked it.

Write a procedural dungeon generator for [game] that builds levels from cycles rather than branching trees, in the spirit of Joris Dormans' cyclic generation in Unexplored.

Stage 1, mission graph: start, goal, and 1 to 3 cycles. Each cycle is a pattern: lock and key (the lock visible before the key), hidden shortcut, or a one-way drop that returns to the start of the loop.
Stage 2, space: place rooms and corridors on a grid sized to the player metrics in metrics.json, preserving the graph.
Stage 3, content: encounters and pickups placed by beat, with rising intensity toward the goal.
Seeded: the same seed gives the same level. Expose the seed in the URL.
Validate every generated level: the goal is reachable, every key is reachable before its lock, no softlocks, the critical path length stays within [min to max] rooms. Reject and regenerate on failure, and log the reason.
Output: 20 seeds rendered as a contact sheet of top-down maps with the critical path, locks and keys drawn, plus pass or fail per seed. (Algorithms and validation: see Procedural generation.)

Block out an open zone, about [400 × 400] m of game space, for [game], in grey with terrain as stepped terraces first, smoothed later.

Points and lines: one tall landmark visible from the whole zone, plus [4] smaller points of interest, each distinct in silhouette. Main paths run low along valleys, so walking downhill tends to lead somewhere.
Over or around: hills and rock forms shaped so the player must choose to climb or circle, hiding what is behind them. Put a reward or view at each peak.
Density: from any point on the main paths, at least one unvisited point of interest is in view.
Metrics from metrics.json: climbable slope limit, sprint speed, and a target of [30 to 60] s between points of interest at walking speed.
Verify: a heatmap of 50 bot walks from spawn with random goals, a view-coverage map showing where no point of interest is visible, and screenshots from the player's eye at each point of interest. Fix empty stretches before any art.

Game AI

Pick the decision model

The common practitioner advice: start with the simplest model that serves the gameplay. Davide Aversa's rule of thumb is that behaviour trees cover most cases, and planners pay off only when you need emergent solutions. Studios often combine them, for example a utility layer choosing priorities and a behaviour tree executing them. Game AI Pro's overview explains the HTN versus GOAP difference: HTN plans forward from the current state through a designer-built network, GOAP plans backward from the goal.

The four layers

Libraries for the web

What an agent can verify on its own: scripted scenarios with expected outcomes ("noise at X, the guard arrives within 6 s"), a headless run of 500 seeded encounters reporting detection time, time to lose the guard and stuck agents, and screenshots of the debug overlay at each state change.

Add stealth guard AI to [game] in [Three.js / Canvas] using [Yuka / a hand-written FSM] and [recast-navigation-js / grid A*].

States: patrol (waypoints), investigate (a noise), chase (player seen), search (last known position, then look around for [4] s), return. Every state has an exit and a timeout.
Perception: vision cone [90]° and [18] m with line of sight through the navmesh or walls, hearing radius per noise type, memory of last known position. Awareness fills over [0.4 to 1.5] s depending on distance and light before a chase starts, shown above the guard.
Barks for each transition ("Who's there?", "Lost them"), so the state is readable without UI.
Performance: decisions at 10 Hz, movement every frame, path requests capped at [4] per frame.
Debug overlay on [F1]: state name, vision cone, hearing radius, current path, last known position.
Verify: seeded scenario tests (noise at X reaches X within 6 s, a player out of sight for 5 s gets lost), then 200 headless seeded runs reporting detection time and stuck guards, plus overlay screenshots at each state.

Build squad combat AI for [game]: a utility layer chooses what each enemy wants, a behaviour tree executes it.

Utility options: attack, take cover, flank, reload, retreat, regroup. Each score is a curve over inputs (health, ammo, distance to player, cover quality, allies nearby). Show the scores on the debug overlay.
Behaviour tree per option: move via navmesh to a cover point scored by protection and line of sight, then act. Tokens limit attackers to [2] at a time so the player is never swarmed.
Fairness: telegraph shots with a [0.4] s aim line, accuracy that ramps over the first second of exposure, never shoot through cover.
Barks when flanking or reloading so the player can read the plan.
Verify: 300 seeded fights against a scripted player bot, reporting time to kill, damage taken per second, how often each option wins, and any agent stuck for more than 3 s.

Add an AI director to [game] that shapes pacing, modelled on Left 4 Dead's build-up, peak and relax cycle.

Intensity per player from damage taken, enemies nearby and recent kills, decaying over time.
Build-up: spawn threats out of sight, ahead on the player's path. Peak: when intensity passes [0.8], stop new spawns. Relax: [30 to 45] s of calm, or less if the player pushes forward. Then build up again.
Change pacing, not difficulty: enemy strength stays fixed, frequency and placement change.
Log intensity and director state every second and chart them after each run.
Verify: 50 seeded runs with a scripted player bot. The intensity chart must show repeated peaks and valleys, no stretch of calm longer than [60] s, and no death spiral.

Procedural generation

The algorithm cookbook

WFC ships in Bad North, Caves of Qud and Townscaper according to its author Maxim Gumin, who also notes that contradictions are rare in practice. Red Blob Games' polygon map generator chains Poisson points, Delaunator, and noise-driven elevation, rivers and biomes, which is a good model of stacking simple algorithms.

The process that makes generators good

1. Describe the outputWhat a great output has, what a bad one looks like, and hard constraints
2. Hand-make three examplesYou cannot generate what you cannot describe or build once
3. Structure firstGraph, zones or constraints before geometry
4. Stack simple algorithmsPoints, then cells, then noise, then dressing. Each stage is testable.
5. Validate and rejectConnectivity, path length, playable area. Regenerate and log why.
6. Judge in batchesContact sheets of 50 to 1000 seeds and histograms of every metric
7. Mix with hand-made piecesAuthored rooms or set pieces placed by the generator
8. Curate or tuneFix the rules, not individual outputs

Steps 1, 4 and 6 follow Kate Compton's essay So you want to build a generator, which separates free-form algorithms (noise, Voronoi, triangulation) from constrained tile and constraint-solving methods, and warns that the free-form ones are often too uncontrollable for gameplay. Her best-known warning, the "10,000 bowls of oatmeal" problem, is that outputs can be mathematically unique yet feel identical, which is why you judge perceived variety across batches.

Write a seeded terrain generator for [game] in [Three.js], chunked at [64 × 64] m.

Everything derives from one seed through a seeded PRNG. No Math.random anywhere. Same seed, same world, on every machine.
Height: fBm simplex noise ([5] octaves, lacunarity 2, gain 0.5), domain warped, shaped by a curve so plains stay flat and mountains stay rare. Rivers flow downhill from chosen sources to the sea.
Biomes from height and a moisture noise. Vegetation and rocks scattered by Poisson disk sampling with per-biome density. Nothing on slopes over [35]°.
Design hooks: [3] hand-made landmark set pieces placed on suitable flat ground, at least [300] m apart.
Performance: chunk generation under [8] ms in a worker, streamed around the player.
Verify: a contact sheet of 24 seeds as top-down maps, plus per-seed metrics (land %, largest landmass %, biome shares, landmark placement success). Flag any seed outside the target ranges.

Write a seeded [dungeon / cave] generator for [game] that combines algorithms instead of trusting one.

Structure: [BSP rooms and corridors / cellular automata at 45% fill, 4-5 rule, 4 iterations], then flood fill and remove or connect isolated regions. Add [1 to 2] extra corridors to create loops.
Mix in hand-made pieces: [entrance, treasure room, boss room] templates placed by the generator in rooms that fit.
Placement: start and exit at least [60]% of the level's width apart, keys before their locks, enemies scaled by distance from the start.
Metrics from metrics.json: grid sized to the player, corridors at least 2× player width.
Verify: generate 500 seeds and report playable area, path length start to exit, loop count, rejected seeds with reasons, generation time. Render a contact sheet of 24 and flag outliers.

Implement Wave Function Collapse (simple tiled model) for [a town / a dungeon floor] in [Three.js], seeded.

Tileset: [list tiles] with sockets on each edge, rotations generated automatically, weights per tile. Adjacency is derived from sockets, not hand-listed pairs.
Solver: lowest-entropy cell first with seeded tie-breaking, propagation after every collapse, and backtracking on contradiction with a retry cap.
Constraints before solving: fixed tiles for [the plaza, the road entry points], a border of [wall / water].
Post-process: flood fill to confirm every walkable tile connects to the entry, and reject outputs that fail.
Verify: 200 seeds reporting contradiction rate, backtracks, solve time and connectivity. Render a contact sheet of 24 to check the results do not all look alike.

Physics and character controllers

The loop that fixes it

const DT = 1 / 60;               // simulation step, never the frame delta
let acc = 0, prev = performance.now();
function frame(now) {
  let ft = (now - prev) / 1000; prev = now;
  ft = Math.min(ft, 0.25);       // avoid the spiral of death after a stall
  acc += ft;
  while (acc >= DT) { savePrevious(); step(DT); acc -= DT; }
  render(acc / DT);              // alpha: blend previous and current state
  requestAnimationFrame(frame);
}

This is Glenn Fiedler's accumulator from "Fix Your Timestep": clamp the frame time, step in fixed increments, then render a blend of the previous and current state using the leftover fraction.

Pick an engine

Rapier's character controller handles move-and-slide against obstacles, sliding on slopes, climbing stairs automatically (autostep), snapping to the ground when walking downhill, and moving platforms. Its docs show a 45° climb limit and a 30° slide threshold as example settings. One gotcha costs agents hours: a Rapier sensor collider reports nothing until you enable ActiveEvents.COLLISION_EVENTS on it, so pickups and triggers silently never fire.

Controller numbers that define feel

The height-and-time jump derivation is from Kyle Pittman's GDC talk "Math for Game Programmers: Building a Better Jump". The other values are common practitioner starting points. Tune them in a metrics test map.

Build the player controller for [game] with [Rapier / a hand-written kinematic controller] in [Three.js].

Loop: fixed [60 / 120] Hz simulation with an accumulator, frame time clamped to 0.25 s, rendering interpolated between the last two states.
Controller: kinematic capsule [0.4] m radius, [1.8] m tall. Move-and-slide, climb slopes up to [45]°, autostep [0.35] m, snap to ground [0.3] m, ride moving platforms.
Jump defined by height [1.4] m and time to apex [0.38] s (derive gravity and launch speed). Fall gravity [2]×. Early release halves upward speed. Coyote time and jump buffer [100] ms each.
Ground acceleration [0.12] s to top speed [6] m/s, air control [60]%.
All values in one controller.json, with a live tuning panel.
Evidence: measured jump height within 2% of spec at 30, 60 and 144 fps. A replay of recorded inputs gives identical positions. A test map with every step, slope and gap from metrics.json passes.

Camera systems

2D: a vocabulary from Itay Keren's "Scroll Back"

3D third person: what John Nesky warns against

The "don't" list paraphrases items from Nesky's GDC 2014 talk "50 Game Camera Mistakes", given by the camera designer of Journey. The spring-arm pattern is the standard Unreal approach: without a collision test, the camera ends up inside other objects.

Build the camera for [game], a [2D side-scroller / 3D third-person] game. Keep the 2D or the 3D line below and delete the other.

For 2D: camera window [30% × 40%] of the screen, horizontal look-ahead of [20]% in the direction of travel easing over [0.5] s, vertical re-centring only on landing (platform snap), clamped to level edges, optional zone cues for [boss arenas].
For 3D: orbit camera on a spring arm [4.5] m behind and [1.6] m above the character. Sphere-cast from the character to the camera every frame, pull in within 1 frame on a hit and ease out over [0.4] s. Dither-fade objects between camera and character. Pitch follows slope by up to [8]°. FOV [65]°, no walk-cycle bob, no vertical follow during jumps.
Smoothing: framerate-independent exponential damping. Shake and FOV kicks live on a separate juice layer.
Verify: record camera paths through the test level and report frames with the camera inside geometry (target 0), frames where the character is more than [30]% occluded, and peak angular speed. Screenshot every zone transition.

Character animation

The pipeline

1. Rig and clipsA rig from a CC0 pack or a local auto-rigger (below), plus clips from Quaternius, Mixamo or your own
2. RetargetMap bones between skeletons. Check rest pose, root bone and axis orientation first.
3. State machineIdle, walk, run, jump, fall, land, attack, with blend spaces driven by speed
4. BlendCrossfades of about 0.1 to 0.25 s. Playback rate matched to movement speed.
5. IK and look-atFeet on slopes and stairs, hands on ledges and props, head toward points of interest
6. Secondary motionSprings for tails, capes, antennae and hair
7. EventsFootsteps, hit frames and effects fired from clip markers

In three.js, SkeletonUtils.retargetClip maps a clip from a source skeleton to a target, AnimationMixer handles crossfades, and the CCDIKSolver addon does chain IK. Forum reports show retargeting between mixamorig skeletons with different proportions can invert feet and hands, so compare rest poses before trusting the output.

Auto-rigging on your own machine

Hosted riggers (Meshy for textured humanoids, Tripo for creatures) and local learned auto-riggers both give a usable first pass for the skeleton and body weights. Fingers, shoulders and loose clothing are where they break, and nobody has published an independent benchmark, so treat the output as a draft that must pass weight gates before any animation work.

ComfyUI-UniRig (GPL-3.0, last commit 31 Jul 2026) wraps UniRig and Make-It-Animatable and recommends MIA for humanoids. Its one-click installer is marked experimental, open issues report nodes that fail to register on the latest ComfyUI, and UniRig's sparse-convolution dependency has no CUDA 12.8 build yet (the RTX 5090 fix is an unmerged pull request). Test it on your card before relying on it. UniRig's released checkpoint was trained on the smaller dataset, and its authors now point to SkinTokens. Skip RigAnything (Adobe non-commercial licence), Anymate (no code licence), Puppeteer and MagicArticulate (inactive since Sep 2025), and Mixamo and AccuRig, which need an account and have no API. The pass thresholds above are starting values, not published standards. Confidence: moderate, because quality evidence is mostly GitHub issues and the authors' own benchmarks.

Rig [character.glb] for [Three.js / Godot]. Ask first whether a Meshy or Tripo key is set and whether the model may leave this machine.

Type: [humanoid / quadruped / prop]. Hosted: Meshy rigging for textured humanoids (face +Z, under 300k faces), Tripo auto-rig for creatures. Local: Make-It-Animatable v1 for humanoids, directly or through the MIA node in ComfyUI-UniRig, and SkinTokens for creatures. Prop: a bpy script with one bone per rigid part and weight 1.0.
Clean up in Blender: limit to 4 influences per vertex, normalise, remove weights on non-deform bones. Transfer clothing weights from the body with Robust Weight Transfer.
Gates: 0 unweighted vertices, no vertex whose strongest bone is not among its nearest, mirrored weight difference under 0.05, volume loss under [10]% per joint on the extreme-pose sheet (shoulders ±90°, elbows and knees 130°, spine twist 45°, fists), a CC0 walk clip plays cleanly, the GLB passes glTF Validator and re-imports with the same bones and rest pose.
If a humanoid fails twice, switch to Rigify with a fitted metarig and Rigodotify, and say which gate failed.
Log tool, version, licence and gate results in ASSET_MANIFEST.json. Deliver the GLB, the pose contact sheet and the gate report.

Sprite sheets from a video model

An image model drawing frames one at a time makes the character "boil" because identity shifts between frames. A video model animates one image, so identity holds. H3 Max does the animating with a key (24 fps), Wan 2.2 in local ComfyUI without one (16 fps), and the steps below turn its clip into a clean, anchored, looping sprite. sprite-gen now runs the whole chain for walk sets in up to eight directions.

1. Key pose on a safe keyOne still with margin, on a flat key colour far from the subject's hue (green for pink or red, magenta for green, never blue or cyan)
2. Canvas per actionTall 3:4 with about a third headroom for jumps, wide 16:9 with room in front for attacks, tight for idles
3. AnimatePin first and last frame only for idles and one-shot attacks. Walks and runs get an in-place prompt and no end frame. sprite-gen video-prompt prints the prompt text it measured on Grok Imagine, which you can send to any video model.
4. Key every frame the same wayUnmix edge pixels into clean colour plus partial alpha, with one palette per clip, so edges cannot change between frames
5. Find the periodCompare frames on small thumbnails, take the shortest repeat that is nearly as good as the best, and keep every frame of that cycle
6. Hold size, then remove driftA walk with no end frame is held at its first frame's size before the cycle search, then the leftover offset is spread as a ramp (--anchor motion-auto). No frame is snapped to its own feet.
7. Repair and check the loopRIFE remakes up to three jump frames. Then the seam distance must be at most 2× the average frame-to-frame distance, and the report gives a jolt index and any seam pop. Watch the GIF for limb alternation, stalls and snaps.
8. Align the directionsEvery direction of a walk is resampled to one cycle length and starts as the same foot lands. A loop that may hold two strides stops the set until someone counts them.
9. Pack with a manifestOne row per state and a manifest.json with absolute frame rects, fps, durations and loop flags. The engine never guesses a grid.

Most rules here come from sprite-gen (Apache 2.0, v2.35, 6 Oct 2026, more than 20 releases since 26 Sep), whose docs record the measurements: the period search takes the smallest dip within 15% of the deepest, a seam gate of 2.0, a 96-pixel thumbnail distance, rest frames kept on both sides of one-shots, and jolt reference bounds of 0.43 (index) and 0.75% of body height (head step per frame) from 46 judged takes. The jolt is reported, not gated, unless you pass --jolt-max. Most thresholds rest on one or two hand-run sets, so treat them as starting values. Two extras: video-follow adds damped follow-through to a soft part such as a belly or pouch, and a held walk animated on twos below 13 drawings a second is named for a retake. Prompting for a ground line did not fix drift in Scenario's tests either, while alignment in code brought the spread under 1 px. GIF delays round to 10 ms, so preview at 10, 20 or 25 fps and ship frames or the atlas to the engine. Wan 2.2 14B renders at 16 fps and H3 Max at 24, so pass the real frame rate to every tool.

Turn [character.png] into game sprites for [idle, walk, attack] in [side only / 4 directions / 8 directions], with sprite-gen v2.35 or later.

Route: ask me first. Clips come from H3 Max image to video with a fal or OpenRouter key, from sprite-gen's own video command with a SuperGrok login, or from Wan 2.2 in local ComfyUI. Use one source for a whole direction set.
Body: [biped / quadruped / legless]. Pass --body-plan to every command that takes it. One-sided items: [the sword=right hand], passed as --handed. Draw each left-facing view from its own still instead of mirroring, and run sprite-gen handed-check on the loops.
Still and canvas: put the character on a flat [green / magenta] key chosen away from its colours. Run sprite-gen video-canvas --still [still.png] --state [state] --facing [right] for each state (tall for jump, wide for attack).
Prompt: sprite-gen video-prompt --direction [side] --state [state] --facing [right] --json, adding --no-last-frame for walk and run. Send that prompt and the canvas to the video model. Idle and attack also pin the end frame to the canvas.
Per clip: sprite-gen video-frames --clip [clip.mp4] --key [green / magenta] --spill auto --reference [canvas.png], then sprite-gen video-loop --frames-dir [frames/keyed] --state [state] --fps [the fps in frames.report.json] --cycle auto, adding --anchor motion-auto for walk and run.
RIFE: run sprite-gen rife install once, so jump frames get repaired. Without it, loops are cut as filmed with a warning.
Directions: once a walk is cut in every direction, run sprite-gen video-cycle-align with one --loop-dir and one --view per direction (front, side@right, back). If it stops on a suspect loop, look at that loop's frames, count the strides, and rerun with --cycles [loop]=[1 or 2].
QA: read each loop report. Seam at most 2.0, jolt index at most 0.43, no seam_pop warning, or say why the loop is kept. Build a contact sheet and a GIF per state and check limb alternation, stalls and drift. Report walk as experimental unless it passes.
Pack: one row per state with manifest.json (rects, fps, durations, loop flags), plus Aseprite JSON if the target is Phaser.
Log route, model, seed, key, fps and tool versions in ASSET_MANIFEST.json. Deliver the files, then offer the curation view.

Procedural creatures, no clips needed

Build the skeleton from bounding-box fractions so the rig reruns on a new mesh, and weight each vertex by inverse distance to its two nearest bone segments. Headless automatic weighting can silently give zero weights, so count weighted vertices. To check motion, render a phase grid at uneven fractions (0, 0.23, 0.41, 0.68, 0.87), since even steps can alias with the cycle. From Higgsfield's procedural animation reference.

Animate the player character in [game] ([Three.js], glTF rig).

Clips: [idle, walk, run, jump start, fall, land, attack] from [Quaternius / the attached files / Mixamo, which needs an Adobe account and its terms checked]. Retarget with SkeletonUtils to our rig using an explicit bone map, and check rest pose, root bone and axes before trusting the result.
State machine with a speed blend space (idle, walk, run) and crossfades of [0.15] s. Playback rate matches movement speed so feet do not slide.
Two-bone IK for both feet: raycast to the ground, plant and lock feet during contact, lift and step when drift exceeds [0.25] m. Pelvis lowers to the lowest foot on slopes. Head looks at points of interest within [60]°.
Secondary motion: spring-driven [cape / tail].
Clip events trigger footstep sounds and dust by surface type.
Verify: measure foot slide during planted phases (target under [2] cm per step), screenshot every state and transition, walk the stairs and slope test map, and confirm there is no T-pose frame.

VFX that reads

Turn layers off one at a time. Without smoke the impact has no depth. Without the light pulse it floats above the floor. Without shake it has no weight. Most one-shot VFX ship with the core and the sparks only. Shake, hitstop and knockback also belong to the game-juice layer further down, because they answer gameplay, not just the effect.

Lessons from a 100-spell sandbox

Majid Manzarpour's threejs-vfx, built on Achref Elouafi's original sandbox, draws every effect procedurally in Three.js and GLSL, with no textures or sprite sheets. Its README reads like a VFX prompt checklist:

• tune
  Settings are the APIEvery value lives in one settings object that shaders read each frame, so sliders work live and while paused. You tune a frozen mid-impact frame, not a blur.
• straighten
  Store fractions, not metresA cast records only what the dice decided (positions as fractions, a seed). Dimensions resolve from settings every frame, so dragging height regrows a field already standing.
• bolt
  Noise choice is characterLightning uses piecewise-linear noise because the corners are what read as lightning. A beam uses smooth noise stretched along the flow. "A beam that kinks is a bolt."
• layers
  Draw the glow as geometryA soft halo pass under a hot core keeps glow attached to every kink, where leaving it to bloom smears it. Core, sheath and halo weighted differently fake a volume cheaply.
• cloud
  Additive and non-additive on purposeMist is non-additive so it occludes and gives depth. Glitter and sparks are additive. A depth prepass gives soft intersections so nothing cuts a line into the ground.
• speed
  A budget per castRoughly a dozen draw calls per cast, pooled instances, lights parked at zero instead of added, and a check script that fails if moving a slider changes nothing.

Libraries worth naming in prompts: three.quarks (batched particle systems with a visual editor), TSL compute particles on WebGPU (Dan Greenheck's WebGPU skill covers the API), and hand-written GLSL when you want full control.

Build a [fireball impact] VFX in Three.js ([WebGL2 with GLSL / WebGPU with TSL]), fully procedural, no textures or sprite sheets.

Beats: wind-up [0.4 s], travel [0.5 s], impact, linger [1.1 s]. Each beat has its own layers.
Layers: a hot core, a soft glow drawn as real geometry (not left to bloom), sparks as velocity-stretched streaks under gravity, non-additive smoke that occludes, a ground scorch decal that cools and fades, one pooled point light pulse, and a short screen shake with heat distortion on impact.
Motion character: [piecewise-linear kinks for electric / smooth noise stretched along travel for fire and beams].
Soft intersections against scene depth so nothing cuts a hard line into the floor.
All parameters in one settings object with a lil-gui panel. Edits apply while paused so I can tune a frozen frame.
Budget: about [12] draw calls and [1,500] particles per cast, pooled, four concurrent casts at 60 fps on [target device].
Verify: capture a frame at every beat plus a paused mid-impact frame, on a dark and a bright floor. Each layer must be visible and none may blow out to white.

Shaders and post-processing

A pipeline order that works

Tone mapping is supposed to desaturate the brightest colours as it forms the image. A three.js forum answer on tone mapping recommends accepting that and adjusting colours and exposure instead, and notes that ACES shifts hue more than many people want, which is why AgX was added as an option.

Add a post-processing stack to [game] using [pmndrs postprocessing on WebGL / TSL nodes in three.js RenderPipeline on WebGPU].

Order: render in linear HDR, then [SSAO], bloom from pixels above luminance [1.0] at half resolution, [depth of field], tone mapping ([AgX / ACES]), a colour grade (LUT or lift, gamma and gain), then vignette [0.3], grain [0.04] and chromatic aberration [0.0015], then sRGB output and SMAA.
Merge effects into as few passes as possible. Bloom, AO and blur at half resolution.
Exposure and every effect strength in one settings object with a tuning panel, plus a per-effect on and off toggle.
Budget: the whole stack under [2.5] ms GPU at 1440p on [target device].
Verify: screenshots with each effect isolated and all combined, a luminance histogram to confirm nothing important clips, and a GPU timing per pass.

Sound and music from code

Pick the right tool

The listening loop

This is the audio version of screenshot verification. Community tools already do it: strudel-ai renders patterns to WAV and returns a "hearing" report with spectrogram, envelopes, onsets and estimated BPM, and several Strudel MCP servers let Claude compose and play in the REPL. Without the loop, "make it sound punchy" is a guess.

Game mix and local generation

Levels from Higgsfield's game-audio reference, which gives peak levels rather than loudness, so treat them as starting points. With a key, ElevenLabs covers voices, effects and music with stems (see Generating assets). Locally, MiniMax Music 3 or ACE-Step 1.5 XL (MIT) write music with lyrics and section tags such as [Chorus - soft], and Fish Audio S2 Pro, or Chatterbox Multilingual for shipped work, handles voices. For video set to a supplied track, measure beats and onsets with librosa (ISC) first (see Coded video).

Create the sound effects for [game] in code with [ZzFX / Web Audio], no audio files: [jump, coin, hit, UI click, footsteps on grass and on stone].

For each sound, define the layers (transient, body, tail), the envelope in milliseconds, the pitch movement, and one feeling word ("dry and tight", "heavy and dull").
Variation: ±[5]% pitch and 3 to 5 variants for anything that repeats, so it never machine-guns.
Mix: true peak at −3 dBTP or lower, UI quieter than gameplay, footsteps quietest. Start the AudioContext on the first input, add an [M] mute key, and pan sounds to their on-screen position.
You cannot hear, so verify with numbers: render every sound with OfflineAudioContext, write WAVs, and report peak, RMS, duration, spectral centroid and a spectrogram image for each. Fix clipping, long tails, and sounds that share a band with something that plays at the same time.

Compose an adaptive music loop for [scene] in [Tone.js / Strudel].

Key [D minor], [84] BPM, 4/4, exactly [32] bars ([91.4] s), restarting on a bar line.
Intensity layers: 0 pads and texture, 1 adds bass and soft percussion, 2 adds the melody, 3 adds full drums. Layers crossfade over one bar.
Palette: [warm tape-saturated keys, vinyl crackle, brushed drums]. Avoid [bright supersaws, four-on-the-floor kick].
Render each intensity offline to WAV. Report integrated loudness (target around [−16] LUFS), true peak, a spectrogram, and a zoom on the seam from the last bar into the first. Fix any click or level jump at the loop point.
If you use Strudel (AGPL), render every layer to audio files and ship those. Never ship Strudel itself in closed-source work.

Timing maths to keep in the prompt: bars × 4 × 60 ÷ BPM = seconds. For a video loop, pick BPM so the music loop length equals the visual loop (60 s at 120 BPM is exactly 30 bars).

Game juice

Borrow Feel's vocabulary

More Mountains' Feel is a Unity asset, but its model is the clearest way to describe juice to any engine, including a Three.js or Canvas build. One player component holds a list of feedbacks, and each feedback does exactly one thing: a sound, a flash, a camera shake.

Starting numbers

The numbers are practitioner starting points, not rules. The shake model comes from Squirrel Eiserloh's GDC talk Juicing Your Cameras With Math: trauma decays over time, displacement is trauma squared driven by smooth noise, and the camera's real transform is untouched for gameplay. The canonical demos are Martin Jonasson and Petri Purho's Juice it or lose it and Jan Willem Nijman's The Art of Screenshake.

Do a juice pass on the existing game. Do not change any mechanic, speed, damage or collision.

Structure: one feedback player per event ([jump, land, hit, get hit, pickup, death, UI confirm]). Each player holds a list of single-purpose feedbacks, plays them in parallel unless a pause is listed, and accepts an intensity from 0 to 1 that scales every feedback.
Hit, at intensity = damage ÷ max damage: hitstop [40 to 100] ms of simulation time, target flash for [3] frames, squash spring on the target ([5] Hz, damping [0.4], volume preserved), knockback spring along the hit direction, a spark burst, a layered hit sound with ±5% pitch, and camera trauma +[0.3 × intensity].
Camera shake: trauma model, displacement = trauma² × max offset ([12] px, [3]° roll) driven by smooth noise, trauma decays at [1] per second. Offset only the render camera, never the gameplay transform.
Land: dust puff, squash on contact, a soft thump. Pickup: pop scale, a rising two-note chime, a number that springs in.
Everything runs on the game clock, so pause, hitstop and slow motion affect it. Cap particles and cooldown every feedback against spam.
Settings: one juice object with every value exposed, plus "reduce screen shake" and "reduce flashing" toggles, defaulting to reduced when prefers-reduced-motion is set.
Verify: record the same 10-second input sequence with juice off and on, capture frames at each event, and list every feedback that fired with its measured duration.

Does anime.js help?

Anime.js v4 is a modular, MIT-licensed engine: timelines, stagger, springs, draggable, a scroll observer, SVG morphing, line drawing and motion paths, with every module importable on its own (about 24.5 KB with everything). It animates plain JavaScript objects too, so a Three.js camera position or a shader uniform is a valid target. Version 4.5 (Jun 2026) adds a Three.js adapter for objects, materials, lights and cameras. A v5 beta exists, so pin 4.x in prompts.

// 1. Drive anime.js from the game or Three.js loop, so pause and hitstop apply to tweens
import { engine, animate } from 'animejs';
engine.useDefaultMainLoop = false;
renderer.setAnimationLoop(() => {
  if (!hitstopActive) engine.update();
  renderer.render(scene, camera);
});
animate(camera.position, { z: 6, duration: 600, ease: 'outElastic(1, .6)' });

// 2. Frame-exact video export: build a paused timeline, then seek per frame
import { createTimeline, stagger } from 'animejs';
const tl = createTimeline({ autoplay: false })
  .add('.title span', { y: [40, 0], opacity: [0, 1], delay: stagger(30) })
  .add('.logo', { scale: [0.8, 1], ease: 'outElastic(1, .6)' }, '-=200');
for (let f = 0; f < 15 * 60; f++) { tl.seek(f * 1000 / 60); await captureFrame(f); }

Both patterns follow the anime.js v4 docs: engine.useDefaultMainLoop and engine.update() exist for integrating with Three.js or game loops, and timelines expose seek(). If a prompt names anime.js for a single-file build, ask for the module inlined at a pinned version, with no CDN at runtime.

UI, HUD and accessibility

Start with the basic tier

The four top complaints and the FOV default come from the Game Accessibility Guidelines' basic tier. Xbox Accessibility Guideline 101 adds that text settings must carry over to every important text surface, including error dialogs. For web games, a practical target is WCAG 2.1 AA for menus, with reasonable accessibility for gameplay itself.

HUD design

Design and build the UI, HUD and accessibility settings for [game].

HUD: health, [ammo / stamina], objective and interaction prompts, in a title-safe area, scaled with resolution. Every state uses colour plus shape, icon or text. Prompts switch between keyboard and gamepad glyphs based on the last input used.
Menus in DOM overlays, fully usable by keyboard, gamepad and screen reader.
Settings, applied before the first sound or cutscene: remap every action, text size (at least 3 steps) applied to all text, subtitles on by default with speaker names, a solid background and captions for important sounds, colour-blind safe palette check, difficulty, reduce screen shake, reduce flashing, motion blur off, FOV slider [60 to 100]°. Honour prefers-reduced-motion.
Verify: screenshots of the HUD under deuteranopia, protanopia and tritanopia simulation plus greyscale, every menu navigated with keyboard only, subtitles readable at 360 px wide, and every action remapped once.

Coded video: frameworks and determinism

Which framework?

Remotion's free licence covers individuals, non-profits and for-profit companies with up to three employees, and a larger company needs a paid company licence. Some blogs quote a revenue threshold instead, so check Remotion's own licence page before relying on either. Above that size, assume the company licence.

Ideas worth stealing, whichever tool you use

• schedule
  Every animation is seekableHyperFrames renders by seeking each frame in headless Chrome and encoding with FFmpeg, so the same input gives the same video. Its adapters make library-clock animations (GSAP, anime.js) frame-accurate.
• route
  A router skill that confirms the brief/hyperframes reads first, confirms the creation brief, then loads one workflow (product launch, explainer, music-to-video, motion graphic) and only the domain skills it needs.
• palette
  A design system rewritten for the cameraframe.md translates a web design.md for video, so the agent stops guessing at scale and stops reaching for web chrome like navbars and cards.
• fact_check
  Lint and snapshot before renderCheck the composition, render stills at named timestamps, look at them, then render the whole thing. The community Remotion skill enforces the same render, inspect frames, fix, re-render loop.
• widgets
  Blocks before hand-buildingTransitions, captions, charts and overlays come from a catalogue first. Hand-built only when nothing fits.
• menu_book
  Docs lookup instead of memoryRemotion ships a docs skill so the agent fetches the current API rather than recalling an older version.

Shot planning and continuity

From the shot-planning, cinematography and storyboard skills in the fal and Scenario packs. Chained shots use first and last frame: H3 Max with a key, Wan 2.2 locally. SeedVR2 upscales the result.

From a one-liner to a studio

After the Opus 5.5 launch, coded-video posts said "one prompt". The strongest ones used briefs of 9,500 to 19,000 characters, skills, API keys and runs of up to 12 hours, and one watercolour short openly took 163 model calls over about seven hours. The prompt is a small part of the result. The rest is the harness: a seek(t) renderer, a reference, a beat grid and a loop where the model watches its own frames.

1. One-liner"A 15-second showreel, go all out" tests your setup. Many people reused it, so the reels rhyme. It contains no idea.
2. Brand reelGive the product URL. The agent captures real screenshots, logo, colours and fonts into ./assets, lists them, and never redraws the UI from imagination.
3. ReferenceOne frame, a clip (a frame every 0.5 s) or your own image library becomes style_guide.md and shotlist.md. Take the grammar, never the content.
4. State-list specTagged blocks for inputs, direction, structure, build rules and gotchas. One element morphs through 8 to 12 states on a beat grid.
5. Director's briefLogline, references, tools and budget, character bible, beat sheet, text rules, gated workflow, critique loop, deliverables

From Movez's course on the Opus 5.5 motion trend (27 Sep 2026), which collects the posts behind it, and the example repos listed below. The effort levels, character counts and hours are creator-reported, not measured.

// Damped spring from 0 to 1 as a pure function of time, so seek(t) stays deterministic.
export function spring(t, k = 170, c = 26) {
  if (t <= 0) return 0;
  const w = Math.sqrt(k), z = c / (2 * w);
  if (z >= 1) return 1 - Math.exp(-w * t) * (1 + w * t);   // treat overdamped as critical
  const wd = w * Math.sqrt(1 - z * z);
  return 1 - Math.exp(-z * w * t) * (Math.cos(wd * t) + (z * w / wd) * Math.sin(wd * t));
}

// A value that changes target over time: one spring per change, summed.
export function track(t, keys, k, c) {            // keys: [[time, value], ...] sorted by time
  let v = keys[0][1];
  for (let i = 1; i < keys.length; i++) v += (keys[i][1] - keys[i - 1][1]) * spring(t - keys[i][0], k, c);
  return v;
}

// Render 4 subframes per frame, then blend them into 60 fps with motion blur:
// ffmpeg -framerate 240 -i frames/%06d.png -vf "tmix=frames=4,select='eq(mod(n\,4)\,3)',setpts=N/60/TB" -r 60 -c:v libx264 -pix_fmt yuv420p out.mp4

Make it watch its own frames

# Contact sheet: 2 frames per second, 6 across
ffmpeg -i out/final.mp4 -vf "fps=2,scale=270:-1,tile=6x5" -frames:v 1 out/contact.png
# Strip of 12 consecutive frames around a fast move at 4.1 s (pops, overlaps)
ffmpeg -ss 4.1 -i out/final.mp4 -vf "scale=320:-1,tile=12x1" -frames:v 1 out/strip.png
# Phone test: how it reads at 360 px wide
ffmpeg -i out/final.mp4 -vf "fps=1,scale=360:-1,tile=5x3" -frames:v 1 out/phone.png
# Loop check: play it twice and watch the seam
ffmpeg -stream_loop 1 -i out/final.mp4 -c copy out/loop_check.mp4
# Determinism: render twice, hash every frame, and diff (no output means identical)
ffmpeg -i out/final.mp4 -f framemd5 out/run1.md5
ffmpeg -i out/final_rerun.mp4 -f framemd5 out/run2.md5
diff out/run1.md5 out/run2.md5

Then ask for a harsh director, not a proud author: score the hook in the first 2 s, readability at phone size, motion (springs, no dead frames), variety (something new every 2 to 4 s), composition, brand accuracy and sound sync from 1 to 10. List the three worst problems with timestamps, fix them, re-render only the affected seconds, and repeat until every score is 8 or more or three rounds have passed. Hunt for text overlapping during swaps, anything sliding instead of easing, corner labels and frame borders, centred-on-gradient shots, blurry scaled text, dead beats and a stutter at the loop seam.

Narrated explainers

From Deedy Das's workflow post (29 Sep 2026), which uses hosted models for keyframes, video, voice and music. The picks in Generating assets fit it: GPT Image 2.5 for keyframes, H3 Max or Gemini Omni Flash for shots, ElevenLabs for voice and music, with the local picks as the fallback.

# Motion studio rules

Render: every film is a pure function of time. window.seek(t) paints frame t. No CSS transitions, timers or requestAnimationFrame in render mode, no state carried between frames, seeded noise only. Render with the named framework's own renderer (the HyperFrames or Remotion CLI), or Playwright for a seek(t) page. Encode H.264 yuv420p.
Framework: [single file with seek(t) / HyperFrames / Remotion]. Use only the one named here.
Look: one display face, one UI face, [one accent colour]. Something new on screen every 2 to 4 s. Banned: centred title on a gradient, everything fading in, corner labels and frame borders, glow on UI chrome, generic particle bursts.
Motion: closed-form springs from lib/motion.js. At most 8% overshoot on UI, none on large type. Any value with more than one target uses track().
Sound: synthesise score and effects unless a track is supplied. If one is, measure it into beats.json first and put hits on it. Deliver the social master at −14 LUFS and −1 dBTP.
Before showing me anything: render a contact sheet at one frame per beat, score it on hook, phone readability, motion, variety, composition, brand and sync, fix the three worst problems, and repeat until every score is 8 or more or after [3] rounds. List what is still under 8, then render the full film.

Using /hyperframes, make a [30]-second [product launch / explainer] video for [subject], [1920×1080] at [30] fps.

Confirm the brief with me in one message first: audience, the one idea to land, tone, and whether there is narration or music.
Design: build frame.md from [our design.md / these tokens: colours, two typefaces], sized for the frame, with title safe areas. No web chrome.
Structure: scenes with data-start and data-duration on a [120] BPM beat grid. Hook in the first [2] s.
Motion: GSAP or anime.js timelines only, registered as seekable. No Date.now, no unseeded random, no free-running CSS animation or video.
Use catalogue blocks for transitions, captions and charts before building any by hand.
Loop: lint, check, snapshot stills at every scene start and every beat accent, look at them against the brief, fix, then render.
Deliver the MP4, the snapshot sheet, and a list of anything you invented rather than took from the brief.

Use /remotion-best-practices. Create a Remotion composition for a [30]-second [explainer] at [1920×1080], [30] fps.

Check current APIs with /remotion-docs before using anything you are not sure of.
Every visual value derives from the current frame (interpolate, spring). Nothing reads wall-clock time.
Scenes as Sequences with durations in frames: [hook 60, problem 150, solution 390, CTA 300].
Audio: [music.mp3] trimmed to the composition, volume ducked under [voiceover.mp3]. Captions word-synced from the transcript.
Props validated with a Zod schema so [headline, stats, colour] can change per render.
Loop: render stills at the start of every Sequence, inspect them, fix, then render the MP4.
Licence note: confirm our company licence covers this before it ships.

Build a [15]-second motion piece as one HTML file whose entire state is a function seek(t), with t in seconds.

No requestAnimationFrame timing in the render path, no Date.now, randomness from a seeded generator, fonts awaited before t = 0.
A preview mode plays seek(performance time) in the browser. An export mode is driven by a Playwright script that calls seek(frame / [60]) for every frame, screenshots the canvas at [1920×1080], and pipes the frames to FFmpeg (H.264, yuv420p, [60] fps).
If you use anime.js or GSAP, build one paused timeline and call its seek() inside seek(t).
Motion blur: capture [4] subframes per frame and blend them with FFmpeg's tmix filter.
Verify: export twice and compare per-frame hashes (ffmpeg -f framemd5), then build a contact sheet every 0.5 s, a strip around the fastest move and a 360 px phone sheet, and fix what they show.

Make a [20]-second motion graphics film for [product] ([URL]) paced like a motion designer's showreel: something new on screen every 2 to 4 s.

Assets first: visit the site with Playwright, capture real screenshots, the logo, colours and fonts into ./assets, and list what you found before animating. Crop and animate the real UI, never redraw it from imagination.
Story, one beat each of 2 to 4 s: the problem in [5] words of large kinetic type, the product assembling itself, three features as real UI actions driven by a cursor, one proof number ([metric]), logo and [call to action].
Sound: original music at [120] BPM, synthesised in code, UI clicks and whooshes on the beat.
Formats: [1080×1920] first, then 1:1 and 16:9 from the same timeline, reframed rather than cropped.
Follow the studio rules in CLAUDE.md if the project has them. Show me a contact sheet of one frame per beat before the full render.
Done when all three formats render and every beat on the contact sheet shows real product UI.

<inputs>
Ask me for: product and URL, [8 to 12] UI states that tell its story, the real data in each state, brand colours, fonts and one accent, a track near [120] BPM, formats.
</inputs>
<direction>
Product-film UI motion. One container never cuts: each state is the same element changing size, radius and fill while its content swaps. A cursor drives every change. [Warm neutral] canvas, one accent, springs with at most 8% overshoot. Banned: bouncy easing, glows, gradients on UI chrome, particle bursts, dead time.
</direction>
<structure>
[120] BPM, [8] bars, something happens on every beat: [logo → button → typed field → loader → success → dashboard card → chart → tooltip → command palette → toast → logo].
</structure>
<build>
One HTML file, window.seek(t), closed-form springs with one spring per target change. Text enters after a morph starts and leaves before the next. Beats measured from the track. 60 fps with 4 blended subframes.
</build>
<gotchas>
No will-change on anything the camera scales. The last frame equals the first, cursor position and velocity included.
</gotchas>
Ask for the inputs, then show me the state list on the beat grid before writing code.

You are the director, animator, sound designer and render engineer for a [duration] film made in code. This is a multi-session production. Do not rush to a final render.

Film in one line: [logline, and what the viewer should feel at the end].
References: ./refs/ [video, frames or image library]. Take the grammar, never the content. ./audio/track.wav is used unchanged and measured into beats.json first.
Tools: [skills available]. Generated media: ask which route first (hosted with my keys, or local ComfyUI), then use the picks in the guide and log each one. Budget: [time or turns].
Character bible: proportions, palette, expressions, and an identity that survives every style change.
Beat sheet: a hook in the first 2 s, a visual payoff every 3 to 5 s, and a last frame that sets up the first.
Text on screen: when lines go huge and when they sit like subtitles. Leave room for them in every composition.
Gates, in order: style_guide.md and shotlist.md, stills and a contact sheet for every shot, a 960×540 animatic, full animation, polish, sound, final render. Write ANIMATION_GUIDE.md before splitting chapters across subagents.
Critique every shot for up to [3] rounds: score hook, phone readability, motion, composition, depth, sync and polish, log the three worst problems in docs/review_log.md, and fix them. Stop when every score is 8 or more or after round [3], then list what is still under 8.
Deliver: out/final.mp4, out/loop_check.mp4, out/poster.png, out/contact.png and a README.

Make a [4]-minute [16:9] explainer about [topic] for [audience], in [style].

Plan first: script.md (narration only), shotlist.md (each line mapped to a shot and a technique: HyperFrames, Motion Canvas, Manim or a generated shot), and reference images for recurring elements. Show me both files and wait for my go-ahead.
Narration: a calm expert, "like a university professor". No short punchy sentence runs, no stacks of numbers, about [2 to 2.5] words per second. Voice with ElevenLabs v4 if a key is set, otherwise locally with [Fish Audio S2 Pro for internal cuts / Chatterbox Multilingual if it ships].
Animatic at low resolution with the rough voice before any full render. Fix pacing there.
Assemble the edit as an OpenTimelineIO timeline and render with FFmpeg. Music bed from ElevenLabs Music or, locally, [MiniMax Music 3 / ACE-Step 1.5 XL], ducked 12 to 18 dB under the voice.
Captions: run faster-whisper on the final mix for word-level timings, 3 to 5 words per cue.
Critic: compare the transcript with script.md, and screenshots at every shot change with shotlist.md. Fix mismatches before delivering.
Footage: only clips I supply or whose licence you log in ASSET_MANIFEST.json.
Deliver: final.mp4, captions.srt, script.md, shotlist.md and ASSET_MANIFEST.json. Stop after the critic pass and list any mismatch still open.

Performance and profiling

Tools

Symptom to cause

Starting budgets per device

These are threejs-game-skills' defaults, a starting point to measure against rather than a law. Post-effect cost grows with the square of the pixel ratio, so a DPR of 2 costs four times a DPR of 1. Two habits from recent builds: give each costly subsystem a URL kill switch (Tidewater uses ?noClouds&noVeg) so the agent can bisect frame cost, and run a fast-forward soak test where geometry and texture counts stay flat (one Opus 5.5 demo held a 16 to 26 MB heap over 320 s of play). Sharing one material between objects that look the same is often the easiest win. WebGPU helps most in draw-call-heavy and compute-heavy scenes, but forum users report scenes where it is slower than WebGL 2, so profile before migrating for speed.

GPU compute, only when it pays

Three.js TSL exposes compute shaders with storage buffers, workgroupArray shared memory, workgroupBarrier, atomics and subgroup operations. Use them for large parallel workloads such as particles, simulation or culling, and measure the workgroup size and memory layout on target hardware instead of assuming. Advanced compute (atomics, workgroup memory, indirect draws) is WebGPU-only and plain compute is only partly supported on the WebGL 2 fallback, so a project that ships both needs a reduced path, feature-gated and tested separately.

WebGPU status, Sep 2026: on by default in Chrome and Edge on Windows, macOS and ChromeOS, Safari 26 on every Apple platform, and Firefox 141+ on Windows and 145+ on Apple Silicon Macs. Linux browsers and Firefox on Android still need the fallback. three.js r186 (Sep 2026) adds a TSL Gaussian-splat renderer and loader with glTF import, compileComputeAsync(), a SunLight with cascaded shadows and Object3D.dispose(). It also removes the minified builds and deprecates CommonJS, so single-file prompts should inline the ES module build at a pinned version.

Profile and optimise [project] without visible quality loss.

Benchmark: a fixed [30] s camera path through the heaviest area, run 3 times. Record average, p95 and p99 frame time, draw calls, triangles, GPU time per pass (stats-gl or timestamp queries), and geometry and texture counts.
Quality guard: capture [8] reference frames on the path before changes. After each change, the per-pixel difference must stay under [1]% (report the metric).
Work order: fix the single largest cost first, then re-measure. Try in this order unless the profile says otherwise: shared materials, pixel ratio cap, instancing or batching, texture compression (KTX2) and mesh compression (meshopt or Draco), shadow map size and cascades, LODs with dithered cross-fade, baked lighting, dynamic resolution.
Log every change with before and after numbers in perf-log.md.
Stop after [5] consecutive changes that each improve p95 frame time by less than [5]%, then write a short report.

Iterate like a director

The feedback formula

These rewrites come from a real ocean-simulation thread. The originals worked for a human who could see the screen. The rewrites give the model the same view.

Two notes from that thread already work well and are worth copying: asking it to research first ("look up how waves crash in real life") and pointing at a named reference ("look at the three.js water pro folder for bow spray"). Research and references turn taste into something checkable.

The target-image loop

1. ScreenshotCapture the current build at the target size
2. Edit it into the targetAn edit model (GPT Image 2.5 Sunburst, or Qwen-Image-Edit-2511 locally) repaints the screenshot into the look you want, keeping layout and content
3. Write the specA vision pass opens with "Hard constraints": numbered imperatives with numbers, plus a tokens file for colours, type and spacing
4. Build, then diffRe-screenshot and write 10 to 30 measurable fixes, biggest first: type scale, density, colours, components. Skip what already matches.

Adapted from fal's redesign skill, where the edited image is the spec. Edit models still render small text less reliably than code, so keep final text out of the target image and set it in code.

When something breaks

1. Read the evidenceConsole, screenshots, profiler, the failing test
2. Search firstDocs, release notes and issue trackers, when the cause is not obvious
3. One hypothesisThe strongest explanation the evidence supports
4. Smallest discriminating testOne run that could prove the hypothesis wrong
5. Fix the causeThen run the checks the change could affect
6. Two strikesIf two similar fixes fail, question the assumption, the library or the approach

Evidence that counts

From claude-code-game-builder (MIT, a packaging of Matt Shumer's Gauntlet Loop with Sonnet 5.5 building and Opus 5.5 critiquing), the visual-validation skill in linegel's three.js skill set (ISC, 27 WebGPU and TSL skills) and threejs-game-skills (MIT). All three are days to months old with little outside testing, so treat the numbers as starting points. Moderate

Multi-session builds

Every session, in order

1. Read progress.md, the git log and features.json
2. Run init.sh and the smoke tests. Fix anything broken before starting new work.
3. Pick one failing feature
4. Build it, then test it end to end in a real browser, with screenshots for visual features
5. Compare against golden screenshots and the perf baseline
6. Mark it passing only with evidence, commit, and update progress.md

Anthropic's March 2026 harness-design post adds a separate evaluator agent that clicks through the running app with Playwright MCP and scores four criteria: design quality, originality, craft and functionality. For creative builds, point such an evaluator at taste and leave correctness to tests. It found that a fresh context with a structured handoff beat compaction, and that the evaluator needs its own prompt tuning. The base pattern is Anthropic's harness for long-running agents: an initialiser session sets up the feature list, the progress file, init.sh and the git repository, then each coding session works on one feature at a time, tests end to end with browser automation, commits and leaves notes. For creative builds, add golden screenshots and performance baselines to the feature list, and split roles when it helps: a builder session implements, a reviewer session only critiques against the art bible and budgets.

This is the first session of a multi-session build of [project]. Do not build features yet. Set up the project so future sessions can work reliably.

Create features.json: every feature from the brief as a small, testable item with id, description, acceptance check (how to verify, including which screenshot or metric), and "status": "failing". Include art bible checks, performance budget checks and accessibility checks as features too.
Create progress.md with the goal, the current state, and "next: [first feature]".
Create init.sh that installs dependencies, starts the dev server and runs smoke tests.
Create golden/ with the style frame and an empty perf baseline.
Initialise git and commit.
Put stable rules in CLAUDE.md: link to art-bible.md and metrics.json, the frame budget, the stop rule, and "only mark a feature passing with evidence".

Continue the build of [project].

Start: read progress.md, the last 20 git commits and features.json. Run init.sh and the smoke tests. If anything is broken, fix that first.
Pick the highest-priority failing feature. Work on that one only.
Build it, run it in a real browser, and check it against its acceptance check with screenshots or metrics saved under evidence/[run id]. Compare against golden/ and the perf baseline.
Mark it passing only if the evidence shows it. Commit with a clear message and update progress.md (done, next, blocked).
Keep going to the next feature until [the time budget / N features] is used, then stop with a short summary. Never edit acceptance checks to make a feature pass. Never resubmit a paid or long job whose result is uncertain: check its status first.

The build contract

Ideas worth keeping in every contract

Tune per model

Sources: Anthropic's Opus 5.5 prompting guide (unattended runs, time signals, and the note that Opus 5 patterns remain a reasonable starting point), the Opus 5 guide and release notes (subagent caps, over-verification), Anthropic's Sonnet 5.5 guide (extra review rounds, real checks at low effort), and OpenAI's GPT-6 guide (initiative and follow-through, approval after a reviewable result, skills precedence, delegation, test calibration). In Claude Code the subagent caps are the CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH and CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS environment variables.

# How to work in this repository

Scope: sort each brief into what was asked, what it needs to work well, and optional extras. Build the first two. List the extras you skipped.
Autonomy: work end to end without presenting plans or asking approval for reversible decisions. Ask only when blocked by missing credentials, an irreversible or external action, or an ambiguity that would produce a different product. When approval is needed, finish everything else first so I approve a concrete result. When the brief names a checkpoint ("show me", "stop there"), stop at it. The brief wins over this file.
Reuse: before building a subsystem, check in order: what this project already has, official three.js or browser features, a maintained library, a focused open-source component, an adapted reference, then custom code. Record each dependency, version and licence in THIRD_PARTY.md.
Debugging: when something fails, check docs and issue trackers for known causes, form the strongest hypothesis, and run the smallest test that could prove it wrong. If two similar fixes fail, question the assumption instead of patching again.
Architecture: replace or refactor code when evidence shows it limits correctness, quality or performance. Prefer the smallest change that fixes the cause. Delete the replaced path.
Rendering: choose WebGPU or WebGL by measured need. Feature-gate WebGPU-only work (advanced compute such as atomics and workgroup memory has no WebGL fallback) and test both paths when both ship.
Honesty: no stubs, placeholder features or fake integrations. Never hard-code behaviour for known tests or weaken a valid test to make it pass.
Memory: keep progress.md committed (goal, done, next, blocked, latest evidence). Recover from it after an interruption.
Done: the completion condition in the brief holds in the running build, checked after the last meaningful change.
Quality gaps: for feel and visuals, compare the running build with the brief's reference and fix the largest remaining gap. Stop when the remaining gaps are small or matters of taste, or after [3] passes.
Never without explicit permission: deploy, publish, purchase, change external accounts, delete remote data.
Report: result, what was built, key decisions, evidence (numbers and screenshots), real limitations, changed areas. Keep it short.

Use subagents only for large, independent tracks such as a wide investigation or a separate subsystem. Do not use them to double-check your own work. If one agent can do it, use one.
Put status notes in the same message as your next action. The stops I want: nothing can move without me, or the next step is destructive or irreversible.

When the work I asked for is done and its checks pass, stop and report. Don't start extra rounds of review or hardening on your own, and don't launch reviewer sub-agents unless I asked for a review. If you think a deeper review is worth doing, say so at the end.
When you change code that can be run, built or type-checked, run a real check that exercises the change before reporting it done: the tests, the type-checker, the build, or the changed command itself. A syntax-only check does not count. If no real check can run here, say which one you did not run and why.

Infer intent and scope from the brief and the repository, bias towards action, and persist until the goal is met or [the turn budget] runs out. Treat "can you" and "I want" as instructions to do the work, not to propose a plan.
When work can run in parallel and that saves time or improves quality, delegate it to subagents.
The brief takes precedence over skills and AGENTS.md. If a skill makes you pause or ask permission, name the file and quote the line.
Run the tests each change needs. Broaden or repeat testing only when new changes or failures justify it.

Effort and long runs

Keep unattended builds running

Opus 5.5 posts progress as it works, and some of those updates end the turn with text instead of a tool call. A harness that treats that as "done" stops with work left. On the API those notes arrive as thinking blocks that are empty by default, so a text-only client looks silent. Set display: "updates" (beta) to see them, and after about five silent steps add a turn-scoped reminder to report. Anthropic's fix for early stops is to name the ones you do not want:

Keep going through every step that does not need me, and put status notes in the same message as your next action. Stop only when you cannot continue without my input, or before anything destructive. The task is done when [all four screenshots pass the checklist and the console is clean], or after [30] turns, whichever comes first. If you stop early, say which item is still open and what blocks it.

Which model, and what to add

Confidence: High for release dates, defaults and prices, taken from Anthropic and OpenAI docs. Moderate for community tricks, which are creator-reported and not independently reproduced. Low for GPT-6.1 Sol's habits, which rest on a few early practitioner reports.

Eight prompt shapes

Bars are a rough split of each prompt's words across the nine layers, meant for comparison, not measurement.

Techniques worth stealing

• image
  Reference image firstEarly Astra testers got their best 3D scenes by generating concept art first, then asking the model to match it in code.
• map
  Area by area with an evaluation listMatt Shumer's Manhattan build worked district by district, refining each against a checklist before moving on. His Gauntlet Loop adds a separate harsh critic per piece.
• groups
  Cheap builder, strong criticclaude-code-game-builder runs Sonnet 5.5 as the builder and Opus 5.5 as a blind critic that compares unlabelled pairs against the reference.
• travel_explore
  One sentence plus researchSingle-sentence Opus 5.5 game prompts worked when the model researched the real map layout and the original controls before writing code. Opus 5.5 demo list
• crop
  Give it a crop toolFor dense screenshots, charts and UV layouts, a crop or zoom tool beat raw effort in Anthropic's Sonnet 5.5 tests.
• sports_esports
  The one-shot game checklistTheo's widely shared brief asks for a readable objective, responsive controls, coherent levels, hazards, feedback, scoring, restart and performance safeguards. awesome-astra-prompts

Traps and what to write instead

Pre-send checklist

Sources

• Prompting Claude Opus 5.5Anthropic docs. Effort, early stops, progress updates, design defaults, visual inputs.
• Prompting best practicesAnthropic docs. Clarity, context, examples, XML structure, verification tools.
• Opus 5.5 best practices for Claude CodeCommunity guide (ClaudeFast), drawing on Addy Osmani's playbook. /goal, effort per task, what to delete.
• Using GPT-6 AstraOpenAI docs. Initiative, delegation, testing behaviour.
• OpenAI's Astra prompting tipsThe Decoder. Clarifying questions, bias to action, word blocklist.
• awesome-astra-promptsTripo. 150+ community Astra prompts with previews and sources.
• awesome-claude-opus-5-5-demosMagicCreator. Games, coded films, 3D, with creator attributions.
• img2threejsReference image to procedural Three.js model through staged, gated passes.
• blender-game-skillsMajid Manzarpour. Concept art to rigged game assets with measured gates.
• threejs-vfxMajid Manzarpour, built on Achref Elouafi's sandbox. 100 procedural spells and the techniques behind them.
• three.quarksBatched particle and VFX engine for Three.js, with an editor.
• threenative-asset-mcpLicence-aware asset search across Poly Haven, ambientCG, Sketchfab and audio libraries.
• 3DTilesRendererJSNASA-AMMOS. 3D Tiles in Three.js, including Google Photorealistic Tiles with your key.
• ZzFXFrank Force. MIT sound-effect synth under 1 KB.
• Using Strudel in your projectStrudel docs. The AGPL-3.0 obligations in plain words.
• live-coding-music-mcpMCP server that lets Claude compose and play in Strudel.
• scenario-labs/skillsScenario. Consistency ladder, refine loop, sprite alignment, orbit views, storyboard pose chains.
• higgsfield-ai/skillsHiggsfield. Style formula, video-to-sprite pipeline, image-to-3D input rules, texture seams, game audio levels.
• fal-ai-community/skillsfal. Character anchors, pipeline patterns, shot language, the redesign target-image loop.
• Comfy-Org/comfy-skillsComfy. Cloud-only skills with steering rules worth copying for local use.
• Comfy CLIComfy. Drives a local server with no account, or the cloud when signed in.
• MiniMax H3 Community LicenceMiniMax. Territory exclusions, $20M threshold, display requirement.
• Qwen-ImageQwen. Open image generation and editing models under Apache 2.0.
• TRELLIS.2 and Pixal3D in ComfyUIComfy, 31 Aug 2026. Commercial use without the NVIDIA research dependencies.
• ACE-Step 1.5MIT-licensed local music generation, XL since Apr 2026.
• Hunyuan3D 2.1 licenceTencent. Excludes the EU, UK and South Korea.
• Which Wan versions are openAtlas Cloud. Only 2.1 and 2.2 have open weights, under Apache 2.0.
• Qwen-Image 2.1 licenceQwen Research License. Non-commercial use only.
• Minimax-H3-TurboLightX2V. Community 4 to 8 step distillation for MiniMax H3.
• Poly Haven licenceCC0 for every asset, with a public API.
• Blendkit licencesCC0 and Royalty Free, and the no-resale rule.
• Goodbye BlenderKit, hello BlendkitThe rename, 23 June 2026.
• BlendSwap MCP and APIOfficial agent access, uploader-declared licences, download caps.
• Sketchfab licence listEvery licence slug, including Standard and Editorial.
• KitBash acquires ArtStation and SketchfabEpic Games, 10 Aug 2026.
• ComfyUI-UniRigUniRig and Make-It-Animatable nodes for ComfyUI.
• UniRigVAST. Learned skeleton and skinning for arbitrary meshes, SIGGRAPH 2025.
• SkinTokensVAST. One-stage skeleton and skinning, MIT, GLB out.
• Make-It-AnimatableHumanoid auto-rigging, CVPR 2025.
• RigodotifyRigify to game skeleton for Blender 4 and later.
• Robust Weight TransferWeight transfer and inpainting for clothing, SIGGRAPH Asia 2023.
• glTF 2.0 specificationSkinning: joint and weight sets, normalisation tolerance.
• itch.io CC0 game assetsBrowse filter by licence and AI disclosure.
• Generative AI disclosure taggingitch.io, Nov 2024. Mandatory for asset creators.
• itch.io server-side APICovers your own projects and purchases, not the catalogue.
• SAM 3.1 release notesMeta, 27 Mar 2026. Object multiplex, text prompts in video, speed-ups.
• SAM LicenseCommercial use allowed, with trade-control and ITAR limits.
• SAM 3.1 for ComfyUIComfy-Org repack with image and video segmentation templates.
• Depth Anything 3ByteDance Seed. Every checkpoint with its licence.
• DA3MONO-LARGEApache 2.0 monocular depth with sky segmentation.
• Depth Anything 3 in ComfyUINative nodes for Small, Base, Mono-Large and Metric-Large.
• Blendkit terms and conditions 2026§5.4 and §5.8: Royalty Free assets must not be separable or exportable from software.
• Comfy MCPComfy. MCP server for a local ComfyUI, no sign-in.
• Pixal3DTencentARC. Image and multi-view to 3D with PBR, MIT.
• Marigold V2Depth, normals and albedo from one image, Apache 2.0.
• MOSS-SoundEffect v2.0Text to sound effects, 48 kHz, Apache 2.0.
• Harness design for long-running application developmentAnthropic, Mar 2026. Generator and evaluator agents, four design criteria.
• Keep Claude working toward a goalClaude Code docs. How /goal evaluates, limits and check-ins.
• Claude Code model configurationEffort levels, ultracode, ultrathink.
• Rethinking skills and prompts for GPT-6 AstraOpenAI, 11 Sep 2026. Short skill descriptions, AGENTS.md as a router.
• three.js r186Gaussian splats in TSL, compileComputeAsync, build changes.
• WebGPU implementation statusWhich browsers ship WebGPU, per platform.
• Blender Lab MCP serverBlender Foundation. Official MCP server for Blender 5.1 and later.
• three.js llms.txtDocs for agents, pinned to the current release.
• React Three Fiber v9 migration guideReact 19, new types, async gl factory.
• Babylon.js MCP serversOfficial MCP servers for the node editors.
• PlayCanvas editor MCP serverOfficial. Drives the PlayCanvas editor.
• Phaser 4 migration guideWhat changed from Phaser 3.
• Godot releases4.7 released 18 Jun 2026.
• Godot command line tutorialHeadless import, export and scripts.
• Godot Movie MakerNon-real-time frame capture at a fixed fps.
• Exporting Godot for the webWebGL 2, cross-origin isolation, no C#.
• godot-mcpCommunity MCP server for Godot.
• Unity pricing updatesPersonal up to $200k, Enterprise above $25M.
• Unity CLIBuilds, tests, editor commands and unity mcp.
• Replace the MCP server with the Unity CLIUnity. The AI Assistant MCP server is deprecated.
• Unity command line argumentsBatch mode, execute method, tests.
• UnityYAMLWhy agents should not hand-edit Unity scenes.
• Unreal Engine licence5% game royalty above $1M, $1,850 per seat for non-game use.
• Scripting the Unreal Editor with PythonHeadless Python commandlet.
• Run automation tests in UnrealCommand-line test runs and reports.
• Unreal MCP in Unreal EditorExperimental MCP plugin in 5.8.
• Unreal Engine skills for Claude CodeEpic Games. MIT plugin over Unreal MCP.
• Bevy 0.19Release notes, Jun 2026.
• Supercharge web AI testingChrome. Headless GPU flags for WebGPU.
• sprite-genaldegad. Sprite skill and CLI: keying, loop finding, atlas manifest, QA, curation.
• sprite-gen: chroma to alphaKey choice, edge unmixing, and why learned matting was not adopted.
• sprite-gen: video pipelineCanvas per action, period search, one-shot cuts, foot-line anchoring.
• sprite-gen: states and framesFrame counts per state, why locomotion stays experimental.
• How to build a motion design studio with Opus 5.5Movez, 27 Sep 2026. The posts behind the trend, and the harness around them.
• Opus 5.5 video generation workflowDeedy Das, 29 Sep 2026. Script, animatic, captions, critic, timeline assembly.
• PDoomVideoJohn Heibel. Chaptered music video with ANIMATION_GUIDE.md and STORYBOARD.md.
• ClaudeAnimationBaseJohn Heibel. MIT starter for seek(t) films.
• claude-animation-skillMIT Claude Code plugin for hand-drawn canvas films.
• awesome-opus-5-5-videosCC BY 4.0 dataset of Opus 5.5 videos and prompts.
• awesome-ai-motionMIT prompt library for coded motion.
• ManimMIT. Maths and diagram animation.
• OpenTimelineIOApache 2.0. Editorial timelines as data.
• faster-whisperMIT. Local speech recognition with word timestamps.
• librosaISC. Beat, downbeat and onset detection.
• Prompting Claude Sonnet 5.5Anthropic docs. Default effort, extra review rounds, real checks at low effort, thinking line, crop tools.
• EffortAnthropic docs. Per-message effort beta, cache behaviour, supported models.
• Claude Sonnet 5.5Simon Willison, 28 Sep 2026. Max effort used 128k tokens with no output, xhigh finished in 41 s.
• Opus 5.5, Sol and LunaSimon Willison, 22 Sep 2026. Opus 5.5 at max hit the output limit on a simple SVG.
• Introducing GPT-6.1 SolOpenAI, 29 Sep 2026. Positioning and pricing against Astra and Luna.
• GPT-6.1 Sol model pageOpenAI. Context, effort levels, prices.
• frontend-design skillAnthropic. The five clusters of default design traits.
• threejs-game-skillsMajid Manzarpour. Test hooks, bot playtest, canvas checks, budgets, release checks.
• Game Studio pluginOpenAI. HUD rules, sprite normalising, 3D playtest checks.
• claude-code-game-builderGauntlet Loop packaging: blind A/B critic, numeric specs, model roles.
• threejs-complete-set-of-skilllinegel. WebGPU and TSL skills, including visual validation with labelled evidence.
• draw-better-svgSVG in passes with render checks and a local review page.
• blender-node-skillsNodeCue. Geometry Nodes resolved live in Blender and read back.
• Artificial Analysis image arenaRead 30 Sep 2026. GPT Image 2.5 Sunburst and Flare lead generation and editing.
• Artificial Analysis video arenaRead 30 Sep 2026. H3 Max leads image to video, Gemini Omni Flash text to video.
• GPT Image 2.5 SunburstOpenAI, 8 Sep 2026. Model id, snapshot, token prices.
• Sora discontinuationOpenAI. The Sora API closed on 24 Sep 2026.
• OpenRouter video generationAsync jobs, first and last frame, audio, model list endpoint.
• MiniMax H3 Max on falImage to video with an end frame.
• Tripo P2 on falQuad or triangle meshes with a face budget, price per model.
• Tripo P2 reviewDigital Production, 29 Sep 2026. Mostly quads, edge flow still needs checks.
• Meshy API changelogMeshy 7.1, smart topology, rigging and multi-clip animation.
• top3d.ai leaderboard26 Sep 2026. Blind votes on image-to-3D output.
• ElevenLabs modelsv4 speech, Sound Effects v2 with loops, Music with stems.
• fal termsCommercial use per model, no exposing the API to end users.
• Qwen-Image 2.1 licenceResearch and evaluation only.
• Comfy MiniMax licencePaid licence for local H3 use above the free terms.
• Artificial Analysis open-weights TTSRead 30 Sep 2026. Breeze TTS 2 and Fish Audio S2 Pro lead.
• Fish Audio S2 Pro80+ languages including Hindi. Fish Audio Research License, non-commercial.
• Chatterbox MultilingualMIT. 23 languages including Hindi, voice cloning.
• Step Audio EditXApache 2.0. Cloning and emotion editing, English and Chinese.
• MiniMax Music 3 licenceAttribution, and approval above $20M revenue.
• WildSongBench results12 Sep 2026. YuE2, MiniMax Music 3 and ACE-Step compared, run by YuE2's lab.
• HunyuanVideo-FoleyVideo to audio. Licence excludes the EU, UK and South Korea.
• Artificial Analysis open-weights videoH3 far ahead of LTX-2.5.
• SkinTokens paperSkinning and bone errors against UniRig and Puppeteer.
• sprite-gen: loop repairRIFE jump-frame repair, jolt index, seam pop, one cycle per direction set.
• sprite-gen: looping an ambient clipFlow-matched cut and a RIFE seam bridge for ambient clips.
• sprite-gen changelogv2.12 to v2.35: body plans, handedness, video-prompt, cycle alignment.
• A model guide for the GPT-6 familyOpenAI, 2 Oct 2026. Roles for Astra, 6.1 Sol and Luna, lean prompts, when to try xhigh and max.
• OpenAI scraps GPT-6.1 AstraWashington Post, 28 Sep 2026.
• Opus 5.5 and longer sessionsAnthropic, 24 Sep 2026. Keeping cached reads in long sessions.
• OpenAI deprecations1 Oct 2026. tts-1 and gpt-4o-mini-tts shut down on 6 Jan 2027.
• Artificial Analysis text to videoRead 6 Oct 2026. Wan 3.0 first with audio.
• riba2534 Opus 5.5 demosSoak test numbers and the NaN-through-bloom black screen.
• Turbo Kart RallyMIT. Five Opus 5.5 subagents behind an architecture contract and file ownership.
• TidewaterMIT. Raw WebGPU fishing game with URL kill switches per subsystem.
• LaunchVideo (shipvideo)HTML films checked under a virtual clock, then rendered frame by frame.
• lemo-opuscar39 film styles as STYLE.md files over shared director and technique guides.
• mcp-for-blender2.1.8, 5 Oct 2026. Guides and safe mode for blender-mcp.
• Prompting Claude Opus 5Anthropic. Subagent caps and over-verification, still the baseline for Opus 5.5.
• Using GPT-6: prompting best practicesOpenAI. Initiative, skills precedence, delegation, test calibration.
• MDA: A Formal Approach to Game Design and Game ResearchHunicke, LeBlanc and Zubek. Mechanics, dynamics, aesthetics and the eight kinds of fun.
• Game design booksGame Design Skills. Schell's lenses, Swink's Game Feel, Sylvester's Designing Games.
• Working with colour in generative artTyler Hobbs. HSB, gradients, palettes as probability distributions.
• Colour arrangement in generative artTyler Hobbs. Why random colour per element fails.
• GPT-6 Astra pelicansSimon Willison. SVG quality across reasoning effort.
• Effective harnesses for long-running agentsAnthropic. Initialiser session, feature list, progress file, one feature per session.
• 100 Three.js tips that improve performanceUtsubo. Measuring first, draw-call budgets, WebGPU caveats (r186).
• Three.js performance: 60 fps patternsIGC. renderer.info, Spector.js, symptom-to-cause matching.
• Rapier character controllerDimforge. Move-and-slide, slopes, autostep, snap to ground.
• Scroll BackItay Keren. 2D camera techniques and vocabulary.
• 50 Game Camera MistakesJohn Nesky, GDC 2014. Third-person camera failures and fixes.
• SkeletonUtilsthree.js docs. Clip retargeting between skeletons.
• pmndrs postprocessingEffect merging into single passes for three.js.
• Game Accessibility Guidelines: basicThe four most complained-about issues and the easy wins.
• Xbox Accessibility Guideline 101Microsoft. Text display rules across every surface.
• The Level Design Book: blockout, metrics, flow, wayfindingRobert Yang and contributors. The process, metrics and the case against over-guiding.
• Critical pathThe Level Design Book. Beats, layouts, and Goldeneye's space-first approach.
• How Nintendo solved Zelda's open world problemGame Maker's Toolkit. Points and lines, and the triangle rule.
• Nintendo's level design in four stepsMCV on GMTK. Kishōtenketsu in Super Mario 3D World.
• Unexplored's cyclic dungeon generationGame Developer. Cycles, lock and key, why trees feel artificial.
• Behavior Selection Algorithms: An OverviewGame AI Pro. FSMs, behaviour trees, utility, GOAP and HTN compared.
• Choosing between behaviour trees and GOAPDavide Aversa. Pick the simplest model that serves the gameplay.
• The AI systems of Left 4 DeadMike Booth, Valve. The director's adaptive dramatic pacing.
• Amit's A* pagesRed Blob Games. Pathfinding, heuristics, flow fields.
• Yuka and recast-navigation-jsGame AI and navmesh libraries for the web.
• So you want to build a generatorKate Compton. How to design, stack and judge generators.
• WaveFunctionCollapseMaxim Gumin. The algorithm, its ports, and games that use it.
• mapgen2Red Blob Games. Polygon map generation from Poisson points, Delaunator and noise.
• rot.jsRoguelike toolkit: map generators, FOV, pathfinding.
• Feel: core concepts and springsMore Mountains. Feedback players, pauses, intensity, channels, springs, global switches.
• Juicy BreakoutMartin Jonasson and Petri Purho. The source behind "Juice it or lose it".
• 2D screen shake exampleBevy. Squirrel Eiserloh's trauma model, annotated line by line.
• anime.js engine.update()Anime.js docs. Driving tweens from a Three.js or game loop.
• GSAP, Anime.js, Motion and WAAPI comparedICS MEDIA. Performance, footprint and features, 2026.
• HyperFramesHeyGen. HTML to deterministic MP4, 21 agent skills, Apache 2.0.
• Remotion Agent SkillsRemotion. Official skills for Claude Code and other agents.
• Remotion licence and pricingRemotion. Check free-licence eligibility here, not in blog summaries.
• Remotion vs Motion Canvas and Revideosnapcn. Authoring models and licences compared.
• claude-remotion-skillCommunity skill built around a render, inspect frames, fix loop.
• GPT-6 Astra 3D demosMindStudio. Tester reports on 3D worlds and games.