requesting-code-review

What this skill does

Dispatches a code-reviewer subagent to review a non-trivial diff as a whole — typically the cumulative changes on a feature branch before merge. The reviewer loads the same rubrics SDD's per-task reviewer uses (quality-gate.md / arch-gate.md / security-checklist.md, functional-copied from domain-teams:code-team), but applies them at branch scope rather than per-atomic-task.

Asking the user

When you relay the reviewer's verdict back to the user — Step 4 below ("Surface to user / Print the verdict + findings"), or the push-as-trigger steps 4-6 in §Push-as-trigger — three gates apply: whether to interrupt the user at all, what to bring when you do, and how to phrase it. The reader is a warm-but-interrupted human, not the code-reviewer subagent.

① Whether to ask — tier by reversibility × cost

Every question spends the user's attention; asking on autopilot is confirmation fatigue. Before surfacing a decision, tier it:

• Reversible and inferable from context → just do it, mention it after. Under a standing "just finish it" authorization, do not re-confirm each step.
• Irreversible, outward-facing, or costly → always confirm first. The push-as-trigger actions (git push / gh pr create / gh pr merge) are exactly this case: they publish to teammates / CI / production, so they are never auto-run — confirm before each one.
• Genuine taste, scope, or un-inferable → ask, per gate ②.