runcastle vs. raw Claude Code + skills

If you already run Claude Code with a skills workflow — grill the idea, write the spec, cut tickets, implement at the seams, review — then you are not choosing between two tools. runcastle requires Claude Code, and its skill packs are forks of the same skills you are using. The only real question is whether you want that workflow hand-driven in a terminal, or systematized by something that remembers.

The verdict, up front

Stay with raw skills if you work one feature at a time and you are usually at the keyboard while the agent runs. The terminal workflow is free, transparent, and infinitely hackable, and for a single thread of work it has almost no overhead worth removing. Nothing on this page argues otherwise.

Reach for runcastle when the bottleneck stops being the agent's output and starts being you — when you have three features you would like moving at once, when you keep re-explaining last week's decisions to a fresh session, or when you want tickets burning inside a container while you are asleep. That is a scheduling and memory problem, and no amount of skill authoring fixes it, because skills live inside one session and the problem is between sessions.

Not a rival: runcastle runs on top of Claude Code

This needs saying plainly, because the URL of this page implies a fight that does not exist. runcastle does not replace Claude Code, does not reimplement it, and does not route your prompts anywhere else. It launches Claude Code. Interactive phases open a real Claude Code terminal with context pre-injected; unattended phases run Claude Code headless inside a container. Claude Code — and a paid Claude plan — is a hard prerequisite. If you uninstall it, runcastle does nothing at all.

The methodology is borrowed too, and credited. Five of runcastle's six skill pack skills — ideate, spec, tickets, qa, and converge — are adapted forks of Matt Pocock's skills, each carrying a provenance header naming its upstream source. The upstream repository is MIT-licensed and its licence is reproduced in full in runcastle's NOTICE.md. Only waypoint is original work. runcastle forks rather than depends, so upstream changes cannot break a running install and the forks can diverge toward runcastle's machine-readable contracts — but the ideas are Matt's, and the grilling rule that a spec and its tickets must come out of one unbroken context window is his, load-bearing, and kept.

What the raw workflow actually is

Claude Code skills are a SKILL.md file with instructions. They live in ~/.claude/skills/ for personal use, in a repo's .claude/skills/ to share with a team, or inside a plugin. You invoke one with /skill-name, or the model reaches for it when it looks relevant, and the body only loads when it is used. Claude Code watches the directories, so editing a skill takes effect in the session you are already in.

Matt's pack installs as a plugin — claude plugins install mattpocock-skills, or npx skills@latest add mattpocock/skills for other agents — and you run /setup-matt-pocock-skills once per repo. From there the shape is /grill-me (or /grill-with-docs) to force alignment before any code, /to-spec to freeze the conversation into a spec, /to-tickets to cut it into tracer-bullet tickets that declare their blocking edges, /implement driving /tdd at the pre-agreed seams, and /code-review before you commit. /wayfinder sits above it for multi-session work and /handoff exists precisely because sessions end.

It is a genuinely good system. It costs nothing beyond your Claude plan, every rule is a markdown file you can read and rewrite, and it works in any repo on any machine with no server, no container runtime, and no port to remember.

Stay with raw skills if…

• You ship one thing at a time. One feature, one terminal, you present while it runs. Everything runcastle adds is scheduling, memory, and isolation for work you are not watching. With a single live thread there is nothing to schedule, you are the memory, and the isolation is just your working tree. You would be paying setup cost for machinery that has nothing to do.
• You are still tuning the methodology itself. If you are actively editing your skills — arguing with the grilling prompt, changing what a ticket has to declare — raw files in ~/.claude/skills/ are the right surface. Edit, re-run, see the change immediately. runcastle vendors its packs and injects them per session, which is exactly what you want when the workflow is settled and exactly what you do not want when it is the thing under experiment.
• You cannot run a container, or you work on someone else's locked-down machine. runcastle's interactive phases need only Bun, Git, and Claude Code, but unattended ticket-burning needs Docker or Podman and a claude setup-token credential. Without those you get the pipeline and lose the headline feature, and skills in the terminal give you the same methodology with no infrastructure at all.
• Your work is exploratory rather than feature-shaped. Debugging, spikes, one-off refactors, reading unfamiliar code. A pipeline that expects an idea to become a spec, tickets, and a merged branch is overhead when the honest output is "now I understand it."

What falls over without structure

The failure modes below are not criticisms of the skills. They are the things a skill cannot reach, because a skill is instructions inside one conversation and these all happen outside one.

Parallel features become bookkeeping. Two features means two branches, two worktrees, two terminals, and a mental note about which one was waiting on you. Four means you have quietly become a scheduler. Nothing breaks — you just spend your attention on tab management instead of on the work.

Context dies with the session. The grilling was the expensive part, and it lives in a context window that ends. /handoff and a maintained CONTEXT.md are real answers to this, and they work — as long as you remember to run them, every time, on every feature. The discipline is the product, and discipline degrades on a Friday.

Nothing stands between the spec and the merge. A skill is advice the model can decline. There is no check that a spec exists before tickets get cut, and nothing stops a branch reaching main without a test drive. Most of the time you are fine. The one time you are not is the time you skipped the step because you were sure.

The same feature, both ways

Take a real one: add rate limiting to the public API. Both workflows start identically, because they are the same skills.

Notice what the right-hand column does not claim: better prompts, better code, a smarter agent. Same engine, same methodology. What changes is that the steps are enforced rather than remembered, the build happens somewhere that is not your working tree, and the whole thing survives you closing the laptop.

What runcastle actually adds

• Persistence. Every feature is a session on its own branch with its own memory. Several run at once. Knowledge is plain markdown committed to your repo, so it outlives runcastle if you stop using it.
• An enforced pipeline. Ideation → spec → tickets → build → review → shipped, with gates between the phases. They block by default and every one takes an override with a one-line reason that is recorded. Seatbelt, not cage.
• AFK ticket-burning. Sandboxed agents burn tickets inside Docker or Podman on your own machine, on the feature branch, with no human in the loop.
• Two clicks. Burn and merge. Those are the only two moments the system requires you.
• A browser UI at localhost:4512, served by a Bun server on your machine. MIT-licensed, installed with bun add -g runcastle, no account, no hosted backend, nothing leaves your machine that Claude Code was not already sending.

So do you need it?

Honestly: not yet, if the terminal is keeping up. The skills workflow is the good version of AI-assisted engineering and runcastle's entire claim is that it is worth systematizing — which is a compliment to it, not a replacement for it. Use the raw skills until you notice yourself doing the scheduler's job, losing decisions between sessions, or wishing a ticket could build itself while you did something else. Those three complaints are the whole reason runcastle exists, and if you do not have them, you do not need it.

If you do: bun add -g runcastle, then runcastle doctor. It runs on the Claude Code you already have, with the skills you already trust.