SAST skills audit a codebase in fifteen model passes, and the resume rule trusts whatever files already exist

The whole deliverable is a folder of instructions with no manifest and no tags

The repository root holds five entries: .gitignore, LICENSE, README.md, demo.gif, and sast-files/. There is no package manifest, no lockfile, no build script, and no code to compile, and the project language field comes back unknown because there is no source to classify. Everything that makes this work sits inside sast-files as instructions an assistant reads. The installation step is therefore a file copy, not a dependency resolution, which also means there is nothing to pin. The repository publishes no GitHub releases, and no version appears in the README, so the copy you take is whatever sits on the branch head, and a scan run today and a scan run next month are running whatever changed in between. For a security tool that is the part worth thinking about before the first run.

Your project is copied inside the skill bundle, so the workspace root is not your repo

The install instruction is a copy of your project into the toolkit's own folder:

cp -r /path/to/your/project sast-files/

After that you open sast-files as the workspace in your assistant, not your repository. So the directory the assistant treats as the project root is the bundle, your source tree is now a subdirectory of it, and the orchestration file that drives everything ships alongside your code. The output section then says everything is written to a sast/ folder in your project root, which is now ambiguous: the sast/ folder lands next to the copied source inside the bundle unless you move it. Keeping the target inside the bundle has one clear benefit, since the skills and the code under audit travel together and the orchestration file is found automatically, and one clear cost, since a folder meant to hold someone's project also holds the instructions that grade it.

The install note tells you to delete your own CLAUDE.md or AGENTS.md

One warning carries more weight than the rest of the installation section: if the project already has a CLAUDE.md or AGENTS.md file, remove it before running the assessment, because it will conflict with the orchestration file the toolkit provides. Two files at once at the same level is the collision being described. In practice that means the house rules your assistant normally follows, your conventions, your review checklist, your build commands, are gone for the duration of the audit, and the assistant is working from the scanner's instructions instead. It also means the file names are load bearing in two directions. The toolkit ships one entry point for Claude Code and another for Opencode and other IDEs, so which rules win depends on which assistant you opened the workspace in, and if you add a second copy of your own by mistake there is no documented precedence.

Resume is decided by file existence, so a second pass can report stale findings

The usage section says the entry point file orchestrates the whole workflow and will skip any steps whose output files already exist, which is offered as the reason you can re-run safely after fixing issues. The mechanism is a file existence check, not a freshness check. architecture.md from the first run survives, so the architecture mapping is never rebuilt, and each per class results file survives too. If you fix a SQL injection finding and re-run, the SQL injection step is skipped and the old results file is still sitting there for the report step to consolidate. Nothing in the description compares file timestamps, hashes input against output, or clears the sast/ folder. To get a clean second pass you have to delete the specific results files you expect to change, and the document never says so.

One analysis pass, thirteen parallel subagents, one report pass

The workflow has three steps and the class table makes the arithmetic exact. Step one is sast-analysis, which maps the technology stack, architecture, entry points, data flows, and trust boundaries into sast/architecture.md. Step two runs every detection skill at once as subagents, and there are thirteen of them: SQL injection, GraphQL injection, XSS, remote code execution, SSRF, IDOR, XXE, template injection, insecure JWT, missing authentication and function level authorization, path traversal, file upload, and business logic flaws. Each writes sast/*-results.md. Step three is sast-report, which folds those into sast/final-report.md ranked by severity. The README's count matches the table exactly, which is a small sign that the list is maintained as a set rather than appended to casually.

The verification phase is a second model pass, so exploitability is asserted rather than proved

Each detection skill runs in two phases. The first is recon and discovery, finding candidate sections of code. The second is verification, and the stated purpose is to confirm exploitability. No scanner binary, no request replay, and no test execution sits between those two phases, because the toolkit requires no third party tools. The confirmation step is the model reading its own candidate again with a different instruction, and its output lands in a results file described as carrying proof and remediation, while the final report is said to include dynamic test instructions. Read that as a work item for a human rather than a receipt. A finding that survives two passes of the same reader is better filtered than a single pass, and it is still the same reader.

Thirteen classes read code, and nothing here reads your lockfile or your secrets

Every class in the table works from source, so the boundary of the toolkit is the boundary of static reading. There is no skill for vulnerable or abandoned dependencies, and there is nothing in the repository that reads a manifest of third party packages, which is the job software composition analysis does and this is not. There is no skill for hardcoded credentials either, even though missing authentication and function level authorization are both covered, so a leaked key in a config file or in a committed environment file is out of scope. Unsafe deserialization is folded into the remote code execution class rather than given its own row. Business logic is one skill carrying price manipulation, workflow bypass, and race conditions, which is a lot of different reasoning to hand one subagent while thirteen siblings run in parallel.

Editorial conclusion

Take this if you want a second reader over code you cannot review by hand, you are willing to have the whole tree read by a paid model, and you can live with findings that a model produced rather than a parser proved. Do not take it as a compliance artifact, as a dependency check, or as something to run unattended on a schedule. Before the first run, copy the project rather than pointing at your working tree, read what deleting your CLAUDE.md costs you, and decide now where the sast/ folder is going to live so that clearing stale results before a second pass is a habit rather than a surprise.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. utkusen/sast-skills on GitHub