Check

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, find the problems, fix what can be fixed safely, ask about the rest. Done means verification ran in this session and passed.

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 close with a completion ledger (done / not applicable / remaining), never a narrative that leaves the user asking "is everything done".

Worktree Safety Preflight

Before any review, triage, ship, release, or PR operation, read the current worktree with:

git status --short --branch -uall

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 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.

Before any mode, run Project Context Extraction and (if memory is in scope) 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.

Durable Context Preflight

See 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.

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

Get the full diff between the current branch and the base branch. If already on the base branch, ask which commits to review.

Scope

Measure the diff and classify depth:

State the depth before proceeding.

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.

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

Pattern-Fix Completeness

When the diff fixes one instance of a class-of-bug (a missing validation, a wrong selector, an off-by-one, a missing lock), the same shape often lives elsewhere. Extract the pattern signature, grep -rn it across the repo (exclude generated dirs), and confirm sibling instances were also handled. List any unswept sibling: flag it as a hard stop when it carries the same risk, advisory when lower-risk. For a deeper sweep playbook, see hunt's Scope Blast Mode.

Testability Seam For Recurring Bugs

When the diff fixes a visual, layout, timing, or stateful-UI bug that has recurred (the same area broke before, or the fix reads as "tune a number until it looks right"), a code change alone will let the regression return: the logic is entangled with mutable render or UI state, so there is nowhere to assert on it. Flag the fix as incomplete unless it pulls the decision into a pure function -- inputs in, value out, no mutable receiver -- and unit-tests the invariant that was violated (a width never collapses to zero, a hit region stays half-open, an offset stays in bounds). "Verified by running the app" confirms this one instance; only a pinned invariant stops the next one. Reserve this for classes that recur or that runtime checks cannot see; do not demand a seam for one-off logic that already has straightforward coverage. If no honest seam exists -- the only place to assert is past a shallow interface that never exercises the real failure at the call site -- do not fake a hollow test to satisfy the gate. Record "no correct test seam" as an architectural finding and surface it: the missing seam is the actual defect.

A pure function is the right seam when the bug is one wrong decision. It is the wrong seam when the bug is "a future call site will bypass this": a guard hoisted into a shared helper still only protects the callers that route through it, and the next contributor adds the eleventh call site without it. For that class, the guard that holds is a test that asserts on the source tree itself -- enumerate the call sites of the risky primitive and fail on any that skips the wrapper, or fail on any new occurrence of the raw pattern outside an explicit allowlist. It runs in the normal suite, needs no runtime, and turns "someone must remember" into a failing build. Reserve it for primitives where forgetting is silent and costly (unbounded external commands, direct deletion, raw privilege escalation), and keep the allowlist in the test so each exemption is a reviewed line.

CLI Command Surface

When a diff touches a CLI entrypoint, installer, completion, config/env handling, package wrapper, or a mutating command such as cleanup, update, uninstall, migration, or cache removal, load references/release-surfaces.md (CLI Command Surface) and work its checklist, then fill the CLI Command Surface template from references/project-context.md before sign-off. The core stance: verify command contract and installed-runtime behavior, not just library tests, and treat every mutating command as a safety sink.

Terminal output is a rendered surface. After changing CLI-facing text, spacing, or layout, re-run the command and read the real output before claiming done; editing the string is not seeing the screen.

Skill, Plugin, And Packaged Install Surface

When a diff touches a skill, plugin, marketplace entry, installer, package allowlist, package manifest, generated mirror, or published archive, load references/release-surfaces.md (Packaged Install Surface) and verify the installed runtime contract through its five steps: real user install path, rebuilt package contents, isolated install smoke, noise filtering, and explicit gaps when the smoke cannot run. Manifest JSON, source tests, or a successful local import never substitute for installed-runtime proof.

Hard Stops (fix before merging)

Examples, not exhaustive -- flag any diff that could cause irreversible harm if merged unreviewed.

