Super Review v3.29.0

Changelog

3.29.0 — 2026-11-12

Super Review now asks whether a computation needs every case and step it spells out.

• New conditional lens: logic (go/ts/rust/java.logic.fewer-moving-parts). For each computation a change adds or reshapes: is there a form with fewer cases, passes or intermediate values that gives the same result for every input and that a reader can check at a glance? It looks for a special case the general path already covers (empty, single, zero, first or last, a boundary index), cases a formulation removes (input normalized where it enters, an identity element, a sentinel or half-open range, a lookup table), a case product that independent decisions or a table state with fewer paths, and a detour through extra passes, intermediate collections, sorts or round-trip conversions. A finding shows the simpler form and traces, through quoted lines, that every removed case takes a path yielding the same values, errors, effects and order, edges included; a form that changes the result for some input is not a simplification. Cases stay when the unified rule needs a trick the reader must prove, when a special case states a requirement, or when an early exit is the shortest explanation. Each language names the edges that break equivalence: Go's nil versus empty slices and silent overflow; Rust's empty iterators, slice patterns and debug-build overflow panics; TypeScript's reduce on an empty array and its nullish, falsy, NaN and -0 distinctions; Java's null versus empty collections, immutable List.of() and % versus Math.floorMod. Guards for cases already ruled out stay with defensive-checks, the layout of remaining decisions with control-flow, and values kept in sync with data-flow.
• Selected when changed code branches on special values or edges beside a general path, branches over combinations of conditions, or computes one result through several passes or conversions. 56 stable rule IDs.

Shaped by reading. Not compared in model runs.

3.28.0 — 2026-11-12

Performance Review 0.4.0 reports two kinds of saving a later pull request on the reviewed service found after the runs had passed over them: a faster hasher for tables only the service fills, and tables of log fields no longer filled in full. Readers had seen both places and set them aside, one by following the complexity lens, the other inside a larger change.

• Hashing by who fills the table. The complexity lens ruled out a faster hasher for any key that comes from a request. Flooding needs colliding keys in the table, so the line now follows who decides what goes in: keys the program assigns, a table filled at startup and entries added only after their key is verified take a faster hasher; a table that requests, peers or files fill keeps the default. The hash runs over the whole key, so a long key hashed per request costs the most. The runs passed over SipHash of a whole service token on every call; a faster hasher made that cache hit 105.5 → 43.6 ns in the service's own measurement.
• Small is not hidden. Amdahl's rule rejected a saving the dominant cost "hides from every caller and operator", and a challenger read tens of nanoseconds beside the rest of a call as hidden. A saving is now hidden only when the larger cost bounds the resource whatever the saving does, such as CPU saved beside a longer wait it runs alongside. CPU and allocations add up across units: a small saving is reported with the larger cost beside it, and the ranking places it.
• A cheaper operation at the same count. A faster hasher keeps every count. Such a finding gives the count, what one operation does on each side and the basis for its cost: the source of both implementations or a benchmark one of them publishes. The challenger and the orchestrator check that basis, and whoever applies the change times that operation alone. Under the counts rule of 3.26.0 alone, such a saving read as a missing step.
• Initialization is work. The allocation lens asks whether a unit allocates, copies or initializes more than it keeps or reads, and names storage filled to its capacity and read to a length, such as [EMPTY; N] beside a count. The contract counts a hash over the whole key and storage initialized to its full capacity. A span with two fields initialized 192 table entries; filling only the used ones made creating it 405 → 335 ns.
• The free part of a tradeoff. When removing a whole cost is a tradeoff, a form that removes part of it and keeps everything is a finding of its own. A reader folded filling only the used entries into a per-thread buffer that holds memory on every thread, and the free part was reported only as a tradeoff.

Shaped by reading the runs on the crates that pull request changed. Not compared in model runs.

3.27.0 — 2026-11-12

The existing-helpers profile looks beyond small functions. It now asks who already does any code a change writes by hand for a general job, in Go, TypeScript, Rust and Java.

• Hand-written mechanisms. Besides a small function, the profile covers a whole mechanism or implementation written by hand for a general job, rather than the project's own domain, that the standard library, a dependency or code generation (a derive, a record, an annotation) already provides. Size does not matter; a maintained owner of the same knowledge does. A replacement must keep every behavior the users of such a mechanism rely on. The profile states this as a principle, without lists of examples.
• Chosen dependencies. A dependency the build already declares, or one the project's documentation recommends for the job, is the team's choice: hand-written code doing that job is the clearest candidate, even when nothing uses the dependency yet. A recorded decision against a library for the job keeps the hand-written code, cited where it is recorded.
• Verification and the routing row apply the same search to any hand-written code a change adds.

Shaped by reading a library audit of a Rust service template. Not compared in model runs.

3.26.0 — 2026-11-12

Performance Review 0.3.0 takes in fifteen real runs on a Rust service. Defect Review 0.11.0 and Test Review 0.10.0 share its rule for reading. The instructions of all four skills now say what an agent must achieve, not how to do what it can work out itself; outside Performance Review no review criterion changes.

• Reading in full. A branch the user names, such as the main branch, is pinned to one commit. Every agent reads what it reviews in full: a part it did not see, for whatever reason, is not read, and it finishes that part before it reports. In the runs, about half the whole-file reads through the shell came back cut, readers reported the rest as unread, and orchestrators started readers again for it, up to 21 agents on one crate. The instructions state the goal, not a read command.
• No readers where nothing runs per unit. When every entry in the scope only starts, wires or stops a long-lived program, the report lists the entries, how often each runs and where the per-unit work runs, and no readers start. One run started twelve readers on such a crate and found nothing.
• Findings on one path are checked together. Two findings each kept behavior, but applied together they let a stopped request start an introspection call; only an existing test caught it. The orchestrator now walks the forms that touch one function or path applied together, and says which to apply or how to combine them.
• Outside a narrowed scope, one line. A cost whose cheaper form changes only code outside the packages or files the user chose, sibling or not, is named with its location and not traced or challenged. Parallel runs on neighboring crates traced the same code up to three times and then changed it in conflicting branches.
• Predicted counts. Each finding states counts per unit before and after, such as 3 → 1 allocations per request. The challenger and the orchestrator check them, and whoever applies the change checks them first: a count does not depend on machine load. Time is measured only where the saving is time, on an otherwise idle machine. In the runs, half the applied changes were merged without any measurement, and timings on a loaded machine varied twofold. Each reallocation of a growing buffer counts as work, and the allocation lens names values built only to take their length: one run predicted one to three saved allocations where the change saved seven.
• Waiting. The Claude Code harnesses keep the fact that the forked turn ends at the orchestrator's first reply without a tool call and that completion notices of the processes it started do not reach it, and say not to reply while they run. The recipe of foreground shell calls of up to ten minutes is gone, and so is the wait loop on exit files in each external.md.
• Processes of other reviews. Each external.md still keeps a review's processes apart, records each one's PID, output and exit code in the review's own directory, and never selects processes by name or command line; the shell line that did the recording is gone. Flags come from what the installed CLI documents, not from memory, without a prescribed --help step.
• Super Review source access. The gh commands, Git inventory steps, hashing, -- and NUL-delimited listings are replaced by what they protect: PR identities resolved by reading only, staged source read as the captured index, one fixed version of working files for every specialist, paths that never become options or commands, and no repository-configured command (external diff, textconv, pager, fsmonitor) run during inspection. Verification reads the target files' history rather than running git log, and the other three workflows no longer say where in Git to read a PR; fetching its commits is still allowed.
• Super Review scheduling. The workflow keeps the default of eight running children, the user's override, the host's limits ...

Super Review v3.28.0

Changelog

3.28.0 — 2026-11-12

Performance Review 0.4.0 reports two kinds of saving a later pull request on the reviewed service found after the runs had passed over them: a faster hasher for tables only the service fills, and tables of log fields no longer filled in full. Readers had seen both places and set them aside, one by following the complexity lens, the other inside a larger change.

• Hashing by who fills the table. The complexity lens ruled out a faster hasher for any key that comes from a request. Flooding needs colliding keys in the table, so the line now follows who decides what goes in: keys the program assigns, a table filled at startup and entries added only after their key is verified take a faster hasher; a table that requests, peers or files fill keeps the default. The hash runs over the whole key, so a long key hashed per request costs the most. The runs passed over SipHash of a whole service token on every call; a faster hasher made that cache hit 105.5 → 43.6 ns in the service's own measurement.
• Small is not hidden. Amdahl's rule rejected a saving the dominant cost "hides from every caller and operator", and a challenger read tens of nanoseconds beside the rest of a call as hidden. A saving is now hidden only when the larger cost bounds the resource whatever the saving does, such as CPU saved beside a longer wait it runs alongside. CPU and allocations add up across units: a small saving is reported with the larger cost beside it, and the ranking places it.
• A cheaper operation at the same count. A faster hasher keeps every count. Such a finding gives the count, what one operation does on each side and the basis for its cost: the source of both implementations or a benchmark one of them publishes. The challenger and the orchestrator check that basis, and whoever applies the change times that operation alone. Under the counts rule of 3.26.0 alone, such a saving read as a missing step.
• Initialization is work. The allocation lens asks whether a unit allocates, copies or initializes more than it keeps or reads, and names storage filled to its capacity and read to a length, such as [EMPTY; N] beside a count. The contract counts a hash over the whole key and storage initialized to its full capacity. A span with two fields initialized 192 table entries; filling only the used ones made creating it 405 → 335 ns.
• The free part of a tradeoff. When removing a whole cost is a tradeoff, a form that removes part of it and keeps everything is a finding of its own. A reader folded filling only the used entries into a per-thread buffer that holds memory on every thread, and the free part was reported only as a tradeoff.

