01
What this skill does
Use this skill after a `code-review` report or equivalent PR feedback. Before assigning dispositions, it reconstructs each problem from its real trigger and entry through guards, control/data/state propagation, persistence and external effects, failure semantics, and terminal impact. It preserves matching Intentional, Disproved, Stale, and Duplicate decisions across generations, blocks fixes when chain or product-authority evidence is incomplete, implements only compatible confirmed actions in the coordinator or through justified delegation, reuses evidence only after checking that it still applies, returns distinct adjacent discoveries as provisional residuals, and allows at most one terminal post-implementation review without automatically consuming its findings. Invocation is explicit-only: a user must invoke `$receiving-code-review`; matching prompts do not activate it automatically.
02
When to use it
- 01Re-verifying every `F#`, `T#`, and uncovered `A#` against a complete end-to-end execution chain.
- 02Formally challenging incorrect, overstated, or stale review claims with evidence.
- 03Fixing confirmed correctness, security, contract, or test issues with proportionate implementation ownership.
- 04Preserving authoritative product intent unless code, contract, or material evidence changes.
- 05Preserving staged work while keeping new fixes unstaged unless publication is requested.
03
How it works
- 01
Read the complete source review or normalize unstructured feedback into stable item IDs.
- 02
Capture lineage and Git state, establish current EC# execution chains, and assess whether delegation adds material value.
- 03
Verify each item against its complete chain and expected-behavior authority, then assign compatible verdict, action, and implementation states.
- 04
Implement confirmed fixes in the coordinator or through justified coding delegation with explicit ownership and a no-staging rule.
- 05
Use at most one implementation-delta post-review for a generation-0 source, link it as terminal, and return remaining findings without automatic receiving.
04
What you get back
- 01A validated `receiving-code-review` disposition ledger and resolution report.
- 02Formal challenge cards for disputed source claims.
- 03Auditable EC# execution-chain and semantic-lineage ledgers.
- 04Scoped unstaged fixes for confirmed review findings, plus verification evidence.
05
Important boundaries
- 01Do not blindly apply review feedback.
- 02Do not edit code until intake, item enumeration, and complete-or-blocked EC# reconstruction are recorded.
- 03Choose delegation by risk and execution benefit; coordinator implementation still requires item ownership and current verification evidence.
- 04Do not stage, commit, or mutate the Git index unless the current request explicitly asks for it.
- 05Do not claim resolution until every source item has a disposition and every implemented item has targeted verification.
- 06Do not silently drop or auto-implement distinct verifier discoveries; return them as provisional residual candidates.
- 07Do not auto-fix blocked chains or unconfirmed product choices, and do not start another receiving cycle from the terminal post-review.
06