The pipeline

Every feature you build in runcastle gets a persistent session that walks six phases: ideation, spec, tickets, build, review, shipped. The phase is not a label you set to feel organised — it is what the app uses to decide which context to inject, which agents to launch, and what the one next step is.

The shape of it

You get grilled on an idea until a spec and a set of tickets fall out. Sandboxed AFK agents burn those tickets on a branch. You test drive the result and merge. Human in the loop at only the two ends.

That is the whole system in four sentences, and the six phases are just those sentences made concrete enough for software to act on. A chat window has no idea whether you are still arguing about the idea or waiting on a build; runcastle does, so it can put the right thing in front of you and run everything in between without you.

The six phases

Grilling, and why the spec is worth the argument

Ideation is not a form. runcastle launches a real Claude Code terminal — not a rebuilt chat UX — with the feature's brief already in the system prompt, the phase's rules injected per turn, and a phase-scoped skill pack loaded. Its job is to be difficult: to keep asking until the idea is concrete enough that the next phases have something to bite on.

What comes out is written to your repository, not to a database you cannot read. Spec, decisions, research and notes land as plain markdown under docs/features/<slug>/ — versioned, diffable, readable by any agent you point at the repo later, and still there if you stop using runcastle entirely.

Tickets: the spec, cut into work

The spec becomes a set of atomic tickets in a dependency order. Each one names its goal, its acceptance criteria, and the seams to test at, and knows which tickets block it. That dependency order is what makes the build phase parallel: everything unblocked can start at the same time.

The spec and the ticket list come out of one unbroken conversation, so nothing is rebuilt from a summary of a summary. Then the pipeline stops and waits for you. Skimming a ticket list is cheap; discovering after a long build that the plan was wrong is not.

Build: sandboxed agents on one branch

Click burn and the tickets go to AFK agents running headless inside a Docker or Podman container on your own machine. Each picks up an unblocked ticket and commits to the feature's branch. You can close the tab.

The git topology underneath is deliberate:

• One branch per feature. Commits from every agent on that feature land on it, and nowhere else.
• Planning sessions get docs-only worktrees. They only read code and write docs, so they need no dependency install — which is what makes grilling several features at once cost nothing.
• The main checkout stays yours. Unattended builds never touch your working tree; they happen in containers.

Review, then shipped

When every ticket has finished, the feature moves to review. runcastle sets your own work aside, checks out the finished branch, and starts it on its own port so you can click through the feature before it lands — then puts your work back. Review findings feed fix cycles inside the burner; only hard blockers surface to you.

From review there are three ways out. Fix promotes a test-drive note into a ticket and loops back through the build phase — same lap. Rethink starts a new lap back at ideation, because the problem was the plan, not the code. Merge closes the loop. Shipped keeps the spec, the decisions, and the run history queryable.

Several features, same loop

Nothing above assumes one live feature. A feature that is mid-build wants nothing from you, which is exactly the point: while agents burn tickets on one branch you can be grilling the next idea, and the sidebar flags the features actually waiting on you.