Claude Code is the editor. runcastle is the IDE.
An editor opens one file. An IDE runs the whole project. runcastle gives every feature its own branch, its own memory, and its own place in the queue, so several move at once.
A ninety-second walkthrough of runcastle. A feature is named and sized; a real Claude Code session opens with the brief already injected and grills the idea into a spec that is committed to the repo; the spec is split into ten dependency-ordered tickets; one Burn click hands them to six sandboxed Docker agents that pick up every unblocked ticket at once and commit to a single branch; four features run side by side; the finished branch is test-driven on its own port and merged.
Six phases. Two decisions.
An IDE always knows which file you are on. runcastle always knows what your feature needs next, and says so in one sentence. It asks you for exactly two things: approve the plan, and approve the merge.
The phase stepper with ideation current, above a live Claude Code session bound to the ideation phase, opened with an injected instruction to invoke the runcastle ideate skill.
The phase stepper with spec current, above the generated spec document opened from the workspace, showing the decision, the scope, what is out of scope, and a resolved open question.
The phase stepper with tickets current, above a next step bar offering to burn ten tickets, and the ticket list in dependency order.
The phase stepper with build current, above a run in progress: four of ten ticket lanes done with their commits, one lane running, and a live event log beside them.
The phase stepper with review current, above the run summary showing ten of ten tickets done across eleven commits, beside the test drive panel that boots the branch on its own port.
The phase stepper with every phase done and shipped current, above the shipped panel: the branch is merged and no gates remain.
Approve the plan
The spec and the task list come out of one unbroken conversation, so nothing is rebuilt from a summary of a summary. You skim it and say go.
Approve the merge
runcastle sets your own work aside, checks out the finished branch, and starts it, so you can click through the feature before it lands. Then it puts your work back.
Six features open, the way you keep six files open.
One chat window means one feature at a time, so you become the scheduler: what is half-done, what is blocked, what you meant to come back to. runcastle carries that instead, and the sidebar flags the features actually waiting on you.
The feature list, grouped by what each feature wants from you: two under Needs you, three under In progress, one under Shipped. Every row carries a six-segment map of how far that feature has walked the pipeline, so they are all visible at once.
The bar on each row is where that feature has got to in the six phases. Two are waiting on a decision from you. The other four are working.
Sorted by who is blocking
The two features that want a decision from you sit at the top. Everything else is working, and the bar on each row says how far along it is.
Starting another one costs nothing
An ideation session gets its own docs-only copy of the repo, with no dependency install, so opening a second and a third is instant.
Conflicts are a task, not a wall
When a branch will not merge cleanly, an agent resolves it in that feature's own copy with the whole spec in front of it, then hands the branch back to you.
Nothing is lost when you close it
The spec, the decisions, and the map are committed under the feature's folder, and the run history stays in the app. Come back in a week and it still knows what it was doing.
Guardrails, not handcuffs.
Each phase ends with a check that has to pass before the next one starts. Every one of them can be waved through with a one-line reason, and the reason is kept.
Everything that happened, in order
Sessions, overrides, generated docs, blocked runs: all of it lands in one stream per feature. Work that ran while you were somewhere else is still readable afterwards.
A feature activity stream listing session, gate, docs, and converge events, each with a type and a relative timestamp.
It tells you what is missing
A check does not just refuse. It names the one condition that is not met and what would clear it, right beside the button that does it.
Gate G4, test driven, blocked because the branch has not been test driven yet, with an override link.
Skipping one is on the record
Waving a check through is one click and one sentence. That sentence joins the feature's history, instead of becoming a decision nobody can find later.
Your machine. Your subscription. Your repo.
runcastle is a small server and a browser tab on localhost. There is no runcastle account, and no server of ours for your code to pass through.
Nothing routes through us
You sign in with your own Claude subscription, using a token you generate yourself. runcastle never holds a key of yours.
Unattended work runs in a container
Work that runs while you are away happens inside Docker or Podman on your own box. Podman works just as well, so a Docker Desktop licence never blocks you.
What it learns, it commits
Specs, decisions, and maps are plain markdown in your repository under
docs/features/. They outlive the tool.
# the human keeps the main checkout main your working tree # one branch per feature feature/realtime-collab commits land here feature/entry-tags commits land here # planning sessions get a docs-only copy of the repo, # so planning several features at once costs nothing ~/.runcastle/worktrees/ no dependency install # unattended builds get a container each sandbox docker | podman merged back to the branch
Get started
One global command. Before anything boots, the doctor names the exact prerequisite you are missing and the line that fixes it.
bun add -g runcastle
install
runcastle doctor
check prerequisites
runcastle
boots on localhost:4512
Needs Bun, Git, and a Claude Code login on a paid plan. Containers are only required for builds you walk away from. Full prerequisites