Bu sayfa yalnızca İngilizce olarak mevcut.

Code Review

Pathrule3 kural • 1 hafıza kaydı • 1 beceri

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.

Önerilen yol haritası

Pathrule her parçayı eşleşen yola yerleştirir; böylece asistanınız onu yalnızca ait olduğu yerde görür. İçe aktardığınızda kapsam böyle kurulur; isterseniz çalışma alanınızda değiştirebilirsiniz.

/ çalışma alanı kökü

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

Kurallar

Keep pull requests small and single-purpose/rootyüksektavsiyeCap 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/rootyüksekkatı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/.githubortatavsiyeA 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.

Hafıza kayıtları

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.

Beceriler

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.

Neden bu kalıp

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

Hedef kitle: Engineering teams using PR-based GitHub or GitLab workflows with human and AI reviewers.

Asistanınızı şunlardan alıkoyar:

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

Markdown olarak görüntüle

Lisans: Apache-2.0
Sürüm: 1.0.1
Güncellendi: 2026-08-25