# 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 clear 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, add a `## Why this is large` section to the PR body so the reviewer knows it is intentional.

---

### [RULE] Review for correctness and security; delegate style to automation  (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 block a merge on a style nit that automation should enforce.
- Verify external input is validated and escaped at trust boundaries to prevent injection, XSS, and path-traversal.
- 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 know what must change before merge.

---

### [RULE] PR descriptions state the what, why, and how to test  (path: /.github)
<!-- scope: project | priority: medium | advisory -->

A PR that lands without context becomes permanent archaeology. Require every PR to carry a useful description.

- The title is a single imperative sentence summarising the change; it should also be a valid Conventional Commit subject if the team uses squash merge.
- The body must explain the motivation (the 'why'), a short description of the approach, and a testing section listing how to verify the change manually or via CI.
- Link the associated issue or ticket so the decision trail is traceable.
- Screenshots or screen recordings are required for any UI change so reviewers do not have to check out the branch.

---

### [MEMORY] Structured feedback labels and turnaround norms  (path: /)

Two things keep review healthy: clear comment intent and fast response time. Both are non-obvious and worth encoding.

- Prefix each comment with its kind: `issue:` (blocking), `suggestion:` (non-blocking improvement), `question:` (needs clarification), `nit:` (trivial preference), or `praise:` (call out good work). This follows Conventional Comments labelling.
- Critique the code path, not the person; propose an alternative rather than just flagging a problem.
- Respond to a review request within one business day. If only minor comments remain, approve with 'LGTM, nits aside' rather than blocking another full round.
- When a PR is too large to review promptly, ask the author to split it rather than letting it sit without feedback.

---

### [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 and unblocked.
---

# 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 is a single imperative sentence; body states the motivation, approach, and how to verify.
- [ ] Issue or ticket is linked.
- [ ] UI changes include a screenshot or recording.

## 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.
- [ ] Authorization 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 request review.