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, infer the feature's real intent, model the risk surface, find the problems, fix what can be fixed safely, ask about the rest. Done means the functional acceptance path, adversarial risk pass, and verification all have current evidence or explicit blockers.

Outcome Contract

• Outcome: a review, release decision, or maintainer action grounded in the current diff, feature intent, 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.
• Core question: "Given what this change is trying to accomplish, what could go wrong for a real user, operator, maintainer, or security boundary?"

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//head:refs/tmp/pr-, and git merge-tree.

Mode Picker

Pick the mode that matches the user's intent, then read that section in full. Modes layer on top of the shared review surface (Scope, Hard Stops, Autofix, Specialist Review, Verification, Sign-off) further down.

| 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", "批量处理" | [Triage Mode](#triage-mode) | | "is this worth a release", "值不值得发版" | [Release Worthiness Analysis](#release-worthiness-analysis) | | "commit", "push", "publish", "release", "close issue", "发布表情" | [Ship / Release Follow-through](#ship--release-follow-through) | | "audit", "项目体检", "项目评分", "给项目打分", "深入分析项目代码", "scorecard", "linus review" | [Project Audit](#project-audit-mode) | | Document, PDF, prose review | Delegate to /write (see [Document Review](#document-review)) |

Before any mode, run [Project Context Extraction](#project-context-extraction), [Feature Intent And Risk Model](#feature-intent-and-risk-model), 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.

Durable Context Preflight

See [references/durable-context.md](references/durable-context.md) for when to read durable context, the read-order budget, and the memory-type mapping.

For /check, private task constraints are decision, preference, and principle entries; review checklists are pattern and learning. Current code, diff, public docs, CI, tests, 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, the diff, and explicit instructions in the current thread. Never cite private memory as a public project requirement.

Feature Intent And Risk Model

This is the primary review spine for completed feature work. Do not reduce /check to a static checklist, and do not bind it to one domain such as Kubernetes, frontend, backend, or packaging. Start from the change's purpose, then derive the checks that matter for this exact change.

Build a compact risk model before detailed findings:

1. Intent: infer the user-visible, operator-visible, or maintainer-visible promise from the request, diff, issue, PR, or plan. If the promise is unclear, state the assumption and review against it.
2. Source of truth: identify where the authoritative data, config, permission, generated artifact, or external state lives. Watch for duplicated sources, stale caches, compatibility shims, and fallback precedence.
3. Control path: trace one representative path from entrypoint -> input or state -> validation -> authority or ownership check -> state change, side effect, or output -> observable behavior.
4. Risk surfaces: classify only the surfaces touched by this change, but include any surface that can realistically be affected indirectly: UI, API, CLI, auth/session, tenant/workspace isolation, secrets, database, filesystem, shell, network, dependency, background worker, cache, config, deploy, packaging, generated artifacts, release, observability, or rollback.
5. Failure modes: name the most plausible ways the feature can fail: wrong source of truth, missing validation, bypassed authority check, partial update, stale or hostile config, broad matcher, unsafe fallback, secret exposure, race, retry duplicate, compatibility break, generated-artifact drift, deploy skew, or user workflow dead end.
6. Review plan: choose the smallest checks that can prove or falsify the risky assumptions: code trace, grep for sibling paths, targeted test, runtime smoke, artifact inspection, CLI invocation, API call, browser path, cluster/service health check, package dry-run, or manual residual-risk note.

Use this model to decide which later gates get emphasis. Security is mandatory whenever the trace crosses a trust boundary, but it is not the only goal: functional correctness, deployability, operability, compatibility, and user workflow completion are equally reviewable outcomes when they are what the feature promises.

Do not stop at "tests passed" when the risk model says the real failure would show up only in runtime state, a generated artifact, an operator action, a browser workflow, a permission boundary, or an external integration. Conversely, do not invent heavyweight checks for surfaces the model does not touch.

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. Work through each plan item as a to-do. Mark each complete as you go.
4. After all items are done, run the project's verification command.
5. Transition automatically into Ship mode 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, 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 unclear, ask. If already on the base branch, ask which commits to review.

Triage Mode

Activate when the user mentions: issue, PR, "review all", triage, "batch", or "批量处理". Skip the diff flow and run this instead.

Action-first rule: Items with a clear disposition (already fixed, duplicate, already released) get acted on immediately without analysis paragraphs. When analyzing screenshots or images, state what you see and the suggested action in one message. Only ask the user when the disposition is genuinely ambiguous.

Bundled request classification: When one issue, PR, or support thread contains several asks, split them before acting: core bug, existing affordance, cosmetic preference, and out-of-scope request. Fix or close only the validated core bug; answer existing affordances with the current path; defer or decline cosmetic and out-of-scope asks instead of treating the whole report as a to-do list.

Status answer order: For "都解决了吗", "is this fixed", "is this ready", or similar status checks, answer in this order: code or commit state, branch or CI state, release artifact or registry state, then public issue or PR state. Do not collapse fixed-on-main, available in pre-release, next stable release, and already shipped.

Flow: First identify the project's issue/PR host from public context. For GitHub projects, pull open items with gh issue list -R --state open --limit 20 and gh pr list -R --state open. For non-GitHub projects, use the platform CLI/API named by the project docs or user request; if none exists, stop and report the missing integration instead of pretending GitHub commands apply. For each item, check if a fix already shipped: git log --oneline ..HEAD | grep -i "". If shipped: close with note. If merged but unreleased: reply "已修复，等下一个版本 release" and close. If no fix: analyze and act. Fix now if possible (fix: closes #N commit); when the target project documents a nightly, beta, or pre-release channel that already contains the fix, reply with that exact upgrade path and close; for valid-but-unreleased items acknowledge and leave open; for invalid items give one-two sentence reason and close.

Before final conclusions in a live queue, refresh the issue/PR list once more and re-read any item that changed during the run. If evidence is incomplete, hold the item instead of closing it on a guess.

PR handling: If the PR direction is accepted but the patch needs changes, prefer pushing the maintainer's fixes to the contributor's PR branch and then merging the PR. Check maintainerCanModify first, then confirm the push remote, target branch, and current HEAD immediately before pushing so you do not overwrite contributor work or push maintainer fixes to the wrong repository. If branch edits are not allowed, ask the contributor to enable maintainer edits or push the needed revision; only fall back to a separate maintainer commit when timing or release safety requires it, and say so in the PR. Close without merging only when the direction is rejected, unsafe, no longer needed, or explicitly not part of the project's scope. Do not silently absorb an accepted PR into main and close it.

Public reply shape: load references/public-reply.md for the full template (mention, single thanks, factual paragraphs, next-release step, editing rules, closure criteria). Ship Mode uses the same template; the file is the single source.

Sign-off line (append to standard sign-off):

triage:           N reviewed, N closed, N deferred

Release Worthiness Analysis

Activate when the user asks "深入分析 X 是不是值得发新版本", "is this worth a new release", "值不值得发版", or similar.

1. Run git log ..HEAD --oneline (find last tag with git tag --sort=-version:refname | head -1).
2. Count and classify commits: feat (new feature), fix (bug fix), chore/docs/refactor (internal).
3. Output:

• Commit summary: N feat, N fix, N chore since last release
• Verdict: release / skip (one line)
• Recommended version bump: patch (fixes only), minor (feat present), major (breaking change)
• Key risk: one sentence on the biggest risk in this batch

1. If verdict is "release", offer to transition into Ship mode.

Ship / Release Follow-through

Activate when the user asks to commit, tag, release, publish, push, reply on an issue/PR, or close an issue after a change is ready.

This mode extends review; it does not skip review. Before any public or irreversible action:

1. Extract release rules from public project context: README, manifests, CI workflows, release notes, package scripts, changelogs, and explicit user instructions in the current thread.
2. Fill the Release Gate 2.0 matrix from references/project-context.md: 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.
3. Verify generated or bundled outputs, version fields, release notes, package contents, and required artifacts are in sync. Prefer dry-run commands when the ecosystem provides them.

Generated deliverables include tracked archives, ignored dist files, appcasts, site/download copy, registry packages, checksums, and release assets. If project docs require them, regenerate, inspect, and stage or upload them explicitly even when they are ignored by git; do not infer readiness from source-only tests.

1. Commit only intended files. Preserve unrelated dirty work, serialize git operations so index locks or overlapping adds do not corrupt the workflow, and re-check HEAD/status before pushing so concurrent agent or maintainer commits are not swept into your ship action.
2. Push, publish, tag, or create a release only when the user has explicitly approved that action. If auth, OTP, CI, registry, or network state blocks the operation, pause and report the exact blocker.
3. For issue/PR follow-through, confirm the item identity with the host's read command before posting.

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: mlhiter
• Source: mlhiter/skills
• License: MIT

Install and usage instructions live in the source repository linked above.