achimala/dream-loop: an agent skill that builds visuals against an AI-generated target

The gap dream-loop is built to close

Most agent-driven build loops optimize against text. You describe a scene, the agent writes code, and the only feedback is whether the code runs. Nothing in that loop knows whether the result looks good. dream-loop targets exactly that gap: the README describes an agent skill that builds a game, app, or scene with impressive visuals by running a closed loop between image generation and a critic. The intended user is someone already working with a capable coding agent on graphics-heavy output, browser demos, 3D scenes, or game prototypes, where the acceptance criterion is visual rather than functional. The README's own example prompt asks for an isometric fantasy scene in Three.js running above 60fps with click-to-move controls, and explicitly tells the agent not to confirm the art and not to ask questions. That prompt is the shape of the intended use: a one-shot brief with a visual bar the agent has to reach on its own.

How the loop actually runs: target, build, critic, repeat

The README lays out five steps. First, the AI dreams up a high-quality target screenshot using image generation. Second, the AI builds with that target in mind. Third, a separate AI critic compares the live screenshot to the target and provides feedback. Fourth, the AI loops back to step two until the critic is satisfied. Fifth, and optionally, the AI loops back to step one and dreams up an even better target based on the current state.

The mechanism is a comparison loop, not a code review. The critic never reads the source; it looks at a rendered screenshot next to the generated target and reports the difference. That design choice matters. It means the feedback signal is perceptual, so a build can pass the critic while remaining structurally poor, and it means the critic's usefulness depends entirely on how good the target image is. Step five is the interesting one: raising the target after the build has caught up turns the loop into a moving goalpost, which can push quality upward or simply never terminate. The README does not document a stopping condition for step five beyond the agent's own judgment, and it does not describe how many iterations are expected. The repository layout includes a scripts/ directory and a references/ directory alongside SKILL.md, so the skill's instructions and helper scripts are separated, but the README does not explain what lives in either.

Installing dream-loop and running a first build

The README gives three installation paths: add it through the skills CLI, clone it into your agent's skills directory, or paste the repository link into your agent and tell it to figure it out. The CLI form is the most reproducible.

npx skills add achimala/dream-loop

After that, your agent should see the skill. The README states the prerequisites plainly: the agent needs access to image generation, either built-in or via API, plus vision input, and subagents are optional but strongly preferred. If you are supplying image generation through an API rather than a built-in tool, the README's example is a Gemini API key. Blender is only needed if you want custom 3D modeling, and the README prefers the Blender MCP or scripting interface over computer use because it produces better results.

The README's example prompt is the best template for a first run. It specifies the camera, the art style, the stack, a frame-rate floor, a time limit, the controls, and the scope boundaries, then ends with an instruction not to ask questions. A trimmed version:

Build me a graphics demo: isometric camera, voxel-ish art style with realistic shading
and reflective wet floors, a character in an interesting scene. Three.js in browser, >60fps.
Don't download assets. Time limit of 1 hour. Controls: click to move the character, camera
lazy-follows; drag to rotate camera; scroll to zoom in/out. No gameplay for now.
No need to confirm the art with me or ask questions, just go!

What you should see is the agent generating a target image first, then building, then a critic pass comparing a screenshot to that target. If your agent starts writing code without producing a target image, image generation is not wired up and the loop has already broken at step one.

Where the loop breaks down

The README is explicit that this is only tested with GPT-6 Astra in Codex, and that other strong models like Claude Fable 5.1 can likely work too. Likely is doing real work in that sentence. A skill that depends on subagents, vision input and image generation is sensitive to how a given agent runtime exposes those three capabilities, and the project has not published results for any model other than the one it was tested with.

The harder limitation is the critic. Comparing a screenshot to a generated target is a judgment call, and the README does not describe the rubric the critic uses, how disagreement between critic and builder is resolved, or what happens when the critic is satisfied by a build that renders correctly but is, say, unplayable. There is also no documented rollback: if iteration four looks worse than iteration three, the README does not say whether the skill preserves earlier states. For a loop that can run for an hour under a time limit, that is a real gap. Finally, this is the wrong tool when the visual target is already fixed. If you have a design file, a mockup, or a brand guide, you do not need an agent dreaming up a target; you need the agent to match the one you have.

dream-loop versus a plain agent build loop

The obvious alternative is the loop most people already run: prompt a coding agent, look at the result yourself, and write the next prompt. The difference is where the feedback comes from. In the manual loop, you are the critic, and your attention is the bottleneck; you can review perhaps a handful of iterations in an hour. In dream-loop, the critic is a subagent, so the loop can spin without you watching, and the target is an image rather than a sentence in your head. That is a genuine structural difference, not a packaging one.

The cost is control. In the manual loop you decide when the output is good enough. In dream-loop the critic decides, and the README does not document how to tune that threshold or override it mid-run. There is also a second-order difference: because the target is generated rather than chosen, the loop can produce something visually striking that you never asked for. The README's example prompt handles this by naming the setting and style up front, which constrains the image generator's output. A prompt without that constraint gives the critic a target you may not want.

Maintenance, licence and what a PR costs

The repository is MIT licensed and is not archived. The last push was on 2026-09-09, one week before this writing, so the project is being touched. There are no releases retrieved, which means there is no versioned artifact to pin to; installation through npx skills add pulls whatever is on main at the time. For a skill that is essentially a set of instructions plus scripts, that is a normal shape, but it does mean an upgrade can change behavior without a version number changing.

The README sets a specific bar for contributions: if you open a PR, provide example results produced by the skill, so changes do not regress performance. That is an unusual requirement and it tells you what the maintainer is optimizing for. It also tells you what an upgrade costs you: you cannot evaluate a change to this skill by reading a diff, because the thing being changed is a prompt and a loop, not a function with a test. Any evaluation has to be a run. The MIT licence permits commercial use and modification, but the README is the only documentation of intent, and it does not address attribution requirements for outputs or the terms of the image generation provider you plug in. Those terms come from your provider, not from this repository.

Editorial conclusion

Adopt dream-loop if you already run a coding agent with image generation, vision input and subagents, and you want a self-correcting loop for scene or graphics work; the README names GPT-6 Astra in Codex as the only tested combination. Skip it if your agent lacks vision input or image generation, because the loop cannot close without both, and skip it for projects where the visual target is already fixed by a design file. Before relying on it, verify three things: that your agent exposes subagents, that Blender is installed if you want custom 3D modeling, and that a one-hour run like the README's Vesper demo actually converges under your model rather than looping.

Frequently asked questions

Official sources

1. achimala/dream-loop on GitHub
2. Issues
3. License: MIT
4. README