The pipeline

Every feature gets its own conversation, which walks six phases: ideation, spec, tickets, build, review, shipped. The phase is not a label you set to feel organised. It decides which context gets injected, which agents launch, and what the app tells you to do next.

The shape of it

You get grilled on an idea until a spec and a set of tickets fall out. Sandboxed agents burn those tickets on a branch. You test drive the result and merge. You are needed at the two ends and nowhere in between.

The six phases are those four sentences made concrete enough for software to act on. A chat window cannot tell whether you are arguing about an idea or waiting on a build. runcastle can, so it runs the middle without you.

Where a feature comes from

There are three doors, and they all land in the same place.

• New Feature, when you already have a title and a one-liner.
• The project session, when you have a complaint or a paragraph instead of a plan. It cuts the lump into features and creates them.
• Starting a draft, which is a feature you parked earlier with no branch and no repo changes. Start cuts its branch and opens ideation.

The six phases

Ideation: why the spec is worth the argument

Ideation is not a form. runcastle opens a real Claude Code terminal, not a rebuilt chat UI, with the feature's brief in the system prompt, the phase's rules injected each turn, and a phase-scoped skill pack loaded. Its job is to keep asking until the idea is concrete enough for the next phases to bite on.

What comes out goes into your repository, not a database you cannot read. Spec, decisions, research, and notes land as plain markdown under docs/features/<slug>/: versioned, diffable, readable by any agent later, and still there if you stop using runcastle.

Tickets: the spec, cut into work

The spec becomes a set of small tickets in dependency order. Each names its goal, its acceptance criteria, and the seams to test at, and knows what blocks it. That order is what makes the build parallel: everything unblocked starts at once.

The spec and the tickets 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 takes a minute. Finding out after a long build that the plan was wrong does not.

Build: sandboxed agents on one branch

Click burn and the tickets go to agents running headless in a Docker or Podman container on your machine. Each picks up an unblocked ticket and commits to the feature's branch. They already know your setup and verify commands, and which tests were red before they started, because preparation told them.

The git layout underneath is deliberate:

• One branch per feature. Every agent's commits land there and nowhere else.
• Planning sessions get docs-only worktrees. They read code and write docs, so they skip the dependency install. That is what makes grilling several features at once cost nothing.
• Your checkout stays yours. Unattended builds happen in containers and never touch your working tree.

Review, then shipped

When every ticket finishes, the feature moves to review. runcastle sets your work aside, checks out the finished branch, starts it on its own port so you can click through the feature, then puts your work back. Review findings feed fix cycles inside the build agents, and only hard blockers reach you.

Review has three ways out:

• Fix turns a note you wrote during the test drive into a ticket and loops back through build. Same lap.
• Rethink starts a new lap at ideation, for when the problem was the plan rather than the code.
• Merge closes the loop.

Shipped keeps the spec, the decisions, and the run history queryable, including from the project session later on.

Several features, same loop

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