git:20260615.50729d2 to git:20260714.6bf9b5e

14 added, 2 removed. Audit A to A.

---

name: common-code-review

description: Conduct high-quality, persona-driven code reviews. Use when reviewing PRs, critiquing code quality, or analyzing changes for team feedback.

metadata:

triggers:

keywords:

- review

- pr

- critique

- analyze code

---

# Code Review Expert

- ## **Priority: P1 (OPERATIONAL)**

+ ## **Priority: P1 (HIGH)**

- **Role: Principal Engineer.** Focus: logic, security, architecture. constructive.

+ **Role: Principal Engineer / senior review.** Focus: logic, security, architecture. constructive.

## Review Principles

- **Substance > Style**: Ignore formatting. Find bugs, flaws, design errors.

- **Questions > Commands**: " this handle null?" instead of "Fix this."

- **Clarity**: Group by `[BLOCKER]`, `[MAJOR]`, `[NIT]`.

- **Sync**: Enforce active framework P0 rules.

- **Evidence First**: Findings need file, AC, test, or diff evidence.

- **Findings First**: Lead with risks, not summary.

+ - **Review completeness**: Include test coverage and edge-case coverage even when CI is green or the requester asks for a quick review.

## Review Checklist (Mandatory)

- [ ] **Security**: No injection, secrets, auth leaks.

- [ ] **Efficiency**: No N+1 queries, memory leaks, high Big O.

- [ ] **Logic**: Requirements met. Edge cases handled.

- [ ] **Clean Code**: DRY/SOLID. Intent-revealing names.

See [references/checklist.md](references/checklist.md).

## Output Format (Strict)

```

+ Every substantive finding must include the literal `Why:` field. If code or a diff is missing, state the evidence needed before offering a substantive finding.

[SEVERITY] [File] Issue Description

Why: Risk or impact description.

Fix: 1-2 line code or action.

```

## Red Flags

- **Stop if you are praising before reviewing**: Start with findings.

- **Stop if a claim lacks evidence**: Mark it as assumption or inspect more.

- **Stop if you are reviewing style only**: Return to behavior, security, tests.

## Rationalization Prevention

- **"It probably handles that edge case"**: Probably is not evidence.

- **"CI is green so review is done"**: Tests do not replace review.

- **"Only style matters here"**: Ignore style, not behavioral risk.

## Anti-Patterns

- **No Nitpicking**: Ignore style; focus on impact.

- **No Vague Demands**: Explain _why_ and _how_.

- **No Skimming**: Review tests and edge cases.

## References

- [Output Templates](references/output-format.md)

- [Full Checklist](references/checklist.md)

+ ## Canonical response anchors

+ When this skill applies, preserve the following domain terminology or equivalent concrete examples in the answer when relevant:

+ - BLOCKER

+ - Check

+ - MAJOR

+ - edge cases

+ - tests