/senior-review · Workflow

Senior Review

A senior second pair of eyes that proves every bug it flags.

FR EN

"/senior-review --deep before merging my feat/auth-refresh branch"

The skill starts by assembling context: cross-file call sites, project conventions, git history, linked ticket. Blind reviewers run in parallel, each different from the author. Every critical finding requires concrete proof (grep, execution, red test), and an adversarial panel tries to refute it. The final report caps nitpicks and stays silent when nothing material is found.

A.

What it does

A research-grounded pipeline: context assembly first (cross-file call sites, conventions, git history, ticket), an objective tool gate, blind reviewers in parallel (reviewer != author), a verification gate where every critical finding needs a receipt (grep, execution, or a red test), then an adversarial panel that tries to refute the critical or uncertain findings.

B.

When to use it

Before a merge, on a working tree, staged changes, a branch or a PR. Optimizes signal/noise over recall: caps nits, says explicitly what NOT to flag, stays silent when nothing is material. Tiers --quick / standard / --deep. Not for building a feature nor for pure lint.

The stance

The stance: a review that lists 40 remarks doesn't get read. This one optimizes signal over noise: every critical finding needs a receipt (grep, execution, red test), an adversarial panel tries to refute it, and it stays silent when nothing is material.

Install this skill

claude code
$ /plugin marketplace add ohugonnot/claude-skills
$ /plugin install senior-review@web-developpeur-skills
#code-review#security#quality#fresh-eyes#pr#audit

Frequently asked questions

What's the difference between --quick, standard, and --deep?

The three tiers adjust analysis depth and the number of blind reviewers. --quick suits a short, low-risk PR; --deep is for critical code or a large change surface.

Why does every critical finding require proof?

To eliminate false positives. A finding without proof (grep, red test, execution) is rejected by the verification gate, which keeps real issues from getting buried in noise.

Can I use it on a working tree or staged changes, not just a PR?

Yes. The skill accepts a working tree, staged changes, a branch, or an existing PR as its entry point.

See the skill source: SKILL.md on GitHub. The skill also triggers automatically when your request matches its description, and an AI agent discovers it via the MCP server. To understand how these skills are designed, read the official skills patterns.

Feedback & discussion · 0

No feedback yet. Tried it? Tell us what you think.