One target screenshot gives the agent a concrete visual job
Dream Loop begins by generating what the finished product should look like. If a product already exists, the skill first captures its current state and asks the image model for a refined version rather than an unrelated redesign. The chosen target is saved as .dream-loop/target.png. That file gives the coding agent something more exact than requests such as "make it feel premium" or "add atmosphere."
The method is aimed at games, apps, and scenes where composition and materials carry much of the result. The README's example asks for an isometric Three.js fantasy scene with reflective floors, movement controls, animation, and a rate above 60 fps. Dream Loop does not supply that application code. It supplies instructions for an agent to build, capture, compare, and revise until the live frame approaches the generated one.
Plus stops after 3 passes; Pro targets 8 out of 10
The Plus workflow delegates each pass to a fresh, stronger subagent and tells the main agent to test the result, fix loading or orientation bugs, and take another screenshot. It stops after 3 passes and asks the user whether to continue. That cap gives a lower-subscription user a predictable review point, though the skill still assumes the host can create true subagents in the same thread.
Pro mode adds an independent visual judge. Composition, lighting, and materials each receive up to 3 points; fine detail gets 1. A score of 8 or more plus acceptable FPS ends the loop. Repeated gaps or less than a full point of improvement over 2 rounds trigger a larger rethink, and another failed redesign sends the decision back to the user. Those stop rules are more useful than endless requests to "polish it."
The two modes are intentionally separate. The skill chooses one from the user's subscription tier and tells the agent not to read both workflow files. Pro may use Blender, while Plus avoids it and prefers external or generated assets. Both can call Fal for image-to-3D output, with a bundled helper that checks input files, preserves queue identities, and avoids repeating an uncertain paid submission.
What happened when we ran it
Our sandbox installed commit 9bddb90 in 23 seconds, adding 35 packages and using 37 MB on disk. The build then succeeded in 10 seconds. The container had 3 CPUs, 8 GB of RAM, Python 3.12 on Debian, no secrets, and no elevated privileges. Pip-audit reported 0 known vulnerabilities. The checkout itself was 7 MB, with 13 files and about 368 lines of source.
There was no test script or target, so our runner skipped tests. The repository does contain a Node test file for its Fal batch helper, but there is no package manifest or standard test command in the 13-file checkout that our lab could invoke. We did not generate a target, launch subagents, call Fal, render a Three.js scene, or score two screenshots. A passing 10-second build therefore verifies repository mechanics, not the visual claim.
The scan also found 0 CI workflow files, no Dockerfile, and no tests directory. None is essential for a Markdown skill, but their absence leaves the workflow's main promise dependent on manual examples and user reports. Before trusting it on a deadline, run one small scene through the exact model, browser, capture method, and hardware you plan to use.
A five-round report found progress and a blank capture trap
Open issue 6 documents a five-round Claude Code run by a contributor. Its visual score rose from 1.55 to 5.65 over four rounds, then slipped to 5.42 after a post-processing change and was reverted. The report says the stall rule fired twice as intended. It also found that the supplied capture route returned a blank PNG for the WebGL project until preserveDrawingBuffer: true was added to the renderer.
The same report found that the judge described visible symptoms better than technical causes. It sometimes called present effects missing when they were merely weak, and one measured recommendation made the image worse even after its metric improved. FPS also changed when concurrent subagents loaded the machine. These are one contributor's results, not our lab measurements, but they expose the right risk: a screenshot critic can turn a visible gap into a confident, wrong diagnosis.
September 9 was the last source push
Dream Loop was created on September 7, 2026 and reached commit 9bddb90 after 5 commits by September 9. GitHub showed 1,602 stars on September 30, plus 3 open issues and 1 open pull request. User feedback continued through September 24, including the controlled run and a critique of missing platform, delivery, and functional gates. There are no published releases.
That is early interest, not a long maintenance record. The README says GPT-6 Astra in Codex is the only tested setup and says other strong models will likely work. One issue describes a Claude Opus run, but that does not establish consistent support across hosts. Model names, tool permissions, and subagent behavior are part of this skill's runtime, so portability needs a real trial.
An 8 out of 10 image still needs a product checklist
Dream Loop gives an agent a strong visual feedback habit. The fixed target prevents taste from drifting, fresh critics reduce attachment to the current implementation, and stall rules force a change of approach. For a graphics prototype, those instructions can be more helpful than adding another library.
Its finish line is too visual for a complete product. The steps tell the agent to test and validate, yet the formal exit rule is an 8/10 screenshot plus FPS, with no named artifact, interaction suite, accessibility check, or delivery format. Use the loop to converge on appearance, then require controls, error handling, packaging, and a repeatable frame-time test before you accept the build.