diff --git a/.claude/skills/pr-review/SKILL.md b/.claude/skills/pr-review/SKILL.md
index fc852dbbe..5b9afd59f 100644
--- a/.claude/skills/pr-review/SKILL.md
+++ b/.claude/skills/pr-review/SKILL.md
@@ -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