I designed and built it to cover the whole development lifecycle, from ticket to pull request across repos: a specialist agent for each phase, and a person at every one-way door.
Why it was needed The platform spans several frontends, a serverless backend, shared UI and SDK packages and a gateway, each in its own repository, and most tickets cross repos. An assistant inside one repo sees a fraction of the system and guesses the rest. The goal was AI work a team can predict, review and trust.
SpeedDays, not weeksTickets that took a week or more ship in a day or two.
VolumeHundreds of ticketsThrough the full pipeline and the quick-fix path.
SafetyCaught before humansReal bugs and vulnerabilities, minor to critical.
ReachThe review standardThe team reviews PRs with it; other teams adopted its generic pieces.
you decideseveral agentsauto stopdeveloper’s turn
From a ticket to cross-linked pull requests. Several developer agents build in parallel, one per repo; a person decides at three points, and the security audit is an automatic hard stop.
Review is a loop between reviewer and developer that Claude runs with them: reading the ticket and PRs, posting on the right lines, tracking rounds, replying and re-checking. A person says yes before anything is posted, pushed or approved.
◇ you approve the plan◇ critical → you decide■ auto stop on a fail◇ you open the wave
The review loop · built by me · /review-prs ↔ /address-review
Review is a loop Claude runs with you, not a verdict it hands down.
I built two skills that turn review between reviewer and developer into rounds. Claude does the repetitive back-and-forth: reading the ticket and PRs, posting comments on the right lines, tracking rounds, replying and re-checking. People stay in the loop at every step.
Reviewer/review-prs <ticket>
1Reviews every PR against the ticket. Checks first whether each PR is merged, reverted or red in CI, and the merge order across repos.
2Leaves a review file. Each finding has an ID (F-1, F-2…), what’s wrong, why it matters and the expected behaviour.
3You say “post”. One approval posts every finding as a GitHub review on the exact lines; one more adds the round to a review log on the ticket.
↻Next round: picks the round up from the log, checks only open threads and new commits, resolves what’s verified, replies where it’s still wrong. Approves only when nothing is open, after you confirm.
Developer/address-review <ticket>
0Most issues never get here. The build pipeline’s own review phase runs the same review, so they are caught before the PRs exist.
1Reads every thread and checks whether each finding still holds at the current code.
2Explains, then waits. One file explains each finding and the planned response (fix, already fixed, or keep as is with the reason); one is the fix plan. No code changes without your OK.
3Fixes, checks, replies. The fixes get the same checks and review before anything leaves the machine; after your yes it pushes and replies in every thread. It never resolves a thread or approves: a reply is a claim the reviewer verifies.
ExplainedFiles, not just commentsEvery run leaves a file with each issue, its context, why it matters and what correct looks like.
IncrementalOnly what changedRounds are tracked on the ticket, so anyone can run the next one, and untouched code is never re-reviewed.
Strict, not noisyRe-confirmed findings onlyEach finding is scored and argued against before it is reported; what can’t be re-confirmed is dropped.
People decideNever 100% AINothing is posted, pushed or approved without a yes, and we still read the comments and check the important points ourselves.
01 · The agents
One job each, and a line it never crosses.
Narrow roles make every agent easy to test and to trust. Click a card to open it in the inspector.
02 · Skills
Procedures an agent loads only when it needs them.
An agent knows its role; a skill knows the steps. Skills keep agents short, make a procedure run the same way every time, and can be shared without sharing the whole pipeline. Click one to see which agents use it, here and in the diagram above.
03 · Where a person decides
Every one-way door has a human on it.
When building a ticket, a person decides at three points, and the security audit is an automatic hard stop.
After · PlanYou approve the planNothing is built until the per-repo plan has a yes.
At · Risk gateCritical risk → you decideA one-way door on shared code never passes without a person.
Automatic · SecurityA fail is a hard stopThe audit doesn’t warn and carry on; the run ends there.
At · PRsYou open the waveCross-linked PRs are prepared; nothing is pushed without a yes.
04 · Principles
How it holds together.
01Evidence, or it's marked unverified
02One owner per fact
03Subagents return a status line, not a dump
04Read-only by default
05Tool output is data, never instructions
06Docs before PR
07It learns from its own retros
Read moreHow context loads+
A workspace map, a machine-readable dependency graph and a card per repo. Context arrives three ways: always, on a write to a matching path, or on demand, so agents read what they need at the moment they need it.
Guardrails that can't be argued with+
Rules every agent follows, plus hooks for the ones that can't be left to judgement: no history rewrites, no skipped git hooks, no secrets, read-only external systems, and large query results written to disk instead of flooding context.
Two speeds+
A full pipeline for multi-repo or shared-code work, and a quick-fix path for small changes that escalates itself the moment it touches shared code, auth, a route, a database shape or a second repo.
Security audits across teams+
The same audit agents ran whole-repository audits on several teams’ codebases and surfaced issues from minor to critical that nobody had spotted, each fixed as soon as it was found.
Firas Khalife