Shaped by reading the runs on the crates that pull request changed. Not compared in model runs.

3.27.0 — 2026-11-12

The existing-helpers profile looks beyond small functions. It now asks who already does any code a change writes by hand for a general job, in Go, TypeScript, Rust and Java.

• Hand-written mechanisms. Besides a small function, the profile covers a whole mechanism or implementation written by hand for a general job, rather than the project's own domain, that the standard library, a dependency or code generation (a derive, a record, an annotation) already provides. Size does not matter; a maintained owner of the same knowledge does. A replacement must keep every behavior the users of such a mechanism rely on. The profile states this as a principle, without lists of examples.
• Chosen dependencies. A dependency the build already declares, or one the project's documentation recommends for the job, is the team's choice: hand-written code doing that job is the clearest candidate, even when nothing uses the dependency yet. A recorded decision against a library for the job keeps the hand-written code, cited where it is recorded.
• Verification and the routing row apply the same search to any hand-written code a change adds.

Shaped by reading a library audit of a Rust service template. Not compared in model runs.

3.26.0 — 2026-11-12

Performance Review 0.3.0 takes in fifteen real runs on a Rust service. Defect Review 0.11.0 and Test Review 0.10.0 share its rule for reading. The instructions of all four skills now say what an agent must achieve, not how to do what it can work out itself; outside Performance Review no review criterion changes.

• Reading in full. A branch the user names, such as the main branch, is pinned to one commit. Every agent reads what it reviews in full: a part it did not see, for whatever reason, is not read, and it finishes that part before it reports. In the runs, about half the whole-file reads through the shell came back cut, readers reported the rest as unread, and orchestrators started readers again for it, up to 21 agents on one crate. The instructions state the goal, not a read command.
• No readers where nothing runs per unit. When every entry in the scope only starts, wires or stops a long-lived program, the report lists the entries, how often each runs and where the per-unit work runs, and no readers start. One run started twelve readers on such a crate and found nothing.
• Findings on one path are checked together. Two findings each kept behavior, but applied together they let a stopped request start an introspection call; only an existing test caught it. The orchestrator now walks the forms that touch one function or path applied together, and says which to apply or how to combine them.
• Outside a narrowed scope, one line. A cost whose cheaper form changes only code outside the packages or files the user chose, sibling or not, is named with its location and not traced or challenged. Parallel runs on neighboring crates traced the same code up to three times and then changed it in conflicting branches.
• Predicted counts. Each finding states counts per unit before and after, such as 3 → 1 allocations per request. The challenger and the orchestrator check them, and whoever applies the change checks them first: a count does not depend on machine load. Time is measured only where the saving is time, on an otherwise idle machine. In the runs, half the applied changes were merged without any measurement, and timings on a loaded machine varied twofold. Each reallocation of a growing buffer counts as work, and the allocation lens names values built only to take their length: one run predicted one to three saved allocations where the change saved seven.
• Waiting. The Claude Code harnesses keep the fact that the forked turn ends at the orchestrator's first reply without a tool call and that completion notices of the processes it started do not reach it, and say not to reply while they run. The recipe of foreground shell calls of up to ten minutes is gone, and so is the wait loop on exit files in each external.md.
• Processes of other reviews. Each external.md still keeps a review's processes apart, records each one's PID, output and exit code in the review's own directory, and never selects processes by name or command line; the shell line that did the recording is gone. Flags come from what the installed CLI documents, not from memory, without a prescribed --help step.
• Super Review source access. The gh commands, Git inventory steps, hashing, -- and NUL-delimited listings are replaced by what they protect: PR identities resolved by reading only, staged source read as the captured index, one fixed version of working files for every specialist, paths that never become options or commands, and no repository-configured command (external diff, textconv, pager, fsmonitor) run during inspection. Verification reads the target files' history rather than running git log, and the other three workflows no longer say where in Git to read a PR; fetching its commits is still allowed.
• Super Review scheduling. The workflow keeps the default of eight running children, the user's override, the host's limits and that a finished child's slot goes to the next ready task; the slot-release, batch and queue steps are gone. Codex keeps the fact that a finished child can hold its slot until it is closed. Tool names for reading and waiting are gone from the Codex, Cursor and OpenCode instructions and the specialist roles, and "using Read" from the Claude commands.

Shaped by reading. Not compared in model runs.

3.25.0 — 2026-11-12

Super Review now asks who already does what a new helper does.

• New profile: existing-helpers (owner duplication) for Go, TypeScript, Rust and Java. For each small function a change adds for a general operation (strings, collections, numbers, time, paths, retries, parsing, comparison), often at the bottom of a file, it searches in order: the standard library at the project's language version, a helper already in the repository under any name, a dependency already declared, and only for logic with real edge cases a widely used new dependency, named as a cost for the team to weigh. The reverse case too: the same helper written in several files is extracted once it has a second user today, to where the project keeps such helpers or to the concept it serves; a use that might come later is Speculative Generality. A replacement must behave the same on the edges callers reach (empty and absent values, Unicode, rounding, ordering and ties, errors); a helper with domain meaning, or a two-line one whose replacement needs a dependency, stays. Each language lists its version-bound standard operations and the edges that differ.
• Verification applies the existing-owner search to helpers the change adds, not only to remedies the review proposes.

Shaped by reading. Not compared in model runs.

3.24.0 — 2026-11-12

Super Review says how it sizes a review: when to split an area, how many tasks it starts, and a compact mode for small changes.

• Splitting areas. A lens's work is split by area when its files are more than one specialist can re...

Super Review v3.27.0

Changelog

3.27.0 — 2026-11-12

The existing-helpers profile looks beyond small functions. It now asks who already does any code a change writes by hand for a general job, in Go, TypeScript, Rust and Java.

• Hand-written mechanisms. Besides a small function, the profile covers a whole mechanism or implementation written by hand for a general job, rather than the project's own domain, that the standard library, a dependency or code generation (a derive, a record, an annotation) already provides. Size does not matter; a maintained owner of the same knowledge does. A replacement must keep every behavior the users of such a mechanism rely on. The profile states this as a principle, without lists of examples.
• Chosen dependencies. A dependency the build already declares, or one the project's documentation recommends for the job, is the team's choice: hand-written code doing that job is the clearest candidate, even when nothing uses the dependency yet. A recorded decision against a library for the job keeps the hand-written code, cited where it is recorded.
• Verification and the routing row apply the same search to any hand-written code a change adds.

Shaped by reading a library audit of a Rust service template. Not compared in model runs.

3.26.0 — 2026-11-12

Performance Review 0.3.0 takes in fifteen real runs on a Rust service. Defect Review 0.11.0 and Test Review 0.10.0 share its rule for reading. The instructions of all four skills now say what an agent must achieve, not how to do what it can work out itself; outside Performance Review no review criterion changes.

• Reading in full. A branch the user names, such as the main branch, is pinned to one commit. Every agent reads what it reviews in full: a part it did not see, for whatever reason, is not read, and it finishes that part before it reports. In the runs, about half the whole-file reads through the shell came back cut, readers reported the rest as unread, and orchestrators started readers again for it, up to 21 agents on one crate. The instructions state the goal, not a read command.
• No readers where nothing runs per unit. When every entry in the scope only starts, wires or stops a long-lived program, the report lists the entries, how often each runs and where the per-unit work runs, and no readers start. One run started twelve readers on such a crate and found nothing.
• Findings on one path are checked together. Two findings each kept behavior, but applied together they let a stopped request start an introspection call; only an existing test caught it. The orchestrator now walks the forms that touch one function or path applied together, and says which to apply or how to combine them.
• Outside a narrowed scope, one line. A cost whose cheaper form changes only code outside the packages or files the user chose, sibling or not, is named with its location and not traced or challenged. Parallel runs on neighboring crates traced the same code up to three times and then changed it in conflicting branches.
• Predicted counts. Each finding states counts per unit before and after, such as 3 → 1 allocations per request. The challenger and the orchestrator check them, and whoever applies the change checks them first: a count does not depend on machine load. Time is measured only where the saving is time, on an otherwise idle machine. In the runs, half the applied changes were merged without any measurement, and timings on a loaded machine varied twofold. Each reallocation of a growing buffer counts as work, and the allocation lens names values built only to take their length: one run predicted one to three saved allocations where the change saved seven.
• Waiting. The Claude Code harnesses keep the fact that the forked turn ends at the orchestrator's first reply without a tool call and that completion notices of the processes it started do not reach it, and say not to reply while they run. The recipe of foreground shell calls of up to ten minutes is gone, and so is the wait loop on exit files in each external.md.
• Processes of other reviews. Each external.md still keeps a review's processes apart, records each one's PID, output and exit code in the review's own directory, and never selects processes by name or command line; the shell line that did the recording is gone. Flags come from what the installed CLI documents, not from memory, without a prescribed --help step.
• Super Review source access. The gh commands, Git inventory steps, hashing, -- and NUL-delimited listings are replaced by what they protect: PR identities resolved by reading only, staged source read as the captured index, one fixed version of working files for every specialist, paths that never become options or commands, and no repository-configured command (external diff, textconv, pager, fsmonitor) run during inspection. Verification reads the target files' history rather than running git log, and the other three workflows no longer say where in Git to read a PR; fetching its commits is still allowed.
• Super Review scheduling. The workflow keeps the default of eight running children, the user's override, the host's limits and that a finished child's slot goes to the next ready task; the slot-release, batch and queue steps are gone. Codex keeps the fact that a finished child can hold its slot until it is closed. Tool names for reading and waiting are gone from the Codex, Cursor and OpenCode instructions and the specialist roles, and "using Read" from the Claude commands.

Shaped by reading. Not compared in model runs.

