Product manager
Turns the PRD into a backlog of stories with acceptance criteria and measurable goals.
Nebula Swarm: A Full Engineering Team, Installed in Your Repo.
Nebula Swarm is an agentic engineering harness. It gives your AI coding tools a product manager, an architect, developers, a tester and an independent reviewer, then makes them work the way a good team does: plan first, build in small tickets, review everything, write down what they learned. Every one of those steps serves one outcome: higher-quality software. In Deliveri's first six weeks, that meant 7,673 automated tests and 0 production rollbacks.
It installs into your repository and runs in the terminal inside your IDE, on the AI models you already pay for. We set it up with your team in a one-day on-site Rollout.
Works Where You Already Work.
No new IDE and no new chat window. Nebula Swarm drives the coding CLI your team already uses, files its work in your tracker and opens pull requests on your Git host.
- AI models and CLIs:
-
- Claude Code
- OpenAI Codex
- Gemini CLI
- GitHub Copilot
These four work out of the box. Nebula Swarm also runs on other models, including DeepSeek and local LLMs, when you point one of these tools at them. Task state lives in files, so you can switch models mid-task.
- Dev tools:
-
- GitHub
- Jira
- Confluence (read-only)
Jira and Confluence are optional. Nebula Swarm has its own ticket board and project memory, kept as plain files in your repo.
- IDEs:
-
- VS Code
- Cursor
- JetBrains
- Any terminal
One Lifecycle, Four Phases, Humans at the Gates.
Every piece of work goes through the same loop. Agents do the drafting, building and checking. People make the calls that matter: approve the plan, answer open decisions, merge the pull request.
-
Plan: turn a PRD into tickets.
Specialists draft in parallel; one combined plan; tickets in dependency order.
/prd-planfor a new product,/prd-extendfor one you already have,/task-createfor a single ticket. On an existing repo,/repo-scanprimes memory first.PM · architect · UX · dev manager
You approve the plan.
-
Build: each ticket on its own branch.
Plan, build and review per ticket, several tickets at once.
/dev-taskfor one ticket,/dev-autopilotfor many in parallel.developers · architect · reviewer
You approve each ticket plan, or let autopilot run.
-
Test & Review: nothing merges unchecked.
Tests mapped to requirements, an independent reviewer, your CI, a human merge.
/dev-task-review, the last phase of every/dev-task.tester · code reviewer · you
You merge.
-
Learn: write down what happened.
Conventions, repo map, glossary and lessons updated after every ticket.
Memory updates run in every review.
/update-oracleshares them across repositories.project manager
Project memory, in files in your repo. Read at the start of every phase, written at the end of every ticket. The next ticket starts smarter than the last one.
The loop runs per ticket. Learn feeds the next Plan through project memory.
A Written Plan Before Any Code.
You bring a product requirements document. Nebula Swarm turns it into a reviewed plan and a ticket backlog your team can read, argue with and approve.
Seven Drafts, Merged Into One Plan.
One command, /prd-extend, starts seven planning agents in parallel. Three product managers draft backlogs, two architects and two UX designers set constraints, and a reducer merges all seven into one plan.
- Several specialists draft in parallel. By default three product-manager drafts of the backlog, two architecture drafts and two UX drafts, each written from a different angle: pragmatic, security-first, user-obsessed, conservative, cost-aware.
- The drafts are compared and combined into one gold plan. A reducer agent reads every draft, keeps the best ideas, resolves contradictions and writes down why. The same happens for the implementation plan and task graph.
- Gaps are found and fixed. An audit checks the plan against every section of the PRD and adds tickets until coverage is complete.
- Open decisions go to a person. A planning gate report lists the risks and unresolved questions, with a pass or fail verdict. You answer them before anything is built.
- The plan becomes tickets, in order. Each ticket carries acceptance criteria, a definition of done, the PRD sections it comes from and the tickets it depends on. They land in Jira, or in files in the repo.
Every Ticket Gets Its Own Mini-Project.
Tickets don't go straight to a coding agent. Each one is planned, built and reviewed in its own isolated workspace, and several run side by side. Run /dev-task for one ticket, or /dev-autopilot for many at once.
- Its own branch and worktree. Each ticket gets an isolated git worktree with its own dependencies and ports, so parallel tickets never step on each other.
- Plan the ticket. The architect drafts an implementation plan, the tester drafts a test plan and the doc writer drafts a documentation plan. The reviewer approves or rejects each one, up to ten rounds.
- Build it. A backend, UI or full-stack developer agent writes the code against the approved plan. The reviewer checks the diff; if it's rejected, the developer reads the feedback and goes again.
- Run your checks. Your own lint, typecheck, test and build commands run before anything is committed. Failures go back to the developer with the error output.
Autopilot: Many Tickets, One Approval.
Pick a set of tickets, or everything that's ready, and run /dev-autopilot. Nebula Swarm plans which ones can safely run in parallel, shows you that plan once, then drives each ticket through plan, build and review with no further prompts. Up to six run at a time by default, each with time limits and a retry budget. Finished work lands on a separate integration branch, and you review one pull request into main.
At Deliveri the goal is to keep the crew working around the clock: queue approved work before signing off, review it in the morning, and queue the next batch. In the last 14 days measured, at least one agent was working about 12.5 hours a day on average, and the agents logged about 32 agent-hours of work a day across parallel tickets. [confirm: founder estimates 16–19 hours a day including the second director's machine, which the audit didn't capture]
Checked by Someone Who Didn't Write It.
The agent that writes the code never approves it. Review is a separate agent with a separate brief, and the last word is always a person's. This is where Nebula Swarm's quality comes from: the reviewer won't pass a ticket while a fixable problem remains, so fixes happen on the ticket's own branch, before the work reaches main or your users.
Adversarial Review on Every Plan and Every Pull Request.
Every reviewer is a separate agent with one brief: find what's wrong. It has to reject while any fixable problem remains, and say exactly what to change. The author fixes those gaps and resubmits, and nothing is approved while a fixable gap is still open.
None of them grade their own homework.
In this run, the code-reviewer sends the dev-manager's plan back with two gaps. Plan v2 fixes both, and only then does it come to you for approval.
Who Checks What.
The run plan
Which tickets run in parallel, from the dev-manager
Checked by the code-reviewer, before any code
Each ticket's plans
Implementation, test and docs plans, from the architect, tester and doc writer
Checked by the code-reviewer, before any code
The code
From a backend, UI or full-stack developer agent
Checked by the code-reviewer, against the approved plan
The pull request
The finished ticket, with its tests and docs
Three verdicts, all required: the code-reviewer, a full test run by the tester, and a docs check by the doc writer
The plan and the merge
Every run, before work starts and before it lands
A person on your team approves the plan and merges into main
Each loop runs until the reviewer approves: up to 10 rounds for a ticket's plans, code and review, and up to 5 for the run plan. Only an approved draft is carried forward to the next step.
Why Does Nebula Swarm Do All This Extra Work?
Because it produces better software. Nebula Swarm is built to catch problems before they merge, not after. The reviewer's own brief says: “When in doubt, reject. It is cheaper to do one more iteration than to ship a known issue.”
What you get is code your team can trust, and room to take on more complex products. Optiverse, the real-time desktop app for options traders that our co-founder Claudio Cannizzaro built with Nebula Swarm, is one example.
In Deliveri's first six weeks on Nebula Swarm, nothing was rolled back in production, and both hotfixes fixed dev, not production.
- Requirements mapped to tests. Every ticket records which PRD sections it serves. The tester agent writes a test plan that covers every acceptance criterion, then writes and runs the tests.
- An independent code reviewer. The reviewer reads the pull request against the approved plan and your conventions. It is told to reject when a fixable problem exists, and it sends the work back with a written report.
- Three verdicts, all required. Code review, a full test run and a documentation check each return approve or reject. Any rejection sends the ticket back to the developer.
- Nothing quietly dropped. A finding that genuinely can't be fixed in this ticket becomes a new ticket, typed as a bug, task or story.
- Your CI, then a human merge. Nebula Swarm, by default, never merges to main on its own. The pull request goes through your CI and waits for your team.
- developer
- reviewer
- tester
- your CI
- your engineer merges
The Team Remembers.
Every agent writes a short retrospective. After each ticket, a project-manager agent turns them into lasting project memory, stored as plain files in your repo and reviewed in the same pull request as the code.
- Conventions
- How this codebase does things: patterns, naming, the commands that must pass.
- Repo map
- What lives where, updated with every new or changed file.
- Glossary
- Your domain terms, so agents use your words.
- Lessons
- Project-wide, plus one file per agent role: what went wrong last time.
- Design records
- One per ticket: what was built and why.
- Knowledge
- Lessons that proved themselves, promoted to standing guidance.
Agents read this memory before they start the next ticket. During the Rollout we prime it with /repo-scan, which scans your existing codebase, and every item it records must cite a file in your repo.
Memory updates run as part of every /dev-task-review. If your product spans several repositories, /update-oracle also loads what each one learns into a shared knowledge graph.
The Crew.
Fourteen specialist roles, each with a narrow brief and a defined hand-off. You can add your own.
Architect
Sets module boundaries and contracts for the product, then writes each ticket's implementation plan.
UX designer
Writes user flows, a component inventory, states and accessibility rules. No code.
Reducer
Compares the competing drafts and combines them into one gold version, with its reasoning written down.
Dev manager
Breaks the plan into small tickets and a dependency graph, then files them in your tracker.
Backend developer
APIs, schemas, validation, persistence and the tests that go with them.
UI developer
Frontend components, state and client-side logic, themeable and accessible.
Full-stack developer
End-to-end slices across frontend and backend, with the contract kept in line.
Tester
Maps acceptance criteria to tests, writes and runs them, and reports coverage.
Code reviewer
Reviews every plan and every diff. Approves, or rejects with a written report.
Doc writer
Plans and updates the docs that each change needs, with examples.
Project manager
Runs the planning gate and turns every retrospective into project memory.
Research assistant
De-risks unknowns: libraries, APIs, existing patterns. Also audits plans for coverage.
Repo scanner
Reads an existing codebase and primes memory with conventions, a repo map and a glossary.
What Makes It Work.
Six design choices sit underneath the lifecycle. Each one is how the harness is actually built, not a setting.
Multi-LLM.
Runs on Claude, Codex, Gemini or Copilot. One set of agent and workflow definitions serves all four, so you aren't locked in to one vendor.
How it works
- One definition layer. Agents and workflows live once in the repo; each platform gets a thin wrapper that points to them.
- Same dispatcher for every CLI. Unattended runs go through one wrapper that knows each CLI's flags.
- Task state lives in files, not in a chat. Each phase starts by rebuilding its context from a checklist and a hand-over file, so a different model can pick up a task mid-flight. [confirm: cross-model hand-off tested end to end]
Token-Efficient.
"Deliveri runs Nebula Swarm mostly on a single Claude Max 20x plan."
Founder-reported, not measured.
More agents doesn't have to mean a bigger bill. The harness spends tokens on the work, not on re-reading everything.
How it works
- Each agent gets only what it needs. A developer reads the approved plan and the lessons for its role, not the whole planning history.
- Phases are scoped. Plan, build and review each run in a fresh context window and end with a short hand-over.
- Memory lives in files. Conventions, repo map and lessons are read on demand instead of being carried in the context window.
- The right model for the job. The default Claude setup puts the strongest model on architecture, review and synthesis, and lighter models on documentation and memory upkeep.
Context Discipline.
Long AI sessions drift: the context fills up and quality drops. Nebula Swarm is built so no single session has to hold the whole job.
How it works
- The coordinator stays thin. It reads routing data and approve/reject verdicts, never the plans, code or reviews themselves. The agents that need those load them.
- Hand-offs are files with fixed names. Draft, review, verdict, retrospective: every step leaves an artifact the next one can find.
- Autopilot summarizes in one line. A separate analyzer reads each finished phase and reports proceed, retry or fail.
- Memory must cite your code. When Nebula Swarm learns an existing repo, anything it can't tie to a file is dropped, so agents aren't misled by generic advice.
Extensible and Malleable.
Nebula Swarm is a set of plain text files in your repo, so you can read it, change it and add to it like any other code.
How it works
- Add your own agents and workflows. They're markdown files; a built-in agent writes new agent definitions from a description.
- It follows your conventions. Your build, lint, typecheck and test commands live in one config file, and your house rules live in the instruction file every agent reads.
- It adapts to an existing repo. A repo scan records your patterns and terms before the first ticket.
- Upgrades keep your changes. Re-running the installer refreshes the framework and leaves project memory alone, with a backup of anything it overwrites.
Mono-Repo or Multi-Repo.
Works in a single repository out of the box. If your product spans many, a shared knowledge graph links them so agents can see across the boundaries.
How it works
- One graph, many repositories. Each repo's code and docs are summarized and loaded into a shared knowledge graph, then updated after every ticket.
- Agents query it while planning. The architect asks how other services behave before it writes a plan.
- Answers say where they came from. Facts are labelled with their source repo; other repos are treated as contracts to respect, not code to change.
- Optional. It needs a knowledge-graph server you host. Without one, everything else works and the step is skipped.
Built for a Whole Team in One Repo.
Several people, each running their own agents, can work in the same repository at the same time without stepping on each other.
How it works
- Every ticket gets its own workspace. Each task runs in a separate git worktree on its own branch, with its own dependencies and its own local ports, so two builds never share files or a dev server.
- Tickets are claimed before work starts. A ticket moves to In Progress with an owner before anyone builds it, and the local tracker claims it under a file lock, so two people can't pick up the same work.
- Merges happen one at a time. The merge step takes a lock, rebases onto the latest code and only then merges. If real code conflicts appear, it stops and hands them to a person rather than guessing.
- Nothing lands on main directly. Every change arrives as a pull request a human merges, so the shared branch stays clean.
Nebula Swarm vs AI Coding Tools Alone.
AI coding tools are good at writing code when someone tells them exactly what to write. Nebula Swarm adds the parts of an engineering team that sit around the code.
| Compared | AI coding tool alone | With Nebula Swarm |
|---|---|---|
| What it's built for | Writing the code you asked for, quickly. | Quality first. Each change reaches your engineer already planned, tested and challenged. |
| Planning before code | Whatever the person prompting writes down, if anything. | A PRD becomes a reviewed plan and ordered tickets before any code is written. |
| Independent review | The same session that wrote the code checks it. | A separate reviewer agent approves or rejects every plan and diff, then a person merges. |
| Tests mapped to requirements | Tests when asked for, with no link back to the spec. | Every ticket traces to PRD sections; the test plan covers every acceptance criterion. |
| Project memory | Starts each session from scratch, or from one hand-written notes file. | Conventions, repo map, glossary and lessons, updated after every ticket. |
| Multi-model | One vendor per tool. | The same workflows on Claude, Codex, Gemini or Copilot. |
| Jira and Confluence | Copy and paste. | Tickets created and moved in Jira, or on the built-in board in your repo; Confluence specs read directly. |
| Team trained | Each engineer works it out alone. | A one-day on-site Rollout trains your team on your own codebase. |
What Changed When Deliveri Installed Nebula Swarm.
- 7,673Automated tests added in Nebula Swarm's first six weeks, against 56 from the human team in two years.
- 0Production rollbacks over the same six weeks.
- 15.2 h → 3.3 h Median build time per ticket.
- 2.0 → 29.4 Tickets completed per week.
Human team (109 weeks) vs. first 6.2 weeks on Nebula Swarm. From git, GitHub, Jira and CI history. Rollbacks are counted for the Nebula Swarm period only; earlier periods have no deploy records.
See It on Your Own Codebase.
On a scoping call we look at your repositories, your roadmap and the AI tools you already pay for, and tell you plainly whether Nebula Swarm fits. If it does, we install it in one day on site and train your team on real tickets from your backlog.