📝 Written ● Intermediate Updated 2026-05-13

Run /security-review on your branch

/security-review is the focused sibling of /review. Same input — your branch's pending changes — but a different lens: threat surfaces, secrets, input validation, auth checks. The things general review skims over because it has so many other things to look at.

Security problems in code share a property that makes them especially hard to catch in normal review: they don't look wrong. The unsafe SQL string concatenation parses fine. The unauthenticated endpoint compiles and tests pass. The hardcoded API key works in production until it leaks. The reviewer who knows what to look for finds these; the reviewer who's tired, on PR seven of the morning, and reading for general correctness reads past them.

A general-purpose review prompt averages across all those things. It catches some security issues but not consistently. A focused security review prompts the model to scan with a specific lens — "where does external input enter this code, and is it validated?" — and that single shift changes what gets found. The same agent, the same diff, the same code. Different findings.

The /security-review skill is exactly that prompt. It runs against your branch's pending changes (everything not yet on the base branch), categorizes findings by severity, and tells you which ones to fix before shipping versus which ones are "should we open a ticket" material. Use it before merging anything that touches a public surface, handles secrets, or moves data across trust boundaries.

What you'll learn

What categories of finding /security-review looks for
Running it on your current branch
How severity is assigned and what each tier means
Following up: from finding to fix
Where it ends and a real security audit begins

Step 1: Run it from your feature branch

One command, branch-scoped

Check out the branch you want reviewed. In the chat panel:

/security-review

The agent diffs against the base branch (usually main), reads every changed file plus enough surrounding context to understand the change, and runs through a security-focused checklist. The output is a structured findings list, ordered by severity.

Unlike /review, this one specifically ignores style and most general bug-hunting — it's looking at your changes through one lens, not all lenses.

Step 2: What the skill looks for

Six categories

The review walks (roughly) these categories:

Input handling — Where does external input enter? Is it validated before use? Are SQL queries built with parameters, not concatenation? Are file paths checked for traversal?
Auth and authorization — New endpoints, new operations on existing endpoints. Is auth required where it should be? Are roles/scopes checked?
Secrets — Hardcoded keys, tokens, passwords, internal URLs. Logging that prints credentials. Config files committed with secrets.
Injection surfaces — SQL, shell, template engines. Anywhere user input concatenates into something that gets executed or interpreted.
Crypto and randomness — Use of insecure algorithms (MD5 for security purposes, ECB mode, etc.), Math.random() where CSPRNG is needed.
Data exposure — Endpoints that return more user data than the caller should see. Error messages that leak implementation details.

Step 3: Read severities carefully

Three tiers; only the top two block shipping

Findings are flagged by severity:

High — exploitable, with a plausible attack path. Don't merge until fixed. Examples: SQL injection from user input, unauthenticated endpoint that returns user data, hardcoded production credential.
Medium — concerning but bounded. Fix in this PR if you can; open a ticket if you can't. Examples: weak password requirements, missing rate limiting on a sensitive endpoint, insecure cookie attributes.
Low — defense-in-depth. Worth fixing eventually but not blocking. Examples: a logger that's slightly chatty, a header missing on responses that doesn't currently leak anything.

Don't dismiss "medium" findings just because they aren't "high." Most real incidents start as mediums that compounded with other mediums.

Step 4: Follow up on each finding

Ask for the fix

For each finding, the next prompt is usually some variant of:

"Show me the unsafe code." — the agent quotes the line, shows context.
"Propose a fix." — the agent suggests the change.
"Apply the fix." — the agent makes the edit (under your usual permission mode).
"Add a test that would catch this regression." — the agent writes a test specifically for the case it flagged.

The last one is high-value. A vulnerability fixed without a test will eventually regress. A test attached to the fix prevents that.

Step 5: Triage the false positives

Some findings are wrong; tell the agent why

Static security review always has false positives. The agent sees a SQL query that looks like concatenation but is actually using a parameterized API in a wrapper it doesn't recognize. Or it flags a "missing auth check" on an endpoint that's already protected by middleware higher up.

When you disagree, say so: "This is fine because queryWithBind is parameterized — see db/helpers.ts." The agent will revise its assessment. If the false positive is structural (the codebase has a pattern the agent keeps misreading), add a note to CLAUDE.md: "We use queryWithBind for safe parameterized queries — it's not concatenation."

Step 6: Where this ends and a real audit begins

This is a checklist, not an audit

/security-review catches a useful subset of issues — the kind that show up in code, in this diff, that a careful reader with security training would also catch. What it doesn't do:

Architectural review. "Is this whole authentication scheme sound?" — a question for a real audit, not a diff scan.
Cryptographic protocol review. Issues that come from the math, not the code.
Threat modeling. What attacker types should you care about? What assets matter? /security-review assumes general threats; for high-stakes systems, you need a model.
Dependency analysis. CVE-tracking, SBOM, license issues — those want dedicated tooling (Dependabot, Snyk, etc.).

For systems where security failure is expensive (payments, identity, infrastructure), pair /security-review with periodic human audits. The agent is the floor; humans are the ceiling.

Don't paste the findings into a public ticket if they describe an unpatched issue. "Here's an SQL injection in our checkout flow" is information you want only the people fixing it to see. Triage privately; file the public ticket once it's fixed.