Overview Shipped
Classify the change, decide who is eligible, run your own tooling first, dispatch one narrow reviewer per concern, then separate finding a problem from deciding what it is worth.
You run one command. What happens next is a fan-out: the change is classified, a scope decides which specialists are even eligible, your own linters run before any model does, and then each selected specialist reviews the change through exactly one narrow lens, in its own dispatch, with no idea who else is on the run. Everything after that is about separating who found a problem from who decides it is real.
A run, end to end
- ClassifyWhat changed, and what technologies it touches.
- SelectWhich specialists are eligible, and which of those are relevant.
- Pre-checkRun your linters and typecheckers first, so no model re-reports them.
- ReviewOne narrow lens per dispatch, each checked for coverage as it finishes.
- MergeTwo lanes on the same defect become one corroborated finding.
- ScoreConfidence recomputed by an actor that does not know who raised it.
- ReportEverything, ranked. Nothing filtered out.
Step 4 is the expensive one and the only one that scales with the roster — which is why steps 1 and 2 exist, and why both are deterministic.
The three claims worth checking
Every finding appears in the report, ordered rather than filtered. No reviewer can see who else is reviewing. No actor can delete a finding. All three are asserted by tests rather than stated as policy, because all three are the kind of invariant that erodes quietly.
A run in progress
Try it
myteams devteam review code --base main
myteams devteam review code 3:3 --security --dataWhere to go from here
Who does the work names every actor and what each one is allowed to decide. Why it works this way is the argument for the structure — start there if this looks like more machinery than a code review needs. The stages of a run opens the mechanism up properly.