Source: raw/reddit-1v94nal.md (carries the full ~15k-character base prompt verbatim)
Author: u/Any-Reputation8118 | URL: https://www.reddit.com/r/ClaudeAI/comments/1v94nal/ | Posted: 2026-07-28 | Score: 2,337 | Comments: 165
SNOWFLOW is a browser-based WebGPU graphics demo — deformable snow, atmospheric lighting, water-inspired spells, and snow surfing — built end to end by Claude Code with Opus 5 in about 9 hours and ~4M tokens (uncached). The interesting reusable artifact is the prompt that drove it: a self-contained “implementation brief” that is simultaneously the spec, the art direction, and the acceptance criteria, handed to the agent up front so it builds from a document rather than from a starter repo. The author shared the full base prompt after his earlier desert demo drew the same request, with one honest caveat: the brief created the base, but “a lot more prompts” were needed to guide Opus further.
Key Takeaways
- The demo: persistent snow deformation (footsteps, movement, and spells carve trenches, raise berms, compress snow into ice, and leave trails that gradually refill), procedural terrain, cloth simulation, dynamic spell lighting, particle effects, and a third-person snow-surf system. Live at https://snowflow-lilac.vercel.app/ (WebGPU-capable machine required; F1 settings, WASD movement, 1-5 spells, RMB/Space to surf). Code: https://github.com/Noniv/snowflow_demo.
- The numbers: ~9 hours, ~4M tokens not counting cached ones, Claude Code + Opus 5 end to end — planning the architecture, writing the Babylon.js and WGSL systems, profiling performance, iterating from screenshots, and documenting technical decisions.
- The pattern: an implementation brief is one document that bundles role, prime directive, hard constraints, per-system specs, an explicit performance budget, milestone gates with mandatory self-inspection, a visual acceptance checklist, and a working agreement about how the agent should spend its time. The agent starts from a blank directory plus this document — spec-driven, not scaffold-driven.
- Quality is enforced by judgment criteria, not feature lists: the brief’s prime directive defines success as a viewer reaction (“this is AAA” vs close the tab) and grants the agent authority to break any requirement that conflicts with beauty, provided deviations are logged in
DECISIONS.md. - Verification is baked into the prompt: screenshot-at-every-milestone with critical self-inspection, a hard gate at the terrain/shading milestone (“Do not proceed until this is true”), and a 13-item visual acceptance checklist — verifier discipline expressed inside a single prompt rather than as an external loop.
- Honest caveat from the author: the base prompt got the project started; many follow-up guiding prompts were still required. “One-shot” describes the brief’s scope, not the session count.
The Demo Facts
- SNOWFLOW follows the author’s earlier viral desert demo (“People liked my desert, so here’s a waterbending demo!”); the author reports performance “way better” than the desert demo, without published numbers.
- Snow surface reacts persistently: trenches, raised berms, compressed snow, ice, and trails that gradually refill.
- Stack per the brief: modern JavaScript (ES2023 modules), Babylon.js on WebGPU only, WGSL shaders, Vite, no TypeScript build step.
- Opus 5’s role explicitly included iterating from screenshots and writing decision documentation (
DECISIONS.md,PERF.md,ASSETS.md) — the agent maintains its own engineering record.
The Implementation-Brief Pattern
What distinguishes this from ordinary prompting is that the entire project definition travels in one self-contained document with defined authority relationships. Key structural elements, quoted from the brief:
Role assignment
“You are the sole engineer and technical artist on a real-time graphics tech demo. Build it end to end. This document is the spec, the art direction, and the acceptance criteria.”
Prime directive with a human judgment criterion
“Visual quality is the product. There is no gameplay loop, no progression, no UI to design around. A player will load this, walk around a snow field for ninety seconds, cast a few spells, surf across a dune, and either think ‘this is AAA’ or close the tab.”
Two override rules sit above everything else:
“If a requirement in this brief conflicts with making the demo more beautiful, break the requirement. Note the deviation in DECISIONS.md with a one-line rationale.”
“Anything that reads as low-poly, flat-shaded, untextured, placeholder, or ‘indie prototype’ is a defect, not a stepping stone.”
And the stopping condition: “Do not stop at ‘it works.’ Stop when every captured frame looks polished, cohesive, and production-ready.”
Hard constraints, with fallbacks banned
A constraints table pins language, engine (Babylon.js latest stable, WebGPU only), bundler, a single target machine (Chrome on Windows 11, RTX 5070 Ti, 2560x1440), and measurable performance targets: 90 FPS sustained, 60 FPS floor, no frame exceeding median + 4 ms. Then: “No fallbacks. No WebGL path, no mobile path, no feature detection branches… Do not spend a minute on compatibility.”
Per-system specs with required behaviours
Nine systems get their own sections (terrain clipmap, custom snow shader, terrain state/deformation buffer, atmosphere/lighting, post-processing, character and robe cloth, camera, five spells sharing one “bending grammar,” and the snow-surf centrepiece), each stating required behaviours and priorities — e.g., “This shader is the most important code in the project. Budget accordingly,” and the deformation buffer as “the core interactive system. Everything writes here; the snow shader reads it.”
Explicit performance engineering and budget
“Garbage collection is your primary enemy.” Zero allocations in the render loop, object pools, pre-allocated typed arrays, frozen static content — and an instruction to allocate the 11.1 ms frame budget explicitly across systems and record measured costs in PERF.md. A separate section mandates warming every GPU pipeline before the loading screen dismisses.
Milestone gates with screenshot self-inspection
“Take a 1440p screenshot at every milestone, inspect it critically, and commit the screenshots.”
Milestone 2 (terrain + snow shading) is a hard gate: “a static screenshot with no character already looks polished, atmospheric, and production-ready. Do not proceed until this is true.”
Visual acceptance criteria
A 13-item checklist verified against fresh screenshots and in motion — no visible faceting, unclipped snow highlights with blue shadows, three simultaneous detail scales, self-shadowing trails with berms, stable non-crawling sparkle, 90 FPS with clean 1% lows, no first-cast hitches.
Working agreement
“Build, don’t test-loop.” Playwright is allowed for milestone screenshots and hard regressions only; “Do not build a test suite; time spent on tests is time not spent on the snow shader.” Plus: “Look at your own output constantly,” “Do not move on from an ugly milestone,” record every deviation in
DECISIONS.md, and the closing line — “Ship something worth screenshotting.”
Why This Pattern Travels
- The brief substitutes for a starter repo: constraints, structure (a suggested
/srclayout), and quality bar arrive as text, so the same skeleton adapts to any ambitious build-from-spec project. - It resolves the agent’s classic failure mode — stopping at “works” — by redefining done as an aesthetic/perceptual standard with checkable proxies (screenshots, checklist items, frame-time graphs).
- It pre-answers the judgment calls that normally trigger clarifying questions (what to cut, what to fake, where to spend time), which is what makes long unattended runs possible.
- Contrast with the same week’s Gauntlet Loop: SNOWFLOW is maximal specification with self-verification gates in one prompt; the Gauntlet Loop is minimal goal specification with an external reference bar and adversarial critic subagents. Two opposite answers to the same question — how do you stop an agent from settling for “pretty good for AI”?
Try It
- Read the full base prompt in
raw/reddit-1v94nal.md(the stub carries it verbatim; the sections quoted above are ~20% of it). - Copy its skeleton: role, prime directive + override rules, hard-constraints table, per-system specs, performance budget, milestone gates with screenshot inspection, acceptance checklist, working agreement.
- Swap the domain content (snow/spells/surf) for your project’s systems; keep the authority structure — especially the deviation log and the “do not proceed past an ugly milestone” gate.
- Run in Claude Code with Opus 5; budget on the order of 9 hours / 4M tokens for comparable scope.
- Expect to steer: plan for follow-up prompts after the base build, as the author did.
Open Questions
- How many follow-up prompts did the base build require, and what share of the final quality came from them? The source only says “a lot more.”
- Was the 90 FPS sustained / 60 floor target actually met? The author reports performance improved over the desert demo but publishes no measurements.
- Did Opus 5 honor the milestone hard gates in practice, or blow through them? The committed screenshots in the repo could answer this.
- Dollar cost of ~4M uncached tokens on Opus 5 is not stated.