What the source did
- He is a solo creator about 18 months into a commercial cozy colony adventure sim, with a story mode and a colony mode, heading for early access.
- Its creatures each have a personality with memory, relationships, emotion and belief. He calls the system "Contextual Relational Intelligence" (CRI); no LLM runs inside the game.
- His background is 10+ years of web development, then technical program management and solutions architecture. He never learned C++ or GDScript. He worked with a 3D artist from Fiverr and a composer.
- Tools: Cursor as the IDE, running Claude and Codex subscriptions. He runs Claude Opus 5.5 on High or Extra High, 5 to 15 agents at a time across two or three context windows. He tried Fable 5.2 and hasn't found it significantly better so far.
- Linear holds the tickets, milestones, delivery plans and acceptance criteria, with Claude and Codex linked by API and CLI. He says tickets hold agent context far better than .md files, and calls the ticketing system "the biggest game changer" for continuity.
- Links between tools: Claude, Codex and Godot through a custom MCP bridge and Godot's headless CLI; Blender through its official MCP; OpenArt through its official MCP and CLI. He concepts art in OpenArt (GPT 2.5 Sunburst), then uses GPT Astra for 3D modelling in Blender and for ideation. Canva makes his weekly social video.
- Testing: work runs through the headless CLI, plus windowed mode for visual tests. Agents gather data and screenshots and run unit, smoke and visual tests. Automated visual runners are agents that play the game and judge whether it's good enough; he also tests in windowed mode himself.
- Agent roles in the repo: developer, game designer, QA tester, adversarial tester, reviewer, researcher, blind tester, automation expert, 3D modeller, integration expert and systems designer.
- In the comments: the first agent he opens is the "lane lead", which owns coordination through the repo instructions. Every agent works to Linear tickets, only Opus 5.5 on High or Extra High may write code, and Sonnet does blind review.
- What didn't work: video generation models (he spent "well over $500" experimenting), so cutscenes became still images with narrative text boxes; and Tripo-style 3D generators, which gave bad decimation and triangle counts that were too high.
- His role: 60 to 70 hours a week, about half of it planning and ideating with the agents. He redirects them, rejects weak implementations, solves technical problems and heads off performance issues, treating them like junior-to-mid developers. His lesson: don't let models run free; contain them with tickets and design docs.
- Heads-up: no repo, template or game name was shared, the game isn't out yet, and the post is long and partly personal (he says he has spent much of his savings and may move back in with his dad).
“I don't progress work if it isn't via a ticket now.”— u/Hostarro (r/ClaudeCode), Reddit
Summary written by Agent Cookbook from the original post. See the original for the full context. How we source recipes
Our notes
- What it takes
- Cursor running Claude and Codex subscriptions, Linear tickets with acceptance criteria, Godot's headless CLI with an MCP bridge, and a second model for blind review. He published no repo or instructions; the lane-lead file is ours.
- Where it breaks
- Letting agents run without tickets, keeping their context in loose .md files, running more agents than you can review, and spending on video or 3D generators that didn't work for him. The game isn't released yet.
- Human checkpoint
- Agents work only from tickets; only one model writes code and another reviews blind. You approve every merge and anything published, and reject weak work.
- Tools involved
- Cursor as the IDE, running Claude and Codex subscriptions, Claude Opus 5.5 on High or Extra High for all coding, A separate model for blind review (he uses Sonnet), Linear for tickets, milestones, delivery plans and acceptance criteria, linked to both agents by API or CLI, Godot's headless CLI plus a custom MCP bridge, and windowed mode for visual testing, Blender and OpenArt over their official MCP servers, if you make your own 3D art, You, planning with the agents and approving what ships
✓ Verified Source link checked and still live. Notes by Thomas, editor. How we verify
Copy the prompt
Ours Our version, based on u/Hostarro's workflow. He didn't publish his repo instructions, so this lane-lead file is ours. Fill in the [BRACKETS].
REPO INSTRUCTIONS: LANE LEAD (our version, based on u/Hostarro's workflow)
You are the lane lead: the first agent opened in this repo. You own coordination.
TICKETS ONLY
- No work happens unless it is on a Linear ticket with acceptance criteria and a milestone.
- If a request has no ticket, draft one and wait for my approval before anyone starts.
- Every agent reads its ticket and the linked design doc before starting, and updates the ticket when it stops.
ROLES (assign one per ticket)
developer, game designer, QA tester, adversarial tester, reviewer, researcher, blind tester,
automation expert, 3D modeller, integration expert, systems designer.
- Only [CODING MODEL, e.g. Opus 5.5 on High/Extra High] may write or change code.
- Blind review is done by a different model [e.g. Sonnet] that didn't write the change and sees only the diff and the ticket.
GATES BEFORE A TICKET IS "READY FOR REVIEW"
1. Unit and smoke tests pass through Godot's headless CLI.
2. Visual check: run the build in windowed mode, capture screenshots, and have a tester agent play the affected part and say whether it's good enough, with evidence.
3. Blind review passes, or its findings are fixed and re-reviewed.
4. Note any performance risk you see on the ticket.
STOP AND ASK ME
- Before any merge to the main branch: I approve every merge.
- Before anything is published, uploaded, posted or sent outside the repo, or anything is deleted.
- When the design doc and the ticket disagree, or a fix needs a design decision.
- Never let agents work outside their tickets or rewrite the design docs on their own.
Approval rule
🛡
He keeps agents to tickets with acceptance criteria, lets only one model write code and has a different model review it blind. In our version you also approve every merge and anything that's published, and you redirect or reject weak work. Sending, buying, posting and deleting always need a human.
Set it up
- Write design docs for the game's systems before handing work to agents.
- Set up Linear (or another tracker) with milestones, delivery plans and acceptance criteria, and link Claude and Codex to it.
- Connect the agents to Godot through its headless CLI and an MCP bridge, and keep windowed mode for visual testing.
- Add a lane-lead instructions file to the repo (ours above) and define the agent roles.
- Pick one model to write code and a different one for blind review.
- Require unit, smoke and visual tests on every ticket, including an agent that plays the game, and test in windowed mode yourself.
- Spend part of each day planning with the agents; redirect them, reject weak work and approve every merge.
Common failures
⚠
- Letting the models run free. His lesson is to contain them with tickets and design docs.
- Keeping agent context in loose .md files. He found tickets hold it far better.
- Expecting video generation to cover cutscenes. He spent well over $500 and switched to still images with text boxes.
- Auto-generated 3D models with bad decimation and too many triangles. He uses GPT Astra with Blender for 3D instead.
- Too many agents for what you can review. He runs 5 to 15 and still spends half his time planning and checking.
Variations
- Start with three roles (developer, reviewer, QA tester) and add more as the ticket volume grows.
- Use the same ticket-and-gates setup for an app or website instead of a game.
- If you don't make 3D art, skip the Blender and OpenArt links and keep only the Godot bridge.
Related setups: The writer never reviews its own lane → · Claude Code builds, Codex reviews → · Done-when lists for multi-agent coding → · Run Claude Code sessions in parallel worktrees →
Get the 10 best agent setups. Free.
Plus new recipes every week. One email, no spam.
Unsubscribe anytime. Privacy