MalinandClaude Sonnet 5
c7ce105e00
Evaluated obra/superpowers and JuliusBrussee/caveman for gaps in the existing library. These three fill real ones (plan-to-delegate handoff, evidence-based review triage, completion vs. integration authority); adapted for this fleet's Gitea/RLS/multi-delegate conventions. Everything else in both repos duplicated existing skills or didn't fit (see README Provenance note on caveman). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
90 lines
3.6 KiB
Markdown
90 lines
3.6 KiB
Markdown
---
|
||
name: receiving-code-review
|
||
description: Use when acting on code-review findings from a human or delegate, especially when feedback is ambiguous, technically questionable, or may conflict with the specification or existing behavior.
|
||
license: MIT
|
||
source: https://github.com/obra/superpowers/blob/main/skills/receiving-code-review/SKILL.md
|
||
---
|
||
|
||
# Receiving Code Review
|
||
|
||
Review feedback is a claim to investigate, not a patch queue to apply blindly.
|
||
The reviewer may have missed codebase context; the implementer may be biased
|
||
toward defending their own work. Resolve both risks with evidence.
|
||
|
||
## Triage the complete review first
|
||
|
||
For every finding, record:
|
||
|
||
- exact file/line and the claimed failure;
|
||
- severity and whether it blocks the stated requirements;
|
||
- the reviewer’s proposed fix, if any;
|
||
- whether the finding is clear, verified, disputed, or needs a decision.
|
||
|
||
Read all findings before editing. Items can depend on each other, and fixing a
|
||
clear symptom before understanding a related architectural concern can create
|
||
rework.
|
||
|
||
## Verify against this codebase
|
||
|
||
For each material finding:
|
||
|
||
1. Restate the falsifiable claim: what input or state should produce what bad
|
||
result?
|
||
2. Inspect the cited code plus its callers, tests, compatibility constraints,
|
||
and relevant specification.
|
||
3. Reproduce the problem or add the cheapest check that distinguishes a real
|
||
defect from a false positive.
|
||
4. Decide whether the proposed fix addresses the root cause without breaking
|
||
existing behavior, tenant isolation, platform support, or scope.
|
||
|
||
For multi-tenant changes, explicitly test a cross-tenant negative case; a
|
||
query that returns the expected row for one tenant does not prove RLS safety.
|
||
For WordPress or infrastructure changes, verify the actual runtime convention
|
||
instead of substituting a generic framework preference.
|
||
|
||
If a finding cannot be verified with available access or artifacts, say
|
||
exactly what evidence is missing. Do not silently convert uncertainty into an
|
||
implementation decision.
|
||
|
||
## Resolve conflicts before editing
|
||
|
||
- If the finding is unclear, ask one concrete question and do not guess at the
|
||
requested behavior.
|
||
- If it conflicts with the approved spec or a prior user decision, present the
|
||
conflicting texts and ask which governs.
|
||
- If it requests unused “professional” machinery, search for actual callers
|
||
and requirements first; reject scope growth that has no consumer.
|
||
- If it is technically wrong, push back with code, tests, or runtime evidence.
|
||
Do not comply merely because the reviewer sounds confident.
|
||
- If it is correct, fix it without performative agreement. State the verified
|
||
problem and the change.
|
||
|
||
## Implement and close findings one at a time
|
||
|
||
Order work by security/data-loss defects, other blocking correctness defects,
|
||
then non-blocking improvements. For each accepted finding:
|
||
|
||
1. Create or identify a check that fails for the reported problem.
|
||
2. Apply the smallest in-scope fix.
|
||
3. Re-run the targeted check and relevant regression tests.
|
||
4. Record the evidence and mark only that finding resolved.
|
||
|
||
Do not let the implementer’s self-review close the loop. A fresh reviewer (or
|
||
the lead model) must inspect the fix diff, and `verification-before-completion`
|
||
still applies before reporting the review resolved.
|
||
|
||
## Response format
|
||
|
||
Keep the response technical:
|
||
|
||
```text
|
||
Finding: <location and claim>
|
||
Verdict: accepted | rejected | needs decision | unverified
|
||
Evidence: <test, code path, or missing access>
|
||
Action: <fix made, reason no change was made, or exact question>
|
||
Verification: <command and result, if changed>
|
||
```
|
||
|
||
Avoid gratitude, defensiveness, or automatic agreement. The useful output is
|
||
a traceable decision backed by evidence.
|