agentleFS
Sign inStart free
jocarrdjocarrd/crux-agents/skills/security-audit/SKILL.md

security-audit

Skill4 starsChanged 18 days agoMITView on GitHub

Find real vulnerabilities in a repository with Cloudflare's multi-phase audit: map trust boundaries, hunt with isolated agents, disprove every candidate with an independent one and report only what holds. Works on source and sandboxed local checks, never on live systems. Use when asked to audit a codebase or a system for vulnerabilities, for a pen test of the code, whether a service, API or daemon is exploitable, or when a security question needs more than a look at a diff. For the security angle of one open proposal, use review-pr.

192 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use create-stories, story-done and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • lilangMaxSkill

    create-stories

    Break a single epic into implementable story files. Reads the epic, its GDD, governing ADRs, and control manifest. Each story embeds its GDD requirement TR-ID, ADR guidance, acceptance criteria, story type, and test evidence path. Run after /create-epics for each epic.

    Also in 11 projects that use this

  • lilangMaxSkill

    story-done

    End-of-story completion review. Reads the story file, verifies each acceptance criterion against the implementation, checks for GDD/ADR deviations, prompts code review, updates story status to Complete, and surfaces the next ready story from the sprint.

    Also in 11 projects that use this

  • nicepkgSkill

    community-led-growth

    Expert in community-led growth (CLG) - leveraging user communities to drive acquisition, retention, and expansion. Covers building developer communities, user groups, ambassador programs, and turning customers into advocates. Knows the difference between community as a feature vs community as a growth engine, and how to measure community ROI. Use when "community-led, CLG, ambassador program, champion program, user community, developer community, word of mouth, user group, " mentioned.

    Also in 5 projects that use this

  • nicepkgSkill

    ph-community-outreach

    Engage Reddit, Indie Hackers, Hacker News and other communities for Product Hunt launches. Use this skill to identify relevant communities, craft appropriate posts, and drive cross-platform engagement without appearing spammy.

    Also in 5 projects that use this

  • +7 more from lilangMax
  • +1 more from nicepkg

The file

We split this skill into the rules it gives an agent

4 rules. 0 are common, 3 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 173 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Keep the results out of the repository: Use the default output directory outside the target.

    line 24
  2. Distinctive:

    Do not read secrets to audit them.

    line 33
  3. Very specific:

    Only confirmed findings become work: one task per root cause, without the exploit details in a place others can read.

    line 42
  4. Distinctive:

    Run it again after the fixes.

    line 46

“Common” is measured: kept by at least 6 in 10 of the 173 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

security-audit

This is an adapter. The method is Cloudflare's and lives untouched in <this-skill-directory>/upstream/security-audit/; read its METHOD.md, upstream's SKILL.md renamed, and follow it. Here are only the decisions the method leaves to whoever runs it. The reasons are in <this-skill-directory>/references/why.md.

Before starting

  1. Choose the mode. The method separates guidance from a full audit. A focused question stays in guidance mode: no artifacts and no six phases.
  2. Give the cost first. A full audit launches dozens of agents. Present the scope, the profile and a maximum number of agents, and wait for a yes. That number is the budget of the run. Do not start a full audit on a guess.
  3. One target per run. A project with several repositories is several runs, riskiest first. Start with what receives untrusted input and holds data. Use quick or a scoped run for a first pass and say that coverage is partial.
  4. Keep the results out of the repository. Use the default output directory outside the target. A report of open vulnerabilities must not reach a public repository, a change proposal or a chat.

The limits do not bend

  • Source and sandboxed local checks only. No probing of deployed endpoints, even your own and even if the owner would agree. What depends on the live system stays needs_validation, with the owner's safe way to check it.
  • Do not read secrets to audit them. Environment files, credentials and keys on disk or in containers stay closed: a secret that may have leaked is reported from its path and its Git history, without printing its value.
  • Without an OS-enforced sandbox, target code does not run. The lead is recorded as needs_validation. The method's validators are not target code: they only read the run's JSON and can run directly.

After the report

  • Only confirmed findings become work: one task per root cause, without the exploit details in a place others can read.
  • Fix through the project's normal flow, with a regression test. The audit describes the fix and never applies it.
  • Run it again after the fixes. Upstream measured that one run finds roughly half of what repeated runs find, so one clean run does not mean a clean system.

Updating from upstream

upstream/UPSTREAM.md records the commit. To update: fetch that repository, read the diff in full as you would any third-party change, replace upstream/security-audit/ without editing its files, run the two *.test.cjs and record the new commit. A local change belongs in this file, never in upstream/.

Related

  • review-pr — the security angle of one proposal
  • prod-signals — what is happening in production, read-only

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free