feat(directives): scavenge superpowers plugin (receiving-code-review, requesting-code-review): 4 directives

conductor/directives/verify_critique_before_implementing/meta.md

@@ -0,0 +1,8 @@
+# verify_critique_before_implementing
+
+## v1
+
+**Why this iteration:** Lifted from the global OpenCode superpowers plugin (obra/superpowers) — `skills/receiving-code-review/SKILL.md`. The directive encodes the "From External Reviewers" block at lines 67-86 (5-point verification before implementing). Counterweight to the LLM default of blind compliance with reviewer suggestions, even when they may be wrong or may conflict with the user's prior decisions.
+**Source:** superpowers plugin `skills/receiving-code-review/SKILL.md:67-86` (From External Reviewers)
+
+**Lifted:** 2026-07-04 (scavenge sweep: superpowers plugin directives)

conductor/directives/verify_critique_before_implementing/v1.md

@@ -0,0 +1,41 @@
+# Verify review feedback is technically correct BEFORE implementing — reviewer suggestions are evaluations, not orders
+
+## The rule
+
+When the agent receives code-review feedback (from the user, a teammate, or an external reviewer), the agent verifies the suggestion against the codebase BEFORE implementing. The agent does not assume the reviewer is correct; the agent does not assume the reviewer is wrong; the agent checks and decides.
+
+Per `skills/receiving-code-review/SKILL.md:67-86` (Source-Specific Handling: From External Reviewers):
+
+> ```
+> BEFORE implementing:
+>   1. Check: Technically correct for THIS codebase?
+>   2. Check: Breaks existing functionality?
+>   3. Check: Reason for current implementation?
+>   4. Check: Works on all platforms/versions?
+>   5. Check: Does reviewer understand full context?
+>
+> IF suggestion seems wrong:
+>   Push back with technical reasoning
+>
+> IF can't easily verify:
+>   Say so: "I can't verify this without [X]. Should I [investigate/ask/proceed]?"
+>
+> IF conflicts with your human partner's prior decisions:
+>   Stop and discuss with your human partner first
+> ```
+
+## Why
+
+Reviewers have less context than the implementer. They see the diff or the discussion; they do not see the broader code, the design constraints, the prior decisions. Their suggestions are hypotheses, not commands. Implementing without verification is "blind compliance," which is its own failure mode — the agent ships a worse code path because the reviewer may have been wrong.
+
+The "principle of least astonishment" applies both ways: the user is surprised when the agent silently implements a wrong suggestion (trust loss) and is surprised when the agent silently overrides a correct one (because the trust was based on the agent's judgment). The transparent path is: verify, then either implement or push back with reasoning.
+
+## What this means in practice
+
+- The agent reads the suggestion, identifies what it claims is wrong/missing/improvable.
+- The agent looks at the actual code at the location in question.
+- The agent considers the 5 checks (correct for this codebase / breaks nothing / reason for current impl / platform coverage / reviewer context).
+- The agent decides: IMPLEMENT (with technical note), PUSH BACK (with technical reasoning), or DEFER (need more info from user).
+- "Defer" is the default for the "can't easily verify" case — the agent names what's needed and asks.
+- The agent NEVER writes performative agreement ("You're absolutely right!") as a substitute for verification (see `no_performative_agreement_in_review`).
+- A reviewer suggestion that conflicts with the user's prior decisions is escalated to the user, not silently implemented or silently overridden.