القائمة
Use when reviewing branch or PR changes against a base branch for correctness, security, concurrency, architecture, maintainability, testing, and performance risks.
Use when posting validated code review findings as GitHub PR line-level comments or a GitHub PR review after completing a review.
Applies Karl Popper’s critical rationalism to software engineering, programming, and product building by treating requirements, designs, implementations, and product ideas as falsifiable hypotheses. Emphasizes conjectures and refutations, explicit assumptions, fast error discovery, small risky experiments, observable failure signals, reversible designs, and iterative elimination of mistakes.
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design.
Baseline coding behavior. Use before writing, reviewing, debugging, or refactoring code. Establishes ground rules for assumptions, simplicity, surgical edits, and verification.
Generate or check Codex CLI .codex-plugin/plugin.json and Gemini CLI gemini-extension.json manifests from a Claude Code .claude-plugin/plugin.json source manifest. Use when maintaining one plugin across Claude Code, Codex CLI, and Gemini CLI, syncing plugin metadata, preserving platform-specific manifest fields, or validating cross-platform plugin manifests before release.
Use when improving an article or long-form draft for structure, clarity, coherence, flow, readability, or prose quality while preserving meaning, accuracy, intent, and voice.
| name | code-review |
| description | Use when reviewing branch or PR changes against a base branch for correctness, security, concurrency, architecture, maintainability, testing, and performance risks. |
| argument-hint | [--base BRANCH] [--comment [LANGUAGE]] |
| disable-model-invocation | true |
Review the current branch or PR against a base branch with adversarial, evidence-based scrutiny. Prefer concrete regressions over style feedback.
Default to a single pass. One reviewer reads the whole diff against the checklist in step 3; a single context keeps cross-cutting bugs (e.g. a change that is both a concurrency and a security issue) visible and findings high-signal. Reserve isolated subagents for one case: a diff too large to review in one focused pass. Partition the substantive files into a few cohesive groups (by module/directory), review each group against the full checklist — sequentially, or as a handful of parallel subagents — then merge and dedup. Never fan out by lens, and never one subagent per file — both fragment cross-cutting bugs and inflate false positives.
origin/main. --base BRANCH compares against BRANCH.--comment [LANGUAGE]: after the report, gate posting through Posting (below) — the user approves a subset in chat and only that subset is posted via add-pr-comments. LANGUAGE sets comment language (default English). Without --comment, the report (step 6) is the final artifact and nothing is posted.Pin the comparison. Set BASE_BRANCH from --base or origin/main, then:
HEAD_SHA=$(git rev-parse HEAD)
MERGE_BASE=$(git merge-base "$BASE_BRANCH" "$HEAD_SHA")
Review "$MERGE_BASE".."$HEAD_SHA" for the entire pass.
Inventory the diff: changed files, shortstat, added/deleted files, diff body. Ignore generated files, vendored code, lockfiles, snapshots, and docs-only changes unless they affect runtime, build, or security.
Read the whole diff against this checklist — or, if it is too large for one focused pass, partition it as described in the intro. correctness always applies; the rest are cues — weight attention to what the diff actually touches. Gather evidence first (cited ranges, prior vs current behavior, touched callers, reachable inputs), then draft a finding only from evidence: title, severity, confidence, file:line, failure mode, fix.
| Lens | Look for |
|---|---|
correctness | logic, null handling, contracts, stale callers, data corruption, migrations, cache staleness, unreachable code |
security | auth/authz, injection, unsafe deserialization, SSRF, path traversal, tenant or PII leaks |
concurrency | non-atomic updates, lock ordering, cancellation hazards, retry interactions, double-submit/double-process |
architecture | boundary breaks, dependency direction, wrong-layer abstractions, cross-module coupling |
maintainability | brittle abstractions, unclear invariants, accidental complexity, obvious simplification not taken |
testing | coverage gaps for changed behavior, weak assertions, flakiness, fixture pollution |
performance | query shape, N+1s, hot-path allocations, nested loops over user data, missing or wrong caching |
Apply the bar. Self-critique each candidate from the PR author's perspective and keep only what the author would clearly fix. Returning zero findings is correct — if nothing clears the bar, say so; never pad the report. Move plausible-but-unverified concerns to residual risks.
Validate every surviving finding against the current code and diff; drop anything the cited range does not support. Dedup overlapping findings, keeping the strongest severity/confidence.
Report in this order:
<merge-base>..<HEAD> resolved to short SHAsready to approve, ready after fixes, or not ready — one line, naming the blockers if anySEV/CONF, file:line, failure mode, fixIf --comment is set, gate posting through Posting below — the only path that writes to GitHub, and only after explicit user approval.
--comment)Posting is the only irreversible step — never invoke add-pr-comments or any gh write until the user approves the final set.
F1, F2, …). Ask the user to reply keep / drop / dive per finding — e.g. "drop F2, dive F4: check the lock at L138, keep the rest."git rev-parse HEAD; if it moved since the review, warn that line anchors may have shifted and confirm before continuing. Hand the kept set + LANGUAGE (default English) to add-pr-comments.After the report, answer user follow-ups conversationally:
critical: exploitable security issue, auth bypass, data loss, corruption, severe outagehigh: likely production failure or serious regressionmedium: real bug under a plausible edge caselow: non-trivial issue worth fixing, not a blockerA blocker is a finding that makes the change unsafe to merge as-is — critical or high by default, a medium only when its edge case is plausible in practice; low is never a blocker.
high: directly supported by cited codemedium: strong evidence with one assumptionlow: plausible but speculative — prefer residual risk over a low-confidence finding