Stop prompting your AI. Start conducting it.

Part of my methodology series. If you have not read the overview, start there. This piece goes deep on one part of it: the command that runs the loop.

Three apps. One database. Two and a half weeks. One person. That is what came out the other end of a build I did recently, and the part that stuck with me was not the speed, it was how little of it felt like prompting. I was mostly answering one small question, over and over: what’s next? Something else was keeping track of the answer. This is the story of that something.

The overview describes the wall you hit when you build with an agent one prompt at a time: it forgets a decision it made an hour ago, reinvents an approach you settled yesterday, and staying on top of it becomes your full time job. The fix is not a better prompt. It is orchestration. This is what I put in front of the wall.

The pipeline it runs

Instead of asking one agent to do everything out of one big blob of context, I break the work into specialized steps, each with a single job, each reading and writing a shared source of truth. The pipeline has four moves:

• Establish a foundation. Turn the idea, or the existing code, into a set of locked decisions written down with their reasoning. This is the context system.
• Design the next slice. Pick one feature sized piece and spec it properly before touching code.
• Build it. Implement that spec, and nothing more.
• Prove it. Run the real app against the spec’s acceptance criteria before anything ships.

The middle two and the proving are three skills working together. Each step hands cleanly to the next because they all point at the same foundation. The catch is that orchestrating four steps by hand means remembering the sequence, the commands, the checkpoints, and the discipline not to skip the boring parts. That is the exact skill most people do not have, and honestly the one I did not want to need every single time.

So I put a conductor in front of it

build-flow is one command whose only job is to run that pipeline for you. It is not a wrapper that hides the steps. It is closer to a re-entrant hub: it looks at where your project actually stands, recommends the next move, runs the right step, and hands control back to you at every real checkpoint. You return to it, and it picks up from the new state. Less “automation,” more a senior engineer sitting next to you who already knows the playbook.

Two commitments make it more than convenience.

Foundation wins. Every load bearing decision, the stack, the data model, the auth approach, gets locked once, with its reasoning, in a file the whole pipeline treats as law. When the code and the foundation disagree, the foundation wins, and no agent gets to quietly re-litigate a settled call three sessions later. This one rule kills most of the drift.

Prove it before you ship. After every build, build-flow runs the verify step on its own. It drives the real application against the spec’s acceptance criteria, and a failure stops the ship cold. It is not a suggestion you have to remember, it is a beat in the rhythm. Everything that touches the outside world, the commit, the push, the merge, still waits for your yes. Verifying only observes, so it is the one thing allowed to run unattended.

The real point is teaching

Here is the part I actually care about. build-flow explains itself. One line of why at every hand off: “designing this slice first because it unblocks three others,” “reviewing the spec before we build, every time,” “running verify before we ship.” It refuses to be a black box.

That is deliberate. A tool that builds for you leaves you exactly as dependent as you started. A tool that narrates what an expert would do, and why, leaves you a little more capable each loop. The goal was never to remove the human, it was to move the expertise out of my head and into a flow anyone can follow, so the method survives without me standing over it. Speed was a side effect. The point was making a good process the path of least resistance.

What it feels like

You mostly answer “what’s next?” build-flow recommends a slice, and always offers the alternatives, because sometimes you deviate on purpose. It designs the slice with you, reviews the spec, builds it, proves it works, ships it when the checks go green, writes down what got built, and asks again. The expertise lives in the loop, not in your memory. That was always the goal.

I originally built this to hand my approach to a friend who could not drive the pipeline themselves. Somewhere along the way I realized the friend is basically everyone who has felt that one prompt at a time wall. So I made it agent agnostic, taught it to fail loudly and helpfully when a piece is missing, and published it.

Try it

# the conductor
npx skills add Chineme-Portfolio/build-flow -a '*' -g

# the pipeline it drives
npx skills add Chineme-Portfolio/context-system -a '*' -g
npx skills add JavaScript-Mastery-Pro/skills -s architect,develop,check -a '*' -g

Restart your agent, then say the quiet part out loud: what should I build next? That is the whole interface. The pipeline handles the rest, and tells you why as it goes. build-flow is open source at github.com/Chineme-Portfolio/build-flow. If you want the pieces it conducts, the context system is the memory, and design, build, prove is the loop it runs on each slice.