3.25.0 — 2026-11-12

Super Review now asks who already does what a new helper does.

• New profile: existing-helpers (owner duplication) for Go, TypeScript, Rust and Java. For each small function a change adds for a general operation (strings, collections, numbers, time, paths, retries, parsing, comparison), often at the bottom of a file, it searches in order: the standard library at the project's language version, a helper already in the repository under any name, a dependency already declared, and only for logic with real edge cases a widely used new dependency, named as a cost for the team to weigh. The reverse case too: the same helper written in several files is extracted once it has a second user today, to where the project keeps such helpers or to the concept it serves; a use that might come later is Speculative Generality. A replacement must behave the same on the edges callers reach (empty and absent values, Unicode, rounding, ordering and ties, errors); a helper with domain meaning, or a two-line one whose replacement needs a dependency, stays. Each language lists its version-bound standard operations and the edges that differ.
• Verification applies the existing-owner search to helpers the change adds, not only to remedies the review proposes.

Shaped by reading. Not compared in model runs.

3.24.0 — 2026-11-12

Super Review says how it sizes a review: when to split an area, how many tasks it starts, and a compact mode for small changes.

• Splitting areas. A lens's work is split by area when its files are more than one specialist can read in full, as in Defect Review. Before, large changes were split into "coherent areas" by judgment.
• Task count. The orchestrator announces how many tasks it will start. A whole-project review that would start more than forty asks the user whether to narrow it or run it as planned.
• Compact review, on request. When the user asks for a compact review of a small change (about three hundred changed production lines in one package or module, or a package of about a thousand lines reviewed whole), one specialist takes a related pair: naming with api-clarity, control-flow with function-cohesion, abstractions with duplication, data-flow with representation, change-locality with placement, rationale with conventions. A small change then takes five or six specialists instead of eight to twelve. Each lens of a pair reports its own coverage, and the report marks the pair. Whether pairing costs attention is unverified, so one lens per specialist stays the default until a comparison shows no lens loses annotated improvements.

Not compared in model runs.

3.23.0 — 2026-11-12

Child agents default to cheaper models; the user still picks the orchestrator's model and can pick the children's. Super Review 3.23.0, Defect Review 0.10.0, Test Review 0.9.0 and Performance Review 0.2.0 share these defaults.

• Claude Code. The review commands and orchestrators no longer pin opus: the orchestrator runs on the session's model and effort. Specialists, readers and challengers select sonnet at medium effort. No child defaults to an Opus- or Fable-class model.
• Codex. Every child gets gpt-6.1-terra with high reasoning effort. Super Review no longer chooses between gpt-6-luna and gpt-6-sol per task.
• Explicit choice wins. A model or effort the user names for children applies to every child and continuation of that review; in Claude Code the orchestrator passes it as the Agent call's model and effort. The orchestrator does not raise either on its own judgment.

Not compared in model runs.

3.22.0 — 2026-11-12

Super Review now asks whether code lives where a reader would look for it.

• New conditional lens: placement (go/ts/rust/java.placement.find-it-where-it-belongs). For each declaration a change adds or moves: which package, module, directory or file would a reader who knows the concept but not the code open first, and does it live there? The lens names what it looks for with words a model already knows: Feature Envy at module level, Divergent Change at file level, a grab-bag util or common, colocation with the only user, and drift from the layout the module already uses consistently (by feature or by layer; one precedent is not a layout). A recommendation names the destination and the search it saves; ...

Super Review v3.26.0

Changelog

3.26.0 — 2026-11-12

Performance Review 0.3.0 takes in fifteen real runs on a Rust service. Defect Review 0.11.0 and Test Review 0.10.0 share its rule for reading. The instructions of all four skills now say what an agent must achieve, not how to do what it can work out itself; outside Performance Review no review criterion changes.

• Reading in full. A branch the user names, such as the main branch, is pinned to one commit. Every agent reads what it reviews in full: a part it did not see, for whatever reason, is not read, and it finishes that part before it reports. In the runs, about half the whole-file reads through the shell came back cut, readers reported the rest as unread, and orchestrators started readers again for it, up to 21 agents on one crate. The instructions state the goal, not a read command.
• No readers where nothing runs per unit. When every entry in the scope only starts, wires or stops a long-lived program, the report lists the entries, how often each runs and where the per-unit work runs, and no readers start. One run started twelve readers on such a crate and found nothing.
• Findings on one path are checked together. Two findings each kept behavior, but applied together they let a stopped request start an introspection call; only an existing test caught it. The orchestrator now walks the forms that touch one function or path applied together, and says which to apply or how to combine them.
• Outside a narrowed scope, one line. A cost whose cheaper form changes only code outside the packages or files the user chose, sibling or not, is named with its location and not traced or challenged. Parallel runs on neighboring crates traced the same code up to three times and then changed it in conflicting branches.
• Predicted counts. Each finding states counts per unit before and after, such as 3 → 1 allocations per request. The challenger and the orchestrator check them, and whoever applies the change checks them first: a count does not depend on machine load. Time is measured only where the saving is time, on an otherwise idle machine. In the runs, half the applied changes were merged without any measurement, and timings on a loaded machine varied twofold. Each reallocation of a growing buffer counts as work, and the allocation lens names values built only to take their length: one run predicted one to three saved allocations where the change saved seven.
• Waiting. The Claude Code harnesses keep the fact that the forked turn ends at the orchestrator's first reply without a tool call and that completion notices of the processes it started do not reach it, and say not to reply while they run. The recipe of foreground shell calls of up to ten minutes is gone, and so is the wait loop on exit files in each external.md.
• Processes of other reviews. Each external.md still keeps a review's processes apart, records each one's PID, output and exit code in the review's own directory, and never selects processes by name or command line; the shell line that did the recording is gone. Flags come from what the installed CLI documents, not from memory, without a prescribed --help step.
• Super Review source access. The gh commands, Git inventory steps, hashing, -- and NUL-delimited listings are replaced by what they protect: PR identities resolved by reading only, staged source read as the captured index, one fixed version of working files for every specialist, paths that never become options or commands, and no repository-configured command (external diff, textconv, pager, fsmonitor) run during inspection. Verification reads the target files' history rather than running git log, and the other three workflows no longer say where in Git to read a PR; fetching its commits is still allowed.
• Super Review scheduling. The workflow keeps the default of eight running children, the user's override, the host's limits and that a finished child's slot goes to the next ready task; the slot-release, batch and queue steps are gone. Codex keeps the fact that a finished child can hold its slot until it is closed. Tool names for reading and waiting are gone from the Codex, Cursor and OpenCode instructions and the specialist roles, and "using Read" from the Claude commands.

Shaped by reading. Not compared in model runs.

3.25.0 — 2026-11-12

Super Review now asks who already does what a new helper does.

• New profile: existing-helpers (owner duplication) for Go, TypeScript, Rust and Java. For each small function a change adds for a general operation (strings, collections, numbers, time, paths, retries, parsing, comparison), often at the bottom of a file, it searches in order: the standard library at the project's language version, a helper already in the repository under any name, a dependency already declared, and only for logic with real edge cases a widely used new dependency, named as a cost for the team to weigh. The reverse case too: the same helper written in several files is extracted once it has a second user today, to where the project keeps such helpers or to the concept it serves; a use that might come later is Speculative Generality. A replacement must behave the same on the edges callers reach (empty and absent values, Unicode, rounding, ordering and ties, errors); a helper with domain meaning, or a two-line one whose replacement needs a dependency, stays. Each language lists its version-bound standard operations and the edges that differ.
• Verification applies the existing-owner search to helpers the change adds, not only to remedies the review proposes.

Shaped by reading. Not compared in model runs.

3.24.0 — 2026-11-12

Super Review says how it sizes a review: when to split an area, how many tasks it starts, and a compact mode for small changes.

• Splitting areas. A lens's work is split by area when its files are more than one specialist can read in full, as in Defect Review. Before, large changes were split into "coherent areas" by judgment.
• Task count. The orchestrator announces how many tasks it will start. A whole-project review that would start more than forty asks the user whether to narrow it or run it as planned.
• Compact review, on request. When the user asks for a compact review of a small change (about three hundred changed production lines in one package or module, or a package of about a thousand lines reviewed whole), one specialist takes a related pair: naming with api-clarity, control-flow with function-cohesion, abstractions with duplication, data-flow with representation, change-locality with placement, rationale with conventions. A small change then takes five or six specialists instead of eight to twelve. Each lens of a pair reports its own coverage, and the report marks the pair. Whether pairing costs attention is unverified, so one lens per specialist stays the default until a comparison shows no lens loses annotated improvements.

Not compared in model runs.

3.23.0 — 2026-11-12

Child agents default to cheaper models; the user still picks the orchestrator's model and can pick the children's. Super Review 3.23.0, Defect Review 0.10.0, Test Review 0.9.0 and Performance Review 0.2.0 share these defaults.

• Claude Code. The review commands and orchestrators no longer pin opus: the orchestrator runs on the session's model and effort. Specialists, readers and challengers select sonnet at medium effort. No child defaults to an Opus- or Fable-class model.
• Codex. Every child gets gpt-6.1-terra with high reasoning effort. Super Review no longer chooses between gpt-6-luna and gpt-6-sol per task.
• Explicit choice wins. A model or effort the user names for children applies to every child and continuation of that review; in Claude Code the orchestrator passes it as the Agent call's model and effort. The orchestrator does not raise either on its own judgment.

Not compared in model runs.

3.22.0 — 2026-11-12

Super Review now asks whether code lives where a reader would look for it.

