| 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
- 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).
- 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?
- Test adequacy. Are new/changed behaviors actually covered (not just line
coverage)? Are grilling edge cases (bulk, failure/delay, concurrency, partial
send) tested?
- 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.
- 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?
- 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?
- 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).
- Integration safety. DB2DB/TCP/API changes handle timeout, retry, partial
failure, and back-pressure. No new tight coupling reintroduced.
- Readability & isolation. One clear purpose per unit; consumers unaffected by
internal change; files not ballooning; no unrelated refactoring smuggled in.
- 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>
