Reviews code diffs, PRs, issue queues, release readiness, commits, pushes, publishing, and project audits. Use when users ask in any language for code review, issue or PR triage, release gates, publishing follow-through, or project audits. Not for debugging root causes or prose review.

Check: Review Before You Ship Prefix your first line with 🥷 inline, not as its own paragraph. Note: /review is a built in Anthropic plugin command for PR review. Waza uses /check (or the alias code review ) instead. Do not re trigger /review from within this skill. Read the diff and find the problems. Review, audit, triage, and readiness requests are report only; apply fixes only when the current turn explicitly asks to fix, change, implement, or optimize. Done means the requested review surface is covered and every verification claim comes from this session. Outcome Contract Outcome: a review, release decision, or maintainer action grounded in the current diff, project context, and live evidence. Done when: findings, fixes, shipped state, or blockers are stated with the commands, artifacts, or remote state that prove them. Evidence: worktree status, diff, public project docs, manifests, CI, package contents, release or registry state, and current command output. Output: concise findings first, then verification and shipped state summary when applicable. Multi step or ship action runs, and any request with several items or screenshots, close with a numbered completion ledger (done / not applicable / remaining), never a narrative that leaves the user asking "is everything done". Authorization: read only intent may inspect the worktree and remote state but may not edit files, apply autofixes, commit, push, publish, comment, close, merge, or change branches. Each write or public action needs current turn authorization, except when the user explicitly authorizes a named batch that contains it. Durable Context Preflight See [references/durable context.md](references/durable context.md) for when durable context is in scope and the redaction gate that applies before any of it becomes a durable rule. For /check : the current diff, CI, and remote state override memory. Durable memory can explain user intent and preferred follow through, but public project rules still come from README files, manifests, CI workflows, release docs, and explicit instructions in the current thread. Never cite private memory as a public project requirement. Worktree Safety Preflight Before any review, triage, ship, release, or PR operation, read the current worktree with: Treat modified, staged, and untracked files as user work. You may read them and include them in the review surface, but you must not move, hide, overwrite, clean, or discard them without explicit user approval in the current turn. Do not run these commands as default review or PR setup: git switch , git checkout , git reset hard , git clean , git stash u , git stash include untracked , git stash a , git stash all , or gh pr checkout . If a branch change or cleanup is genuinely required, stop and ask for that exact operation. Do not "protect" user work by moving untracked files, generated files, screenshots, or local scratch files into /tmp or another holding directory. Moving someone else's WIP out of the checkout is the same class of interference as stashing it. If a clean tree is required for generation, packaging, or verification, use a separate worktree from a known commit and copy only the artifact or patch you own back into the current checkout. For commit or push follow through in a dirty or multi agent checkout, record git rev parse HEAD before staging. Re read git status short branch uall and git rev parse HEAD immediately before commit and again before push. If HEAD moved, unknown commits appeared, or the worktree changed outside your intended files, stop and report the mismatch instead of rebasing, recommitting, or pushing. For PR inspection, prefer commands that do not switch the current working tree: gh pr view , gh pr diff , git fetch origin pull/<n /head:refs/tmp/pr <n , and git merge tree . Mode Picker Pick the mode that matches the user's intent, then read it in full before acting. Modes layer on top of the shared review surface (Scope, Hard Rules, Hard Stops, Autofix, Specialist Review, Verification, Sign off) further down, which applies in every mode. Load a mode file only when its row matches; the default review path needs none of them. User intent Mode "implement this plan", /think output handed off [Plan Execution]( plan execution mode) Diff or PR ready, "review", "看看代码", "合并前" Default review (start at [Get the Diff]( get the diff)) "look at issues", "review PRs", "triage", "批量处理" load references/mode triage.md "is this worth a release", "值不值得发版" load references/mode ship.md (Release Worthiness Analysis) "commit", "push", "publish", "release", "close issue", "发布表情" load references/mode ship.md (Ship / Release Follow through) "audit", "项目体检", "项目评分", "给项目打分", "深入分析项目代码", "scorecard", "linus review" load references/mode audit.md Document, PDF, prose review Delegate to /write (see [Document Review]( document review)) Before any mode, run [Project Context Extraction]( project context extraction) and (if memory is in scope) [Durable Context Preflight]( durable context preflight). Project Context Extraction This is Waza's public, standalone code review capability. It should not depend on private machine paths or unpublished project instructions. Before reviewing, extract project constraints from repository context: 1. Read the diff and identify changed languages, frameworks, manifests, generated outputs, release files, and CI workflows. 2. Inspect public project files only as needed: README, AGENTS/CLAUDE instructions when present, package manifests, lockfiles, build configs, test configs, workflow files, and release notes. 3. Compress the findings into review context: verification commands, protected or generated files, release artifacts, domain risks, and public reply rules. 4. Apply the stricter rule when project context and this skill overlap. 5. If project docs or CI name a verification command, prefer that over auto detection. For the context shape, see references/project context.md . For release or maintainer work, also fill the Release Gate 2.0 matrix from references/project context.md . It covers review base, dirty/staged/untracked state, latest tag, origin sync, version fields, generated artifacts, package/archive contents, release assets, registry/appcast/CI, and public issue/PR state. Missing matrix evidence is a blocker for a "ready to release" claim. Plan Execution Mode Activate when the user's message starts with "Implement the following plan", "按计划实施", "按照计划", "整", "可以干", "直接改" followed by a plan body, or links to a /think output. In this mode, do not run a code review. Instead: 1. State which plan is being executed (first heading or summary line). 2. Check for obvious repo drift: run git status short branch uall and skim any changed files that contradict the plan. If drift makes the plan unsafe, name the specific conflict and stop. 3. After all items are done, run the project's verification command. 4. Transition automatically into references/mode ship.md if the project context or current thread indicates review then ship. Default Continuation (review then ship) When the project's AGENTS.md or the current thread explicitly asks to "commit after review", "ship if green", or equivalent, load references/mode ship.md and transition directly from review to the ship flow after a clean review. Do not ask again. State "proceeding to ship" before acting. Get the Diff Derive the review baseline from the user's words and current repository state. Do not ask for commits when the scope is already inferable: All local or uncommitted changes : inventory staged, unstaged, and untracked files, plus local commits ahead of the configured upstream. Being on the base branch does not make this scope ambiguous. PR or branch review : use the merge base through the reviewed head, then add any dirty files in that checkout as a separate surface. Since the last release : use the latest published stable tag through HEAD , not the local version field, then add dirty files. Recent N days or an explicit ref : resolve that time/ref boundary through HEAD , then add dirty files. Known good or previous working version : compare that ref through HEAD ; route to /hunt Bisect Mode only when the regression point itself is unknown. Whole project audit : use Audit Mode rather than pretending one diff is the repository. Freeze the resolved base, HEAD , worktree inventory, generated/distribution surfaces, and delegated scopes before review. Ask one narrow question only when two plausible baselines would materially change the verdict. If review fixes are applied or repository state moves, the old verdict expires: re read HEAD , status, and the full resolved diff before signing off. Scope Measure the diff and classify depth: Depth Criteria Reviewers Quick Under 100 lines, 1 5 files Base review only Standard 100 500 lines, or 6 10 files Base + conditional specialists Deep 500+ lines, 10+ files, or touches auth/payments/data mutation Base + all specialists + adversarial pass State the depth before proceeding. Explicit depth language overrides the size thresholds. "All", "全部", "deep", "深入", or "仔细" means whole scope coverage of the resolved inventory, even when the textual diff is small; it does not permit skipping untracked files, generated mirrors, required artifacts, or pending reviewers. Static content diffs can stay quick even when they touch several generated files: version strings, dates, release copy mirrors, sitemap dates, or one for one localization copy changes usually need line by line readback plus grep consistency, not a specialist fleet. Escalate only when the diff changes logic, generation rules, public distribution behavior, or user facing semantics beyond the literal text replacement. Did We Build What Was Asked? Before reading code, check scope drift: do the diff and the stated goal match? Label: on target / drift / incomplete . Also check surgical traceability: every changed file and every new public surface must trace back to the user's stated goal. If a file, dependency, config knob, abstraction, generated artifact, workflow permission, or release behavior cannot be explained in one sentence from the request, label it drift until proven necessary. For every new public setting, flag, environment variable, command, or service, ask who will change it and why one correct default cannot serve them. If there is no evidenced user split, treat the knob as scope drift and fix the default path instead. Drift signals (examples, not exhaustive any one is enough to label drift): A changed file has no connection to the stated goal The diff includes pure refactoring (renames, formatting, restructuring) when the goal was a bug fix or feature A new dependency appears that the goal did not mention Code unrelated to the goal was deleted or commented out A new abstraction or helper was introduced that is not required by the goal A maintainability, review, or cleanup change quietly adds user visible UI, default config, workflow permissions, or release behavior Question the Approach, Not Just the Diff Scope drift checks the diff against the stated goal; this checks the goal against the approach. Skip when the user declares the route settled or the repo's design docs record the decision do not re litigate deliberate trade offs. When findings cluster on one root cause the same bug class patched repeatedly, permission or state problems that follow from the architecture itself, a simple problem made complex stop listing patches and state the route verdict first: keep / adjust / replace / insufficient information. Compare a real alternative only when it eliminates the problem class at an acceptable migration cost; never manufacture one to fill the report. No patch