How rdn-swarm works

The seven-phase pipeline that turns a requirements doc into a tested, scored app.

rdn-swarm works like a small software team. You write down what you want. An Analyst turns that into a plan with testable criteria, a Project Manager splits the work, developers build in parallel, and QA reviewers check the result. The build is scored, and the team goes round again until you're satisfied.

Everything runs on your phone. Each agent is a call from your phone straight to the AI provider you assigned it. There is no rdn-swarm server in between.

The pipeline#

Every run moves through seven phases. The phase track on the live dashboard shows them as seven nodes, and you can tap a finished or active node to see its detail.

Track label: REQ
Phase: Requirements
Who does the work: Analyst, with the Test Author
What happens: Reads your requirements doc and produces a structured plan with numbered acceptance criteria. The Test Author turns the functional criteria into executable tests.

Track label: PLAN
Phase: Planning
Who does the work: Project Manager
What happens: Breaks the plan into files and assigns each file to one developer, so no two developers write the same file.

Track label: DEV
Phase: Development
Who does the work: Developers, in parallel
What happens: Write the assigned files. From the second iteration on they edit existing files rather than rewriting them.

Track label: INT
Phase: Integration
Who does the work: Integration Architect
What happens: Checks that the files fit together: HTML ids used by the JavaScript exist, CSS classes match, imports resolve. It patches what's broken.

Track label: QA
Phase: QA Review
Who does the work: QA reviewers, Visual QA, acceptance tests
What happens: Reviewers independently read every file and report issues. In Visual or Interactive mode, Visual QA also inspects screenshots of the running app. The acceptance tests are executed.

Track label: FEED
Phase: Feedback
Who does the work: Feedback Coordinator
What happens: Merges and de-duplicates the findings, then computes the Quality Scorecard.

Track label: SUM
Phase: Summary
Who does the work: Summary Generator
What happens: Writes a README of what was built. Runs once, when the loop ends.

#	Track label	Phase	Who does the work	What happens
1	REQ	Requirements	Analyst, with the Test Author	Reads your requirements doc and produces a structured plan with numbered acceptance criteria. The Test Author turns the functional criteria into executable tests.
2	PLAN	Planning	Project Manager	Breaks the plan into files and assigns each file to one developer, so no two developers write the same file.
3	DEV	Development	Developers, in parallel	Write the assigned files. From the second iteration on they edit existing files rather than rewriting them.
4	INT	Integration	Integration Architect	Checks that the files fit together: HTML ids used by the JavaScript exist, CSS classes match, imports resolve. It patches what's broken.
5	QA	QA Review	QA reviewers, Visual QA, acceptance tests	Reviewers independently read every file and report issues. In Visual or Interactive mode, Visual QA also inspects screenshots of the running app. The acceptance tests are executed.
6	FEED	Feedback	Feedback Coordinator	Merges and de-duplicates the findings, then computes the Quality Scorecard.
7	SUM	Summary	Summary Generator	Writes a README of what was built. Runs once, when the loop ends.

Phases 1 to 6 make up one iteration. Phase 7 runs once, after the last iteration.

The loop#

At the end of each iteration the swarm scores the build and, by default, checks in with you. You can accept the build or send it round again.

A second iteration doesn't start from scratch. The Project Manager assigns work only on the files with open issues, the developers patch those files in place, and QA reviews again. This bug-fix loop is how a score rises from, say, 70 to 92 over a couple of passes.

The Analyst runs again only if you've added a note since the last iteration, because only the Analyst can decide whether your note means a new or changed acceptance criterion.

Nothing stops the loop on its own except you and the limits you set. Iterations and check-ins covers Autorun, Max iterations and Max cost.

What a run produces#

Source files: the app itself, usually HTML, CSS and JavaScript for the bundled projects.
Docs: docs/SUMMARY.md (the README), docs/requirements.md (the brief the run used), and docs/notes.md if you added notes.
Screenshots of the running app, when QA mode is Visual or Interactive.
A scorecard for every iteration, and a per-call ledger of tokens and cost.

All of it is stored on your phone. You can browse it under Output, run it in App Preview, and export it as a zip. See Review output and preview the app.

Why several models instead of one#

Each role can use a different provider and model. That means you can:

put a strong reasoning model on the Project Manager, which has to plan the whole build, and cheaper, faster models on the parallel Developers;
have QA review with a different model from the one that wrote the code, so its blind spots don't match the developers';
compare providers fairly on the same brief, using the Data tab's Leaderboard.

See Agent roles for what each role needs from its model.