Dream Loop Skill: Build 3D Scenes With a Concept-Art Fidelity Loop

Dream Loop is an optional Hermes Agent skill that runs a closed visual-fidelity loop for 3D scenes: it generates photorealistic concept art of the ideal result, builds the scene, screenshots the live build, has a judge score the screenshot against the concept on a gated ladder, and iterates until the result converges. Reach for it when a user asks for a game, scene, or app built to a very high level of graphical fidelity, or when you are doing refinement passes on an existing visual product. It is not a general web-app builder and does not touch 2D UI design or non-visual quality.

What it does

The skill turns "make it look amazing" into a measurable loop. The target is not a vague aesthetic; it is a concrete image: a realistic, high-quality concept that looks like a current AAA game running in real time. The build is then judged against that image, not against taste.

The loop has eight stages, and the skill keeps its working context in a .dream-loop/ directory (which you should gitignore unless told otherwise):

Stage	What happens	Artifacts (.dream-loop/)
1. Target	Get/confirm the user's description	notes
2. Concept	Generate "in-engine screenshot" concept art	concept.png
3. Budget	Record time budget & start time (if given)	notes
4. Build	Implement the concept as well as possible in one go	source, plans
5. Screenshot	Capture live build at concept resolution	round-N.png
6. Self-check	Rigorous side-by-side audit before judging	assessment log
7. Judge	Ladder-scored comparison, actionable directives	verdict log
8. Iterate/Exit	Address directives or exit per criteria	,

The goal is the most visually stunning result at an acceptable frame rate for the target platform, for example 60 fps in a browser or 120 fps on modern mobile. The skill is explicit that it covers only the visual-fidelity loop, not general web-app functionality, 2D UI design, or non-visual quality.

Before you start

The loop depends on three tools, and the skill says to flag missing tools early and stop if you cannot run the full loop.

• Concept art: the image_generate tool. If it is unavailable, stop and ask the user for a concept image, or for an image-generation API to connect to.
• Screenshots: browser_exec. Serve the build locally (python3 -m http.server for static builds), then call new_tab(url), wait_for_load(), and capture_screenshot().
• Judging: vision_analyze. Note the one-image-per-call constraint covered in the Judge section.

Optional extras: Blender for asset modeling (see the blender-3d-automation skill), and delegate_task for parallel asset work and fresh-context judging.

The skill ships as version 1.0.0 under the MIT license, authored by Anshu Chimala and adapted by Nous Research. It is an optional skill installed on demand from optional-skills/creative/dream-loop, and it targets linux and macos.

The target concept

If the user already described the game, scene, or app, proceed. Do not ask for clarification unless the description is too vague to generate concept art from. If there is no description, ask for one. Working context and files go in .dream-loop/, which should be gitignored unless you are told otherwise.

Concept art

The concept is the anchor for every later judgment, so it has to be right. It should read as a realistic, high-quality, impressive target: the look of a current AAA game running in real time. That means physically plausible materials (wet stone, brushed metal, cloth, glass) with real roughness and normal detail, correct proportions, atmosphere such as fog, haze, rain, dust, or volumetric light, and 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.

When generating with image_generate, avoid two failure modes:

• Overbaked: photographic clutter, film grain, hundreds of unique small objects, excessive detail on every surface that reads as noise. A real-time build with modeled assets will not match this, and it will not even look good.
• Oversimplified: a cartoon or toy look, flat shading, blobby primitive shapes, empty surfaces. It is boring and will not impress the user.

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, rather than every element fighting for attention.

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

If you generated the art rather than the user supplying it, pause and confirm it matches the user's vision before starting the build loop.

Time budget

If the user gives a time budget, record the start time and check the clock between rounds. The skill is firm that you do not degrade visual fidelity to hit the budget. Strive for the absolute best result and do not rush work to the judge. To hit the time goal, parallelize or distribute work, for example with delegate_task for independent assets, but take no shortcuts: it is 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 the user upfront that this may consume a lot of tokens.

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. Do not settle for basic procedural elements and flat surfaces unless the art style calls for it. Write intermediate files and plans to .dream-loop/.

• If Blender is installed and the concept involves 3D assets, prefer modeling in Blender (see the blender-3d-automation skill). For complex assets, delegate to subagents via delegate_task.
• If the user allows external assets, prefer them over modeling unless the asset is simple. If unspecified, assume NO external assets from the web.
• Do not be lazy with key environmental details such as scenery, flooring, and buildings. Simple shapes look blocky, shiny, flat, and fake. Tiny details and texturing matter and need custom sculpting.
• Use image_generate for textures, normal maps, skyboxes, and similar assets. They look better and are faster than procedural ones.

Screenshot

Serve the build, for example with python3 -m http.server in the build directory, then drive browser_exec:

new_tab('http://localhost:8000')
wait_for_load()
# allow the scene to settle
capture_screenshot()

Target the same resolution and aspect ratio as the concept art so the comparison is fair. Save the capture as .dream-loop/round-N.png.

Self-check before judging

Every round, review the candidate screenshot yourself before submitting it. Do not submit half-baked work. Compare screenshot and concept side by side and log an honest assessment of judge-readiness. Only submit if you are confident you have significantly improved the score.

Be rigorous and audit every pixel: big things such as missing or incorrect objects, wrong scale, perspective, and positioning, and small things such as rendering glitches, flat untextured surfaces, ugly lighting, poor contrast, washed-out or oversaturated color, speckles, and ugly shadows. Scan surface by surface and object by object, and list your findings.

