In development · early access on request

Agile Dev Team

A Claude Code plugin that works as a complete software delivery team. It is built to be fast, light on cost and right the first time. You say what you need in plain English. The team plans it, builds it, tests it, checks it and hands you one pull request per change, with the evidence at the top. You stay in charge: you approve the plan once, and you decide how changes are merged.

Request early access

Why

Why a team, not a single assistant

An AI assistant can write good code. What it cannot do is run a delivery. It has no team structure, no agile discipline, no governance, and none of the judgement that comes from years of running real programs. And it cannot vouch for its own work: "the tests passed" means nothing until something other than the author proves it.

Agile Dev Team gives AI agents the roles, the order and the controls of a professional delivery team. The agent that writes the code is not the one that writes the tests, and neither of them signs the work off. Every check is run by a program and recorded as a receipt. The practices come from how regulated financial institutions and top consulting firms manage change and transformation: nobody checks their own work, tests come before code, and every change leaves a record. The plugin applies them for you.

Who it is for

Created for people who build with AI

It is made for solo builders, product owners and founders who use Claude Code and have never run a development team. Nothing is reachable only by command. You describe what you want in your own words; the plugin confirms in one plain sentence what it understood, and only then acts. Every question comes with a sensible default, and "I don't know, you pick" is always a valid answer.

Early access

How the team works today

One user story in. One pull request out.

