super-review

AI code review for readable, maintainable Go, TypeScript, Rust and Java code
Claude Code · Codex · Cursor · OpenCode

Quick start · What it reviews · How it works · Defect Review · Test Review · Performance Review · FAQ

Super Review is an AI code review plugin for Claude Code, Codex, Cursor and
OpenCode. It reviews pull requests, local changes or a whole project in
Go, TypeScript, Rust and Java for one thing: how easy the code is to read
and change. Independent specialist agents each answer one question; an
orchestrator checks their evidence and hands you a report of concrete,
verified recommendations.

It only reads. It never edits, builds or runs your code, and it never posts
comments on your PR.

Four reviews, one plugin

The four share no policy. A readability review never reports bugs, a bug
hunt never comments on style, and slow code is not a bug.
The family design explains why.

Quick start

Claude Code

claude plugin marketplace add Dankosik/agent-skills-marketplace
claude plugin install super-review@dankosik-skills

Codex

codex plugin marketplace add Dankosik/agent-skills-marketplace
codex plugin add super-review@dankosik-skills

Cursor: install the native Cursor adapter from
adapters/cursor/plugin, project-local or user-wide. A public Cursor
Marketplace listing is a separate Cursor review.

OpenCode: extract the OpenCode ZIP from
Releases and use its
super-review launcher; see the OpenCode adapter.

Any agent that reads skills: download the skill archive from
Releases.

Start a new session after installing or updating; nothing else needs
configuring. Native integrations covers updates
and removing old configuration.

Ask for a review

Follow the command with what to review:

/super-review:review Review this PR for readability and maintainability: https://github.com/org/repo/pull/123
/super-review:review Review my staged and unstaged changes, focusing on API clarity and naming.
/super-review:review Review all production Rust in the current project, excluding tests.

Asking for help explains usage without reading anything. If the target is
missing, the review asks for it; otherwise it starts at once.

What it reviews

Every review covers eight base questions:

Representation and rationale are added when relevant, and language and
framework profiles deepen the questions that own them. A targeted request
narrows coverage explicitly; work that was not done is never reported as clean.
Tests, generated and vendored code, and unsupported languages are excluded.

TypeScript/TSX reviews pick framework profiles from the source and
configuration of each package. They look at state ownership, cohesive
interactions, component contracts, server/client boundaries, explicit data
paths, shared design knowledge and primitive composition. Profiles deepen the
eight base questions instead of adding four broad framework reviewers.

$super-review Review my local TypeScript/TSX changes for readability and
maintainability in React 19, Next.js 16, Tailwind and shadcn/ui.

The review does not push upgrades, memoization campaigns, forced Server
Actions, design-system rewrites, or bug, accessibility or performance audits.
Locally maintained shadcn components are reviewed like any other code.
JavaScript/JSX, CSS and MDX are not standalone targets, but theme CSS and
configuration can support a recommendation about TypeScript/TSX. Missing local
implementations or configuration are reported, not guessed.

See frontend routing and profiles.

Java reviews select Spring profiles for bean wiring and configuration,
application operations, HTTP contracts and errors, managed lifecycle and value
shapes. Each profile deepens one existing Java question; there is no broad
Spring agent and no mandatory framework-wide pass.

$super-review Review this Java/Spring PR for readability and maintainability.
Use only the Spring modules actually established in each owning module.

Compatibility takes in Framework/Boot, the actual web and Spring Data modules,
the persistence API and provider, validation and serialization dependencies,
not just the JDK. MVC, WebFlux and client-only WebClient use are told apart.
Clear interfaces, transactional operations, constructors, annotations, entities
and separate DTOs stay when their contracts justify them. No reactive
migration, ORM change, Spring Modulith adoption, universal mapper or
interface-per-service is required.

See Spring routing and owners.

What you get

Each recommendation names the source, the improvement it shows, the proposed
change and what the change must preserve. The report lists file coverage,
every candidate decision and useful open observations. A good review may
suggest a local clarification, a structural improvement, or leaving clear code
alone. Hand accepted recommendations to a coding task to implement and test.

How it works

flowchart LR
    T["PR, local changes<br/>or whole project"] --> O["Orchestrator<br/>pins the source"]
    O --> S1["Specialist:<br/>naming"]
    O --> S2["Specialist:<br/>control flow"]
    O --> S3["Specialist:<br/>API clarity"]
    O --> S4["…one per<br/>question"]
    S1 & S2 & S3 & S4 --> V["Orchestrator<br/>verifies evidence"]
    V --> R["Report:<br/>recommendations<br/>+ coverage"]

• Pinned source. PRs are read at fixed base and head commits; local work
  at an identified snapshot. A local review needs no PR.
• Native tools only. Super Review uses the host's own file, search, Git,
  GitHub and agent tools. It ships no MCP server, custom source reader, result
  daemon or runtime dependencies. The host's permissions govern those tools.
• Your accounts. GitHub access is needed only for remote source. The
  plugin supplies no credentials or model subscriptions.

Models

In Cursor, ask for a specialist model in the prompt, for example
"Для subagent используй <Cursor model ID>". The adapter applies it
through native per-call selection or says it cannot, without silently
substituting; the chat model stays as is. See
model profiles. In Codex and Claude Code, a model or
effort you name for specialists replaces the default for every child of that review.

Team conventions

