# Pathrule Pattern: Code Review (1.0.0)
# ::pathrule:package:code-review

### [RULE] Keep pull requests small and single-purpose  (path: /)
<!-- scope: project | priority: high | advisory -->

Each PR should do one thing and stay reviewable in a single focused pass.

- Target under ~400 changed lines of meaningful diff; split larger work into stacked PRs that build on each other.
- Never mix a refactor, a feature, and reformatting in the same PR — separate them so each diff has one intent.
- Exclude generated files, lockfile churn, and bulk renames from logic PRs, or call them out explicitly in the description.
- If a change cannot be split, write a `## Why this is large` note so the reviewer knows it is intentional.

---

### [RULE] Review for correctness and security, automate style  (path: /)
<!-- scope: project | priority: high | strict -->

Reserve reviewer attention for what tools cannot catch: correctness, security, and long-term maintainability.

- Let formatters and linters (`prettier`, `eslint`) own style; never leave a style nit that automation should enforce.
- Verify external input is validated and escaped at trust boundaries to block injection, XSS, and path-traversal classes.
- Confirm error and edge paths are handled and that no secrets, tokens, or credentials are committed.
- Use `nit:` for optional polish and `issue:` for blocking concerns so authors can tell what must change before merge.

---

### [MEMORY] Fast turnaround keeps reviews unblocking  (path: /)

What slows teams down is reviewer response time, not total review duration, so we keep the first response fast.

- Respond to a review request within one business day; if mid-focus, do it at the next natural break, ideally same day.
- For distributed teams, aim feedback inside the author's working hours so a late reply does not cost a full day across regions.
- If a PR is solid and only minor comments remain, approve with `LGTM, nits aside` instead of blocking another round.
- When a PR is too large to review promptly, ask the author to split it rather than letting it sit.

---

### [MEMORY] Give specific, kind, conventional feedback  (path: /)

Structured comments make intent obvious and keep review collegial, following the Conventional Comments labels.

- Prefix each comment with its kind: `issue:`, `suggestion:`, `question:`, `nit:`, or `praise:` so the author knows what is blocking.
- Be specific: point at the line and the concrete risk, and propose an alternative rather than just flagging a problem.
- Critique the code path, not the person; reserve `nit:` for trivial preference and never let nits block a merge.
- Note positives with `praise:` too, so reviews reinforce good patterns and not only defects.

---

### [SKILL] code-review-review  (path: /)

---
name: code-review-review
description: Author self-review checklist to run before requesting review on a pull request. Confirms scope, description, correctness, security, and tests so the first reviewer pass is fast.
---

# Code review self-check

## Scope and description

- [ ] The PR does one thing; unrelated refactors and reformatting are in separate PRs.
- [ ] Diff is roughly under 400 meaningful lines, or a `## Why this is large` note explains why not.
- [ ] Title and description state the what and the why, and link the issue or ticket.

## Correctness

- [ ] The code does what the description claims, and I have run it or the tests locally.
- [ ] Edge cases and error paths are handled, not just the happy path.
- [ ] No leftover debug logs, commented-out code, or TODOs without a tracking link.

## Security

- [ ] External input is validated and escaped at trust boundaries (injection, XSS, path traversal).
- [ ] No secrets, tokens, or credentials are committed; config comes from env or a secret store.
- [ ] Authz checks gate any new endpoint, mutation, or data access.

## Tests and automation

- [ ] New behavior has tests; changed behavior has updated tests.
- [ ] Linters and formatters pass, so no style nits reach the reviewer.
- [ ] CI is green before I hit request review.