MINIONS · Plan · Build · Verify · Ship

Minions

Double the output.
Not the headcount.

Most AI dev tools make individual engineers faster. Minions makes your engineering org larger — without the hire. It removes the three limits on a developer: one story at a time, work stuck on a laptop, output that stops at the end of the day. Seven specialized agents — Planner, Plan Reviewer, Builder, Test Author, Reviewer, CI Fixer, and Auto-Merger — run every ticket from spec to a merged PR, around the clock, coordinated across your repos, tracked by team, and costed to the dollar. Your leads stay in control — you approve the plan and the merge. Your board gets a number, not a guess.

GitHub App Jira SOC 2 Compliant Self-hosted option
10×
Engineering Output. Same Team Size.
0
Ticket → Mergeable PR
0
Agent Types
0
Coverage · Written Blind
The Developer Eras

Solo coder. Copilot era.
Then Minions.

Every era of software development compared side by side — see where the shift actually happens.

Where It Starts

Pick the work.
Minions take it from there.

One well-defined change is a Task. A larger initiative is a Feature — Minions scope it and break it into waves. Or run a Vulnerability Scan and turn findings into tickets.

Minions create dialog: choose Task, Feature, or Vulnerability Scan
The Crew

Seven agents. Seven jobs.
One way to ship.

A copilot autocompletes. Minions delivers. Seven agents take every ticket through planning, plan review, building, independent testing, review, and merge — in parallel, around the clock — so your actual engineering team is doing the work only humans should do. What lands in your inbox isn't a suggestion. It's a PR.

P Step 01

Planner

Reads the ticket. Writes the spec.

A two-line Jira ticket becomes a real engineering plan — goals, acceptance criteria, edge cases, and a test strategy. Nothing downstream moves until you sign off on the spec. The most expensive bug is the one nobody scoped.

  • Goals, acceptance criteria, technical notes
  • Test strategy authored alongside the build plan
  • Gated · waits for your approval before dispatch
PR Step 02

Plan Reviewer

Vets the spec before a line of code.

Every plan gets a second set of eyes before the build starts. Plan Reviewer checks the spec for gaps, bad assumptions, and missing edge cases — and can send it back to Planner to re-plan. The cheapest place to catch a mistake is before any code exists.

  • Reviews goals, criteria, and edge cases
  • Can re-plan before any code is written
  • Catches scope gaps at the cheapest point
B Step 03 · parallel

Builder

Takes the spec. Opens the PR.

Writes code in your repo's own conventions — your naming, your patterns, your stack. Pushes a draft PR. Compiles and self-checks before handoff. Doesn't write its own tests, and that isn't a limitation — it's the design.

  • Code in your style, not generic boilerplate
  • Draft PR opens on your branch convention
  • Compile + lint gates before review
T Step 04 · parallel

Test Author

Writes tests from intent. Never reads the build.

Tests written against implementation pass the implementation. Tests written against intent catch the bugs. Test Author works from the same spec as Builder — blind to the code being written next to it — so the green checkmark actually means something.

  • Unit, integration, and regression coverage
  • Authored from the spec, not from Builder's diff
  • Adversarial by design — catches the lazy pass
R Step 05

Reviewer

Holds code, tests, and spec against each other.

Runs through the spec line by line and asks one question on each: does the code satisfy this? Does a test prove it? One green box per acceptance criterion, or it goes back. Reviewer doesn't merge — that's your job — but it doesn't hand you garbage either.

  • One verdict per acceptance criterion
  • Flags spec drift before it reaches you
  • Sends it back to Builder if it isn't there yet
C Step 06 · CI-triggered

CI Fixer

Watches CI. Fixes what breaks.

When your GitHub Actions regression suite fails, CI Fixer gets the webhook. It queues a prioritized story for your team's board — or, with auto-fix enabled, dispatches Builder and Test Author immediately to patch it. Runs pre-merge as a gate or post-merge as a safety net — whichever matches your team's release process.

  • Triggered by your GitHub Actions webhook — no polling
  • Auto-fix mode dispatches Builder + Test Author immediately
  • Configurable pre-merge or post-merge, per repo
M Step 07 · on your approval

Auto-Merger

Merges the PR — only when you say go.

Once a PR clears review, Auto-Merger handles the merge, the branch cleanup, and the ticket close-out — but only after you approve it. Nothing lands in main on its own. It takes the busywork out of shipping, not the decision to ship.

  • Merges, cleans up the branch, closes the ticket
  • Never merges without your explicit approval
  • Takes the busywork · leaves you the decision
Live Demo

Watch Minions ship a feature in minutes.

Drop a request into Minions. Watch the Planner, Plan Reviewer, Builder, Test Author, and Reviewer work in parallel. Reviewed PR ready for merge — in under 10 minutes.

Control Room

Every ticket. Every agent.
One screen.

What's shipping, what's blocked, what's waiting on you. Cost-per-task in dollars, time-per-task in minutes, and the full agent log for any job. Built for multiple orgs and teams with role-based access — admins steer, members ship, viewers watch. Each team gets its own view. You get all of them.

Minions dashboard: estimated value delivered, tasks shipped, agents running in parallel, autonomy rate, and a needs-your-attention queue with merge and answer actions
The Numbers

Measure the output.
By team, by day, by line.

