Skip to main content
Install two packages, write one file, and a team of models writes code, runs your tests and reviews the result before you see it. Each team below is a complete file: copy it, put your brief and your engines in, run it. The smallest team, whole. A Claude seat writes the files the brief names, Node runs the test, and a Codex seat reviews the result:
What that printed on one real run, and the files the two models wrote, are on its page.

Teams you run on your own work

  • A writer and a reviewer. One model writes the files your brief names and a model from a different family reads them. Your test command runs in between. A rejection sends the work back once.
  • A review panel with a threshold. One model implements, several review at the same time, and the change passes when enough of them accept. Every seat is a different model family.
  • Feature delivery. Nine stages: research and a plan, each reviewed; tests before code; an implementation that runs again with the reviewers’ findings; a person’s decision; evidence. Work goes back to the stage that owns it.
Each team is a graph of named steps. Every step carries a desc sentence saying what it does and a gate sentence saying what must be true for it to count, and both reach the reviewer’s input and the run record.

Teams outside a software change

The same form, for the work most teams do that is not a pull request. Each file is built to stop at a person, so nothing is sent or filed without one; each is a complete file with its brief and sample inputs beside it under examples/use-cases/. Each page carries one real run. Two reached their person. The third stopped earlier, when its reviewer sent the work back a third time and the loop ran out of attempts rather than pass on stories nobody had agreed. Software and product engineering: Business and commercial:
  • A contract against a playbook. Every clause mapped to accept, push back or never, the redlines written from the playbook’s own wording, a negotiating note saying what to hold and what to concede; the lawyer decides what goes back.
Other:

Mechanisms shown one at a time

These files run offline against the public packages and nothing else.
  • Three candidates, one winner. Three isolated attempts at one task, a deterministic judge, the winner lands and the losers leave nothing behind.
  • A command decides the path. The tests run as a node with no inference; a red run goes straight back to the writer with the output attached, and a second command’s exit code chooses which review runs next.
  • A person decides. A question to a person as a step: a no goes back to the writer with the note as the finding, a yes passes, and with nobody answering the run pauses and carries on from the answer.
  • A review that sends work back. A reviewer rejects the first draft with a reason and the second draft passes.
  • A file change approved byte for byte. Source records are captured, every mapping checked, exact output bytes approved, each target backed up before a merge, and a mismatch pauses the run.
  • A feature from written issue to approval. One issue through analysis, implementation, a real test run, a review panel, a bounded repair, and an approval bound to the exact bytes.
  • Shipping a reviewed change through GitHub. Push the branch, open one pull request, pass a strict gate on the exact head revision, squash the merge, delete the branch.