How a change travels through Agile Dev Team A ring of six stops. You write a user story; the manager plans it as small tasks; the developers build it one task at a time, tests first; programs check every task and write a receipt, and a failed check sends the task back; the manager audits the whole change; a pull request with its evidence on top returns to you, and you review and merge it. In the middle: agents decide, programs check, you merge. a failed checksends it back Agents decide. Programs check. You merge. 01 You say what you need, as one user story 02 Manager plans it as small tasks 03 Developers build it, one task at a time, tests first 04 Programs check every task and write a receipt 05 Manager audits the whole change 06 Pull request one change, with its evidence on top you review and merge you, and what comes back to you an agent: it decides and builds a program: it checks and records At most two fix rounds; then the team stops and asks you. Every check runs again, independently, on GitHub.
Agents decide. Programs check. You merge. The detail of every check is in the six steps below; the whole of it is in the evidence on each pull request.
  1. You write what you want

    as a short user story (one change, described from the user's point of view) with acceptance criteria, and start the run.

  2. The manager plans it

    as small tasks and assigns each to a developer. A program refuses a plan that is vague.

  3. The developers build it

    one task at a time, writing the test first. They may not touch test files, and a program checks that from git.

  4. Programs check every task

    the tests are seen failing before the change and passing after it; the project's own quality gate runs in a clean copy; nothing the step started is left running; a receipt is written for each task.

  5. The manager audits the whole story

    at most two fix rounds; after that the pull request is marked NOT APPROVED and waits for you.

  6. A program writes the evidence block

    and opens the pull request (a proposed change on GitHub that you can read and approve). You read it and merge it. An independent check on GitHub runs the same proofs again on every pull request.

Full release

The full team at full release

Eight roles. The moon grows as the work is proven: new moon when you ask, full moon when you hold the evidence.

Agile Dev Team at full release: three phases A rising path of five moons joined by arrows, from a new moon to a full moon. The new moon is you, saying what you need. A crescent for Understand and plan: the analyst turns your words into user stories; an optional architect learns your systems; the manager sizes the work, team and cost, and you approve once. A half moon for Build: the tester locks the tests before any code; senior and junior developers build; programs check every task and the manager audits; an optional security expert proposes features. A gibbous moon for Learn and hand over: a retrospective improves the playbook; the governance expert maps the evidence; everything still owed by you is listed. The full moon is you again, receiving the evidence pack. You say what you need You receive the evidence pack 1 · UNDERSTAND AND PLAN A plan you approve once Analyst turns your words into user stories Architect learns your systems (optional) Manager sizes the work, team and cost 2 · BUILD Tests first, one change at a time Tester locks the tests before any code Senior and junior developers build Programs check every task; manager audits Security expert proposes features (optional) 3 · LEARN AND HAND OVER Evidence, not promises Retrospective improves the playbook Governance expert maps the evidence Everything still owed by you is listed Standing rules in every release: programs check, agents do not vouch · tests fail first · every loop has a cap · a program merges · evidence. In early access today: the manager and the developers, with every check. The full release adds the rest. The product is in development.
Agile Dev Team at full release: three phases A rising path of five moons joined by arrows, from a new moon to a full moon. The new moon is you, saying what you need. A crescent for Understand and plan: the analyst turns your words into user stories; an optional architect learns your systems; the manager sizes the work, team and cost, and you approve once. A half moon for Build: the tester locks the tests before any code; senior and junior developers build; programs check every task and the manager audits; an optional security expert proposes features. A gibbous moon for Learn and hand over: a retrospective improves the playbook; the governance expert maps the evidence; everything still owed by you is listed. The full moon is you again, receiving the evidence pack. You say what you need 1 · UNDERSTAND AND PLAN A plan you approve once Analyst turns your words into user stories Architect learns your systems (optional) Manager sizes the work, team and cost 2 · BUILD Tests first, one change at a time Tester locks the tests before any code Senior and junior developers build Programs check every task; manager audits Security expert proposes features (optional) 3 · LEARN AND HAND OVER Evidence, not promises Retrospective improves the playbook Governance expert maps the evidence Everything still owed by you is listed You receive the evidence pack
You approve once at the start and receive the evidence at the end. The role details are presented in the table; if you would like to understand more about the mechanics of the build, contact us.
The eight roles
RoleWhat it doesStatus
ManagerKnows the project, plans each user story as small tasks, assigns them, and audits the finished work. Never writes code.Early access
Senior developerBuilds tasks that need judgement or span several files.Early access
Junior developerBuilds small, tightly specified tasks. Stops and asks rather than guesses.Early access
Top-model developerTakes the hardest tasks, and tasks the senior could not bring to standard.Early access
TesterWrites each task's tests before the code exists, locks them, then reviews the code after.Planned, 0.2
AnalystTurns what you say in plain English into user stories with acceptance criteria that can be tested. Handles change requests the same way.Planned, 0.2
Cybersecurity and governance expertProposes security features if you want them, and always writes the end-of-project findings, governance mapping and evidence pack.Planned, 0.3
Solution architectOptional, for builds that must fit systems you already have: learns your setup before the build and checks the fit at the end.Planned, 0.3

Rules

The rules it works by

  • Programs check. Agents do not vouch. Running the tests, the quality gate and the readiness checks, and recording the results, is done by programs. No agent is ever the source of "the tests passed".
  • Tests fail first, then pass. Code is never accepted on a pass alone.
  • Nobody checks their own work. The agent that writes the code does not write its tests, and neither signs the work off.
  • Every loop has a limit. Two fix rounds, then the team stops and reports to you.
  • A program merges, never an agent. And only in the way you chose at setup: automatically once every check passes, or you merge each change yourself on GitHub.
  • Evidence based. The plugin provides full audit and test evidence; the final results are always owed by you.
  • Your systems stay yours. The plugin never connects to your systems. Where it needs to know your setup, you describe it in a form and share exported files.

Design

Built to be fast, economical and right the first time

Agile Dev Team follows how well-run delivery teams work and how current AI agent systems are designed. These choices keep a build quick, light on tokens (the units AI models charge by) and high in quality.

  • Agile, from the first word. Work is written as user stories with acceptance criteria that can be tested, kept in a prioritised backlog, built in small steps and closed with a retrospective that improves the team's playbook for the next story.
  • The whole software lifecycle. Requirements, design decisions, build, test, release readiness and change requests each have an owner, and the end-of-project record refers to ISO/IEC standards for the lifecycle and for testing.
  • Quality built in. Tests are written before the code, and the whole test suite runs again after every task, so a regression is caught where it starts.
  • The right model for each job. Judgement roles use the strongest model; routine building uses smaller, cheaper ones. You choose the models at setup; none is fixed in the plugin.
  • Programs do the checking. Tests, quality gates and scans use no tokens and give the same answer every time.
  • Each agent reads only what it needs. Hand-offs are short written plans, not long conversations, so no agent pays to re-read the whole history.
  • Plan, then spend. In the full release a quick sizing pass gives you a cost estimate before a large run, planning is done story by story so no plan goes stale, and independent work runs in parallel. Security proposals are opt-in, so you pay only for the review you want.

The design follows patterns that have become standard for AI agent systems: specialised roles, written hand-offs, programs around the model, a human decision at the gates, and a limit on every loop. Early access has the written plans, the model tiers and programs checking every task; the cost estimate, parallel work and security proposals arrive with the full release.

Outcome

What you get at the end

  • One pull request per change, each opening with the evidence: every requirement, the test that covers it, and the result. You choose at setup whether you merge each one yourself or a program merges it once every check passes.
  • A traceability record from requirement to story to test to commit to pull request, written by a program.
  • At full release: a plain-language record of how the team worked, the cybersecurity findings, a mapping to published frameworks (NIST AI RMF and the EU AI Act where there is an AI component; ISO/IEC references for the process), and a list of what is still owed by you, such as a penetration test.

Requirements

What you need

Claude Code, GitHub and Python 3.11 or newer. It runs on Windows, macOS and Linux.

Contact

Early access

Agile Dev Team is in development. The manager and the developers, with every check, are available now to a small number of early users. Write to us with a line about what you are building and we will reply by email.