Code Review

Pathrule3 Rules • 1 Memory • 1 Skill

A workflow bundle that keeps code review focused on correctness, security, and maintainability instead of style nits. It encodes small-PR discipline, an author self-check before requesting review, structured reviewer feedback, and a fast turnaround norm so changes merge in hours, not days.

Suggested path map

Pathrule places each piece on the matching path, so your assistant only sees it where it belongs. This is the scoping you get on import; you can adjust it in your workspace.

/ workspace root

Keep pull requests small and single-purpose

Review for correctness and security; delegate style to automation

Structured feedback labels and turnaround norms

code-review-review

.github/

PR descriptions state the what, why, and how to test

Rules

Keep pull requests small and single-purpose/roothighadvisoryCap PR scope so reviewers can finish in one sitting.

1	Each PR should do one thing and stay reviewable in a single focused pass.
2
3	- Target under ~400 changed lines of meaningful diff; split larger work into stacked PRs that build on each other.
4	- Never mix a refactor, a feature, and reformatting in the same PR; separate them so each diff has one clear intent.
5	- Exclude generated files, lockfile churn, and bulk renames from logic PRs, or call them out explicitly in the description.
6	- If a change cannot be split, add a `## Why this is large` section to the PR body so the reviewer knows it is intentional.

Review for correctness and security; delegate style to automation/roothighstrictHuman and AI review focuses on logic and risk, not formatting.

1	Reserve reviewer attention for what tools cannot catch: correctness, security, and long-term maintainability.
2
3	- Let formatters and linters (Prettier, ESLint) own style; never block a merge on a style nit that automation should enforce.
4	- Verify external input is validated and escaped at trust boundaries to prevent injection, XSS, and path-traversal.
5	- Confirm error and edge paths are handled and that no secrets, tokens, or credentials are committed.
6	- Use `nit:` for optional polish and `issue:` for blocking concerns so authors know what must change before merge.

PR descriptions state the what, why, and how to test/.githubmediumadvisoryA reviewable PR must have enough context that a reviewer can test and approve without asking the author.

1	A PR that lands without context becomes permanent archaeology. Require every PR to carry a useful description.
2
3	- 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.
4	- 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.
5	- Link the associated issue or ticket so the decision trail is traceable.
6	- Screenshots or screen recordings are required for any UI change so reviewers do not have to check out the branch.

Memories

Structured feedback labels and turnaround norms/rootLabel every review comment by intent and respond within one business day.

1	Two things keep review healthy: clear comment intent and fast response time. Both are non-obvious and worth encoding.
2
3	- 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.
4	- Critique the code path, not the person; propose an alternative rather than just flagging a problem.
5	- 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.
6	- When a PR is too large to review promptly, ask the author to split it rather than letting it sit without feedback.

Skills

code-review-review/rootAuthor self-check to run before requesting review on any PR.

1	---
2	name: code-review-review
3	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.
4	---
5
6	# Code review self-check
7
8	## Scope and description
9
10	- [ ] The PR does one thing; unrelated refactors and reformatting are in separate PRs.
11	- [ ] Diff is roughly under 400 meaningful lines, or a `## Why this is large` note explains why not.
12	- [ ] Title is a single imperative sentence; body states the motivation, approach, and how to verify.
13	- [ ] Issue or ticket is linked.
14	- [ ] UI changes include a screenshot or recording.
15
16	## Correctness
17
18	- [ ] The code does what the description claims, and I have run it or the tests locally.
19	- [ ] Edge cases and error paths are handled, not just the happy path.
20	- [ ] No leftover debug logs, commented-out code, or TODOs without a tracking link.
21
22	## Security
23
24	- [ ] External input is validated and escaped at trust boundaries (injection, XSS, path traversal).
25	- [ ] No secrets, tokens, or credentials are committed; config comes from env or a secret store.
26	- [ ] Authorization checks gate any new endpoint, mutation, or data access.
27
28	## Tests and automation
29
30	- [ ] New behavior has tests; changed behavior has updated tests.
31	- [ ] Linters and formatters pass so no style nits reach the reviewer.
32	- [ ] CI is green before I request review.

Why this pattern

Pull requests pile up because they are too large, mix unrelated changes, and trigger slow rounds of vague review feedback.

Built for Engineering teams using PR-based GitHub or GitLab workflows with human and AI reviewers.

Keeps your assistant from:

Oversized PRs that mix refactors, features, and formatting in one review
Style and lint nits crowding out correctness and security feedback
Reviews stalling for days because turnaround has no agreed norm

View as markdown

License: Apache-2.0
Version: 1.0.0
Updated: 2026-06-09