The Swifter Manifesto
A short, shared set of principles for teams delivering software through Swifter. Modelled on the Agile Manifesto, but expanded — because Swifter is not a methodology, it is a way of running a real SDLC with specialised AI agents under human steering. It is grounded in the existing onboarding documentation (What is Swifter?, Agentic SDLC, Project Guidelines, Work-Item Composition / Lifecycle, Scope Breakdown, Monitoring, Roles).
The shift
Generic chat-style LLM coding — "vibe coding" — produces a different result every time the prompt is rewritten. There is no separation of analysis from implementation, no spec the next person can read, no convention enforcement, no test discipline. Every change is a roll of the dice, and reviewers carry the consequence.
Swifter replaces that with a real software-development lifecycle: specialised agents, each with a narrow proficiency, working off shared inputs and producing artefacts the next agent can read. The proficiencies of a full team — analyst, developer, tester, architect — do not disappear; they shift from typing code to writing specs, reviewing agent output, and amending the guidelines.
The whole point: the same work item, run twice, produces the same software — because the structure does.
The agents behind the flow
Each phase is carried by a specialised agent with a narrow proficiency, invoked through its own
commands. Analysts produce specs and never write production code; developers translate the spec into
code; the tester turns acceptance criteria into runnable scripts; the architects sit across every
phase, producing the guidelines that every other agent reads on every run (Principle 11). Most work
items enter through swifter-default:/start, which triages and routes to the right agent.
Cross-cutting: the architects (swifter-backend-architect, swifter-database-architect,
/create-guidelines) sit outside this strip — the guidelines they produce are read as inputs on
every run of every stage above.
What we value
We are uncovering better ways of building enterprise software with AI. Through this work we have come to value:
| We value… | …over… |
|---|---|
| Reviewed specifications | ad-hoc prompts |
| Specialised agents in sequence | one all-knowing generator |
| Verification at every handoff | inspection at the end |
| Atomic, traceable work items | bundled, untracked changes |
| Living guidelines used as inputs | documentation read once and forgotten |
| Humans at decision points | humans in every keystroke — or no human at all |
That is, while there is value in the items on the right, we value the items on the left more.
The principles
How we shape the work
1. The specification is the contract. Agents produce a structured spec — data model, presentation model, logic, acceptance criteria — before any code, and the human reviews the spec, not the diff. Code is the spec's mechanical translation. Disagreements are settled in the spec, where they cost minutes — not after implementation, where they cost a session.
2. One scope per work item. One component, one page, one integration — never "and also." When a description grows a second clause after the main verb, split it. Two small work items finish faster and more reliably than one ambiguous one; bundling is the leading cause of abandoned sessions.
3. State what is out of scope. The single highest-leverage line in a work item is "X is out of scope; use mocked data." Without it, the agent helpfully builds adjacent functionality nobody asked for. The scope-out line is the cheapest defence against drift.
4. Agents read literally.
Quote every label, enumerate every enum value, write rules as IF <condition> THEN <state>. Never
write "as per design." The agent copies quotes faithfully and paraphrases prose unpredictably — so
name the sources of truth, not the implementation steps.
When a work item carries more than one example of the same thing — a Figma screen and the source JSON behind it — the data must match across both, field for field. Mismatched placeholders force the agent to guess — and it could guess wrong. See Work-Item Composition → Keep example data consistent.
How we run the lifecycle
6. Separate the proficiencies. Each agent owns one narrow job: the analyst never writes production code, the developer never invents requirements, the tester never writes implementation. A single goal per step is what lets a reviewer know exactly where to look for which kind of mistake.
7. Build verification in, don't bolt it on. A human gate sits at every handoff — the tech lead validates scope before the analyst runs, the BA compares the generated spec to expectation (~90% match) before the developer runs, QA reviews the scripts before they execute. Catch the problem where it is cheapest to fix, not at the end.
8. Fix the contract before you parallelise.
Frontend and backend build independently only once the API contract is fixed; they converge at
integration. Make every dependency explicit — linked WI, blocked by — because implicit ordering
("everyone knows X comes first") becomes mis-ordered execution within a week.
9. Humans decide; the platform drives. The platform runs the structured flow — spec → build → integrate → test — and the human supervises at defined decision points. We do not direct the machine keystroke by keystroke, and we do not let it run unattended.
How we protect quality over time
Before development starts, think the project through at a high level — the solution design, and the conventions and patterns you want the code to follow (code style, naming, API conventions). Write them into the project's Swifter knowledge up front, not after the fact. Agents generate against whatever is already there on day one: seed it deliberately and the very first output matches your expectations with far higher probability, instead of converging only after rounds of correction. This is the proactive twin of Principle 11 (guidelines are inputs) and Principle 12 (encode each mistake once) — set the standard before the mistakes, not only after them.
11. Guidelines are inputs, not documentation. The per-module guideline files are read on every generation run, not on day one and then forgotten. A project that treats them as documentation drifts week over week; a project that treats them as inputs converges — the same shape, the same imports, the same error-handling in every generated file.
12. Encode each mistake exactly once. When an agent gets something wrong, the fix becomes a guideline entry, a knowledgebase note, or an implementation hint — so it is never re-explained prompt by prompt. A growing hints section is a signal that the guidelines or the platform need an update; a shrinking one means the platform is improving.
13. Keep the discipline total. Any change to the code is a work item — even a small one. No hand-edits that bypass Swifter. Traceability and repeatability only hold when nothing leaks around the side.
14. Fix the input and rerun in place.
When a work item fails because its data or description was wrong, amend it and rerun the same
session. Do not spawn attempt-2, attempt-3 — each respawn loses the previous context and
litters the backlog. Spawn a new work item only when the scope itself was wrong.
How we deliver and improve
15. Ship vertical slices. Swifter is a tool, not a methodology. Keep your normal Agile/SCRUM cadence and deliver full working increments — frontend, backend, and tests — every layer the increment needs to actually run. The only additions are two ceremonies that protect description quality: spec review and AC review.
16. Stay on the standard stack. The output is normal code in a normal Git repository on mainstream frameworks — no proprietary runtime, no lock-in. The platform is the system of record; the IDE is a finishing tool over the same artefacts. If Swifter left tomorrow, the codebase would keep running.
17. Measure together, and honestly. Establish the team's own baseline at the start and compare against it. Read the headline metrics (automation, manual intervention, verification pass rate, code churn) as trends, not snapshots, and never quote a percentage the platform cannot actually produce.
The platform is its own best documentation. When you are unsure how something works — a workflow, a guideline, a step in the lifecycle — create a work item and ask the question there. Swifter answers from the same artefacts it builds against, so the reply is grounded in your project, not generic advice. Asking in a work item also leaves the answer where the next person will find it, instead of burying it in a chat thread.
In one line
Write the spec, scope it tight, let the right agent build it, verify at every handoff, and encode what you learn — so the next run is better than the last.