Tasks shipped, lines of code and tests written, tasks per person per day, and total agent working time — broken down by team and trended over time. The work Minions does is countable, and it's all here.

Minions reports: tasks, lines of code, lines of tests, tasks per person per day, and agent working time, with a per-team breakdown and activity-by-day chart
The Metadata Layer

It reads your repo before it writes a line.

Connect a repo and Minions spends its first hour studying it — not coding in it. Domain entities, naming patterns, test layout, branch conventions, and the unwritten rules every team has. Every ticket after that runs through your context, not a generic one. The output looks like your team wrote it because, in every way that matters, it did.

  • Indexes entities, relationships, and your domain model
  • Picks up your naming, file layout, and review norms
  • Re-indexes as the repo evolves — never goes stale
  • Separate metadata per repo · multi-project from day one
Minions repos: connected GitHub repos with default branch, stack, last ingest status, and repo-relationship notes
Beyond a Single Ticket

Not just tasks.
A whole delivery org.

Most AI dev tools hand you a faster developer. Minions gives you a more capable engineering org — one that plans epics, processes tickets, authors independent tests, watches CI, and runs security audits, all without growing the team. Raw ideas get shaped into approved specs before a ticket exists. Large initiatives get planned as dependency-ordered waves of tickets that unblock each other. And continuous security review opens its own tickets from the vulnerability findings you approve.

Features · epics into waves

Describe a large initiative in plain language. The planner proposes a full breakdown into dependency-ordered waves of stories — with edge cases, scope, and sequencing already reasoned through. You iterate conversationally, re-sequence, tighten scope, then approve. Wave 1 stories enter the pipeline automatically; later waves unblock as earlier ones complete.

  • Multi-story dependency graph, not a flat list
  • Stories created in Jira only on your commit
  • Track every child story from one place

Proposals · idea to spec

A structured intake flow that turns a raw idea into an approved Feature. Submit an idea (with an optional source URL — the AI will analyze it and extract context), collaborate with the AI on MoSCoW-prioritized requirements and a full SRS document, then invite external stakeholders by email. They get a confined portal at /intake — they can answer questions and suggest changes, but never see the rest of your pipeline. Approve the proposal and it seeds straight into Features.

  • Stakeholder role — sees only what you show them
  • Approve or reject stakeholder suggestions before they land
  • Full event history from discovery to approval

Security Scans · findings that ship

AI-powered vulnerability audits against any registered repo. the scanner reviews the codebase across ten security categories and returns findings organized by severity — critical, high, medium, low. Skip a false positive with one click, or approve a finding to auto-create a Task ticket that goes through the full build pipeline. Security stops being a report and becomes a queue.

  • Ten security categories reviewed per scan
  • Approve → Task created → PR opened
  • False-positive suppression that persists across scans
Orchestration

Multi-repo tasks.
Multi-team access.

Some features don't sit inside one repo. A single Task in Minions can span up to three repos at once, and one Task can wait on another when you need sequenced work. Every repo carries its own metadata layer, its own stack label, its own testing instructions — the agents read all of them and coordinate across every repo the Task touches.

When an agent needs more information from you, the ticket transitions to Needs Clarification and surfaces on a live alert stream. Answer in plain language and choose which status the ticket returns to — Planning, Ready for Dev, or wherever it should pick up.

  • One Task → up to three repos → coordinated PRs
  • Task-to-Task dependencies for ordered work
  • Blockers surface as a live alert stream you can clear in minutes
  • Multi-org tenancy: user, org_admin, and stakeholder roles
Minions reports: tasks, lines of code, lines of tests, tasks per person per day, and agent working time, broken down by team
Built for Teams

Workflow you can audit.
Not vibes.

When engineering leadership asks what Minions is doing, you can tell them exactly — by team, by ticket, by dollar, by minute. No black boxes. No trust-me-it's-working.

A pipeline, not a prompt

Planning, Build, Test, Review, Ready to Merge — every ticket sits in exactly one column. No "ask the AI what it's doing" — you can see it.

Two gates, both yours

One gate on the spec. One on the merge. The agents work between them. Nothing leaves Minions and lands in main without you signing it through.

Lives where you work

GitHub App + Jira native. Minions opens pull requests in your real repos and posts updates as real Jira comments. No new dashboards to learn unless you want one.

Multi-team by default

Multiple orgs, teams, and roles in one tenant. Each team gets its own budget, its own usage report, and its own merge policy.

Per-repo intelligence

Each repo gets its own metadata layer — frontend monorepo, Rails monolith, infra repo. Each one ships in its own voice.

Cost on every line

Every ticket carries a dollar number and a minute count. You can answer "what did this feature cost us" before standup the next morning.

Get Started

Set it running.
Come back to a pull request, not a surprise.

Connect GitHub and Jira. Minions indexes your repo in under an hour and starts opening PRs the same day. It keeps working overnight — and every team's activity, cost, and output is waiting for you in the dashboard when you're back. It stops at the merge gate until you say go.

Tell us where to point it
Add your name so we know who we're meeting.
Enter a valid work email.
Which company are we setting this up for?
Select your team size.
Which tools do you want to see? *
Pick at least one tool to see.

We'll only use this to set up your walkthrough. You approve every next step.

Request sent!

Your request is in — we'll be in contact shortly to schedule your live demo. Nothing runs against your systems until you approve it.

Back to overview
GitHub native Jira native SOC 2 Compliant Code stays yours