• No unverified claims. Do not write "I verified X", "I ran Y", "tests pass", or "this fixes Z" unless the shell output is in this turn's transcript. If you reason about behavior without running, say "based on reading the code" instead of "I verified". Every verification claim in the sign-off must point to a command that actually ran in this session.
• Re-read before citing source-of-truth facts. Before writing a line number, dirty-file count, branch ahead/behind state, fallback behavior, locale coverage, or release artifact state into a handoff or review report, re-read the source in this turn (git status, git diff, file Read, rg, command output). Earlier chat context, prior agent notes, and your own recall are stale by default. Cite the verification path inline (per current Read of <file> / per git status this turn) so reviewers know which facts are anchored.
• String-matching on captured output: when a diff branches on or greps an error message or command output, probe what that string actually holds at runtime before approving. A subprocess spawned with stdio: 'inherit' (or any uncaptured pipe) leaves diagnostics on the terminal and error.message holding only the command line, so the matcher silently matches the command, not the output. Prefer a structured fact the caller already holds (exit code, build target) over re-parsing a string.
• Magic-wait coupling: a fixed sleep, asyncAfter, setTimeout, or "should be enough" timeout standing in for an unobserved async completion, or an animation, poll, or progress step tied to a frame count or fixed duration rather than wall-clock state. It passes on the author's machine and breaks on a slow CPU, a 120Hz display, or a proxied network. Flag it: drive the next step off the real completion signal (callback, navigation-done, frame-changed, state flag), and keep timing machine- and frame-rate-independent.
• Destructive auto-execution: any task marked "safe" or "auto-run" that modifies user-visible state (history files, config, preferences, installed software) must require explicit confirmation.
• Source and distribution out of sync: everything the source change implies downstream must be regenerated, tracked, uploaded, and version-consistent before declaring done: generated or bundled outputs rebuilt and included, every artifact named in release notes or workflows actually uploaded, every new helper module, reference file, or script present in the built archive, and version fields synchronized across manifests, package metadata, changelogs, tags, and lockfiles.
• Verifier failure layer unclear: if a verifier fails before assertions or due to missing optional dependencies, bootstrap noise, transient build-service crashes, unavailable simulators, or tool setup, classify setup versus product failure. Retry only with new evidence or a narrower environment. Do not call the repo broken until the intended test body or artifact check actually ran. The inverse is the same stop: a verifier that passes without running the real path -- a skipped optional-dependency job that still prints OK, a function that early-returns leaving output empty so a true-on-empty assertion passes, a render reported fixed but never opened -- is a hollow green. A pass counts only when at least one non-skipped, non-empty case exercised the path and the assertions fail on emptiness.
• Manifest-only install proof: if a diff changes a skill, plugin, installer, marketplace entry, package wrapper, or installable archive, metadata and source tests are not enough. Build or install through the real user path in an isolated environment, or mark the install/runtime layer unverified.
• Unknown identifiers in diff: any function, variable, or type introduced in the diff that does not exist in the codebase is a hard stop. Grep before writing or approving any reference: grep -r "name" . -- no results outside the diff = does not exist.
• Consolidation pass with no over-deletion audit: a diff whose stated purpose is simplifying, consolidating, or trimming prose (rules, skills, docs, guidance) gets its deletions read back as a diff, each classified as folded-into-X, redundant-with-Y, or behavior-removed. Behavior-removed entries are listed for the maintainer, never absorbed into a "simplified" summary line. Deletion volume is not evidence of a good pass, and the pruning rules that drive these diffs have no symmetric counterweight of their own, so the audit has to come from review.
• Dead-code or YAGNI deletion without proof: any "zero callers" or "unused" claim must be checked across the whole repository, including top-level entrypoints, docs, tests, generated dispatch tables, scripts, CI, package allowlists, package manifests, and dynamic lookup patterns. Treat sub-agent or tool reports as leads, not proof. Before deleting, batch-grep all candidates, classify test-only references separately from production/runtime references, and chase written variables or data tables that may become orphaned together. If a file is only wrongly exposed through a package, archive, or plugin mirror, tighten that distribution surface and its test instead of deleting the dev tool. If the grep scope is partial, do not delete.
• Injection and validation: SQL, command, path injection at system entry points. Credentials hardcoded, logged, committed, or copied into public docs.
• Dependency changes: unexpected additions or version bumps in package.json, Cargo.toml, go.mod, requirements.txt. Flag any new dependency not obviously required by the diff. The inverse is a finding too: a declared dependency or linked SDK with zero imports across the repo gets flagged to the maintainer, not silently removed (it may be staged for an upcoming feature, and unused analytics/telemetry SDKs still drag app review and privacy manifests). Removal needs the maintainer's go-ahead in the current turn, a grep proving zero references first, and a full build after.
• Safety sinks: destructive file operations, shell or AppleScript construction, cwd/path/symlink traversal, approval or sandbox boundary changes, signing/appcast flows, and auth prompts need explicit review of validation, rollback, and user-confirmation behavior.
• Audit before restore: when the diff re-adds a symbol, string, asset, or config field that recent history removed, grep the rest of the diff and the main branch to confirm anything still uses it. A rule file that names the symbol is not proof of life. If only a parity test references it, the rule is stale and the restore is wrong; reject the restore and flag the stale rule. Specifically suspicious: re-adding an enum case, xcstrings entry, dictionary key, or asset file that the prior commit deleted intentionally.
• Intentional-divergence normalized: a surface that deliberately breaks a house pattern -- omits a shared step, takes a conditional path the siblings avoid, leaves an asymmetry -- to dodge a known defect, then a later cleanup pass "tidies" it back into uniformity and reintroduces the bug. Before unifying an outlier to match its siblings, read the comment or commit that created it and confirm the defect it prevents survives your change.
• Broad matchers in destructive sinks: any diff that adds recursion, mass-delete, traversal, ID-prefix wildcards, or fallback regex branches feeding a destructive sink gets a line-by-line review of three things: matcher breadth in every branch (fallback paths often regress to broad globs), protected-path coverage for the new entry point, and any bypassed user-confirmation step. Gate on the shape, not the author: the most expensive instances are written by maintainers who know the codebase, where a deletion target is built by string-composing a display name, a vendor prefix, or a user-supplied label into a path, and a neighbour that merely shares that token gets removed too. Ask what the narrowest evidence authorizing this delete is; an exact identifier or an exact path passes, a prefix or a common word does not. Raise the bar further when the PR is plausibly AI-generated, and do not approve "this looks fine." Where the guard lives matters as much as its breadth: a check placed at the call site protects only that caller, so prefer it inside the deletion primitive itself.
• Two derivations of one value: the same classification, ordering, threshold, count, or eligibility rule computed independently in two places (a summary and the list it summarizes, ordering and the control it orders, a score and the diagnosis text beside it, a preview count and the executor's predicate). They agree the day they are written and drift on the first change to either. When a diff adds a second derivation, require one source of truth: hoist the rule into a shared constant or pure function and have both sides read it. When a diff changes one side of an existing pair, grep for the other side and confirm it moved too. A user-visible disagreement between two numbers that describe the same thing is the symptom this prevents.
• Test asserts on a surface production never runs: a test that pins a helper no call path reaches, or asserts the literal source shape of a command or config string, stays green while the shipped path is broken and blocks the correct fix by pinning the broken form as correct. Related to hollow green above, but the inverse failure: there the verifier skipped the real path, here it exercises a path that is not the real one. When reviewing a test added alongside a fix, ask whether it would fail on the unfixed code and whether the entry point it asserts on is the one users reach. If the answer to either is no, the test is a finding, not coverage.
• Migration code for features that did not ship before: reject migration scaffolding, version-gated defaults, or "carry old key forward" logic when the underlying preference / schema / feature was introduced in this same release. git show v<last-release>:<path> is the gate: if the key is absent from the last tag, no migration is needed; ship the default. Migration code added for a never-shipped key is dead-on-arrival complexity.

Finding Quality Gate

Before writing any finding into the report, run this gate:

Pre-report self-check (four questions, every finding must pass):

1. Can I cite the exact file:line?
2. Can I describe the specific input or state that triggers the bad outcome?
3. Have I read the upstream callers / downstream consumers, not just the function in isolation?
4. Is the severity defensible? Would a senior reviewer raise this at this level in a real PR?

If any answer is "no", drop the finding or downgrade it to advisory. Vague findings train the reader to ignore real ones.

A clean review is a valid review. Do not manufacture findings to justify the invocation. Zero findings with a stated review surface is a complete output. Padding the report with low-confidence noise is a worse outcome than reporting nothing.

HIGH and CRITICAL require three pieces of evidence:

1. The exact file:line where the bug lives.
2. The specific trigger: what input, state, or sequence produces the bad outcome.
3. Why existing guards (validation, type system, upstream catch, framework default) do not already prevent it.

Cannot supply all three? Downgrade to MEDIUM, or drop. "This might break under some condition" is not a HIGH.

Knowledge Sync

After reviewing the diff, check whether it introduces invariants not yet captured in project docs:

• New safety gate or path-guard rule → AGENTS.md
• New UI constraint (layout rule, animation, overlay registration) → .claude/rules/*.md
• New deploy/release step or artifact → AGENTS.md or docs/
• New cross-file sync requirement (enum ↔ HTML anchors, Swift keys ↔ xcstrings) → AGENTS.md
• One-off review reports or diagnostic snapshots should not become durable docs as-is; extract the stable rule into AGENTS/CLAUDE/rules/references and drop the stale report from the commit.

Snapshot Report Routing

Treat review reports, scorecards, and diagnostic snapshots as evidence, not as source-of-truth docs. Before approving one:

1. Re-read the current diff or repo surface named by the report. If the claim is stale, exclude the report from the commit or rewrite it into a stable rule.
2. Keep project-specific commands, paths, protected areas, release rituals, and safety constraints in that project's public context. Do not promote them into Waza.
3. Promote only transferable review behavior into Waza: e.g. "check untracked files before readiness", "inspect generated package contents", or "turn one-off reports into invariants."

If found, either apply the doc update as safe_auto (when the invariant is clear from the diff) or flag it in the sign-off as doc debt. When no new invariants exist, sign-off says doc debt: none.

Specialist Review (Standard and Deep only)

Load references/persona-catalog.md to determine which specialists activate. When the environment has an agent or sub-agent facility, launch all activated specialists in parallel, each with the full diff and its own persona brief. If no parallel reviewer facility exists, run the specialist passes sequentially in the same session.

Merge findings: when two specialists flag the same code location, keep the higher severity and note cross-reviewer agreement. Findings on different code locations are never duplicates even if they share a theme.

Every specialist finding is a claim to verify, not a fact to act on. For HIGH and CRITICAL claims, when the agent facility allows it, spawn one independent skeptic per finding whose only brief is to refute it against the actual code; a finding the skeptic refutes on direct read is dropped or downgraded regardless of which persona raised it. Without the facility, run the skeptic pass yourself: re-read the cited code this turn and confirm the claim is real and live, not already handled elsewhere, not consistent-by-design, not a latent-only risk labeled as a live bug. Parallel reviewers over-report from name-based inference and partial context; drop what dissolves on direct read, and cite the verification path before routing anything to Autofix or sign-off.

Autofix Routing

Apply all safe_auto fixes before surfacing the gated_auto confirmation block.

Adversarial Pass (Deep only)

"If I were trying to break this system through this specific diff, what would I exploit?" Four angles (see references/persona-catalog.md): assumption violation, composition failures, cascade construction, abuse cases. When the agent facility exists, run the four angles as parallel agents, each blind to the others' findings: convergence from independent angles raises confidence, and singleton findings face the same per-finding skeptic verification as specialist claims. Suppress findings below 0.60 confidence.

Platform Operations

Use the platform tool that matches the project. For GitHub projects, prefer gh or the available GitHub integration and confirm CI passes before merging. For non-GitHub projects, derive the CLI/API from public project docs or the user's explicit platform context; do not force GitHub commands onto other hosts.

Poll CI as structured state, not streamed text: gh run view <id> --json status,conclusion (or the host's equivalent). Piping gh run watch, test output, or build output through tail/head swallows the real exit code and can report a failed or still-running run as green.

Verification

Run bash <skill-base-dir>/scripts/run-tests.sh from the target project root (<skill-base-dir> is this skill's base directory; the script auto-detects the project's test command from the current working directory), or the project's known verification command. Paste the full output.

If the script exits non-zero or prints (no test command detected): halt. Do not claim done. Ask the user for the verification command before proceeding. If the user also cannot provide one, document this explicitly in the sign-off as verification: none -- no command available and flag it as a structural gap, not a pass.

For bug fixes: a regression test that fails on the old code must exist before the fix is done.

In a dirty or multi-agent checkout, a passing local build or test run is not proof your change is sound: unrelated WIP already in the tree can supply missing symbols, mask a break, or fail for reasons unrelated to you. Verify in isolation -- git worktree add --detach <known-good-commit>, git apply only the diff of the files you own, then build/test there. The clean isolated pass is the real signal; the contaminated local pass is not.

Gotchas

Document Review

For document, PDF, white paper, or prose review, route to /write (Document Review Mode). /check handles code diffs and release artifacts only.

Sign-off

Open the final message with the status line as plain prose before any table or detail: exactly where the work stands now, with the hash, tag, or blocker. A verdict buried under verification tables reads as unfinished and makes the user re-ask "都提交了吗"; the tables support the verdict, they do not replace it.

status:           [committed and pushed as <hash> / staged, not committed / released vX.Y.Z / blocked on <what>]
files changed:    N (+X -Y)
scope:            on target / drift: [what]
review depth:     quick / standard / deep
hard stops:       N found, N fixed, N deferred
sibling sweep:    N same-shape sites checked, N fixed / none found / not applicable
specialists:      [security, architecture] or none
new tests:        N
public actions:   replied #N, closed #N, reactions done / none pending
doc debt:         none / AGENTS.md needs X / rules need Y
verification:     [command] -> pass / fail

public actions lists every outward-facing step the task implied (issue replies, closures, release reactions) with its done or pending state; an external action the user has to ask about was not finished.