Pathruleこのページは英語でのみご覧いただけます。
Code Review
Pathruleルール3件 • メモリ1件 • スキル1件
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.
推奨されるパスの配置
Pathruleは各要素を対応するパスに配置するため、アシスタントはそれが属する場所でだけ参照します。これはインポート時に適用されるスコープで、ワークスペースで調整できます。
/ ワークスペースのルート
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
ルール
3Keep pull requests small and single-purpose/root高助言Cap 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/root高強制Human 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/.github中助言A 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. |
メモリ
1Structured 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. |
スキル
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 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. |
このパターンを使う理由
Pull requests pile up because they are too large, mix unrelated changes, and trigger slow rounds of vague review feedback.
対象：Engineering teams using PR-based GitHub or GitLab workflows with human and AI reviewers
アシスタントが次のことをしないようにします。
- 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
- ライセンス
- Apache-2.0
- バージョン
- 1.0.1
- 更新日
- 2026-08-25