The Loop I Use to Ship Features with AI

When I give an AI agent a feature to build, finishing the next task isn’t enough. The work can expose a hidden dependency, a bad assumption, or a better shape for the feature. If that discovery stays in one chat or one task, the next piece of work can keep moving in the wrong direction.

That’s the problem I’ve been working on with Dotbrain. I want a loop that starts with what the project already knows, turns an idea into a design and workable slices, checks each slice against reality, and feeds what it learns back before work continues.

I took the idea of small, composable skills from Matt Pocock’s skills. These skills ship with the Dotbrain plugin for Claude Code and Codex. Each has a bounded job and a clear handoff. Together, they form the loop I use to keep an agent working toward the feature I want while making room for what we learn as we build it.

From idea to working feature

First, surface what you don’t know and challenge the idea against the project’s existing language and decisions. When there is enough shape to build, write a design: what the feature should do, which choices shape it, what remains unknown, and how we’ll know it works. Then cut the work into slices: small pieces of the feature that we can build and check one at a time.

Build a slice, check what happened, and feed the result back. Even after tasks have been cut, a discovery can send the work back to the design. If an API cannot support the behavior we expected, the agent brings that constraint back as a design question before adding a workaround to the next task. Once we settle the direction, the design and tasks change together. If a discovery only reveals more work without changing the design, update the tracker. Repeat until the agreed criteria are met or the work is blocked.

Under an explicit handoff, iterate-design can run this as a bounded loop. The design stays active throughout, so each new slice starts from what we learned on the last one.

The workflow guide walks through these stages and how the skills hand work to one another.

One owner per artifact

The loop is easier to follow because each kind of knowledge has one home. A skill can finish its job and hand work to the next one without turning every document into a running log.

• find-unknowns surfaces blind spots before the design takes shape. Inspired by Anthropic’s field guide.
• grill-decisions settles shared vocabulary in a glossary and records decisions worth keeping. Those are project context: each new design starts from them instead of inventing its own words and reopening decisions we’ve already made.
• to-design writes the living design for one initiative. During execution, design-relevant discoveries go back into that document. close-design ends it and promotes lessons that should guide future work.
• to-issues turns the design into slices with dependencies. operate-execution keeps their state in Beads, which I use as the internal, private execution tracker for what’s ready, blocked, or done.
• Project rules live in the agent’s instructions, where write-agent-docs helps keep them usable.

The design doc doesn’t collect task status, and the tracker doesn’t carry the rationale. Vocabulary and durable decisions remain available to every design that follows. I still use plan mode to examine an approach: Claude Code’s plan mode lets me review it before edits, and Codex’s ExecPlan approach can keep progress and evidence with implementation decisions. Dotbrain’s design has a narrower job. It holds the current shape of the feature, while the other skills own the work around it.

A way to end

The design needs one more rule: it must have an end. It starts as a draft, becomes active, and finishes in one of three states: shipped, abandoned, or superseded by a newer design. Active doesn’t mean thinking is over. The agent works a slice, checks it, and updates the design when the result changes what we know about the feature. It records current intent and criteria, not every step the agent took. Once the design reaches an end state, it freezes.

Closing a design doesn’t delete it. You record what was actually verified against the criteria you agreed to, keep the lessons future work will need (a decision becomes a decision record, a settled term goes into the glossary), and record the date it ended. Future work uses the glossary and decision records; the finished design remains a record of what happened.

The agent never moves its own definition of done

The other half of this is trust. You agree on the criteria before work starts, and only you can change them. If a criterion turns out to be wrong or impossible, the agent stops and asks. You can change it, with the reason recorded, rather than letting the agent quietly loosen it to fit what it built.

Unattended work follows the same rule. When an agent iterates on a design on its own, the loop has hard stops: a retry cap, a no-progress cap, and a handoff contract that authorizes a branch and a draft pull request and nothing else. Merging, deploying, and publishing stay with a person.

Review works the same way. An agent can record findings, file follow-ups, and give a verdict, but it can’t use that verdict to close its own review. A person closes the record, or design close-out closes it after the findings have been dealt with. A passing verdict from the agent alone isn’t enough to close the review.

Steal the shape

You don’t need the tool to use the loop. Four habits carry most of it:

• Give each stage a bounded job and a clear handoff. Feed discoveries from implementation back into the design before taking the next slice.
• Give vocabulary, decisions, design, and task state their own homes, so each stage can find what is current.
• Give a design an end state, so it doesn’t keep getting read as current after it stopped being true.
• Write the acceptance criteria before the work starts, and approve any changes as you learn.

All of it works by hand: a glossary file, a folder of decision records, one design doc per initiative, and a tracker kept apart from the rest.

What it costs

The skills are opinionated. Vocabulary, decisions, designs, and task state each have a defined home and rules for how they change. Keeping them in sync takes work. On a multi-step initiative the structure is the point. On a two-line fix it’s ceremony, and you should skip it. The gates also cost attention, which is the thing they’re supposed to save.

That’s why I built Dotbrain around bounded skills: each does a small job, passes on what it learned, and gives the next slice a current design to work from.

The Dotbrain documentation explains how to set it up and use the skills.