id-review

/foundry:id-review — the infra-delivery two-lens advisory review procedure (general always + security on high-risk, over diff + plan-as-DATA + policy-risk findings)

The infra-delivery step sequence (a documented procedure this skill family forms — no workflow engine or state-machine file ships)'s review step (step 10) — the infra analog of sd-review. A separate-context, infra-specific mistake-catcher pass over an infra change BEFORE the merge pivot. Without a procedure the implementing agent reviews in its own already-biased context, runs a single ad-hoc pass, forgets the security lens on an IAM-policy / connection-string / provider-bump change, misses that a plan REPLACE/deletes a stateful resource, or (worst) treats its own advisory review as if it were an approval to merge. This skill is the disciplined procedure the agent runs instead: it dispatches the two MERGED review lenses — the general code lens always, the security lens when the change is high-risk — feeds them the infra context (the diff + the change's policy-risk findings + the plan's actions_detail, all as plan-as-DATA), collates their categorized findings for the trusted operator, and surfaces the extra-approval expectation for the operator/reviewer to weigh at the merge floor. It defines no reviewer of its own; the pr-reviewer and security-reviewer agents own the review craft.

When to trigger

• An infra atom's implementation is complete and the change is ready to walk to the merge floor, and the operator wants a fresh separate-context, infra-specific review pass the implementing context lacks.
• The operator says "/foundry:id-review", "review this infra change", or the infra-delivery workflow advances to the review step (step 10).

Advisory-never-a-merge-approval — this skill advises the operator; it is NOT a gate / NOT an approver / NOT the merge authority

This skill and both review lenses are advisory mistake-catchers FOR the trusted operator — they are NOT a gate, NOT an approver, and NOT the merge authority. They surface categorized findings (and, on an ackable-risk policy finding, the extra-approval expectation to weigh); they never approve, gate, or merge anything, and this skill does NOT itself flip the workflow's review step. The merge floor (the adopter's branch protection + CI checks + human review — see docs/merge-floor.md) remains the only merge authority. A Block finding is a strong advisory signal for the operator to act on — not an automated veto. id-review only names the extra-approval expectation; the bespoke machinery that once mechanically re-derived and enforced it was retired, so it can neither satisfy, skip, nor waive anything — the trusted operator decides what to do with every finding; this skill enforces nothing.