A task board for you and your coding agents: they claim the work, you merge it.
翻譯準備中
取自儲存庫 README
正在載入完整 README。 以下為已儲存的摘錄。
breakaway is a task board for you and your coding agents.
They claim the work. You merge it. Free, and it runs on your own Cloudflare account.
New in 1.5: every board is an MCP server, and breakaway’s plugin brings the board into Claude Code in one install. Read the release notes .
Paste this into Claude Code, in an empty folder:
It sets up your board with you: it runs and checks what it can, and stops for each step only you can do, like signing in or making a token. It never asks for a secret in the chat.檢視完整 README ↗Paste this into Claude Code, in an empty folder:
Set up a breakaway board for me. Read https://leavethepack.dev/install.md and follow it.
It sets up your board with you: it runs and checks what it can, and stops for each step only you can do, like signing in or making a token. It never asks for a secret in the chat.
You need a Cloudflare account, a GitHub account, and Node 20 or later. A Claude plan with routines lets the board start agents for you. Without one, the board works the same, and the agents you start yourself use the CLI.
Rather do it by hand? The self-hosting guide has the same steps, from an install repository (npx breakaway install init) to a board that starts agents and updates itself. Each step ends in a check on the board's Connections view.
Closes BRK-12. puts the task in review. The task is done when you merge it.Group tasks into a feature, aimed at a release, and press Chase. The board starts an agent on every ready task in it, and on every task that blocks it, in any area or repository, until each one is done or in review. You watch it on the feature’s page: what’s running, what waits on what, and what needs you.
npx breakaway features # features by release, their progress and chase
npx breakaway chase inbox-filters --dry-run # what a chase would start now
npx breakaway chase inbox-filters # start it
The peloton is where agents running at the same time check in with each other, so two of them never change the same file at once. Every repository has one, and every chase opens its own.
@ and an agent’s name reaches one.breakaway’s plugin for Claude Code puts the tasks skill, /breakaway:claim <ID>, /breakaway:next, /breakaway:hand-over, the session hooks that post a task’s output live and wake a session when you message it, and the board’s MCP server in one install.
/plugin marketplace add TheAnarchoX/breakaway
/plugin install breakaway@breakaway
Claude Code asks for your board’s address and its token, which it keeps in your system keychain. To turn it on for every session in a repository, the board’s cloud agents included, run npx breakaway repos init <slug> in its checkout.
Every board is an MCP server at its own address followed by /mcp. Claude Code, or any client that speaks MCP over HTTP, lists, claims, and comments on tasks with tools instead of the CLI, with the same token and the same rules. An app that signs in to MCP servers asks for a connection you approve on the board, with its own token for one repository and one agent name. npx breakaway mcp prints the line to add it.
New in 2.0.0. The board can run what your repositories run on too: environments, plans you approve, and incidents, in an Infrastructure view, pushes, and npx breakaway infra. Code still ships through the deploy flow; Architect looks after what exists around it.
.github/breakaway-infra/, started from what already runs. A pull request that changes one shows its plan as a check: what changes, what it costs, what else it touches, and whether it can be undone. Or change it yourself on an environment's console: the board opens the pull request, and Approve merges it and applies the plan.The Architect docs have the rest, and the manual's Architect section is the reference the code is written against.
Agents ping you when they need you. A question, a decision only you can make, or a task that looks done comes to your inbox, and as a push if you want one. The rest waits on the board.
Bring the people you trust. Invite them by a link you share by hand. Each signs in with a passkey, holds a role in each repository (maintainer, member, or viewer), and starts agents on their own Claude. Every change names who made it, and a plan can wait for two people to approve. You stay the owner: the token always signs you in.
From a pitch to a deploy. Kick off a project from a few lines in your own words, read each repository's specs beside their tasks and refine one with an agent, group tasks into features on a roadmap and chase one, and move a repository to breakaway's deploy flow, all in pull requests you merge.
npx breakaway next --claim --as claude-brk-12
npx breakaway comment BRK-12 "The inbox sorts by age."
npx breakaway list --ready
One Cloudflare Worker serves the API, the MCP server, the web app (Preact), and Taskwarrior sync, and one SQLite Durable Object holds every task, claim, comment, and change. The board reads GitHub through a private GitHub App you make for it, and starts cloud agents through a Claude Code routine you save. Architecture has the rest.
| Read | For |
|---|---|
| Run your own board | From nothing to a board that starts agents and updates itself |
| Concepts | Tasks and work IDs, areas, horizons, claims, dependencies, and how a pull request closes a task |
| Playbook | Write tasks agents finish, run many agents without collisions, and keep the review load to one person |
| Agents | Cloud agents from the board, local agents, limits, live output, and messaging a running agent |
| The web board | The views, a task's panel, Settings, and each repository's page |
| Features, chase, and the peloton | A roadmap of features, a chase that starts agents on what's ready, and agents checking in with each other |
| Ideas, decisions, and pings | Let an agent shape an idea, answer its questions in a form, and get a ping when only you can help |
| Routines | Save an agent run and start it by hand, on a schedule, or on a GitHub event |
| People and roles | Invite the people you work with, give each a role per repository, let them start agents on their own Claude, and ask two people to approve |
| Get started with Architect | From a read-only token to your first approved plan |
You need Node and pnpm.
pnpm install
pnpm dev # the board, locally
pnpm test # the tests
pnpm build # the web app
pnpm interop # checks sync against real Taskwarrior 3
pnpm interop needs Taskwarrior 3 on your PATH.
| Path | What |
|---|---|
src/ | The Worker: the API, the TaskStore Durable Object, GitHub, routines, pings, push, sync |
web/ | The board's web app (Preact and @preact/signals) |
scripts/tasks.mjs | The CLI |
prompts/ | What the agents the board starts follow, and the install prompt |
site/ | The website, the docs, and the update feed |
brand/ | The brand guide, tokens, and logo |
test/ | Tests, run in the Workers pool |
breakaway publishes releases and never deploys an install. Every install, the owner's included, deploys a release from its own repository, and this repository holds no Cloudflare credentials. Its website follows the latest stable release: the release moves the site branch, and Cloudflare deploys it (site/README.md).
vX.Y.Z-main.N on the main channel is the owner's too: merging publishes nothing, and they run the Release workflow on main with prerelease left empty to publish one of main's latest commit, once CI has passed on it. It carries the bundle (breakaway-bundle.tar.gz: the Worker's files and the web app's dist), a manifest.json (version, channel, commit, manual, and the lowest version it updates from), its signature manifest.json.sig (Ed25519, made with a key only the release workflow holds; the public key is src/release-key.js), and SHA256SUMS. The notes list the pull requests merged since the last release by title, and the bundle's dist/whats-new.json carries them, with the notes since the last stable, for the board to show once it runs the release: a dialog after a stable, a small note after a pre-release.vX.Y.Z is the owner's: they run the Release workflow with the pre-release to promote as prerelease. The bundle is that pre-release's, unchanged, and the notes cover everything since the last stable, under the release's own words from docs/releases/vX.Y.Z.md when it's there.breakaway, staged on npm by the same workflow, with provenance, and live once the owner approves it there with 2FA. npm's trusted publishing can't yet read the OIDC identity of a repository as new as this one (npm/cli#9969), so until it can, a token that can stage but never publish by itself stands in, in an environment only main can use. Every pre-release goes out under the next dist-tag, and a stable release as latest. npx breakaway <command> is node scripts/tasks.mjs <command>.plugin/) goes out from the plugin branch, never from main: Anthropic's plugin directory and this repository's marketplace follow that branch. A stable release runs the Plugin workflow, which validates the plugin and moves the branch to the released tag, with 's version set to the release's. To put a fix out before the next release, the owner runs it by hand on with a release tag, or a commit on a pre-release was made from. As with , a ruleset lets only deploy keys move , and the key is the secret in a environment that only can use.breakaway is built by its owner and their agents, and takes no pull requests or issues from anyone else, apart from a licence exception request: CONTRIBUTING.md says what you can do instead, and the contributor licence agreement you sign on the pull request if the owner ever takes one from you. Report a security problem privately, as SECURITY.md says. The agents follow AGENTS.md, and anything people see or read follows the brand guide.
breakaway is free for personal and noncommercial use, under the PolyForm Noncommercial License 1.0.0: personal use, charities and nonprofits, education, public research, and government use it free. Commercial use is by exception, granted case by case by the owner, and leavethepack.dev/licensing says who can ask and how (LICENSING.md has the same words, next to the code).
The licence applies from 2.0.0. Every release before it stays under FSL-1.1-Apache-2.0, in LICENSE-FSL.
breakaway works with Claude Code, GitHub, Taskwarrior, and Cloudflare. None of them made it or endorse it.
| Architect | Environments, plans you approve, policy, envelopes, signals, incidents, cost, freeze, break-glass, patterns, and what agents may and may not do |
| Architect and the deploy flow | Deploy, Promote, and Roll back your app, and approve plans for what it runs on, on the same staging and production |
| The CLI | Every command of npx breakaway |
| The Claude Code plugin | The tasks skill, /breakaway:next, the session hooks, and the MCP server in one install, for you or a whole repository |
| MCP clients | Connect Claude Code or any MCP client to your board's /mcp, and sign in from any app that speaks MCP |
| GitHub | Your own private App, how pull requests link to tasks, merging, and moving a repository to the deploy flow to promote, roll back, and release |
| Taskwarrior | Sync, reports, and contexts with Taskwarrior 3 |
| Deploying | Releases, channels, the Deploy and Update workflows, and rollbacks |
| Operating a board | Secrets, what to keep and what to do when it's lost, backups, and what to do when something breaks |
| FAQ | The licence, your data, what it works with, and what it won't do |
plugin.jsonmainmainsitepluginPLUGIN_DEPLOY_KEYpluginmainmanual: true, which an install's deploy stops on. A change that needs it sets manual and manualSteps in release.json, and the pull request that ships the steps clears them. When the only step is wrangler deploy (a new Durable Object class, a cron, a route), it also sets wranglerDeploy: true, and an install whose Deploy may run wrangler deploy does it itself (the install template's README says when). Data the Durable Object stores changes forward-only and additively, so an install can always go back one release, except across a new Durable Object class, which Cloudflare doesn't roll back.package.json's; the release workflow sets it to the pre-release's before it builds. Patches count by themselves: once a stable is out, the pre-releases work toward its next patch. For the next minor or major, pick it as next when you run the Release workflow (patch, the default, opens nothing): once the stable is published, the workflow opens a pull request setting package.json to it, and after it merges the next pre-release is vX.Y.0-main.1. That needs Allow GitHub Actions to create and approve pull requests on in the repository's Actions settings (if it was off, turn it on and re-run the next version job: it opens the pull request from the branch it already made), and a pull request opened with the workflow's token starts no workflows, so close and reopen it, or push to it, for CI to run. At any other time, Prepare on the board's GitHub view starts an agent that opens the same pull request. GET /api/ping and GET /api/health report it as release. An install that deploys a stable passes it as the BREAKAWAY_VERSION variable, since the bundle was built as the pre-release.