dream-loop skill

Dream Loop Skill

An autonomous process for building extremely impressive visuals, especially 3D scenes (games, apps, usually browser three.js/WebGL): generate photorealistic concept art of the ideal result, build it, screenshot the live build, have a judge score screenshot vs concept against a gated ladder, and iterate until convergence. Goal: the most visually stunning result at an acceptable frame rate for the target platform (e.g. 60 fps browser, 120 fps modern mobile).

This skill does NOT cover general web-app functionality, 2D UI design, or non-visual quality — only the visual-fidelity loop.

When to Use

level of graphical fidelity.

• User says "dream loop" or asks for a game/scene/app built to a very high

loops below).

• Follow-up refinement passes on an existing visual product (see Follow-up

Prerequisites

user for a concept image (or an image-generation API to connect to).

• Concept art: the image_generate tool. If unavailable, stop and ask the

(python3 -m http.server for static builds), then newtab(url), waitforload(), capturescreenshot().

• Screenshots: browser_exec — serve the build locally

workaround).

• Judging: vision_analyze (see Judge section for the one-image-per-call

skill. delegate_task for parallel asset work and fresh-context judging.

• Optional: Blender for asset modeling — see the blender-3d-automation

If you don't have the tools needed for the full loop, flag that to the user early and stop.

Quick Reference

Procedure

1. The target concept

If the user provided a description of a game, scene, or app, proceed — don't ask for clarification unless it's too vague to generate concept art from. If they didn't, ask for it.

Put working context/files in .dream-loop/ and gitignore it (unless told otherwise).

2. Concept art

The concept is a realistic, high-quality, impressive target: the look of a current AAA game running in real time. Physically plausible materials (wet stone, brushed metal, cloth, glass) with real roughness and normal detail, correct proportions, atmosphere (fog, haze, rain, dust, volumetric light), cinematic lighting with a clear key and rich shadows. It should NOT be stylized or an artistic rendition — it should look like a true screenshot of the ideal result.

Avoid these failure modes when generating with image_generate:

objects, excessive detail on every surface that reads as noise. A real-time build with modeled assets won't match this, and it won't even look good.

• Overbaked: photographic clutter, film grain, hundreds of unique small

shapes, empty surfaces. Boring; will not impress the user.

• Oversimplified: cartoon or toy look, flat shading, blobby primitive

Aim for the middle ground: beautiful surfaces and materials that shaders render well, strong atmosphere and lighting, an interesting palette, and focused hero elements with fine detail that draws the eye (not every element fighting for attention).

Prompt for "in-engine screenshot" more than "concept art" and discourage the noisy/grainy look. Review the image with visionanalyze; if it hits a failure mode, pass it back to imagegenerate in edit mode and ask it to fix the issue. Save it as .dream-loop/concept.png.

If you generated the art (the user didn't supply it), pause and confirm it matches the user's vision before starting the build loop.

3. Time budget

If the user gives a time budget, record the start time and check the clock between rounds. Don't degrade visual fidelity to hit the budget — strive for the absolute best result, and don't rush work to the judge. Parallelize or distribute work (e.g. delegate_task for independent assets) to hit the time goal, but no shortcuts: it's better to hit the time limit with meaningful, beautiful progress than with something broadly complete but ugly.

If no time budget is given, run until an exit criterion — but warn upfront that this may consume a lot of tokens.

4. Build loop

Look at the concept art and implement it in one go, making that first pass count across every tier of the score ladder: composition, textures, lighting, details. Sculpt and model assets carefully (or use external ones if allowed); don't settle for basic procedural elements and flat surfaces unless the art style calls for it. Write intermediate files/plans to .dream-loop/.

in Blender (see the blender-3d-automation skill). For complex assets, delegate to subagents via delegate_task.

• If Blender is installed and the concept involves 3D assets, prefer modeling

asset is simple. If unspecified, assume NO external assets from the web.

• If the user allows external assets, prefer them over modeling unless the

buildings): simple shapes look blocky, shiny, flat, and fake. Tiny details and texturing matter and need custom sculpting.

• Do not be lazy with key environmental details (scenery, flooring,

looking and faster than procedural ones.

• Use image_generate for textures, normal maps, skyboxes, etc. — better

5. Screenshot

Serve the build (e.g. python3 -m http.server in the build dir), then via browserexec: newtab('http://localhost:8000'), waitforload(), allow the scene to settle, capture_screenshot(). Target the same resolution and aspect ratio as the concept art so the comparison is fair. Save as .dream-loop/round-N.png.

6. Self-check before judging

Each time, review the candidate screenshot yourself before submitting. Do not submit half-baked work. Compare screenshot and concept side by side and log an honest assessment of judge-readiness; only submit if confident you've significantly improved the score. Be rigorous and audit every pixel: big stuff (missing/incorrect objects, wrong scale, perspective, positioning) and small stuff (rendering glitches, flat untextured surfaces, ugly lighting, poor contrast, washed-out or oversaturated color, speckles, ugly shadows). Scan surface by surface, object by object, and list findings.

7. Judge

Judging should ideally be done by a fresh subagent with a clean context each round (delegate_task), to keep it objective and cheap. Give the judge the latest screenshot, the concept, and (from round 2 on) the previous round's screenshot and verdict.

Mechanics: vision_analyze takes one image per call. Either have the judge make sequential calls (concept, then screenshot, then compare from memory of its own descriptions), or — better — stitch a labeled side-by-side composite with ImageMagick (convert concept.png shot.png +append compare.png) or PIL and analyze that single image.

Judge prompt:

You are an art director reviewing a real-time render against its concept

art. Compare the screenshot to the concept and score it 0-10 using this

ladder. The ladder is gated: a frame cannot score above a tier's cap until

every requirement of the tiers below it is fully met. Be strict about the

gates.

- Tier 1, shape (0-3): camera, framing, composition, and the position