jpmschweitzer/settled-reach
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore(process): all review comments actionable + pushback flow

Browse Source 
Remove severity tiers from PR reviews. Every comment must be addressed
before merge — no "suggestion" category that gets skipped. Teams can
push back on specific comments with a technical rationale; team lead
evaluates and can retract. Bar: "the reviewer was wrong" not "we don't
want to."

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
jpmschweitzer
2026-04-05 10:30:21 +02:00
co-authored by Claude Opus 4.6
parent d2ea687ec3
commit b14c19c65e
1 changed files with 27 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.claude/skills/pr-review/SKILL.md
+27 -9
View File
@@ -151,9 +151,9 @@ reviewer that was spawned (2 for code/visual/audio, 3 for copy):
### <Reviewer Name> (<Focus>): [APPROVE | REQUEST_CHANGES]
[Summary]
| # | File | Severity | Issue |
|---|------|----------|-------|
| 1 | path:line | critical/warning/suggestion | description |
| # | File | Issue |
|---|------|-------|
| 1 | path:line | description |
### <Reviewer Name> (<Focus>): [APPROVE | REQUEST_CHANGES]
...
@@ -187,13 +187,15 @@ Respond with:
2. Summary: 2-3 sentence overall assessment
3. Comments: List of specific issues, each with:
- File path and approximate location
- Severity: critical / warning / suggestion
- Description of the issue
Verdict rules:
- Any **critical** or **warning** issue → REQUEST_CHANGES
- Only **suggestion**-level issues (or none) → APPROVE
If no issues found, say APPROVE with a brief positive summary.
- **Any comment at all → REQUEST_CHANGES.** Every issue is actionable.
There is no "suggestion" tier that gets skipped. If it's worth
mentioning, it's worth fixing before merge.
- If no issues found, say APPROVE with a brief positive summary.
- Do NOT flag something unless you expect it to be addressed. If you
wouldn't fix it yourself, don't mention it.
```
## 6. Posting results to Gitea
@@ -236,8 +238,24 @@ review outcome:
**CHANGES_REQUESTED:**
The sprint-start lifecycle (step 9c) handles dispatching review
comments to agents. After presenting results, remind the lead:
"Review requested changes. Create tasks from the warnings/critical
issues and dispatch to idle agents, then re-push and re-review."
"Review requested changes. Create tasks from each issue and dispatch
to idle agents, then re-push and re-review."
The team may **push back** on specific comments. When a team agent
disagrees with a reviewer comment, the process is:
1. The team agent explains why the comment should be retracted — with
a concrete technical rationale, not just "I disagree."
2. The team lead (you) evaluates the pushback. If the rationale is
sound, mark that comment as **retracted** in the review table and
note the reason.
3. If the team lead is unsure, escalate to the user for a ruling.
4. Retracted comments do NOT need to be fixed. The re-review should
note which comments were retracted and why.
This prevents reviews from becoming dogma while maintaining the rule
that every comment is taken seriously. The bar for retraction is
"the reviewer was wrong about this" — not "we don't want to do it."
**APPROVED:**
The sprint-start lifecycle (step 9c) handles shutdown. After