• New conditional lens: placement (go/ts/rust/java.placement.find-it-where-it-belongs). For each declaration a change adds or moves: which package, module, directory or file would a reader who knows the concept but not the code open first, and does it live there? The lens names what it looks for with words a model already knows: Feature Envy at module level, Divergent Change at file level, a grab-bag util or common, colocation with the only user, and drift from the layout the module already uses consistently (by feature or by layer; one precedent is not a layout). A recommendation names the destination and the search it saves; code stays put when a move saves no search. Each language names what a move costs: Go's package as the unit and internal/; Rust's module path as part of the name, pub use to keep it and visibility that moves with the item; TypeScript's import paths, barrels, exports, module evaluation, framework-fixed files and "use client" boundaries; Java's package-private visibility, fully qualified names in reflection, module-info and Spring scanning. One decision spread across files stays with change-locality, dependency direction with dependency-boundaries, and the way a concern is handled with conventions.
• Selected when a change adds, moves or renames files, modules, packages or directories, puts a declaration where the name describes another concept, grows a file with another responsibility, or adds to a util-like location. 52 stable rule IDs.

Shaped by reading. Not compared in model runs.

3.21.0 — 2026-11-11

A fourth skill, Performance Review 0.1.0 (experimental, Rust): it finds work a hot path does not need and proposes a cheaper form with the same observable behavior. Super Review, Defect Review and Test Review are unchanged.

• What a finding is. Four parts, each checkable from the quoted lines:
  • the hot path: whe...

Super Review v3.25.0

Changelog

3.25.0 — 2026-11-12

Super Review now asks who already does what a new helper does.

• New profile: existing-helpers (owner duplication) for Go, TypeScript, Rust and Java. For each small function a change adds for a general operation (strings, collections, numbers, time, paths, retries, parsing, comparison), often at the bottom of a file, it searches in order: the standard library at the project's language version, a helper already in the repository under any name, a dependency already declared, and only for logic with real edge cases a widely used new dependency, named as a cost for the team to weigh. The reverse case too: the same helper written in several files is extracted once it has a second user today, to where the project keeps such helpers or to the concept it serves; a use that might come later is Speculative Generality. A replacement must behave the same on the edges callers reach (empty and absent values, Unicode, rounding, ordering and ties, errors); a helper with domain meaning, or a two-line one whose replacement needs a dependency, stays. Each language lists its version-bound standard operations and the edges that differ.
• Verification applies the existing-owner search to helpers the change adds, not only to remedies the review proposes.

Shaped by reading. Not compared in model runs.

3.24.0 — 2026-11-12

Super Review says how it sizes a review: when to split an area, how many tasks it starts, and a compact mode for small changes.

• Splitting areas. A lens's work is split by area when its files are more than one specialist can read in full, as in Defect Review. Before, large changes were split into "coherent areas" by judgment.
• Task count. The orchestrator announces how many tasks it will start. A whole-project review that would start more than forty asks the user whether to narrow it or run it as planned.
• Compact review, on request. When the user asks for a compact review of a small change (about three hundred changed production lines in one package or module, or a package of about a thousand lines reviewed whole), one specialist takes a related pair: naming with api-clarity, control-flow with function-cohesion, abstractions with duplication, data-flow with representation, change-locality with placement, rationale with conventions. A small change then takes five or six specialists instead of eight to twelve. Each lens of a pair reports its own coverage, and the report marks the pair. Whether pairing costs attention is unverified, so one lens per specialist stays the default until a comparison shows no lens loses annotated improvements.

Not compared in model runs.

3.23.0 — 2026-11-12

Child agents default to cheaper models; the user still picks the orchestrator's model and can pick the children's. Super Review 3.23.0, Defect Review 0.10.0, Test Review 0.9.0 and Performance Review 0.2.0 share these defaults.

• Claude Code. The review commands and orchestrators no longer pin opus: the orchestrator runs on the session's model and effort. Specialists, readers and challengers select sonnet at medium effort. No child defaults to an Opus- or Fable-class model.
• Codex. Every child gets gpt-6.1-terra with high reasoning effort. Super Review no longer chooses between gpt-6-luna and gpt-6-sol per task.
• Explicit choice wins. A model or effort the user names for children applies to every child and continuation of that review; in Claude Code the orchestrator passes it as the Agent call's model and effort. The orchestrator does not raise either on its own judgment.

Not compared in model runs.

3.22.0 — 2026-11-12

Super Review now asks whether code lives where a reader would look for it.

• New conditional lens: placement (go/ts/rust/java.placement.find-it-where-it-belongs). For each declaration a change adds or moves: which package, module, directory or file would a reader who knows the concept but not the code open first, and does it live there? The lens names what it looks for with words a model already knows: Feature Envy at module level, Divergent Change at file level, a grab-bag util or common, colocation with the only user, and drift from the layout the module already uses consistently (by feature or by layer; one precedent is not a layout). A recommendation names the destination and the search it saves; code stays put when a move saves no search. Each language names what a move costs: Go's package as the unit and internal/; Rust's module path as part of the name, pub use to keep it and visibility that moves with the item; TypeScript's import paths, barrels, exports, module evaluation, framework-fixed files and "use client" boundaries; Java's package-private visibility, fully qualified names in reflection, module-info and Spring scanning. One decision spread across files stays with change-locality, dependency direction with dependency-boundaries, and the way a concern is handled with conventions.
• Selected when a change adds, moves or renames files, modules, packages or directories, puts a declaration where the name describes another concept, grows a file with another responsibility, or adds to a util-like location. 52 stable rule IDs.

Shaped by reading. Not compared in model runs.

3.21.0 — 2026-11-11

A fourth skill, Performance Review 0.1.0 (experimental, Rust): it finds work a hot path does not need and proposes a cheaper form with the same observable behavior. Super Review, Defect Review and Test Review are unchanged.

• What a finding is. Four parts, each checkable from the quoted lines:

  • the hot path: where the code is reached from and why it runs often for the program's unit of work (a request, a message, one run of a command-line tool with its startup), on the evidence of the source, a document or benchmark in the repository, a profile the user supplies, or the user's words. An error path counts when real input takes it routinely;
  • a cost trace that counts the work for one unit and what multiplies it, into callees and dependencies at their Cargo.lock versions, never as invented milliseconds;
  • a cheaper form and what it keeps (results, order, errors, what has happened on a failure halfway, drop timing, Send and Sync, public API), building within the project's rust-version, edition, features and targets;
  • the resource saved, set beside the path's largest cost for that resource, with any work that only moved named.

  A candidate with a gap is unproven. A cheaper form that changes the public API, needs unsafe, adds a dependency, notably hurts readability, spends more CPU in parallel for less latency, buys throughput with each item's latency, or starts work an earlier failure would have stopped is a tradeoff, with both sides shown.

• Scope. Memory footprint beyond the allocator's work on a hot path, build profiles, link-time optimization, the global allocator and compile time are out of scope. Claims about what the compiler, the hardware's caches or a database's query plan do need a profile, a benchmark, a plan or a documented guarantee, from either side.

• Six lenses, one per independent reader, paired for a small change: complexity with allocation, async with contention, io with repeated-work. Each asks one question and has Expect, Look for and Not a finding sections, using names a model already knows: asymptotics, needless clone, allocation per iteration, blocking call on the async executor, lock held across .await, N+1, round trip, buffering and batching, contention and false sharing, loop-invariant work, over-parallelization. They also name costs common in Rust services: deserializing through serde_json::Value, a boxed future per call, routine anyhow errors, #[instrument] on a function called per element, metrics looked up by labels on every call, and queries no index in the migrations covers (unproven without a plan).

• Whole-project scope starts from where work enters the program: handlers, consumers, a command-line tool's main loop, scheduled jobs, a library's public interface, benchmarked functions, the frames of a supplied profile. Readers get what those entries reach; the report lists the entries and what they did not reach.

• Independent challenge on four lines: the path is not hot, the work is not done, the cheaper form changes behavior or does not build for the project, a larger cost swallows the saving. Verdicts are stands, falls or tradeoff; the orchestrator walks every trace and decides.

• Report. Outcomes are finding, tradeoff, unproven and rejected, ranked by work removed per unit: a change of complexity class, then a round trip or blocking wait per element, then an allocation per element, then constant work, which is listed compactly. Candidates that wait only on evidence that their path is hot become questions to the user. The report ends with instructions for whoever applies a finding: measure a release build before and after in the way the saved resource demands (a benchmark for CPU and allocations, load at production concurrency for contention and async waits, counts of queries or round trips for I/O), keep the existing tests passing, keep the change only if the gain shows, and say so when it does not.

• Reading only. Nothing is built, run, benchmarked or profiled.

• Delivery. /super-review:perf in Claude Code with the perf-orchestrator, perf-reader and perf-challenger roles, $perf-review in Codex, /perf-review in OpenCode with its own roles, and external harnesses on explicit request. The standalone archive is perf-review-0.1.0-skill.zip.

• The design is recorded in the family design.

Shaped by reading. Not used on a real repository and not compared in model runs.

3.20.0 — 2026-11-11

Defect Review 0.9.0 and Test Review 0.8.0 get the writing changes of 3.19 that fit their own bar. Super Review's instructions are unchanged.

• **Defect ...

Super Review v3.24.0

Changelog

3.24.0 — 2026-11-12

Super Review says how it sizes a review: when to split an area, how many tasks it starts, and a compact mode for small changes.

• Splitting areas. A lens's work is split by area when its files are more than one specialist can read in full, as in Defect Review. Before, large changes were split into "coherent areas" by judgment.
• Task count. The orchestrator announces how many tasks it will start. A whole-project review that would start more than forty asks the user whether to narrow it or run it as planned.
• Compact review, on request. When the user asks for a compact review of a small change (about three hundred changed production lines in one package or module, or a package of about a thousand lines reviewed whole), one specialist takes a related pair: naming with api-clarity, control-flow with function-cohesion, abstractions with duplication, data-flow with representation, change-locality with placement, rationale with conventions. A small change then takes five or six specialists instead of eight to twelve. Each lens of a pair reports its own coverage, and the report marks the pair. Whether pairing costs attention is unverified, so one lens per specialist stays the default until a comparison shows no lens loses annotated improvements.