Put a SUPER_REVIEW.md at the repository root with explicit language, paths,
lens and action. A rule can add, refine, override or disable a stable rule
within its declared scope. PR policy comes from the target commit; local
policy from the recorded revision.

The file is optional: when it is confirmed absent, the defaults apply. When it
cannot be read, that is a policy gap, not permission to assume defaults or to
use a policy proposed by the PR. All 44 go.*, ts.*, rust.* and java.*
rule IDs are stable across version 3.

See the team-rules contract
and an example.

Defect Review (experimental, Rust)

A separate skill in the same plugin hunts bugs in Rust.

/super-review:defects Review crates/infra-cache in the current project.
$defect-review Hunt for bugs in this PR.
/defect-review Hunt for bugs in this PR.   (OpenCode)

Independent readers each take one lens, or a related pair for a small change:
results, boundaries, errors, time, lifecycle, shared state, stated facts and
team rules. A bug needs:

• a trace through the code: a trigger real use can produce, each step as a
  quoted line, and what the affected party observes;
• a stated expectation with its basis, and a harm to someone;
• survival of an independent challenge.

Nothing has to be written down in advance for something to be a bug, and a
document describing harmful behavior does not make it right.

The challenge keeps false positives down. A second agent gets each claim with
its trace but without the finder's reasoning, follows the trigger through the
source itself and tries to show it is not a bug. When the behavior is a
deliberate choice whose stated reason holds, the finding is reported as
disputed, with the cost and the decision side by side.

Rust only, in Claude Code, Codex and OpenCode. See the design
and the contract.

Test Review (experimental, Rust)

A third skill asks whether your tests would fail if a plausible bug appeared.

/super-review:tests Review the tests of crates/infra-cache in the current project.
$test-review Would the tests in this PR notice a mistake in what it changes?
/test-review Would the tests in this PR notice a mistake?   (OpenCode)

A finding names a promised behavior that no test pins down, and shows it with:

• a mutant: one small, plausible mistake in production code, as a diff
  that is never applied;
• why each test that reaches that code would still pass;
• a witness: a check that holds for the original code and fails for the
  mutant. It proves the mutant changes behavior, and it is the test to add.

A test that breaks a written team rule for tests, such as a fixed sleep where
the rule asks for synchronization, is shown by quoting both. Mutants your tests
catch are counted, not reported, and the review says what it did not probe.

It does not build or run your tests, so it is not a mutation-score tool. Rust
only, in Claude Code, Codex and OpenCode. See the design
and the contract.

Performance Review (experimental, Rust)

A fourth skill finds work your Rust code does not need on paths that run
often.

/super-review:perf Review the request path of crates/api in the current project.
$perf-review Find unneeded work on the hot paths this PR touches.
/perf-review Find unneeded work on the hot paths this PR touches.   (OpenCode)

Independent readers each take one lens, or a related pair for a small change:
complexity, allocation, async, I/O, contention and repeated work. A finding
needs:

• a hot path: where the code is called from and why it runs often for
  the program's unit of work (a request, a message, one run of a
  command-line tool), on the evidence of the source, a document, a profile
  you supply, or your word;
• a cost trace: the work done for one unit, each step as a quoted line,
  counted against what multiplies it ("one allocation per row × rows in the
  request"), never invented milliseconds;
• a cheaper form with the same observable behavior, and the
  resource it saves, set beside the path's largest cost;
• survival of an independent challenge that tries to show the path is
  cold, the work is not done, the cheaper form changes behavior or a larger
  cost swallows the saving.

A cheaper form that changes the public API, needs unsafe, makes the code
notably harder to read or buys throughput with each item's latency is
reported as a tradeoff, with both sides. Findings are ranked by the work
they remove, not by severity labels. For a whole project the review starts
from where work enters the program and lists those entries. Candidates that
wait only on whether a path is hot come back to you as questions.

It runs no benchmark or profiler, so it shows work removed, not time saved.
Each finding predicts counts per unit before and after, such as 3 → 1 allocations per request. The report ends by asking whoever applies a
finding to check those counts first, then to measure time where the saving
is time, a benchmark for CPU and load at production concurrency for
contention, and to keep the change only if the gain shows. Rust only, in Claude
Code, Codex and OpenCode. See
the design and
the contract.

FAQ

No. All four reviews only read. They do not clone, copy, build or run your
project, run its checks or benchmarks, or post comments on a PR.

Super Review does not: it assesses readability and maintainability only, not
bugs, security, product requirements or test coverage. For bugs in Rust, use
the experimental Defect Review; for gaps
in Rust tests, Test Review; for unneeded
work on Rust hot paths, Performance Review.

No. The report says exactly what was covered, and completed coverage is not
exhaustive discovery. Super Review does not claim that a suggested refactoring
is tested to be equivalent.

Go, TypeScript/TSX, Rust and Java for Super Review; Rust for Defect Review,
Test Review and Performance Review. Tests, generated and vendored code are excluded from
Super Review. JavaScript/JSX, CSS and MDX are not standalone targets.

Documentation

• Design and the review family
• Model profiles and native integrations
• Cursor and OpenCode adapters
• Validation: package checks kept apart from model evidence
• Instruction audit: 3.0.1 scope corrections and coverage defaults
• Maintainer evaluation cases: frontend, Spring. Fixture checks do not claim measured model-quality gains.

Contributing

See CONTRIBUTING.md. Also: Privacy ·
Changelog · Third-party notices

License

MIT © Dankosik