Many agents.
One review standard.

.revmux/tasks/pr-123/        a task: one subject, as many rounds as it takes
├── task.md                 optional anchors: description, url, branch, base
├── 01-initial/             a round
│   ├── input/              caller-written, the only channel context travels through
│   │   ├── scope.md        {{SCOPE}}    required
│   │   ├── goal.md         {{GOAL}}     optional
│   │   ├── profile.md      {{PROFILE}}  optional, the project's own conventions
│   │   └── context/        {{CONTEXT}}  optional, any number of files
│   └── ...                 revmux-written artifacts
└── 02-after-fix/           the next round, with its own input/

Both names are caller-chosen and semantic. A round that has already run is an error rather than an overwrite, because a round that went badly is exactly the one worth keeping. Prior rounds are injected into every composed prompt with their own instruction to re-evaluate independently, so round two knows what round one reported without being told to agree with it.

.revmux/tasks/pr-123/02-after-fix/
├── input/              what this round was reviewed against
├── manifest.json       roster, prompt provenance and hashes, requested vs actual model
├── prompts/
│   ├── agents/         the composed prompt each agent received, post-substitution
│   └── stages/         synthesis.md, verify-app-pipeline.md, ...
├── stages/             1-found.json, 2-synthesized.json, 3-verified.json
├── events.jsonl        revmux's own decisions: stalls, retries, degrades, transitions
├── agents/             verbatim tees, one file per attempt
└── report.md, findings.json

manifest.json doubles as the marker claiming the round. It is created exclusively as the run starts, which is both how an already-run round is detected and how a real round is told from a directory somebody left behind. Read the archive rules, or turn the corpus into numbers with revmux stats: what each agent and each lens produced, and how many findings the pipeline dropped between stages.

---
description: pre-release pass over the payment path
model: claude/opus:high
agents:
  - {name: money,     lenses: [bugs, impl, payments],    color: red}
  - {name: contracts, lenses: [architecture, docs],      color: cyan}
  - {name: peer,      lenses: [adversarial], model: codex/gpt-5.6-sol:xhigh}
  - {name: second,    lenses: [bugs],        model: codex/gpt-5.6-sol:high}
stages:
  synthesis: claude/opus:high
  verify:    claude/sonnet:low
---

Everything below the front matter is the preamble every agent in this
roster receives, including what counts as critical, major and minor here.

Four sources, two vendors, four different jobs, and a synthesis model stronger than the verifier that follows it. payments is not a shipped lens: it is .revmux/lenses/payments.md, written by whoever knows what goes wrong in that code. A lens is a file of instructions and nothing else, so a project can have as many as it has subjects worth a dedicated pass, and a profile can have as many agents as it is willing to pay for.

A lens is a file of instructions and nothing else: no executor, no output format, no mention of a prior round. bugs covers correctness, impl goal fit, architecture conventions and organization, quality style and over-engineering, docs and comments the documentation a change leaves stale, tests whether a defect can hide, and adversarial attacks the change looking for what a sympathetic reader would accept.

Prompt text resolves per file across three layers: ./.revmux/, then ~/.config/revmux/, then the embedded defaults. Overriding one lens does not orphan the others, and adding a file is how the set grows. Every lens and key is in the reference.

$ revmux init          # writes whatever currently resolved, ready to edit

.revmux/
├── config                          runtime knobs, shipped commented out
├── lenses/
│   ├── bugs.md                     the shipped lens, now yours to edit
│   └── payments.md                  a lens only this project needs
└── prompts/
    ├── profiles/release.md          the roster above
    └── synthesis.md  verify.md

Checked in, that directory is the project's review, versioned and diffable like the rest of the code. A contributor who clones the repository and runs revmux gets the review the maintainer would have run, before the maintainer ever opens the pull request. A maintainer reading a finding can see which lens text raised it rather than taking it on faith. A review that missed something is fixed by editing a file, once, and every later review has it.

It cuts both ways: that text becomes the instructions a headless agent with a shell executes, so .revmux/ is code and deserves the same look as a Makefile before you run it on a branch you did not write. Running revmux from outside the tree never loads it.

{
  "scope": {"task": "pr-123", "run": "02-after-fix", "scope_path": "..."},
  "sources": {
    "expected": 4, "reported": 3, "degraded": ["docs+tests"],
    "agents": [{"name": "bugs+impl", "lenses": ["bugs", "impl"],
                "executor": "claude", "requested_model": "opus",
                "actual_model": "claude-opus-5", "effort": "high",
                "tokens": 48210, "raised": 6, "degraded": false}]
  },
  "findings": [
    {"id": "f1", "file": "app/pipeline/find.go", "line": 88,
     "severity": "major", "confidence": 90,
     "title": "...", "body": "...", "fix": "...",
     "sources": ["bugs+impl", "codex"], "lenses": ["bugs", "adversarial"],
     "verdict": "confirmed"}
  ],
  "open_questions": [], "pre_existing": [], "immaterial": [],
  "stats": {"duration_ms": 333000, "tokens": 184920, "stages": [...]}
}

Triage is the other job. Point the skill at an issue, a proposal or a discussion and it gathers the item, its thread and the author's history into context/, then runs a four-way panel over them: is the claim true of the code as it stands, how were comparable asks decided here before, the strongest honest case for, the strongest case against, and what the work would reach into. The severities rate how much a point bears on the decision rather than what breaks at runtime, and what comes back is arguments for a maintainer to weigh. revmux decides nothing, and neither does the skill: it puts the six questions to you with the case behind each.

Asked for a pull request instead, the skill fetches the head into a throwaway worktree, points --workdir at it while running from the main checkout, and removes both afterwards. An agent's shell has no tty, so launch-revmux.sh opens the run with its TUI in a terminal overlay when you want to watch it happen.

brew install umputun/apps/revmux   # macOS

# linux, from a release: .tar.gz, .deb and .rpm for amd64 and arm64
dpkg -i revmux_<version>_linux_amd64.deb

# or with a go toolchain, installed as `app`
go install github.com/umputun/revmux/app@latest

Full install notes, including building from a clone and how authentication is passed to the model CLIs.