Not compared in model runs.

3.23.0 — 2026-11-12

Child agents default to cheaper models; the user still picks the orchestrator's model and can pick the children's. Super Review 3.23.0, Defect Review 0.10.0, Test Review 0.9.0 and Performance Review 0.2.0 share these defaults.

• Claude Code. The review commands and orchestrators no longer pin opus: the orchestrator runs on the session's model and effort. Specialists, readers and challengers select sonnet at medium effort. No child defaults to an Opus- or Fable-class model.
• Codex. Every child gets gpt-6.1-terra with high reasoning effort. Super Review no longer chooses between gpt-6-luna and gpt-6-sol per task.
• Explicit choice wins. A model or effort the user names for children applies to every child and continuation of that review; in Claude Code the orchestrator passes it as the Agent call's model and effort. The orchestrator does not raise either on its own judgment.

Not compared in model runs.

3.22.0 — 2026-11-12

Super Review now asks whether code lives where a reader would look for it.

• New conditional lens: placement (go/ts/rust/java.placement.find-it-where-it-belongs). For each declaration a change adds or moves: which package, module, directory or file would a reader who knows the concept but not the code open first, and does it live there? The lens names what it looks for with words a model already knows: Feature Envy at module level, Divergent Change at file level, a grab-bag util or common, colocation with the only user, and drift from the layout the module already uses consistently (by feature or by layer; one precedent is not a layout). A recommendation names the destination and the search it saves; code stays put when a move saves no search. Each language names what a move costs: Go's package as the unit and internal/; Rust's module path as part of the name, pub use to keep it and visibility that moves with the item; TypeScript's import paths, barrels, exports, module evaluation, framework-fixed files and "use client" boundaries; Java's package-private visibility, fully qualified names in reflection, module-info and Spring scanning. One decision spread across files stays with change-locality, dependency direction with dependency-boundaries, and the way a concern is handled with conventions.
• Selected when a change adds, moves or renames files, modules, packages or directories, puts a declaration where the name describes another concept, grows a file with another responsibility, or adds to a util-like location. 52 stable rule IDs.

Shaped by reading. Not compared in model runs.

3.21.0 — 2026-11-11

A fourth skill, Performance Review 0.1.0 (experimental, Rust): it finds work a hot path does not need and proposes a cheaper form with the same observable behavior. Super Review, Defect Review and Test Review are unchanged.

• What a finding is. Four parts, each checkable from the quoted lines:

  • the hot path: where the code is reached from and why it runs often for the program's unit of work (a request, a message, one run of a command-line tool with its startup), on the evidence of the source, a document or benchmark in the repository, a profile the user supplies, or the user's words. An error path counts when real input takes it routinely;
  • a cost trace that counts the work for one unit and what multiplies it, into callees and dependencies at their Cargo.lock versions, never as invented milliseconds;
  • a cheaper form and what it keeps (results, order, errors, what has happened on a failure halfway, drop timing, Send and Sync, public API), building within the project's rust-version, edition, features and targets;
  • the resource saved, set beside the path's largest cost for that resource, with any work that only moved named.

  A candidate with a gap is unproven. A cheaper form that changes the public API, needs unsafe, adds a dependency, notably hurts readability, spends more CPU in parallel for less latency, buys throughput with each item's latency, or starts work an earlier failure would have stopped is a tradeoff, with both sides shown.

• Scope. Memory footprint beyond the allocator's work on a hot path, build profiles, link-time optimization, the global allocator and compile time are out of scope. Claims about what the compiler, the hardware's caches or a database's query plan do need a profile, a benchmark, a plan or a documented guarantee, from either side.

• Six lenses, one per independent reader, paired for a small change: complexity with allocation, async with contention, io with repeated-work. Each asks one question and has Expect, Look for and Not a finding sections, using names a model already knows: asymptotics, needless clone, allocation per iteration, blocking call on the async executor, lock held across .await, N+1, round trip, buffering and batching, contention and false sharing, loop-invariant work, over-parallelization. They also name costs common in Rust services: deserializing through serde_json::Value, a boxed future per call, routine anyhow errors, #[instrument] on a function called per element, metrics looked up by labels on every call, and queries no index in the migrations covers (unproven without a plan).

• Whole-project scope starts from where work enters the program: handlers, consumers, a command-line tool's main loop, scheduled jobs, a library's public interface, benchmarked functions, the frames of a supplied profile. Readers get what those entries reach; the report lists the entries and what they did not reach.

• Independent challenge on four lines: the path is not hot, the work is not done, the cheaper form changes behavior or does not build for the project, a larger cost swallows the saving. Verdicts are stands, falls or tradeoff; the orchestrator walks every trace and decides.

• Report. Outcomes are finding, tradeoff, unproven and rejected, ranked by work removed per unit: a change of complexity class, then a round trip or blocking wait per element, then an allocation per element, then constant work, which is listed compactly. Candidates that wait only on evidence that their path is hot become questions to the user. The report ends with instructions for whoever applies a finding: measure a release build before and after in the way the saved resource demands (a benchmark for CPU and allocations, load at production concurrency for contention and async waits, counts of queries or round trips for I/O), keep the existing tests passing, keep the change only if the gain shows, and say so when it does not.

• Reading only. Nothing is built, run, benchmarked or profiled.

• Delivery. /super-review:perf in Claude Code with the perf-orchestrator, perf-reader and perf-challenger roles, $perf-review in Codex, /perf-review in OpenCode with its own roles, and external harnesses on explicit request. The standalone archive is perf-review-0.1.0-skill.zip.

• The design is recorded in the family design.

Shaped by reading. Not used on a real repository and not compared in model runs.

3.20.0 — 2026-11-11

Defect Review 0.9.0 and Test Review 0.8.0 get the writing changes of 3.19 that fit their own bar. Super Review's instructions are unchanged.

• Defect Review: names for bug classes. Lens items now carry the names a model already knows: off-by-one and fence-post (results), swallowed error and fail-open (errors), check-then-act across a suspension point (TOCTOU), lost update and lost wakeup (shared-state), fire-and-forget task, cancellation safety and leak (lifecycle), an unpropagated deadline (time). They label existing items and add no new demand.
• Defect Review: one cause, one candidate. The orchestrator merges candidates with the same cause even when they surface at several places or through several lenses, and reports one candidate with each effect's trace. A candidate the orchestrator finds itself while reading goes through the same challenge as any other.
• Defect Review: when a lens is finished. A lens is finished when every operation in its files has been taken through the lens's Expect list.
• Test Review: mutation-testing words. A finding is a surviving mutant; a test that fails kills it; the witness separates an unpinned behavior from an equivalent mutant. Oracles names tautological assertions and assertions on the mock; determinism names flaky tests. Report counts read killed and surviving.
• Test Review: one witness for several findings. Where several proven findings touch one operation, the orchestrator checks whether one witness ...

Super Review v3.23.0

Changelog

3.23.0 — 2026-11-12

Child agents default to cheaper models; the user still picks the orchestrator's model and can pick the children's. Super Review 3.23.0, Defect Review 0.10.0, Test Review 0.9.0 and Performance Review 0.2.0 share these defaults.

• Claude Code. The review commands and orchestrators no longer pin opus: the orchestrator runs on the session's model and effort. Specialists, readers and challengers select sonnet at medium effort. No child defaults to an Opus- or Fable-class model.
• Codex. Every child gets gpt-6.1-terra with high reasoning effort. Super Review no longer chooses between gpt-6-luna and gpt-6-sol per task.
• Explicit choice wins. A model or effort the user names for children applies to every child and continuation of that review; in Claude Code the orchestrator passes it as the Agent call's model and effort. The orchestrator does not raise either on its own judgment.

Not compared in model runs.

3.22.0 — 2026-11-12

Super Review now asks whether code lives where a reader would look for it.

• New conditional lens: placement (go/ts/rust/java.placement.find-it-where-it-belongs). For each declaration a change adds or moves: which package, module, directory or file would a reader who knows the concept but not the code open first, and does it live there? The lens names what it looks for with words a model already knows: Feature Envy at module level, Divergent Change at file level, a grab-bag util or common, colocation with the only user, and drift from the layout the module already uses consistently (by feature or by layer; one precedent is not a layout). A recommendation names the destination and the search it saves; code stays put when a move saves no search. Each language names what a move costs: Go's package as the unit and internal/; Rust's module path as part of the name, pub use to keep it and visibility that moves with the item; TypeScript's import paths, barrels, exports, module evaluation, framework-fixed files and "use client" boundaries; Java's package-private visibility, fully qualified names in reflection, module-info and Spring scanning. One decision spread across files stays with change-locality, dependency direction with dependency-boundaries, and the way a concern is handled with conventions.
• Selected when a change adds, moves or renames files, modules, packages or directories, puts a declaration where the name describes another concept, grows a file with another responsibility, or adds to a util-like location. 52 stable rule IDs.

Shaped by reading. Not compared in model runs.

3.21.0 — 2026-11-11

A fourth skill, Performance Review 0.1.0 (experimental, Rust): it finds work a hot path does not need and proposes a cheaper form with the same observable behavior. Super Review, Defect Review and Test Review are unchanged.

