security-audit: have a coding agent run a six-stage security audit

Who it's for

Use security-audit when you want the current coding agent to work as a security auditor and complete six stages — reconnaissance, hunting, validation, reporting, structured output, independent verification — to find vulnerabilities with real impact that can be exploited. It orchestrates multiple parallel sub-agents; it does not have you click an unnamed scanning product by hand.

Prerequisite: the model used by the coding agent must support tool calls and parallel sub-agents; schema validation in stage five also needs Node.js, for validate-findings.cjs. The material does not list agent products; it lists capability requirements, so do not treat this as exclusive to one piece of software. The official guide page is

https://github.com/cloudflare/security-audit-skill

First try in 3 minutes

The official install command is in the excerpt:

npx skills add https://github.com/cloudflare/security-audit-skill  --skill security-audit

This command writes a skill, so it has side effects. Confirm the current environment is the coding agent you will use for the audit, then run it. After install, first check that this machine has Node.js, because stage five uses it to run validate-findings.cjs.

Do not immediately say "pen-test the code" against an unknown repository. Requests matching trigger phrases such as security audit, find vulnerabilities, and pen-test the code activate automatically. If you do not specify an output directory, it will ask, and the default is to write to ~/security-audit-skill/<repo-name>/run-<N>. That creates files under the home directory.

Low-risk first try: after a successful install, first specify an empty output directory you own, and only ask "if we audited now, where would output be written"; do not authorize it to start changing code or sending packets outward. Success signal: the skill is installed, the agent can restate the default output-path rule, and it has not started the six stages before you confirm the directory. When you truly want a full audit, confirm the target repository and output path first, then use a trigger phrase.

Use cases

Case 1: Start an audit on a code repository you own. Finish the official install, confirm Node.js is available, give a clear output directory, then use one of the trigger phrases from the material. Done means the agent has entered the six stages and left this run's output in the specified directory. Do not let the default path overwrite old results you do not intend to keep. The excerpt does not write internal commands for each stage, so do not invent concrete reconnaissance or hunting scripts.

Case 2: Keep only findings that can be exploited. The material requires: report only issues you can exploit, and every finding needs a concrete attack scenario, not "an attacker could theoretically…". Stage five uses validate-findings.cjs for schema validation. This constrains the output: run validation first, then decide which entries stay. The summary also says adversarial verification should be done by an agent other than the finder, but the excerpt does not write a command to switch agents, so this case is done when "entries have concrete scenarios and pass schema", not when a verifier agent has already been swapped in automatically.

Boundaries

The six stages are reconnaissance, hunting, validation, reporting, structured output, and independent verification. Default output is ~/security-audit-skill/<repo-name>/run-<N>. Without Node.js you cannot finish stage-five validation. Without tool calls and parallel sub-agents you do not meet the runtime requirements written in the material.

Do not report theoretical issues that cannot be exploited. Do not use the pen-test trigger phrase against an unauthorized target. The material does not give a client list, and does not say how to skip validation when Node.js is missing. Beyond these written install, trigger, output-directory, and reporting standards, this guide does not cover the rest.