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 under explicit repair authorization still in force for the same task. 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 authorization from the current request, or from an authorization still in force for the same unfinished task: one that named this action and goal and has not been withdrawn. A later turn that asks for progress or says "continue" does not revoke it and does not have to repeat it. A new action, a wider scope, a changed goal, or a risk the original authorization did not cover needs its own. Approval of a draft is not approval to commit, push, publish, or delete. 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 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 . Commit and push follow through adds the HEAD re read in references/mode ship.md . 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 A review prompt, skill, persona, or model changed; "is review still catching bugs" load references/incident ledger.md (Replay eval) Document, PDF, prose review Delegate to /write Document Review Mode, keeping it in the same completion ledger; without /write , use the available prose capability and name the limitation 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 never depends on private machine paths or unpublished instructions. Learn the project from the diff and its public context (manifests, CI workflows, AGENTS/CLAUDE files, release notes) until you know its verification commands, generated or protected files, release artifacts, and domain risks. The shape is in references/project context.md . Where project context and this skill overlap and both can be met, satisfy the stricter one. An explicit project exception wins and the report names it; stricter is not a licence to overrule a written decision or reorder the host's instruction precedence. Prefer a verification command the project names, and read the workflow rather than the sentence describing it. A doc claiming CI enforces something is a claim; a check that runs on only one side (local or CI) means a green run there predicts nothing about the other. For release readiness or publication, 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. A commit/push only task uses the source delivery checks in references/mode ship.md ; unrelated release assets and registry state are out of scope. Plan Execution Mode Activate when the message starts with "Implement the following plan", "按计划实施", "按照计划", "整", "可以干", or "直接改" followed by a plan body, or links to a /think output. Skip the code review: name the plan, check git status short branch uall for drift that makes it unsafe (name the conflict and stop), execute, then run the project's verification command. Review then ship: when AGENTS.md or the current thread asks to "commit after review", "ship if green", or equivalent, load references/mode ship.md after a clean review or finished plan, state "proceeding to ship", and do not ask again. 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 : resolve the latest stable from the delivery channel the product actually uses (feed, registry, store, or release host), map it to a source ref, and review through HEAD , then add dirty files. A stale release host listing is not the baseline when another channel ships the product; a missing artifact to ref mapping stays an explicit gap. 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. For a large inventory, reconcile the union of reviewed paths against that frozen set, including root files and cross domain consumers; assignment alone is not coverage. Repeated locale or generated files may share a semantic check only when it accounts for every member, otherwise name the sampled and unread remainder separately. 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. Depth measures size; risk tier follows paths. A diff touching CI workflows, release or signing, the updater, auth, billing or license, installers, privilege, or deletion paths gets the project's heaviest gate and a human maintainer's review whatever its size or author; an agent's, bot's, or automated reviewer's approval never replaces that review. The method is the Risk tiers section of references/project context.md . 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 . Every changed file and new public surface must trace to the stated goal in one sentence; a file, dependency, config knob, abstraction, generated artifact, workflow permission, or release behavior that cannot is drift until proven necessary. Any one of these is enough: a file unrelated to the goal, pure refactoring or unrelated deletion inside a fix or feature, an unmentioned dependency or helper, or a cleanup that quietly adds user visible UI, default config, workflow permissions, or release behavior. For every new public setting, flag, environment variable, command, or service, ask who will change it and why one correct default cannot serve them; with no evidenced user split, treat the knob as drift and fix the default path instead. Every review, unasked, runs an over design pass: for each new file, option, fallback, layer, or abstracti