Judge

Judging should ideally be done by a fresh subagent with a clean context each round via delegate_task, which keeps 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 and rough scale of every major object match the concept. Layout, not finish: every major element present, in the right region of the frame (within ~10% of frame width/height), at roughly the right size (within ~25%). Right place and vaguely correct outline passes even if edges and surface are wrong; save precision nitpicks for Tier 4. Cap 3 until true.
• Tier 2, light and color (3-5): key light direction and color, overall exposure (no clipping to black or white), shadow depth, palette, contrast, atmosphere. Attend to reflections, glows, etc. Ensure the scene is not too bright or dark relative to the concept. Judge the whole frame, not tiny details (Tier 4). Cap 5 until lighting/reflections/color/ contrast are generally right.
• Tier 3, materials and surfaces (5-7): every surface reads as the right material at a glance: textures, roughness, translucency, wetness, reflections. Assets must not look procedural, blocky, smooth/plastic; frame-dominating elements should be properly sculpted and detailed. Cap 7 until true.
• Tier 4, fine detail (7-9): the small things. Nitpick relentlessly; inspect every little object up close. Layout aligns near-perfectly; materials extremely convincing. Cap 9 until right.
• Tier 5, indistinguishable (9-10): holds up side by side and zoomed in. Nitpick every pixel.

If a previous verdict and screenshot are provided: you are one reviewer in a sequence, not the first. Maintain consistency. First mark each previous directive LANDED, PARTIAL, or NOT DONE against the new screenshot; carry forward anything PARTIAL or NOT DONE. Don't reverse a prior directive unless the result is clearly worse, and if you do, say so and why.

Output format:

1. Score on the first line; "Tier N" (highest fully-passed gate) on the second. 1b. If given a previous verdict: the LANDED / PARTIAL / NOT DONE list.
2. "Blocking:" the specific failures of the next tier's gate. The builder must clear these before anything else counts. Name the element and the change, with magnitudes: "Rocks: replace the stacked ovoid boulders with one continuous fractured slab; cracks 2-5cm wide, dark interiors, add surface texture so they don't look flat/plastic", not "the rocks look artificial".
3. Then at most 4 further directives from higher tiers, same style, ordered by points recoverable.

No non-actionable feedback ("this looks synthetic"), name the specific causes. Every directive must be actionable this round. Don't round up: if a gate isn't fully passed, the cap holds.

Exit criteria

The loop ends in one of several ways:

• Score >= 8 and target FPS acceptable: done. Show the user the latest screenshot and ask if they want more iterations.
• Score >= 8 but FPS unacceptable: optimize, taking lossless wins first and then minimal-visual-impact ones. Re-judge afterwards to confirm no regression.
• Stall approaching (best score has not improved a full point in 2 rounds, or the judge named the same gap 3 times): stop incremental tweaks. Step back and ask what about the approach is capping the score. Make one big structural change in a round: swap asset strategy (sculpt in Blender, pull real models, textures, or HDRIs if allowed), rewrite the lighting model, rebuild the composition, or change the camera. Self-check carefully, because big changes break things. Only repeat parameter tuning if you can articulate why it would work this time.
• Stalled (already tried a big structural change, score flat for 3 rounds, judge is nitpicking or demanding intractable things like raytracing on a GPU-less machine): stop, tell the user why you are blocked, and give options.
• Otherwise: address all or most heavy-hitting gaps this round, not just the top one, because rounds are expensive. Prioritize gaps that move the needle most: lighting, textures, mesh detail. Only revert if the score dropped a full point or more; small dips are judge noise, and reverting a whole round throws out good changes with bad. If one change clearly regressed, undo just that change. Loop.

Follow-up loops

When building on an existing product, or when the user re-invokes the skill for refinements, do not create new concept art in a vacuum, because it may diverge from what exists. Instead, capture a live screenshot of the current product and prompt image_generate to render the best possible version of it (current screenshot to AAA-graphics version of the same shot), then use that as the target. Multiple screens can run parallel judge loops if asked, at higher token cost.

When not to use it

The skill scopes itself narrowly. It does not cover general web-app functionality, 2D UI design, or non-visual quality. If the request is about how the app works rather than how it looks, this is the wrong skill. If the tools for the full loop are missing, the skill says to flag that to the user early and stop rather than run a partial loop.

Limits and gotchas

The skill lists these pitfalls:

• Overbaked or oversimplified concept art (see the failure modes above). Fix the concept before building against it.
• Submitting half-baked screenshots to the judge. The self-check gate exists for a reason.
• Screenshotting at a different resolution or aspect than the concept, which makes the comparison unfair and the verdicts noisy.
• Tunnel-visioning on incremental tweaks when the judge says you are off base.
• Judging both images in one vision_analyze call. It takes one image, so composite them first.
• Screenshotting before the scene loads or settles. Add a wait after wait_for_load() for asset streaming and animation warm-up.

Verification

Before calling the work done, confirm:

• .dream-loop/concept.png exists and passed the failure-mode review, plus user confirmation if you generated it.
• Each round has a screenshot, a logged self-assessment, and a judge verdict with score, tier, and directives.
• You exit only via an explicit exit criterion, and the final screenshot is shown to the user with the final score and FPS measurement.

What pairs with it

Dream Loop is one of several creative skills. The related skills are p5js, claude-design, and manim-video. For the 3D asset side, the skill points at blender-3d-automation. The upstream project is dream-loop by Anshu Chimala (MIT), and the upstream license is vendored as LICENSE.txt.