菜单
Use when reviewing a pull request or diff, giving PR feedback, validating an implementation against a Jira ticket or spec, after completing a feature or task, before merging to main, or whenever you need a fresh set of eyes on changes before they ship
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when creating, editing, reviewing, or rendering software architecture or flow diagrams — C4 diagrams (system context, container, component, deployment, dynamic), sequence diagrams, request-flow visuals, or any Mermaid authoring where the rendered output must be readable. Also use when a Mermaid diagram renders with overlapping labels, parse errors, or a single-column layout, or when the user asks to "diagram the architecture", "draw the request flow", "map the sequences", or wants LucidChart-quality output from Mermaid.
Use when about to create a feature, build a component, add functionality, modify behavior, or start any new work — or when the user asks how should we, what approach, which way, explore options, design X, or spec this out. Triggers before any code, scaffold, or implementation skill runs.
Use when one request spans multiple domains (e.g. code + tests + docs + security + diagrams), has independent workstreams that could run concurrently, or is too large for a single agent in one pass — symptoms include "do all of X, Y, and Z", a multi-part review, or a task that would obviously thrash one agent's context
Use when defining product requirements, writing or updating a PRD, spec'ing out a feature, or deciding what to build — or when the user says write requirements, create a PRD, define the product, what should we build, or hands over stakeholder/engineering feedback to fold into an existing PRD. Especially for non-technical users translating a conversation into structured requirements.
Use when you want brutal, worst-case review of code resilience -- failure modes, race conditions, blast radius, and edge cases optimistic reviewers miss.
Use when reviewing code or a PR for high-confidence, real-exploitation security vulnerabilities (>80% confidence threshold, low false positives).
| name | code-review |
| description | Use when reviewing a pull request or diff, giving PR feedback, validating an implementation against a Jira ticket or spec, after completing a feature or task, before merging to main, or whenever you need a fresh set of eyes on changes before they ship |
Type: flexible (pattern). Adapt the framework to the change; do not skip the adversarial verification.
A review confirms the change is a net improvement to code health AND does what the requirements demand. Net positive over perfection — do not block on imperfections when the change improves the codebase, but never wave through unmet requirements or false-green tests.
Core principle: do not trust the implementer's report. Read the changed code line by line against the requirements.
Mandatory:
Optional but valuable:
Never skip a review because "it's simple" — the simple-looking diff is where the missing edge case hides.
Review only what changed. Establish the file set and diff up front and stay inside it:
gh pr diff --name-only # files in this PR — the review boundary
gh pr diff # the diff to review
# local branch, no PR:
git diff --name-only origin/HEAD...
git diff --merge-base origin/HEAD
Do not review merged worktree code, unrelated files, or the whole repo. If a finding sits outside gh pr diff --name-only, it is out of scope — note it separately, do not review it.
Optionally run scripts/diff-analysis.py --staged (large files, new deps, test-vs-impl ratio, secret patterns) and scripts/pr-context.sh <pr> to orient.
Build the right thing before judging how well it is built.
scripts/extract-ticket-ids.sh <pr> pulls Jira IDs from the PR title, body, and branch.Apply references/REVIEW_CHECKLIST.md in priority order: Architecture, Correctness, Security (non-negotiable), Maintainability, Testing, Performance, Dependencies. The full framework and report structure live in references/pragmatic-code-review.md. Prefix optional polish with "Nit:".
A passing suite proves nothing if it never exercises the real path. For the tests in the diff, confirm they drive production code, not fakes, mocks, or pre-seeded state. The proof: a test that would still pass if the implementation were reverted or mutated is not evidence — call it out by name. This is the dominant ship-breaker; do not skip it.
| Tier | Meaning | Action |
|---|---|---|
| Critical | Bug, security hole, data loss, broken/missing required behavior, false-green test | Fix before merge |
| Important | Architecture problem, poor error handling, test gap, missing edge case | Fix before proceeding |
| Minor / Nit | Style, naming, optional optimization, docs | Note for later |
Categorize by actual severity. Not everything is Critical; do not bury a Critical as Minor.
To preserve your context or get an independent pass, dispatch a Task subagent with the fill-in template at references/reviewer-prompt.md. Paste the FULL requirement/spec/ticket text and the base/head SHAs into the prompt — never tell the subagent to "read the plan" and never pass your session history. The template carries the adversarial stance, the scope pin, and the fixed report format. See references/requesting-code-review/ for the dispatch discipline and SHA setup.
### Strengths
- [specific, file:line]
### Findings
#### Critical
- [file:line] — what is wrong, why it matters, how to fix
#### Important
- [file:line] — what is wrong, why it matters, how to fix
#### Minor
- [file:line] — what is wrong
### Requirements coverage
- [criterion] → [file:line, or MISSING]
### Assessment
Ready to merge? Yes / No / With fixes — reasoning in 1-2 technical sentences
references/feedback-templates.md has reusable phrasings for blocking issues, suggestions, questions, and ticket-alignment notes.
Verdict:
✅ "Ready to merge: With fixes. Two Critical (auth check missing on PATCH /users:42; test at users_test:88 passes against a stubbed repo)."
❌ "Looks good!" — no evidence, no requirement check
Severity:
✅ Critical: SQL built by string concat (db.go:31) — injection vector. Important: no pagination (api.go:55).
❌ Everything marked Critical, or the injection filed as Minor.
Requirements:
✅ "AC-3 (rate limiting) → MISSING. No limiter in the diff."
❌ Reviewing only style and never checking the ticket.
When you are on the receiving end of review, do not perform agreement — verify before implementing, push back with technical reasoning when a suggestion is wrong or breaks existing behavior, and fix Critical first, Important next, Minor as noted. See REQUIRED SUB-SKILL constellation:receiving-code-review.
references/requesting-code-review/ — how to dispatch the reviewer with constructed context and git SHAs.references/pragmatic-code-review.md.