• What a finding is. Four parts, each checkable from the quoted lines:

  • the hot path: where the code is reached from and why it runs often for the program's unit of work (a request, a message, one run of a command-line tool with its startup), on the evidence of the source, a document or benchmark in the repository, a profile the user supplies, or the user's words. An error path counts when real input takes it routinely;
  • a cost trace that counts the work for one unit and what multiplies it, into callees and dependencies at their Cargo.lock versions, never as invented milliseconds;
  • a cheaper form and what it keeps (results, order, errors, what has happened on a failure halfway, drop timing, Send and Sync, public API), building within the project's rust-version, edition, features and targets;
  • the resource saved, set beside the path's largest cost for that resource, with any work that only moved named.

  A candidate with a gap is unproven. A cheaper form that changes the public API, needs unsafe, adds a dependency, notably hurts readability, spends more CPU in parallel for less latency, buys throughput with each item's latency, or starts work an earlier failure would have stopped is a tradeoff, with both sides shown.

• Scope. Memory footprint beyond the allocator's work on a hot path, build profiles, link-time optimization, the global allocator and compile time are out of scope. Claims about what the compiler, the hardware's caches or a database's query plan do need a profile, a benchmark, a plan or a documented guarantee, from either side.

• Six lenses, one per independent reader, paired for a small change: complexity with allocation, async with contention, io with repeated-work. Each asks one question and has Expect, Look for and Not a finding sections, using names a model already knows: asymptotics, needless clone, allocation per iteration, blocking call on the async executor, lock held across .await, N+1, round trip, buffering and batching, contention and false sharing, loop-invariant work, over-parallelization. They also name costs common in Rust services: deserializing through serde_json::Value, a boxed future per call, routine anyhow errors, #[instrument] on a function called per element, metrics looked up by labels on every call, and queries no index in the migrations covers (unproven without a plan).

• Whole-project scope starts from where work enters the program: handlers, consumers, a command-line tool's main loop, scheduled jobs, a library's public interface, benchmarked functions, the frames of a supplied profile. Readers get what those entries reach; the report lists the entries and what they did not reach.

• Independent challenge on four lines: the path is not hot, the work is not done, the cheaper form changes behavior or does not build for the project, a larger cost swallows the saving. Verdicts are stands, falls or tradeoff; the orchestrator walks every trace and decides.

• Report. Outcomes are finding, tradeoff, unproven and rejected, ranked by work removed per unit: a change of complexity class, then a round trip or blocking wait per element, then an allocation per element, then constant work, which is listed compactly. Candidates that wait only on evidence that their path is hot become questions to the user. The report ends with instructions for whoever applies a finding: measure a release build before and after in the way the saved resource demands (a benchmark for CPU and allocations, load at production concurrency for contention and async waits, counts of queries or round trips for I/O), keep the existing tests passing, keep the change only if the gain shows, and say so when it does not.

• Reading only. Nothing is built, run, benchmarked or profiled.

• Delivery. /super-review:perf in Claude Code with the perf-orchestrator, perf-reader and perf-challenger roles, $perf-review in Codex, /perf-review in OpenCode with its own roles, and external harnesses on explicit request. The standalone archive is perf-review-0.1.0-skill.zip.

• The design is recorded in the family design.

Shaped by reading. Not used on a real repository and not compared in model runs.

3.20.0 — 2026-11-11

Defect Review 0.9.0 and Test Review 0.8.0 get the writing changes of 3.19 that fit their own bar. Super Review's instructions are unchanged.

• Defect Review: names for bug classes. Lens items now carry the names a model already knows: off-by-one and fence-post (results), swallowed error and fail-open (errors), check-then-act across a suspension point (TOCTOU), lost update and lost wakeup (shared-state), fire-and-forget task, cancellation safety and leak (lifecycle), an unpropagated deadline (time). They label existing items and add no new demand.
• Defect Review: one cause, one candidate. The orchestrator merges candidates with the same cause even when they surface at several places or through several lenses, and reports one candidate with each effect's trace. A candidate the orchestrator finds itself while reading goes through the same challenge as any other.
• Defect Review: when a lens is finished. A lens is finished when every operation in its files has been taken through the lens's Expect list.
• Test Review: mutation-testing words. A finding is a surviving mutant; a test that fails kills it; the witness separates an unpinned behavior from an equivalent mutant. Oracles names tautological assertions and assertions on the mock; determinism names flaky tests. Report counts read killed and surviving.
• Test Review: one witness for several findings. Where several proven findings touch one operation, the orchestrator checks whether one witness kills all their mutants and gives it once.
• Test Review: closing instructions. The report ends with instructions for whoever adds the tests: run each witness on the original code, apply its mutant locally and see the witness fail, revert, and report a witness that does not behave that way instead of adjusting it.

Shaped by reading. Not compared in model runs.

3.19.1 — 2026-11-11

Republishes 3.19.0 with the same review instructions. The 3.19.0 GitHub release was created by hand before the tag's release job ran and was then deleted; releases are immutable, so that tag can carry no release. This version's release comes from the tag's own CI job. AGENTS.md now records how a release is published.

3.19.0 — 2026-11-11

The orchestrator now decides what the code should become, not only which candidates survive, and the instructions say what to aim for instead of what to avoid.

• Aim for the best version. A new section in verification asks the orchestrator for the version a strong engineer in the language would write today, with behavior and the project's conventions held fixed. Each specialist answered one question; the orchestrator sees all of them. It rewrites a workable remedy when it sees a better one, designs code that several candidates touch once, fixes a cause that candidates from diffe...

Super Review v3.22.0

Changelog

3.22.0 — 2026-11-12

Super Review now asks whether code lives where a reader would look for it.

• New conditional lens: placement (go/ts/rust/java.placement.find-it-where-it-belongs). For each declaration a change adds or moves: which package, module, directory or file would a reader who knows the concept but not the code open first, and does it live there? The lens names what it looks for with words a model already knows: Feature Envy at module level, Divergent Change at file level, a grab-bag util or common, colocation with the only user, and drift from the layout the module already uses consistently (by feature or by layer; one precedent is not a layout). A recommendation names the destination and the search it saves; code stays put when a move saves no search. Each language names what a move costs: Go's package as the unit and internal/; Rust's module path as part of the name, pub use to keep it and visibility that moves with the item; TypeScript's import paths, barrels, exports, module evaluation, framework-fixed files and "use client" boundaries; Java's package-private visibility, fully qualified names in reflection, module-info and Spring scanning. One decision spread across files stays with change-locality, dependency direction with dependency-boundaries, and the way a concern is handled with conventions.
• Selected when a change adds, moves or renames files, modules, packages or directories, puts a declaration where the name describes another concept, grows a file with another responsibility, or adds to a util-like location. 52 stable rule IDs.

Shaped by reading. Not compared in model runs.

3.21.0 — 2026-11-11

A fourth skill, Performance Review 0.1.0 (experimental, Rust): it finds work a hot path does not need and proposes a cheaper form with the same observable behavior. Super Review, Defect Review and Test Review are unchanged.

• What a finding is. Four parts, each checkable from the quoted lines:

  • the hot path: where the code is reached from and why it runs often for the program's unit of work (a request, a message, one run of a command-line tool with its startup), on the evidence of the source, a document or benchmark in the repository, a profile the user supplies, or the user's words. An error path counts when real input takes it routinely;
  • a cost trace that counts the work for one unit and what multiplies it, into callees and dependencies at their Cargo.lock versions, never as invented milliseconds;
  • a cheaper form and what it keeps (results, order, errors, what has happened on a failure halfway, drop timing, Send and Sync, public API), building within the project's rust-version, edition, features and targets;
  • the resource saved, set beside the path's largest cost for that resource, with any work that only moved named.

  A candidate with a gap is unproven. A cheaper form that changes the public API, needs unsafe, adds a dependency, notably hurts readability, spends more CPU in parallel for less latency, buys throughput with each item's latency, or starts work an earlier failure would have stopped is a tradeoff, with both sides shown.

• Scope. Memory footprint beyond the allocator's work on a hot path, build profiles, link-time optimization, the global allocator and compile time are out of scope. Claims about what the compiler, the hardware's caches or a database's query plan do need a profile, a benchmark, a plan or a documented guarantee, from either side.

• Six lenses, one per independent reader, paired for a small change: complexity with allocation, async with contention, io with repeated-work. Each asks one question and has Expect, Look for and Not a finding sections, using names a model already knows: asymptotics, needless clone, allocation per iteration, blocking call on the async executor, lock held across .await, N+1, round trip, buffering and batching, contention and false sharing, loop-invariant work, over-parallelization. They also name costs common in Rust services: deserializing through serde_json::Value, a boxed future per call, routine anyhow errors, #[instrument] on a function called per element, metrics looked up by labels on every call, and queries no index in the migrations covers (unproven without a plan).

• Whole-project scope starts from where work enters the program: handlers, consumers, a command-line tool's main loop, scheduled jobs, a library's public interface, benchmarked functions, the frames of a supplied profile. Readers get what those entries reach; the report lists the entries and what they did not reach.

• Independent challenge on four lines: the path is not hot, the work is not done, the cheaper form changes behavior or does not build for the project, a larger cost swallows the saving. Verdicts are stands, falls or tradeoff; the orchestrator walks every trace and decides.

• Report. Outcomes are finding, tradeoff, unproven and rejected, ranked by work removed per unit: a change of complexity class, then a round trip or blocking wait per element, then an allocation per element, then constant work, which is listed compactly. Candidates that wait only on evidence that their path is hot become questions to the user. The report ends with instructions for whoever applies a finding: measure a release build before and after in the way the saved resource demands (a benchmark for CPU and allocations, load at production concurrency for contention and async waits, counts of queries or round trips for I/O), keep the existing tests passing, keep the change only if the gain shows, and say so when it does not.

• Reading only. Nothing is built, run, benchmarked or profiled.

