Security Review

Purpose

code-review checks the security of a single change as one dimension among seven. That catches the bug in the diff in front of you — but it never steps back to ask what the whole system is protecting, who the attacker is, or where the trust boundaries are. For a client app with authentication, payments, or sensitive user data, that gap matters.

This skill performs a lightweight threat model: it inventories what is worth protecting and where the boundaries are, then sweeps an OWASP-style checklist across the system's security posture — not line by line, but layer by layer. The output is a prioritized, severity-tiered findings report. Because it can be written in PRD format (plans/security-review-<date>/prd.md), the findings enter the build pipeline directly at design-to-tasks for remediation — no separate idea-to-prd pass is needed; the audit is the PRD.

This is one of the suite's three audit skills — with ui-design-audit (consistency) and performance-review (speed) — sharing one contract: standalone, whole-system, severity-tiered, PRD-emitting. See the lifecycle for how audits feed the pipeline.

It is deliberately lightweight: an asset/boundary inventory and a structured checklist, not a formal STRIDE/DREAD exercise or a penetration test. It surfaces the security work that should become tasks — it does not exploit anything.

When to use this vs. code-review

These two skills overlap on purpose and must not duplicate each other. The split: