feat(triage): make minimal-change an explicit PR review check (#5146)

The triage gatekeeper already nudged toward KISS/simpler solutions across
Stage 1c, 2a, and 3, but never explicitly asked whether a diff stays
minimal — leaving unrelated changes, drive-by refactors, and scope creep
to slip through as a soft, easily-skipped signal.

Make it explicit without adding a hard gate:
- Stage 1c: add a dedicated 'Minimal change' checkpoint and extend the
  closing nudge to cover changes beyond the minimal set.
- Stage 1 comment template (EN + ZH): surface unrelated changes / drive-by
  refactors to the contributor and suggest splitting them out.
- Stage 3 reflect: add a checklist item on whether every change is needed.

Keeps the existing 'genuine question, not a blocker' tone.
This commit is contained in:
易良 2026-06-15 17:28:01 +08:00 committed by GitHub
parent a629dd0ab6
commit d219cfd2db
No known key found for this signature in database
GPG key ID: B5690EEEBB952194

View file

@ -83,8 +83,9 @@ curl -s https://raw.githubusercontent.com/anthropics/claude-code/main/CHANGELOG.
- If we cut 80% of the scope, would the remaining 20% already solve the problem?
- Could we achieve the same goal by modifying something that already exists, instead of adding something new?
- Can the complexity live outside the codebase (user config, external tool) instead of inside it?
- **Minimal change:** is every edit in the diff needed for the stated goal, or does it carry unrelated changes, drive-by refactors, formatting churn, or scope creep that should be split into a separate PR? A focused PR that does one thing is easier to review, revert, and reason about.
If you spot a materially simpler path, raise it — not as a blocker, but as a genuine question the contributor should think about before the code review.
If you spot a materially simpler path, or changes that go beyond the minimal set needed for the stated goal, raise it — not as a blocker, but as a genuine question the contributor should think about before the code review.
Implementation-level concerns (over-abstraction, code duplication, "10 lines vs 10 files") belong in Stage 2a code review — you need to see the code for those.
@ -99,7 +100,7 @@ Template looks good ✓
On direction: <state your honest assessment aligned and why, or concerns and why>. CHANGELOG <reference if found, or "no direct reference but the area is relevant">.
On approach: <state your honest assessment the scope feels right / feels like it could be much simpler / here's what I'd consider cutting>. <If you see a simpler path, name it: "Have you considered just X? It might cover most of the use case with a fraction of the complexity.">
On approach: <state your honest assessment the scope feels right / feels like it could be much simpler / here's what I'd consider cutting>. <If you see a simpler path, name it: "Have you considered just X? It might cover most of the use case with a fraction of the complexity."> <If the diff carries unrelated changes or drive-by refactors, name them and suggest splitting them out.>
<If passing:> Moving on to code review. 🔍
<If concerns:> Flagging these for discussion before diving deeper.
@ -113,7 +114,7 @@ On approach: <state your honest assessment — the scope feels right / feels lik
方向:<直接说判断对齐的原因/担心的原因>
方案:<范围合理 / 感觉可以大幅简化 / 建议砍掉的部分><如果看到更简路径点名有没有考虑过直接 X可能用很小的复杂度覆盖大部分场景>
方案:<范围合理 / 感觉可以大幅简化 / 建议砍掉的部分><如果看到更简路径点名有没有考虑过直接 X可能用很小的复杂度覆盖大部分场景><如果 diff 夹带了无关改动或顺手重构点名并建议拆成单独 PR>
<如果通过> 进入代码审查 🔍
<如果有顾虑> 先提出来讨论,再深入看代码。
@ -217,6 +218,7 @@ Step back and look at the whole picture — the motivation, the implementation,
- Does the PR's approach match or exceed my independent proposal? Or did I find a simpler path it missed?
- Does this solve something users actually care about?
- Is the code straightforward, or does it feel like it's trying too hard?
- Is every change in the diff necessary, or did unrelated edits / drive-by refactors bloat it beyond the minimal change the goal needs?
- After seeing it run, do the results match what the PR promised?
- If I had to maintain this in six months, would I curse the author or thank them?
- Am I approving this because it's genuinely good, or because I ran out of reasons to say no?