• Delivery. /super-review:perf in Claude Code with the perf-orchestrator, perf-reader and perf-challenger roles, $perf-review in Codex, /perf-review in OpenCode with its own roles, and external harnesses on explicit request. The standalone archive is perf-review-0.1.0-skill.zip.

• The design is recorded in the family design.

Shaped by reading. Not used on a real repository and not compared in model runs.

3.20.0 — 2026-11-11

Defect Review 0.9.0 and Test Review 0.8.0 get the writing changes of 3.19 that fit their own bar. Super Review's instructions are unchanged.

• Defect Review: names for bug classes. Lens items now carry the names a model already knows: off-by-one and fence-post (results), swallowed error and fail-open (errors), check-then-act across a suspension point (TOCTOU), lost update and lost wakeup (shared-state), fire-and-forget task, cancellation safety and leak (lifecycle), an unpropagated deadline (time). They label existing items and add no new demand.
• Defect Review: one cause, one candidate. The orchestrator merges candidates with the same cause even when they surface at several places or through several lenses, and reports one candidate with each effect's trace. A candidate the orchestrator finds itself while reading goes through the same challenge as any other.
• Defect Review: when a lens is finished. A lens is finished when every operation in its files has been taken through the lens's Expect list.
• Test Review: mutation-testing words. A finding is a surviving mutant; a test that fails kills it; the witness separates an unpinned behavior from an equivalent mutant. Oracles names tautological assertions and assertions on the mock; determinism names flaky tests. Report counts read killed and surviving.
• Test Review: one witness for several findings. Where several proven findings touch one operation, the orchestrator checks whether one witness kills all their mutants and gives it once.
• Test Review: closing instructions. The report ends with instructions for whoever adds the tests: run each witness on the original code, apply its mutant locally and see the witness fail, revert, and report a witness that does not behave that way instead of adjusting it.

Shaped by reading. Not compared in model runs.

3.19.1 — 2026-11-11

Republishes 3.19.0 with the same review instructions. The 3.19.0 GitHub release was created by hand before the tag's release job ran and was then deleted; releases are immutable, so that tag can carry no release. This version's release comes from the tag's own CI job. AGENTS.md now records how a release is published.

3.19.0 — 2026-11-11

The orchestrator now decides what the code should become, not only which candidates survive, and the instructions say what to aim for instead of what to avoid.

• Aim for the best version. A new section in verification asks the orchestrator for the version a strong engineer in the language would write today, with behavior and the project's conventions held fixed. Each specialist answered one question; the orchestrator sees all of them. It rewrites a workable remedy when it sees a better one, designs code that several candidates touch once, fixes a cause that candidates from different lenses share, and then reads the accepted recommendations applied together. Anything still missing becomes its own candidate under the same bar, and a remedy it rewrites or adds passes the same preservation, lint and existing-owner checks as any other. Writing the edit costs nothing, so its size is no reason to settle for less.
• Shared vocabulary. The contract names burdens with words the model already knows: shared knowledge, deep and shallow boundaries, the deletion test, locality, and Fowler's smells (Mysterious Name, Data Clumps, Primitive Obsession, Feature Envy, Shotgun Surgery, Divergent Change, Speculative Generality, Middle Man). Specialists use them in observations, so the orchestrator can see when findings from different lenses are one thing. A term names a burden still to be shown in source.
• Target behavior instead of prohibitions. The judgment section of the contract and the lenses for Go, TypeScript, Rust and Java state what to...

Super Review v3.21.0

Changelog

3.21.0 — 2026-11-11

A fourth skill, Performance Review 0.1.0 (experimental, Rust): it finds work a hot path does not need and proposes a cheaper form with the same observable behavior. Super Review, Defect Review and Test Review are unchanged.

• What a finding is. Four parts, each checkable from the quoted lines:

  • the hot path: where the code is reached from and why it runs often for the program's unit of work (a request, a message, one run of a command-line tool with its startup), on the evidence of the source, a document or benchmark in the repository, a profile the user supplies, or the user's words. An error path counts when real input takes it routinely;
  • a cost trace that counts the work for one unit and what multiplies it, into callees and dependencies at their Cargo.lock versions, never as invented milliseconds;
  • a cheaper form and what it keeps (results, order, errors, what has happened on a failure halfway, drop timing, Send and Sync, public API), building within the project's rust-version, edition, features and targets;
  • the resource saved, set beside the path's largest cost for that resource, with any work that only moved named.

  A candidate with a gap is unproven. A cheaper form that changes the public API, needs unsafe, adds a dependency, notably hurts readability, spends more CPU in parallel for less latency, buys throughput with each item's latency, or starts work an earlier failure would have stopped is a tradeoff, with both sides shown.

• Scope. Memory footprint beyond the allocator's work on a hot path, build profiles, link-time optimization, the global allocator and compile time are out of scope. Claims about what the compiler, the hardware's caches or a database's query plan do need a profile, a benchmark, a plan or a documented guarantee, from either side.

• Six lenses, one per independent reader, paired for a small change: complexity with allocation, async with contention, io with repeated-work. Each asks one question and has Expect, Look for and Not a finding sections, using names a model already knows: asymptotics, needless clone, allocation per iteration, blocking call on the async executor, lock held across .await, N+1, round trip, buffering and batching, contention and false sharing, loop-invariant work, over-parallelization. They also name costs common in Rust services: deserializing through serde_json::Value, a boxed future per call, routine anyhow errors, #[instrument] on a function called per element, metrics looked up by labels on every call, and queries no index in the migrations covers (unproven without a plan).

• Whole-project scope starts from where work enters the program: handlers, consumers, a command-line tool's main loop, scheduled jobs, a library's public interface, benchmarked functions, the frames of a supplied profile. Readers get what those entries reach; the report lists the entries and what they did not reach.

• Independent challenge on four lines: the path is not hot, the work is not done, the cheaper form changes behavior or does not build for the project, a larger cost swallows the saving. Verdicts are stands, falls or tradeoff; the orchestrator walks every trace and decides.

• Report. Outcomes are finding, tradeoff, unproven and rejected, ranked by work removed per unit: a change of complexity class, then a round trip or blocking wait per element, then an allocation per element, then constant work, which is listed compactly. Candidates that wait only on evidence that their path is hot become questions to the user. The report ends with instructions for whoever applies a finding: measure a release build before and after in the way the saved resource demands (a benchmark for CPU and allocations, load at production concurrency for contention and async waits, counts of queries or round trips for I/O), keep the existing tests passing, keep the change only if the gain shows, and say so when it does not.

• Reading only. Nothing is built, run, benchmarked or profiled.

• Delivery. /super-review:perf in Claude Code with the perf-orchestrator, perf-reader and perf-challenger roles, $perf-review in Codex, /perf-review in OpenCode with its own roles, and external harnesses on explicit request. The standalone archive is perf-review-0.1.0-skill.zip.

• The design is recorded in the family design.

Shaped by reading. Not used on a real repository and not compared in model runs.

3.20.0 — 2026-11-11

Defect Review 0.9.0 and Test Review 0.8.0 get the writing changes of 3.19 that fit their own bar. Super Review's instructions are unchanged.

• Defect Review: names for bug classes. Lens items now carry the names a model already knows: off-by-one and fence-post (results), swallowed error and fail-open (errors), check-then-act across a suspension point (TOCTOU), lost update and lost wakeup (shared-state), fire-and-forget task, cancellation safety and leak (lifecycle), an unpropagated deadline (time). They label existing items and add no new demand.
• Defect Review: one cause, one candidate. The orchestrator merges candidates with the same cause even when they surface at several places or through several lenses, and reports one candidate with each effect's trace. A candidate the orchestrator finds itself while reading goes through the same challenge as any other.
• Defect Review: when a lens is finished. A lens is finished when every operation in its files has been taken through the lens's Expect list.
• Test Review: mutation-testing words. A finding is a surviving mutant; a test that fails kills it; the witness separates an unpinned behavior from an equivalent mutant. Oracles names tautological assertions and assertions on the mock; determinism names flaky tests. Report counts read killed and surviving.
• Test Review: one witness for several findings. Where several proven findings touch one operation, the orchestrator checks whether one witness kills all their mutants and gives it once.
• Test Review: closing instructions. The report ends with instructions for whoever adds the tests: run each witness on the original code, apply its mutant locally and see the witness fail, revert, and report a witness that does not behave that way instead of adjusting it.

Shaped by reading. Not compared in model runs.

3.19.1 — 2026-11-11

Republishes 3.19.0 with the same review instructions. The 3.19.0 GitHub release was created by hand before the tag's release job ran and was then deleted; releases are immutable, so that tag can carry no release. This version's release comes from the tag's own CI job. AGENTS.md now records how a release is published.

3.19.0 — 2026-11-11

The orchestrator now decides what the code should become, not only which candidates survive, and the instructions say what to aim for instead of what to avoid.

