The One-Day Rollout: Your Team Ships Real Tickets Before We Leave

We spend one full working day in your office, install Nebula Swarm in one of your real repositories and train your team on a real project from your roadmap. We return for one day at day 15 and one day at day 30. The aim is to leave quickly and leave your team able to run Nebula Swarm without us.

By 17:30, Before We Leave.

  1. Every trained seat has shipped a real ticket from your backlog. Each one went through plan, build, independent review and a human merge.
  2. Your first overnight run is queued. Approved tickets build while the team is offline, and the team reviews the results the next morning.
  3. Nebula Swarm is installed and has learned your repo. It holds your conventions, decisions and glossary, and it runs your own test and lint commands.
  4. Your next project is planned. It has a PRD and ordered tickets, and a named internal champion who writes the runbook before day 15.
[Image placeholder: the client team around one screen during the afternoon review session, with a PR diff and the reviewer's verdict visible. 4:3, real photo from a rollout, no stock.]

Four Touchpoints Over About Six Weeks.

Most of the work happens in the day on site. After that, the two check-ins measure the team against its baseline and deal with whatever is slowing it down.

  1. Prep. 2 weeks before [confirm]. Access, accounts, the project brief and the baseline export.Your side, remote
  2. The Rollout day. Deploy & Scope in the morning, Plan at midday, Build & Review in the afternoon.On site
  3. Day 15 check-in. Measure, unblock, and watch the team plan its next project on its own.On site [confirm: or remote]
  4. Day 30 check-in. Extend Nebula Swarm with your own agents and skills, and hand it over.On site [confirm: or remote]

Eight Things to Have Ready.

The day runs on these. With one day on site, anything missing costs us the morning. Please finish them by [confirm: 5 business days] before the Rollout day. We hold a 30-minute prep call to go through them with you.

  • Repository access.

    Write access to the chosen repo for the two Sidera Labs trainers, permission to open branches and pull requests, and visibility of CI runs. SSH to GitHub must not be blocked on the office network.

    Owner: Eng lead

  • AI tool accounts.

    A working seat for every trainee on your AI coding tool (Claude Code, Codex, Gemini CLI or GitHub Copilot), with a spend limit agreed. Each engineer also needs the GitHub CLI signed in. Windows laptops need WSL.

    Owner: Eng lead · every trainee checks their own login

  • Jira and Confluence, if you use them.

    Admin access to the Jira project where Nebula Swarm will file tickets, plus an API token. Without Jira, Nebula Swarm files tickets on its own board, kept as plain files in your repo. Confluence is optional and read-only, used when your PRDs link to existing specs.

    Owner: QA/EM or Jira admin

  • One real project.

    Choose a roadmap item the team would build anyway, sized at [confirm: 2–6 weeks] of human work, in the repo above. Bring a one-page brief. We turn it into the PRD on the morning of the Rollout day.

    Owner: Product/PM with the eng lead

  • One small job per author.

    For each person who will run Nebula Swarm, one small piece of real work, such as a bug or a copy change, that can be planned, built and merged in an afternoon. A sentence each is enough. It becomes the ticket they ship before we leave.

    Owner: Eng lead with product/PM

  • Named attendees.

    One name per role: eng lead, engineers, product/PM, design and QA/EM, plus the internal champion who will own the runbook. Block their calendars using the hours table below. Five seats are included, and up to [confirm: 10] people can be in the room.

    Owner: Champion

  • Baseline metrics export.

    The last [confirm: 90 days] of Jira issues with status-change timestamps, the merged-PR list, and CI results. We use the measures from the Deliveri story: median build time per ticket, tickets completed per week, and tests added. We run your export through them before the day.

    Owner: QA/EM

  • A room and a big screen.

    One room for the whole day that seats everyone, with a shared screen and space for engineers to pair. The morning splits into two tracks until 10:30, so we also need a second room.

    Owner: Champion

The Rollout Day, Hour by Hour.

One full day on site, 08:30 to 17:30 [confirm]. The agents keep working through lunch and the afternoon, so the long planning runs happen while your team does something else.

  1. Morning 08:30–11:30

    Deploy & Scope.

    By 11:30: Nebula Swarm is installed in your repo and has learned how your team builds software. Your project brief is a PRD draft, and your baseline numbers are agreed.

  2. –

    Kickoff: What "Done by 17:30" Means.

    The plan for the day, the ticket each person will ship, and the house rule that nothing merges to main without a pull request and a passing CI run.

    Who
    Everyone
    Output
    Each person's ticket for the afternoon, named on a shared board
  3. –

    Install Nebula Swarm in Your Repo.

    Run the installer against your real repository. It adds the shared agents, the workflow skills, a memory folder and an entry point for your AI tool. Then we connect Nebula Swarm to your Jira project, or set up its built-in ticket board if you don't use Jira.

    Who
    Eng lead, engineers · QA/EM optional
    Runs
    install.sh
    Output
    The harness on a branch, with its first pull request open
  4. – Two tracks

    Track A: Turn Your Idea Into a PRD.

    The product-manager agent turns your one-page brief into a PRD with measurable goals, user journeys, requirements and an open-decisions list. Design adds the UX intent. The eng lead flags the constraints.

    Who
    Product/PM, design, eng lead
    Runs
    The product-manager agent
    Output
    PRD draft v1 and a list of open decisions

    Track B: Scan Your Repo Into Memory and Prove It Runs Your Checks.

    Parallel scanner agents read the codebase. They write down your conventions, past decisions, glossary, repo map and lessons, and they cite a file for every claim. They also pick up the test, lint and typecheck commands your CI already runs. Then we run those commands from the harness and fix any that fail, and each engineer creates an isolated worktree with its own dependencies and ports, which is where every ticket will be built.

    Who
    Engineers, QA/EM
    Runs
    /repo-scan · .agents/config.json · worktree.sh
    Output
    A primed memory folder, a build config built from your CI, green checks, and one worktree per engineer
  5. –

    Break.

  6. –

    Correct What the Memory Got Wrong.

    The team reads the conventions and decisions out loud and marks every line that isn't how you really work. This is the cheapest half hour of the rollout and saves the most time later, because every future agent reads these files first. Anything we don't reach goes on the list for day 15.

    Who
    Eng lead, engineers, design, QA/EM · product/PM optional
    Output
    The reviewed memory, merged as your first Nebula Swarm pull request
  7. –

    Agree Your Baseline.

    Before the day, we ran your metrics export through the same measures we used at Deliveri. The group checks the numbers and agrees, in writing, the ones we'll compare against at day 15 and day 30.

    Who
    Everyone
    Output
    Baseline scorecard v0
  8. Midday 11:30–14:00

    Plan.

    By 14:00: the PRD is final, every person has a small ticket of their own with an approved plan, and the ticket plan for the rest of the project is being drafted.

  9. –

    PRD Readout and Rulings.

    Product walks the whole group through the draft PRD, and engineers and QA test it for gaps. Agents can plan around a decision, but they shouldn't make it for you. A human rules on each open item, and the ruling goes into the PRD.

    Who
    Everyone
    Output
    The final PRD
  10. –

    Write Your First Ticket and Start Its Plan.

    Each person describes their small job in a sentence, answers the agent's clarifying questions, and gets a full spec filed to Jira or the built-in board. Then they start planning it. At the same time, we start turning the final PRD into a ticket plan for the rest of the project.

    Who
    Everyone
    Runs
    /task-create · /dev-task-plan · /prd-extend
    Output
    One specified ticket per person, with its plan under way
  11. –

    Lunch. The agents keep working. Each ticket's plan goes back and forth with a reviewer agent, while product-manager, architecture and UX agents draft the ticket plan.

  12. –

    Approve Plans Like a Lead.

    Each ticket now has an architecture plan, a test plan and a documentation strategy, and Nebula Swarm stops for a human to approve every plan. The group works through the plans together: QA checks the test plans, design checks the UX, and the lead checks scope. Product, design and QA each pair with an engineer on a ticket in their own area. We cover what to reject and how to send a plan back. Your team sends work back the way the reviewer agent does, even when it costs another round.

    Who
    Everyone
    Runs
    /dev-task-plan, at its approval pause
    Output
    Approved plans, plus a plan-review checklist for your team
  13. Afternoon 14:00–17:30

    Build & Review.

    By 17:30: every trained author has a real ticket merged, the ticket plan is approved, and the first overnight run is queued.

  14. –

    Build Your Ticket.

    Agents write the code in each ticket's own worktree, following the approved plan. Then they write the tests, run your full set of checks and push. Each build starts as soon as its plan is approved. Trainees steer the work but don't type the code. They learn when to step in and when to let the build run.

    Who
    Everyone
    Runs
    /dev-task-build
    Output
    One pushed branch per ticket, with tests passing
  15. –

    Read an Agent's Pull Request.

    What to check first in an agent-written diff, how to read its implementation notes, and the failure patterns we see most often in the first week.

    Who
    Eng lead, engineers, QA/EM · design optional
    Runs
    The code-reviewer agent
    Output
    Your team's PR review checklist
  16. –

    Review, Merge, and Teach the Memory.

    Nebula Swarm opens the pull request, and a separate reviewer agent goes through it. This is where your team sees what the extra work is for: whatever the reviewer finds is fixed, or filed as a new ticket, before anyone merges. The trainee sorts the findings, and lessons from the ticket go into the repo's memory. Then a human merges the PR after CI passes. Each trainee takes their own ticket through every step.

    Who
    Everyone
    Runs
    /dev-task-review
    Output
    Merged PRs, one per trained seat, plus updated lessons
  17. –

    Approve the Ticket Plan and Queue the First Overnight Run.

    A project-manager agent has written a gate review of the ticket plan. Your lead, PM and EM read it, then accept the plan or send it back. Then autopilot plans a dependency graph across the approved tickets and stops once for your lead to approve it. Overnight, it takes each ticket through plan, build, review and merge, running up to [confirm: 3] at a time. Before anything runs, we set the timeouts and merge policy with your lead.

    Who
    Eng lead, engineers, product/PM, QA/EM
    Runs
    /dev-autopilot
    Output
    New tickets in dependency order, with nothing existing overwritten; an approved graph; a queued overnight run
  18. –

    Retro, Day 15 Targets and the Runbook Outline.

    What worked, what slowed people down, and a written target for each scorecard measure at day 15. Then your champion outlines the runbook they'll write before day 15: the morning review routine, who approves plans and merges, what to do when a run fails, and how to upgrade Nebula Swarm.

    Who
    Everyone
    Output
    Day 15 targets, the retro notes and the runbook outline

Every trained author ships a real ticket before we leave.

Two One-Day Check-Ins.

Each check-in starts with the scorecard. We compare your numbers to the baseline from the Rollout day using the same measures, then work on whatever is blocking the team. By day 30 the team is extending Nebula Swarm itself.

Day 15: Measure, Unblock, Run It Solo.

09:00–15:30 [confirm]

Two weeks of real use. We check what the overnight runs produced, fix what's slowing the team down, and watch the team plan its next project without our help.

  1. Morning review, live.

    The team reviews last night's run as they do every day. We watch.

    Eng lead, engineers, QA/EM

  2. Scorecard review.

    Build time per ticket, tickets per week and tests added, compared with the baseline.

    Everyone

  3. Unblocking clinic.

    Failed runs, plans that kept getting rejected, and memory that's out of date. We fix them at the keyboard.

    Eng lead, engineers, QA/EM

  4. Plan the next project, solo.

    Your PM runs the PRD-to-tickets workflow without us. We only step in when asked. /prd-extend-fast

    Eng lead, product/PM, design

  5. Refresh the memory.

    In parallel, engineers fold two weeks of lessons back into the repo memory, including anything the Rollout day didn't reach. /repo-scan

    Engineers, QA/EM

  6. Runbook review and wrap.

    Your champion walks the group through runbook v1. We fill the gaps together and agree the day 30 targets.

    Everyone

Day 30: Extend Nebula Swarm and Hand It Over.

09:00–16:00 [confirm]

A month of data. Your team adds its own agents and skills, and Nebula Swarm becomes something your team owns and changes.

  1. Day 30 scorecard.

    Results against the baseline, presented by your champion, not by us.

    Everyone

  2. Unblock and tune.

    Concurrency, merge policy and review load, adjusted using a month of real runs.

    Eng lead, engineers, QA/EM

  3. Build your own agent.

    Describe a specialist your team needs, such as a migration reviewer, and generate its definition. meta-agent

    Eng lead, engineers

  4. Write a team skill.

    Write one repeatable workflow of your own as a skill, such as a release checklist or a PRD template. SKILL.md

    Eng lead, engineers, product/PM, QA/EM

  5. Ownership and the next 60 days.

    The champion takes over the runbook and upgrades, and decides whether to add seats.

    Eng lead, product/PM, QA/EM

  6. Close-out.

    Final retro, and a decision on whether you'll be a reference customer.

    Everyone

Roles by Session.

Forward this table to calendar owners. Every role ships a ticket before we leave, so every role attends the planning and review sessions that lead up to it.

Required attendOptional welcome, not needed not needed

Which roles attend each session of the Rollout day and the check-ins
SessionEng leadEngineersProduct/PMDesignQA/EM
Morning · Deploy & Scope
KickoffRequiredRequiredRequiredRequiredRequired
Install Nebula Swarminstall.shRequiredRequiredNot neededNot neededOptional
Idea to PRD (Track A)product-manager agentRequiredNot neededRequiredRequiredNot needed
Scan into memory, prove the checks (Track B)/repo-scanNot neededRequiredNot neededNot neededRequired
Correct the memoryRequiredRequiredOptionalRequiredRequired
Agree the baselineRequiredRequiredRequiredRequiredRequired
Midday · Plan
PRD readout and rulingsRequiredRequiredRequiredRequiredRequired
Write and start your first ticket/task-createRequiredRequiredRequiredRequiredRequired
Approve plans/dev-task-planRequiredRequiredRequiredRequiredRequired
Afternoon · Build & Review
Build your ticket/dev-task-buildRequiredRequiredRequiredRequiredRequired
Read an agent's PRRequiredRequiredNot neededOptionalRequired
Review and merge/dev-task-reviewRequiredRequiredRequiredRequiredRequired
Approve the ticket plan, queue the overnight run/dev-autopilotRequiredRequiredRequiredNot neededRequired
Retro, day 15 targets, runbook outlineRequiredRequiredRequiredRequiredRequired
Check-ins
Day 15: scorecard, unblock, solo plan, runbookRequiredRequiredRequiredRequiredRequired
Day 30: own agents and skills, handoverRequiredRequiredRequiredOptionalRequired

Everything Stays in Your Repo and Your Jira.

None of it lives on our servers. If we disappeared tomorrow, you would still have all of it.

  • An installed harness.

    Agents, workflow skills and entry points for your AI tool, merged through your normal pull-request process. .agents/ · .claude/

  • Repo memory.

    Your conventions, decisions, glossary, repo map and lessons, with a citation for every claim. Your team has reviewed it, and it keeps growing with every ticket. AI/memory/

  • Your first PRD.

    A real roadmap project written up with measurable goals, user journeys and ruled decisions. AI/runs/<run>/context/

  • A ticket plan.

    Small tickets in dependency order, in Jira or the built-in board, checked against the whole PRD and against your existing backlog.

  • Merged pull requests.

    At least one per trained seat, each with a plan, tests, an independent review and a human merge. [confirm: 5+ PRs]

  • A queued overnight run.

    Its dependency graph approved by your lead. The results are waiting for the team the next morning.

  • A runbook.

    The morning review routine, who approves what, how to handle failures, and how to upgrade Nebula Swarm. Written by your champion after the Rollout day, and reviewed with us at day 15.

  • An internal champion.

    One named person who can run every workflow on this page, who has done it with us watching, and who owns Nebula Swarm from day 30.

  • A baseline and two scorecards.

    The Rollout day, day 15 and day 30, measured the same way as the Deliveri story.

  • Five perpetual seats.

    Licensed for life, with more seats at Sidera Labs' per-seat price whenever you need them.

Hours per Person, by Role.

Hours in scheduled sessions, not counting lunch or breaks. On the Rollout day, the eng lead and engineers are with us the whole time. Product and design attend about four-fifths of it.

Scheduled hours per person, by role, for prep, the Rollout day and both check-ins
RolePrepRollout dayDay 15Day 30Total
Eng lead3.5 h8.0 h5.5 h6.0 h23.0 h
Engineers (each)0.5 h8.0 h5.5 h5.0 h19.0 h
Product/PM1.5 h6.5 h3.5 h4.0 h15.5 h
Design0.5 h6.5 h3.5 h1.5 h12.0 h
QA/EM2.0 h7.5 h5.5 h5.0 h20.0 h

Prep [confirm] covers access, accounts, the project brief, the small jobs and the baseline export. Optional sessions are not counted. The champion is usually the eng lead or the EM and adds about [confirm: 3 h] to write the runbook between the Rollout day and day 15.

We Rolled It Out on Our Own Team First.

Why one day is enough: we ran Nebula Swarm on our own team at Deliveri first, and measured what changed.

  • 15.2 h → 3.3 hMedian build time per ticket at Deliveri, human team compared with Nebula Swarm.
  • 7,673Automated tests added in Nebula Swarm's first six weeks.
  • 1 + 2Day on site, plus two check-in days. That's all the time we spend with you, and the plan is for you to need no more.

Source: Deliveri git, GitHub, Jira and CI history, data as of 2026-10-08. Read the Deliveri story

Pick the Project, Then Book the Day.

The Sidera Labs Rollout starts at $50,000. That covers prep, one full day on site, both check-ins and perpetual Nebula Swarm seats for up to five people. One person or five, the price is the same. Each person after five adds $10,000, licensed for life. On a 30-minute scoping call we'll look at your repo, your roadmap and your AI tools, and tell you plainly whether Nebula Swarm fits.