---
name: security-review
description: "Identifies security vulnerabilities and threat risks in code"
---


## When to use

This skill should be used in the following situations:

- The user requests a code audit, security audit, or vulnerability scan
- The user requests a check for code security or to find security issues
- The user mentions /audit or /security-review
- The user wants to review vulnerabilities in code before deployment
- The user needs penetration testing preparation or a security assessment

## What to do

Your tasks include:

1. Interact with the user to clarify the scan task objectives and output directory
2. Manage the task queue and schedule audit tasks
3. Summarize task results and clean up intermediate output

Understanding the scheduling logic:

1. Retrieve the next file path to audit from the queue
2. Create a subtask: sensitive operation identification
3. For each sensitive operation, create a subtask: context analysis
4. Until the queue is empty
5. Handle wrap-up work

## Analysis Steps

! Strictly follow the state machine below. Do not truncate or skip steps due to a large number of code files, efficiency concerns, or any other reason
! When there are many files to audit, it is even more critical to strictly follow step transitions -- this is key to ensuring an orderly and comprehensive audit process
! Context analysis tasks must be completed by creating subtasks to isolate the analysis process
! Do not read audit target code files directly in the main flow; analyze them through subtasks instead

### Step1 Clarify the scan directory and output directory with the user

Default scan directory: current working directory
Default output directory: `security-review_result/`
Subtask concurrency: default is 3

Preliminary items (do not ask the user; check on your own via commands/tools):
- Check if bash/git-bash is available: `bash --version`
- Detect the operating system type: linux/macos or windows
- Output language: if the user communicates in Chinese, output in Chinese; otherwise, decide on your own
- Load user instructions: path `<current working directory>/SECURITY.md` (skip if it does not exist)

! If the output directory already exists, ask the user whether to rename it as a backup or delete it directly (default action: backup)
! All output files must be placed under the designated output directory
! Do not change the working directory. When temporary test output is needed, create a `<output directory>/tmp` temporary directory for operations
! On Windows, only use PowerShell to execute `.bat` scripts when bash is unavailable; otherwise, always use bash scripts
! If the user instructions file `<current working directory>/SECURITY.md` exists, it must be loaded

### Step2 Initialize the scan queue

To ensure orderly execution of the scan task, you must use the queue script scripts/queue.sh to generate the audit queue

- When the user specifies a scan directory, use init to create the queue
- When the user specifies files to scan, use push to create the queue
- When the user specifies a branch or commit to scan, flexibly use push to create the queue

! Note: when executing scripts, use **absolute paths** and do not **cd to change the working directory**
! If in a Windows environment without bash, use `scripts/queue.bat` as a replacement
! If the queue script execution fails, load the failure handling process `scripts/fail_process.md` to collect information, then **directly end the audit process**
! If `queue.bat` execution fails, you must skip all subsequent steps, enter the failure handling process `scripts/fail_process.md`, and **free-style auditing is not allowed**

Tool principles:

- For directories, grep lists all non-empty file paths and records them in the .queue file. Each pop removes one audit path from the file
- For diffs, it parses git diff information to extract changed files and line number ranges, recording them in the .queue file. Each pop removes one audit path & range from the file; note that when using the script's diff subcommand, you need to provide diff parameters, such as:
  - Diff two branches: branch1 branch2
  - Diff two commits: hash1 hash2
  - View changes in a commit: hash1^ hash1
- For manual additions, you can specify a list of file paths or add them as a colon-separated change range list in the format <file path>:<start line>:<number of lines>

```bash
# Initialize the audit queue
bash "<this SKILL directory>"/scripts/queue.sh init <scandir>

# Directly specify paths to scan (automatically creates the queue; when specifying a directory, it recursively includes all files under the directory; when specifying a file, you can specify a line number range)

bash "<this SKILL directory>"/scripts/queue.sh push <path1> [<path2> <path3>:<start_line>:<line_num> ...]

# Generate a change-block queue by specifying git diff parameters

bash "<this SKILL directory>"/scripts/queue.sh diff [git diff parameters...]

# View remaining audit paths in the queue
bash "<this SKILL directory>"/scripts/queue.sh status

# Pop one audit path (also prompts the report output directory)
bash "<this SKILL directory>"/scripts/queue.sh pop

# Clean up the scan queue (only use when the audit is complete)
bash "<this SKILL directory>"/scripts/queue.sh clean
```