• Aim for the best version. A new section in verification asks the orchestrator for the version a strong engineer in the language would write today, with behavior and the project's conventions held fixed. Each specialist answered one question; the orchestrator sees all of them. It rewrites a workable remedy when it sees a better one, designs code that several candidates touch once, fixes a cause that candidates from different lenses share, and then reads the accepted recommendations applied together. Anything still missing becomes its own candidate under the same bar, and a remedy it rewrites or adds passes the same preservation, lint and existing-owner checks as any other. Writing the edit costs nothing, so its size is no reason to settle for less.
• Shared vocabulary. The contract names burdens with words the model already knows: shared knowledge, deep and shallow boundaries, the deletion test, locality, and Fowler's smells (Mysterious Name, Data Clumps, Primitive Obsession, Feature Envy, Shotgun Surgery, Divergent Change, Speculative Generality, Middle Man). Specialists use them in observations, so the orchestrator can see when findings from different lenses are one thing. A term names a burden still to be shown in source.
• Target behavior instead of prohibitions. The judgment section of the contract and the lenses for Go, TypeScript, Rust and Java state what to aim for where they used to list what not to do. Abstractions anchors on the deletion test, naming on Mysterious Name, change-locality on Shotgun Surgery and Speculative Generality, representation on Primitive Obsession and Data Clumps. Technical guardrails (ownership and lifetimes, null and proxies, inference and evaluation order) and scope boundaries stay as they were. Rule IDs are unchanged.
• One place per rule. The rule that an unresolved remedy stays out of implementation advice, the separation of coverage from candidate disposition, and the rule that agent agreement is not evidence each lived in three to five files the orchestrator reads together. Each now has one home. SKILL.md points to the workflow and contract instead of restating them.

Shaped by reading, after Matt Pocock's writing-for-agents guidance. Not compared in model runs.

3.18.0 — 2026-11-11

Four new questions for what reviewers rarely look at, and a written standard of well-written code for Go, TypeScript and Java.

• Craft for Go, TypeScript and Java. Rust already had a description of how an experienced author would write the operation today, and a map of which lens owns which idiom. The other three languages only told reviewers to apply language knowledge inside the assigned lens. Each now has its own Craft and Idiom owners sections, which name the defaults of the community sources (Effective Go, Code Review Comments and the Google Go guide; the TypeScript Handbook, typescript-eslint and the Google TS guide; Effective Java) rather than restating them. An idiom earns a recommendation by what it removes. Committed linter configuration (`.golangci.ym...

Super Review v3.20.0

Changelog

3.20.0 — 2026-11-11

Defect Review 0.9.0 and Test Review 0.8.0 get the writing changes of 3.19 that fit their own bar. Super Review's instructions are unchanged.

• Defect Review: names for bug classes. Lens items now carry the names a model already knows: off-by-one and fence-post (results), swallowed error and fail-open (errors), check-then-act across a suspension point (TOCTOU), lost update and lost wakeup (shared-state), fire-and-forget task, cancellation safety and leak (lifecycle), an unpropagated deadline (time). They label existing items and add no new demand.
• Defect Review: one cause, one candidate. The orchestrator merges candidates with the same cause even when they surface at several places or through several lenses, and reports one candidate with each effect's trace. A candidate the orchestrator finds itself while reading goes through the same challenge as any other.
• Defect Review: when a lens is finished. A lens is finished when every operation in its files has been taken through the lens's Expect list.
• Test Review: mutation-testing words. A finding is a surviving mutant; a test that fails kills it; the witness separates an unpinned behavior from an equivalent mutant. Oracles names tautological assertions and assertions on the mock; determinism names flaky tests. Report counts read killed and surviving.
• Test Review: one witness for several findings. Where several proven findings touch one operation, the orchestrator checks whether one witness kills all their mutants and gives it once.
• Test Review: closing instructions. The report ends with instructions for whoever adds the tests: run each witness on the original code, apply its mutant locally and see the witness fail, revert, and report a witness that does not behave that way instead of adjusting it.

Shaped by reading. Not compared in model runs.

3.19.1 — 2026-11-11

Republishes 3.19.0 with the same review instructions. The 3.19.0 GitHub release was created by hand before the tag's release job ran and was then deleted; releases are immutable, so that tag can carry no release. This version's release comes from the tag's own CI job. AGENTS.md now records how a release is published.

3.19.0 — 2026-11-11

The orchestrator now decides what the code should become, not only which candidates survive, and the instructions say what to aim for instead of what to avoid.

• Aim for the best version. A new section in verification asks the orchestrator for the version a strong engineer in the language would write today, with behavior and the project's conventions held fixed. Each specialist answered one question; the orchestrator sees all of them. It rewrites a workable remedy when it sees a better one, designs code that several candidates touch once, fixes a cause that candidates from different lenses share, and then reads the accepted recommendations applied together. Anything still missing becomes its own candidate under the same bar, and a remedy it rewrites or adds passes the same preservation, lint and existing-owner checks as any other. Writing the edit costs nothing, so its size is no reason to settle for less.
• Shared vocabulary. The contract names burdens with words the model already knows: shared knowledge, deep and shallow boundaries, the deletion test, locality, and Fowler's smells (Mysterious Name, Data Clumps, Primitive Obsession, Feature Envy, Shotgun Surgery, Divergent Change, Speculative Generality, Middle Man). Specialists use them in observations, so the orchestrator can see when findings from different lenses are one thing. A term names a burden still to be shown in source.
• Target behavior instead of prohibitions. The judgment section of the contract and the lenses for Go, TypeScript, Rust and Java state what to aim for where they used to list what not to do. Abstractions anchors on the deletion test, naming on Mysterious Name, change-locality on Shotgun Surgery and Speculative Generality, representation on Primitive Obsession and Data Clumps. Technical guardrails (ownership and lifetimes, null and proxies, inference and evaluation order) and scope boundaries stay as they were. Rule IDs are unchanged.
• One place per rule. The rule that an unresolved remedy stays out of implementation advice, the separation of coverage from candidate disposition, and the rule that agent agreement is not evidence each lived in three to five files the orchestrator reads together. Each now has one home. SKILL.md points to the workflow and contract instead of restating them.

Shaped by reading, after Matt Pocock's writing-for-agents guidance. Not compared in model runs.

3.18.0 — 2026-11-11

Four new questions for what reviewers rarely look at, and a written standard of well-written code for Go, TypeScript and Java.

• Craft for Go, TypeScript and Java. Rust already had a description of how an experienced author would write the operation today, and a map of which lens owns which idiom. The other three languages only told reviewers to apply language knowledge inside the assigned lens. Each now has its own Craft and Idiom owners sections, which name the defaults of the community sources (Effective Go, Code Review Comments and the Google Go guide; the TypeScript Handbook, typescript-eslint and the Google TS guide; Effective Java) rather than restating them. An idiom earns a recommendation by what it removes. Committed linter configuration (.golangci.yml, ESLint/Biome and tsconfig strictness, Checkstyle/PMD/Error Prone/SpotBugs) is the project's adopted choice.

• New conditional lens: conventions (go/ts/rust/java.conventions.follow-established-approach). Does the change handle a recurring concern differently from how the codebase already handles it? Examples: errors, logging, configuration, HTTP clients, validation, time. The lens searches the owning package, module or crate first, then the repository or workspace for precedent. A single precedent, a deprecated form, or a split between two forms without a direction establishes nothing. When the established mechanism also does something the new code does not, the remedy stays unresolved if the difference is a decision (retrying, mapping errors); otherwise the recommendation states the effect. Reimplementing a helper stays with duplication (in Go, also abstractions).

• New profile: unused-surface (owner abstractions). The profile looks for:

  • parameters every caller passes the same;
  • options nobody sets;
  • exports with no importer;
  • variants nothing constructs;
  • the last use of an item that the change removed.

  A used item declared wider than its users is visibility, which stays with dependency-boundaries. Visibility bounds the search. Framework, reflection and signature-fixed uses count as uses. A branch for a value from outside the code is not dead merely because nothing in the snapshot constructs it. An item only tests use is unused surface unless it is a deliberate seam.

• New profile: defensive-checks (owner control-flow). A guard for a case the code already rules out tells readers the case can happen. A candidate needs the guarantee traced through quoted lines; without the trace the guard stays. Guards at trust boundaries stay. TypeScript types count as evidence only where checked code produced the value. The opposite shape, the same check repeated downstream, moves to the entry point.

• New profile: diagnostics (owner rationale). Can a reader of a log record or error message tell which operation failed, on which subject? The profile covers:

  • missing identifiers;
  • context repeated across wrapping layers;
  • one failure appearing several times in the output (which layer reports it stays with error-expression);
  • inconsistent structured field names.

  Rewording error text checks its consumers first. A level change classifies an outcome, so its remedy stays unresolved. New events and metrics are out of scope.

• A selected profile whose owner is a conditional lens now selects that owner for the area; the workflow notes this exception to "profiles add no workers".

Every claim about language practice was checked against its community source and corrected where the source disagreed. The sources were:

• Go: Effective Go, Go Code Review Comments, the Google Go Style Guide;
• TypeScript: the TypeScript Handbook, typescript-eslint, the Google TypeScript Style Guide;
• Java: Effective Java, the JDK Javadoc and JEPs, the SLF4J and Spring documentation;
• Rust: the Rust API Guidelines, the Cargo SemVer chapter, std, thiserror and anyhow;
• across languages: Fowler's Refactoring and "Parse, don't validate".

Four rounds of independent checks found and fixed errors, overstatements and contradictions with neighboring lenses and the review contract. The last round cut detail a current model already knows from those sources and kept the decision rules, the traps reviewers get wrong, and recent changes such as Next.js 16; the four language versions of each profile now share one structure. Go and Rust compiler behavior was checked with go 1.27 and rustc 1.98, and JavaScript behavior with node 26. Java and TypeScript compiler rules were checked against the JLS and the TypeScript documentation, not with javac or tsc. Not yet compared in model runs, and no evaluation cases were added.

3.17.0 — 2026-11-11

Next round of fixes from the same 22 runs. Most problems surfaced only when the report was implemented.

• A remedy must not duplicate an existing owner. One recommendation added a CleanupDisposition type that infra-webhooks already had; the repository's duplication gate caught it during implementation. A remedy that introduces a type, helper or constant now needs a search of the snapshot for an existing owner. The orchestrator either reuses the owner or says why a new one is needed.
• Remedy checks cover more project checks. The viability check from 3.16 covered lints only. It no...