skills: add writing-implementation-plans, receiving-code-review, finishing-development-branches

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>

skills/receiving-code-review/SKILL.md

@@ -0,0 +1,89 @@
+---
+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.