Little Paw Prints: one prompt, one image, 24 minutes

A manager loop built a complete small game in one run lasting 24 minutes, from a single prompt and one reference image. The model was Muse Spark, working inside Hermes through the manager-loop skill. The same model is currently free on OpenCode Zen, so this run is reproducible without spend. The skill itself traces to a Matt Shumer post describing week-long autonomous builds. This was the small-scale version: three phases, one implementer at a time, external verification between phases.

The game is Little Paw Prints, an anime-style isometric puzzle-platformer in Three.js. A small black kitten climbs through a messy house to reunite with his big sister, a grey tabby waiting on a pink bed at the top. No enemies, no timer. Push boxes, judge jumps, follow the light up. It is playable below.

Finding

The run followed the skill as written. First a GOAL.md: the goal, a three-phase checklist, and a definition of done per phase worded as completely, extremely well — good enough to move on, not perfect. Then one phase at a time: spawn a fresh implementer, send the phase goal with a required DONE marker, poll until it replies, verify outside the implementer, tick the box, kill the session, advance.

Phase 1 produced the scaffold, core engine, and Living Room level: movement, jumping, platforms, an exit trigger, and the HUD shell. Phase 2 added the Kitchen and Bedroom Loft levels, push and pull box puzzles, the sister cat on the pink bed, the reunion win screen, and level transitions. Phase 3 was the art pass against the reference image — posters with exact text, trailing vines marking climbable surfaces, sun shafts, a pendant lamp, a paw-print blanket — plus HUD polish and a full-playthrough bugfix. Each phase was verified externally before advancing: node --check clean, every file serving 200, and content checks against the artifact itself, including the poster strings. The loop also maintained a visible progress page with a ticked-box counter and a completion chart, the stall detector the skill calls for.

The technical footprint is small. Three.js 0.160.0 pinned through a CDN import map, no build step, runs under python3 -m http.server. The final main.js is about 1,500 lines. Static checks here confirm it parses and all four files serve; a full independent playthrough was not run, so treat gameplay smoothness as manager-verified rather than independently confirmed. Complete from one prompt and one image, in 24 minutes.

Cost is worth stating plainly because it is user-reported rather than measured: a full day of Hermes use including this build came to about $0.25. The per-task cost was not isolated, so read that as context on the price of the run, not as a benchmark.

Meaning

Three details did the work, and all three are control parameters rather than capability claims.

First, the wording of done-ness. Perfect sends an implementer back into minutiae without end. Extremely well licenses moving on. The definition of done is a dial on stalling behavior, and the Shumer field notes call this out explicitly: the same agent with a different stop condition produces a different trajectory.

Second, verification sits outside the implementer. Self-reported checkboxes mean little unless something else checks the box was ticked for the right reason. Here that meant running the syntax check, serving the files, and grepping the artifact for the required strings. The DONE marker is a message, not evidence.

Third, a fresh implementer per phase with the handoff carried in writing. Context grows across phases, and the asymptoting creeps back late if it is allowed to accumulate. Rotating sessions moves the hard problem into the handoff artifact, which is exactly where it can be inspected. The stall rule completes the set: no verified box in some time means wrap up, note it, and advance. Boxes are unequal; the trend is the signal.

None of this required parallelism at scale. The original report mentions dozens of subagents, but the notes are clear that agent count is not the trick. One manager, one implementer, three phases, 24 minutes.

Connection

This lands next to the longer-horizon results carried earlier in the week: multi-day autonomous builds producing playable games through dozens of iterations. The contrast is the finding. Where those runs demonstrate endurance, this one demonstrates how little steering structure is needed before endurance starts paying off. A goal file, a stop condition, an outside check, and a fresh context per phase. That is a small amount of machinery for taking a run from wandering to piecemeal progress.

The failure mode it avoids also has a name in the notes: gauntlet loops, which over-optimize and never move on. The manager loop is the opposite bias — it risks moving on too early instead of too late. For a cozy game about a kitten climbing toward his sister, that bias is correctly chosen. For work where an early error compounds silently, the verification step would need to be heavier than a syntax check and a string search. The structure transfers; the weight of the outside check has to match what is at stake.

Build log and progress page ship with the game: progress. Skill origin: Shumer’s post. Cost figure is as reported for the day, not a per-task measurement.