strict-code-review

name	strict-code-review
description	Use as a mandatory gate before any renovation change is considered done or merged — rigorous review focused on harness regressions, legacy parity, security, and readability. Cross-cutting; invoke on every change. Composes with requesting-code-review / code-review agent.

Strict Code Review

The last gate before a change is done. Be demanding: a renovation touches production-critical paths (message send, approval, integrations), so review is strict, not a rubber stamp. Report only high-confidence issues, but do not wave through real ones.

When to use

• On every change produced by frontend-code-implementation, backend-slice-implementation, ux-modernization, strangler-backend, or ai-augmentation, after test-authoring is green.
• Also on behavior-harness additions and fixture changes before a seam is marked green — the harness is the safety foundation and must itself be reviewed.
• This is a gate: no merge without a pass. Record the result in plan.md's changes entry (review: passed, harness_regression: passed).

Composes with existing skills

If requesting-code-review / a code-review agent is available, use it to run the review. This skill defines the renovation-specific bar it must clear.

Review checklist

1. Harness regression. Does the full characterization suite still pass? If a pinned expectation changed, was the behavior-change protocol followed — requirement-linked, old→new behavior documented, and user-approved? Block if a fixture was edited merely to make a drifting test pass (laundered drift).
2. Legacy parity. For strangler cut-overs: does the new path match legacy output (golden master) for the covered cases? Are rollback and shadow paths intact?
3. Test adequacy. Are new/changed behaviors actually covered (not just line coverage)? Are grilling edge cases (bulk, failure/delay, concurrency, partial send) tested?
4. Optional Figma/design baseline evidence. For UX changes that requested Figma review or claim a Figma baseline, did figma-design-review record the Figma URL/frame ID, open comment status, approver, approval time, and implementation handoff notes? Do not block merely because a UX change did not use Figma.
5. UX action evidence. For UX changes, did web-action-testing run against the real UI/prototype with screenshots/traces? Are Blocker/Major findings closed or explicitly accepted?
6. Azure backend evidence. For backend changes, did azure-backend-architecture record Azure service choices, Well-Architected tradeoffs, security/network/identity constraints, observability, rollback, and Azure tooling gaps?
7. Security. Input validation on new endpoints/UI, authz on approval-affecting actions, secrets not hardcoded, safe handling of recipient PII, AI outputs not trusted blindly (no unchecked action execution).
8. Integration safety. DB2DB/TCP/API changes handle timeout, retry, partial failure, and back-pressure. No new tight coupling reintroduced.
9. Readability & isolation. One clear purpose per unit; consumers unaffected by internal change; files not ballooning; no unrelated refactoring smuggled in.
10. Scope. Change stays within the approved goal level (30/60/100); no gold-plating.

Outcome

• Block on any failing applicable item in 1-10, except advisory readability/style observations that do not affect correctness, security, or isolation. For item 4, block only when Figma review was requested or a Figma baseline is claimed but evidence is missing or open. Items 6 and 8 apply to backend/integration changes; item 7 applies to every change that handles input, identity, authorization, secrets, PII, or AI action output.
• Record findings; require fixes; re-review until clean.

Transition

On pass → the change is done; return control to the phase skill / orchestrator to update plan.md.

Output template and helper script

• Korean template: OUTPUT_TEMPLATE.md
• Scaffold script: scripts/create-review-evidence.sh <repo-root> <target-name>