Code Review
Pathrule2 Rules • 2 Memories • 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, automate style
Fast turnaround keeps reviews unblocking
Give specific, kind, conventional feedback
code-review-review
Rules
2Keep 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 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, write a `## Why this is large` note so the reviewer knows it is intentional. |
Review for correctness and security, automate style/roothighstrictHuman 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 leave a style nit that automation should enforce. |
| 4 | - Verify external input is validated and escaped at trust boundaries to block injection, XSS, and path-traversal classes. |
| 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 can tell what must change before merge. |
Memories
2Fast turnaround keeps reviews unblocking/rootRespond within one business day; optimize response time, not total time.
| 1 | What slows teams down is reviewer response time, not total review duration, so we keep the first response fast. |
| 2 | |
| 3 | - Respond to a review request within one business day; if mid-focus, do it at the next natural break, ideally same day. |
| 4 | - For distributed teams, aim feedback inside the author's working hours so a late reply does not cost a full day across regions. |
| 5 | - If a PR is solid and only minor comments remain, approve with `LGTM, nits aside` instead of blocking another round. |
| 6 | - When a PR is too large to review promptly, ask the author to split it rather than letting it sit. |
Give specific, kind, conventional feedback/rootLabel comments by intent and critique the code, not the author.
| 1 | Structured comments make intent obvious and keep review collegial, following the Conventional Comments labels. |
| 2 | |
| 3 | - Prefix each comment with its kind: `issue:`, `suggestion:`, `question:`, `nit:`, or `praise:` so the author knows what is blocking. |
| 4 | - Be specific: point at the line and the concrete risk, and propose an alternative rather than just flagging a problem. |
| 5 | - Critique the code path, not the person; reserve `nit:` for trivial preference and never let nits block a merge. |
| 6 | - Note positives with `praise:` too, so reviews reinforce good patterns and not only defects. |
Skills
1code-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. |
| 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 and description state the what and the why, and link the issue or ticket. |
| 13 | |
| 14 | ## Correctness |
| 15 | |
| 16 | - [ ] The code does what the description claims, and I have run it or the tests locally. |
| 17 | - [ ] Edge cases and error paths are handled, not just the happy path. |
| 18 | - [ ] No leftover debug logs, commented-out code, or TODOs without a tracking link. |
| 19 | |
| 20 | ## Security |
| 21 | |
| 22 | - [ ] External input is validated and escaped at trust boundaries (injection, XSS, path traversal). |
| 23 | - [ ] No secrets, tokens, or credentials are committed; config comes from env or a secret store. |
| 24 | - [ ] Authz checks gate any new endpoint, mutation, or data access. |
| 25 | |
| 26 | ## Tests and automation |
| 27 | |
| 28 | - [ ] New behavior has tests; changed behavior has updated tests. |
| 29 | - [ ] Linters and formatters pass, so no style nits reach the reviewer. |
| 30 | - [ ] CI is green before I hit 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
- License
- Apache-2.0
- Version
- 1.0.0
- Updated
- 2026-06-09