---
name: security-review-checklist-runner
description: "Runs a code change through auth, input handling, secrets, data exposure, and payment checks and returns findings ranked by severity, each with a fix. Use when a code change touches login, user input, secrets, stored data, or payments and needs a severity-ranked security pass before merge. Do not use for a full penetration test or a review of infrastructure and network configuration. Related topics: coding, technical."
---

# Security Review Checklist Runner

Runs a code change through auth, input handling, secrets, data exposure, and payment checks and returns findings ranked by severity, each with a fix.

## When to use

Use this skill when a code change touches login, user input, secrets, stored data, or payments and needs a severity-ranked security pass before merge. Do not use it for a full penetration test or a review of infrastructure and network configuration.

## Workflow

1. Ask the user for each input listed below in a single message, skipping any they have already given. Where options are listed, offer them, but accept other answers too.
2. Read the whole change and note every entry point, data store, and external call it adds or alters, so the review has a map.
3. Check each selected area against that map, tracing every untrusted value from where it enters to where it is used.
4. Write each finding with file and line, the realistic attack in one sentence, and a severity from critical to low.
5. Drop findings the framework already prevents and those below the chosen reporting threshold, keeping the list short enough to act on.
6. Add a concrete fix for every remaining finding and list the areas checked that came back clean.

## Inputs

- **The change** (longer free text)
- **What the app does** (longer free text)
- **Stack** (free text, e.g. "Framework and database")
- **Areas to cover** (choose any: Authentication, Authorization, Input validation, Secrets, Data exposure, Payments, Dependencies)
- **Handles payments or personal data** (choose one: Yes, No)
- **Reporting threshold** (choose one: Everything, Medium and above, High and critical only)

## Output

A findings table ordered by severity with file, line, attack, and fix, followed by a short list of areas checked with nothing found.

## Prompt template

Fill the inputs into this template and follow it as the full instruction.

### Security Review Checklist Runner

Walk the change below through a security checklist and rank what you find.

- The change: {{The change}}
- What the app does: {{What the app does}}
- Stack: {{Stack}}
- Areas to cover: {{Areas to cover}}
- Handles payments or personal data: {{Handles payments or personal data}}
- Reporting threshold: {{Reporting threshold}}

Read the whole change first, then take the selected areas one at a time. For authentication and authorization, trace who can reach each new route or function and what stops the wrong person. For input, follow every value from the request to where it is used (query, file path, shell, HTML) and check it is validated or escaped there. For secrets, look for keys in code, logs, client bundles, and error messages. For data exposure, check responses, logs, and analytics for fields the caller should not see. For payments, check that amounts and prices are decided on the server and that webhooks are verified and safe to receive twice.

Give each finding a severity (critical, high, medium, low), the file and line, the realistic attack in one sentence, and a concrete fix. Skip theoretical issues that the stack already prevents. Finish with a short list of areas checked with no findings, so the reader knows what was covered.

## Pitfalls

- Flagging every missing header or hypothetical flaw, which buries the one real injection under noise.
- Checking the new code in isolation and missing that an old route now exposes the new data.
- Trusting a client-side price or role check, when the server is the only place the rule holds.