docs(review): cross-link the three review skills, drop a false citation
CI / Check / Test (push) Successful in 1s
CI / Tag release (push) Successful in 1s

Three similarly-named skills cover orthogonal concerns — what to check
(code-review), how to commission a reviewer (requesting), how to behave when
feedback arrives (receiving) — and none of them mentioned the other two. An
agent landing on one had no way to learn the others existed. One line each,
placed at the core-principle line where a reader is already oriented.

stage-gate-review's gate-prep step now says to run grill-me's Full Grill before
bringing an ask: a council's hard questions are cheaper answered in private, and
a gap found by grilling is one you close rather than one the gate reports.

The bug half: receiving-code-review cited "You're absolutely right!" as an
"explicit CLAUDE.md violation". That is obra's upstream convention leaking
through the vendored copy — `grep -ci "absolutely right" ~/dev/CLAUDE.md` is 0,
and so is AGENT.md. The guidance is right, the citation was inventing authority
it did not have; it now says what it actually is, performative agreement rather
than evaluation.

Closes #16
Bump-Type: patch
This commit is contained in:
2026-08-29 11:27:52 +02:00
parent dc97fd4a36
commit e12ac99465
4 changed files with 10 additions and 1 deletions
+2
View File
@@ -14,6 +14,8 @@ Code review is smell detection and principle verification, not style policing. T
**This skill is read-only analysis.** When you find issues, document them with specific file:line references and prioritize by architectural impact. For fixes, load the `refactoring` or `clean-code` skill.
Three similarly-named skills cover orthogonal concerns, and landing on one is no reason to miss the others: this one is **what to check**, `superpowers-requesting-code-review` is **how to commission a reviewer**, and `superpowers-receiving-code-review` is **how to behave when the feedback arrives**.
## When to Use
- Pre-merge review of any pull request
+3
View File
@@ -74,6 +74,9 @@ legal waived"), never silently dropped. Silent omission is the most common way a
3. Mark every discipline: cleared / waived (with reason) / gap.
4. If any gap is on a discipline that gates the whole bet, **do not bring the ask** — close
the gap or bring a feedback-only ask instead.
5. Load `grill-me` (Full Grill) on the ask before bringing it. A council's hard questions are
cheaper to answer in private first, and a gap found by grilling is a gap you close rather
than one the gate reports.
**Chairing a review (you are the council):**
1. Ask for the evidence behind each "cleared", not the claim. Claims are theatre.
@@ -14,6 +14,8 @@ Code review requires technical evaluation, not emotional performance.
**Core principle:** Verify before implementing. Ask before assuming. Technical correctness over social comfort.
This skill starts where `superpowers-requesting-code-review` ends. The substance of what a reviewer should have checked is `code-review`.
## The Response Pattern
```
@@ -30,7 +32,7 @@ WHEN receiving code review feedback:
## Forbidden Responses
**NEVER:**
- "You're absolutely right!" (explicit CLAUDE.md violation)
- "You're absolutely right!" (performative agreement, not evaluation)
- "Great point!" / "Excellent feedback!" (performative)
- "Let me implement that now" (before verification)
@@ -12,6 +12,8 @@ Dispatch a code reviewer subagent to catch issues before they cascade. The revie
**Core principle:** Review early, review often.
This skill is the *commissioning* half. What the reviewer should look for is `code-review`; how to handle what comes back is `superpowers-receiving-code-review`.
## When to Request Review
**Mandatory:**