Windows examples:
```powershell
# On Windows, the format for specifying line number ranges is <path>#<start_line>#<line_count>, using # as the separator
& "<this SKILL directory>\scripts\queue.bat" push "<path1>" ["<path2>" "<path3>#<start_line>#<line_num>" ...]
# Other basic subcommand parameters are largely the same
& "<this SKILL directory>\scripts\queue.bat" status

& "<this SKILL directory>\scripts\queue.bat" pop
```

### Step3 Execute the queue script to audit files one by one

Execute the queue script to pop a file path, and pay attention to the script's **report output path** prompt to confirm the report output directory path
All intermediate results, report files, etc. for that file must be output to that **report output path**

! You must audit files one by one through the queue to ensure no audit items are missed
! Skip the following paths that are unrelated to actual code:
  - IDE and development-related paths, such as .vscode/, .idea/, .claude, .costrict, etc.
  - Binary files, such as xx.png, xx.so, etc.
  - Project documentation, such as xxx.md, xx.rst, etc.
  - Other unrelated files you are aware of

### Step4 Create sensitive operation identification subtasks

Create two sensitive operation identification subtasks, corresponding to the following identification methods:

- Sink-type sensitive operation identification task: `<this SKILL directory>/threat-explore/sink_func_reg.md`
- Logic & configuration-type sensitive operation identification task: `<this SKILL directory>/threat-explore/logic_opr_reg.md`

Information to pass to the subtask:

- Instruct the sub-agent to load the identification method `<this SKILL directory>/threat-explore/xxx.md` to identify sensitive operations and output results as required by the method
- Pass the file path to analyze
- Require it to load rules before analysis
- Require it to strictly follow the identification and analysis steps
- Do not output results to a file
- Require it to output sensitive operations that pose a risk
- All risky sensitive operations -- whether Sink-type, business logic-type, or configuration-type -- must be detected; **none may be omitted**
- User instructions related to the task

! You must create subtasks for sensitive operation identification; do not read code files directly in the current flow for identification, as this will break conversation context isolation
! Before creating subtasks, **do not bypass the subtask to pre-read the identification methods** -- that is not your job
! After the last subtask outputs risky sensitive operations, you must immediately proceed to `Step5`; do not skip or temporarily execute other subtasks

### Step5 Create context analysis subtasks

For each sensitive operation identified in `Step4`, create a **context analysis subtask**. Information to pass to the subtask:

- Instruct it to load the task description `<this SKILL directory>/threat-explore/agent.md`
- Necessary description related to the sensitive operation (including file path, line number range, relevant description, code snippets, etc.)
- Intermediate report output path (when creating multiple subtasks, ensure unique paths by adjusting the trailing number in the filename)
- For results confirmed as no-risk/false positives, do not output a report file
- The only permitted output directory is `<output directory>/`; outputting files to other directories is not allowed. If a temporary directory is needed, create it under the output directory
- Pass precautions: 1. Do not read files outside the workspace by default; 2. Do not execute irrelevant commands, such as installing dependencies or deleting code files; 3. Use built-in tools for file reading and writing whenever possible
- User instructions related to the task

! Note: one sensitive operation corresponds to one subtask
! If there are too many sensitive operations, be careful not to create too many concurrent subtasks; limit concurrency
! After `Step4` outputs sensitive operations, `Step5` must immediately follow; skipping is not allowed
! After a subtask completes successfully, return to `Step3`, unless the queue is empty

### Step6 Summary and wrap-up

1. Output an audit summary for this scan task; save the summary to `<output directory>/task_summary.md`
2. Use `bash "<this SKILL directory>"/scripts/merge_reports.sh <output directory>` to merge the audit summary and all reports
3. Clean up the scan queue: `bash "<this SKILL directory>"/scripts/queue.sh clean`
4. Check whether the `<output directory>/full_report.jsonl` report generated in Step 2 is correct; fix any issues automatically without re-invoking the script

! If in a Windows environment without bash, use `scripts/merge_reports.bat` as a replacement

## Special Notes

! If you detect that you are approaching the token limit, you should attempt to compress and summarize the context rather than hastily ending the audit
! If a script execution failure occurs, enter the failure handling process `scripts/fail_process.md`; free-style auditing is not allowed
