Stats
Actions
Tags
From engineering
Reviews code diffs, PRs, issue queues, release readiness, commits, pushes, publishing, and project audits. Use when users ask review/看看代码/合并前/看看issue/PR/release/push or to implement an approved plan, with safety gates for dirty and untracked worktrees. Not for exploring ideas, debugging root causes, or prose review.
How this skill is triggered — by the user, by Claude, or both
Slash command
/engineering:checkWhen to use
review, 看看代码, 检查一下, 有没有问题, 是否需要优化, 合并前, 继续优化, 优化代码, 看看issue, 看看PR, release, publish, push, release reaction, GitHub reaction, 发布, 提交, 关闭issue, 发布表情, release表情, close issue, issue close, review my code, check changes, before merge, before release, code review, code-review, audit, project audit, 项目体检, 项目评分, 给项目打分, 深入分析项目代码, 评估项目质量, 代码质量评分, scorecard, linus review, rate this codebase, score this project
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Prefix your first line with 🥷 inline, not as its own paragraph.
Prefix your first line with 🥷 inline, not as its own paragraph.
Note:
/reviewis a built-in Anthropic plugin command for PR review. Waza uses/check(or the aliascode-review) instead. Do not re-trigger/reviewfrom 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.
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.
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 |
| Diff or PR ready, "review", "看看代码", "合并前" | Default review (start at Get the Diff) |
| "look at issues", "review PRs", "triage", "批量处理" | Triage Mode |
| "is this worth a release", "值不值得发版" | Release Worthiness Analysis |
| "commit", "push", "publish", "release", "close issue", "发布表情" | Ship / Release Follow-through |
| "audit", "项目体检", "项目评分", "给项目打分", "深入分析项目代码", "scorecard", "linus review" | Project Audit |
| Document, PDF, prose review | Delegate to /write (see Document Review) |
Before any mode, run Project Context Extraction and (if memory is in scope) Durable Context Preflight.
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:
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.
See rules/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.
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:
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.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 full diff between the current branch and the base branch. If unclear, ask. If already on the base branch, ask which commits to review.
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 <repo> --state open --limit 20 and gh pr list -R <repo> --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 <latest-tag>..HEAD | grep -i "<keyword>". 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
Activate when the user asks "深入分析 X 是不是值得发新版本", "is this worth a new release", "值不值得发版", or similar.
git log <last-tag>..HEAD --oneline (find last tag with git tag --sort=-version:refname | head -1).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:
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.gh issue view or gh pr view; on other hosts, use the CLI/API named by project docs or the current request. Use references/public-reply.md for the maintainer reply template (mention, single thanks, facts, explicit next release or verification step) and its closure criteria.repos/<owner>/<repo>/releases/<id>/reactions with gh api or the available GitHub tool, and re-read reactions to confirm. Positive release reactions are +1, laugh, heart, hooray, rocket, and eyes.Activate this gate when a release candidate was cancelled, a preview or beta had repeated bug-fix churn, or the user asks whether a delayed release is finally safe.
HEAD. Do not limit the review to recent commits or the latest local diff.HEAD, dirty state, origin sync, version fields, generated artifacts, release notes, package contents, CI, and remote distribution state. If any state changes mid-review, refresh the range and rerun the fast gates.End with the concrete shipped state: commit hash, tag, release URL, registry/version result, pushed branch, release asset state, release reaction state, issue/PR state, and any remaining blockers. Omit fields that do not apply.
Activate when the user asks for a project-wide code-quality scorecard: "audit", "项目体检", "代码质量评分", "scorecard", "linus 风格 review". Distinct from Default Review (PR/diff scoped) and Triage (issue batching). Single-pass project-wide quality assessment.
Flow
python3 <waza>/skills/check/scripts/audit_signals.py --root <project> from the target repo. The script emits labelled blocks (=== FILE SIZE HOTSPOTS === ... === DENYLIST IN BUILD ===) each ending with status: PASS|WARN|FAIL|N/A.FILE SIZE HOTSPOTS (typically 3-5; stop sooner if the architecture is already clear).CLAUDE.md / AGENTS.md / README.md to learn the project's own stated conventions before judging it against generic ones../docs/<project>-audit.md then; default is ephemeral.Rubric
| Axis | What it covers |
|---|---|
| Architecture | Module boundaries, coupling, abstraction layers vs flat duplication, single source of truth |
| Code Quality | File size discipline, dedup, readability, comments on non-obvious behavior |
| Engineering | Tests, CI gates, version coordination, install URL pinning, packaging posture |
| Perf and Risk | Hazards, scope creep, distribution risk, privacy posture, third-party blast radius |
Scoring anchors
A WARN that the project has explicitly justified (in its own docs or a comment) is not a finding; cite the justification and skip. Do not mechanically convert WARN to CRIT. A block with status: N/A means the surface does not exist (e.g. no packaging script); treat as silence, not as a positive signal.
Output template (terminal)
Project: <name>
Overall: X.X / 10
Architecture: X / 10 -- one-line summary
Code Quality: X / 10 -- one-line summary
Engineering: X / 10 -- one-line summary
Perf & Risk: X / 10 -- one-line summary
Findings
[CRIT] <file:line> -- <issue>
why: <reason grounded in signal or read>
fix: <concrete action>
[STRUCT] ...
[INCR] ...
Top 3 highest-leverage moves
1. ...
2. ...
3. ...
Stop after the report unless the user asks for follow-up implementation. Audit mode does not modify files in the target repo.
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.
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):
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.
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.
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, fill the CLI Command Surface from references/project-context.md before sign-off.
Check command contract and installed-runtime behavior, not just library tests: help/version, subcommands/flags, exit codes, stdout/stderr, JSON/schema output, TTY/non-interactive paths, env/config precedence, shebang/executable bit, PATH shim, and package-manager install path when applicable.
For mutating CLI commands, also run the Safety Sink Review: dry-run or confirmation path, operation log or rollback story, retry/idempotency, signal/partial-failure handling, and test-mode guards for auth prompts or real system changes. For cleanup, uninstall, prune, reset, or cache-removal commands, add two checks before approval: can a normal user verify each selected item is safe, and is the deleted content locally rebuildable rather than a downloaded dependency or user data? If either answer is no, require narrower matching, explicit user selection, or leave the item visible but non-destructive.
Examples, not exhaustive -- flag any diff that could cause irreversible harm if merged unreviewed.
git status, git diff, file Read, rg, command output). Earlier chat context, prior agent's notes, and your own recall from a hundred turns ago are stale by default; restating "the catalog uses en fallback" or "the file is at line 310" without checking has been the recurring failure mode in long sessions. Cite the verification path inline (per current Read of <file> / per git status this turn) so reviewers know which facts are anchored.stdio: 'inherit' (or any uncaptured pipe) streams its diagnostics to the terminal, not into error.message -- which then contains only the command line. Such a matcher silently matches the command, not the output: it can pass tests, fire on the wrong token, or be dead in production while looking correct. Probe the real error.message (a one-line repro) instead of assuming, and prefer driving behavior off a structured fact the caller already holds (build target, exit code) over re-parsing a string.grep -r "name" . -- no results outside the diff = does not exist.find-like recursion, mass-delete, sandbox/container traversal, ID-prefix wildcards, or fallback regex branches feeding a destructive sink, and was likely AI-generated, must be reviewed line-by-line for three things: matcher breadth in every branch (fallback paths often regress to broad globs even when the primary branch is correct), protected-path coverage (does the existing guard list include this new entry point?), and whether the change bypasses an existing user-confirmation step. Generic plausibility is not safety. When in doubt, ask the contributor to narrow the matcher to an exact constant (exact bundle ID, exact app name, exact path), not a prefix or wildcard; do not approve "this looks fine."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.Before writing any finding into the report, run this gate:
Pre-report self-check (four questions, every finding must pass):
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:
Cannot supply all three? Downgrade to MEDIUM, or drop. "This might break under some condition" is not a HIGH.
After reviewing the diff, check whether it introduces invariants not yet captured in project docs:
.claude/rules/*.mddocs/Treat review reports, scorecards, and diagnostic snapshots as evidence, not as source-of-truth docs. Before approving one:
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.
Load references/persona-catalog.md to determine which specialists activate. Launch all activated specialists in parallel via the environment's agent or sub-agent facility when available, passing the full diff. 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.
Treat each specialist finding as a claim to verify, not a fact to act on. Before routing a finding to Autofix or sign-off, re-read the cited code this turn and confirm it 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 or downgrade what dissolves on direct read, and cite the verification path.
| Class | Definition | Action |
|---|---|---|
safe_auto | Unambiguous, risk-free: typos, missing imports, style inconsistencies | Apply immediately |
gated_auto | Likely correct but changes behavior: null checks, error handling additions | Batch into one user confirmation block |
manual | Requires judgment: architecture, behavior changes, security tradeoffs | Present in sign-off |
advisory | Informational only | Note in sign-off |
Apply all safe_auto fixes first. Batch all gated_auto into one confirmation block. Never ask separately about each one.
"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. Suppress findings below 0.60 confidence.
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.
Run bash scripts/run-tests.sh from this skill directory, or the project's known verification command from the target repository. 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.
| What happened | Rule |
|---|---|
| Posted a public reply to the wrong issue or PR thread | Re-read the target with gh issue view N or gh pr view N and confirm title, author, and current state before acting |
| PR comment sounded like a report | 1-2 sentences, natural, like a colleague. Not structured, not AI-sounding. |
| PR comment used bullet points | Write as short paragraphs, one thought per paragraph; thank the contributor first |
| New file name duplicated a locale, platform, or suffix convention | Check the target directory's existing naming convention before creating or renaming files |
| Deployed without provider runtime or env checks | Follow the project's public deployment docs and compare provider config with local required env and runtime settings |
| Push failed from auth mismatch | Check git remote -v, current branch, and auth identity before the first push in a new project |
For document, PDF, white paper, or prose review, route to /write (Document Review Mode). /check handles code diffs and release artifacts only.
files changed: N (+X -Y)
scope: on target / drift: [what]
review depth: quick / standard / deep
hard stops: N found, N fixed, N deferred
specialists: [security, architecture] or none
new tests: N
doc debt: none / AGENTS.md needs X / rules need Y
verification: [command] -> pass / fail
npx claudepluginhub korenkrita/skills --plugin engineeringGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.