This is the software-delivery shape: the most mature team Forge runs, built on the Forge workflow engine . It is one shape among several — the same machinery runs research, content and operations teams. This page is the SDLC version in detail; see the jobs teams hand over for the others.
How it works
You put the forge-pipeline label on a GitHub issue. Forge opens a working session for that issue and starts the first role. Each role does a complete piece of work — reads what it was given, uses the tools it is allowed to use, and finishes by handing a summary to whoever comes next.
What each role does
Product manager — Reads the issue. Asks you a question if the ticket is ambiguous, rather than guessing. Produces an explicit list of what “done” means, and splits a large issue into independent pieces so they can be worked in parallel.
Architect — Takes that list and decides the approach: what goes where, which contracts change, what the data looks like. Points at real files in your repository rather than describing a generic design.
Developer — Builds it. Code, tests and any migration, committed to the branch the run owns.
Tester — Runs the suite. Works through the acceptance criteria the product manager wrote. Looks hard at anything security-relevant. Reports pass or fail with logs you can reproduce.
Reviewer — Reads the diff against the original criteria and the architect’s design. Comments, sends it back, or approves. On approval it opens the pull request for a person to merge.
What passes between them
A role does not hand the next one its transcript to re-read. It hands over a short structured summary: what the scope is, what the acceptance criteria are, which decisions were made and why. The next role starts from that.
Two things about this matter more than the format.
It is read before it is delivered. A management agent sits between every pair of roles and decides whether the handoff is good enough to pass on. It can send the work back with specific instructions, or escalate to a person. This is the part a single agent structurally cannot do — an agent checking its own work shares its own assumptions.
It degrades gracefully. If a model produces something the summary can’t be extracted from, the run does not stall. The next role simply receives the raw conversation as context and carries on. Structure is an advantage when it is there, not a precondition for the run finishing.
Talking to the team mid-run
Once a run is going, every comment you leave on the issue — or later on the pull request — goes to whichever role is working right now. Forge finds the live session, adds your comment to it, and gives that one role another turn. The chain does not restart.
So you can ask the product manager to clarify a requirement, tell the developer to use a different library, or push back on the tester’s coverage, all from the issue page. It works like a console for the run.
Changing the line-up
The five roles are a default, not a fixture. Roles can be switched off, reordered, or replaced with ones you define yourself, per organisation — see Custom Roles . Teams commonly drop the architect for small changes, or add a security reviewer before the code reviewer.
What you get
Everything below is running in production today.
- A ticket label as the entry point, with the run tied to that issue for its whole life
- Five roles progressing in order, each handoff read and judged before it moves on
- Your comments routed to the role that is currently working, on issues and pull requests
- A pull request carrying the full trail of how the work got there
- Review-and-fix rounds — the reviewer can return work to the developer, with a round limit
- Character agents — named personas with their own memory of your organisation
- Compete mode — two teams on one brief when the approach is genuinely uncertain
- Your own roles, defined per organisation
- Per-turn attribution: which machine ran what, visible in the console
- An editor for your organisation’s role defaults
Before any change to Forge itself ships, the whole five-role chain has to run ticket-to-pull-request as an automated test — and so does compete mode. We gate our own releases on it.
Try it
- Install the Forge GitHub App on your repository.
- Open any issue and add the
forge-pipelinelabel. - Watch the comments — each role announces itself and posts its progress.
- Review the pull request when it appears, and merge it yourself.