What xSwarm Is
A pipeline that takes an idea to production without a human in the QA loop — the concept, the purpose, and the principles it runs on.
xSwarm turns an idea into tested, deployed code without a human checking the work.
You describe what you want and approve it when it ships. Everything between — writing the test, writing the code, proving it works, cleaning it up, merging, deploying — happens on your own machine, and reports to a board you watch in a browser.
The purpose
Agents can write code quickly. The bottleneck is trusting it.
The usual answer is a person reviewing every change, which stops working the moment the system gets productive: the more work in flight, the more of a ceiling that person becomes. So the reviewing has to be done by the pipeline, and it has to be done in a way you can audit afterwards without re-reading the code.
That is the whole design goal. Not “agents that write code” — a workflow whose output you can trust without inspecting it.
How it works
npx xswarm login your machine, connected to your account
npx xswarm project add a project on that machine, visible on the board
idea ──▶ ticket ──▶ Planning ▸ Coding ⇄ Testing ▸ Refactoring ▸ Staging ▸ Deployed
│
you watch this happen live on the board ◀─────────────────────┘Work runs on your computer, in a git worktree per ticket. The website is where you file work and watch it move; it never holds your code. Deployment is a branch push your host already subscribes to — there is no CI service in the middle.
A ticket moves through six stages, and each one has to prove it finished. The proof is recorded evidence — a test seen failing, then seen passing, a commit that exists, a sha serving in production — not an agent’s report that it went well.
The principles
Everything here follows from one idea: a claim is not evidence.
Proven, not reported. A stage advances when its proof exists, and not otherwise. The pipeline once marked 91 tickets “deployed” that had never run an agent, because a sweep wrote the flag instead of the work earning it. Every rule below is a consequence of that.
Absent is not green. A check that could not run is not run — never a pass. A browser that failed to launch has verified nothing, and recording it as a zero is worse than recording nothing.
Derive, don’t store. Anything that can be computed at read time is. A stored copy is a clock someone has to wind, and it will drift from the thing it describes.
One rule, one place. When two pieces of code describe one reality, delete one. Three copies of the stage list meant a rename silently broke the merge queue while every number still looked healthy.
The test comes first, and it has to fail. A test written after the code proves the code does what it does. The first commit on every ticket is the test, red, because nothing implements it yet — and that commit is checked, not requested.
The work documents itself as it happens. Each attempt is a commit saying what was tried and whether it passed. Those commits become a pull request, the pull request carries the evidence and the scorecard, and the release tag ties it to a version. All of it written at the moment the work happened, by the thing that did it.
What you can inspect afterwards
- the board — where every ticket is, live
xswarm score— quality, stability, speed and token cost, per stage, per ticket, per release- the git history — one commit per iteration, each labelled red or green
- the pull request — the spec, every failed attempt and why, the refactor, the scorecard
- the release tag — which version carried which ticket
Your role
Ideation and final approval. Decide what should exist; say yes when it ships.
Not QA, not testing, not organising work, not babysitting agents. Those scale with the amount of work in flight, which is precisely why they cannot be yours.
If the system needs you to say “keep going”, that is a bug in the system.
Next: Getting Started to connect a machine · The Work Harness for the stages, the gates and the CLI in full