pashov/skills: three Solidity audit skills you install by saying a sentence to your agent

Installation is a sentence, not a package

The README does not ask you to install anything. Under a heading about install, run and update prompts, it gives three blocks of plain text to copy, one per skill, each naming the repository URL and a verb. The middle one reads: install that URL and run the solidity auditor with all different agents possible on the codebase.

Install https://github.com/pashov/skills/ and run fizz on the codebase

A second block gives the same three commands without the install clause, for when the agent already has the repository, and a third block is a single line that updates the skills to the latest version. There is no package manager step, no manifest to add, no version to specify.

That design is a consequence of the delivery format. These are agent skills: markdown instructions plus whatever scripts live beside them, which the agent reads at the moment you ask. The README badges cover five editors, Claude Code, Cursor, Codex, GitHub Copilot and Windsurf, which is a claim that the instruction-following behaviour needed is portable rather than tied to one product's skill loader.

The tree is consistent with that model. There is no plugin manifest, no skills directory and no package metadata at the root. What is there is a `CLAUDE.md`, three skill folders, and the governance files you would expect from a firm with a public reputation to protect: `CONTRIBUTING.md`, `SECURITY.md`, `CODE_OF_CONDUCT.md` and an MIT licence file.

The consequence you should hold onto is that there is nothing to pin. When you paste the install sentence, the agent fetches whatever the default branch holds at that moment. The changelog for the newest release is mostly about changing the auditor's behaviour, which means what you get from that sentence can differ week to week with no version marker telling you it did.

Three skills covering three different stages of an audit

The skills table is three rows long, and the descriptions are specific enough to be worth quoting closely because they show the intended order of work.

The first is a pre-audit scan that produces a threat model, invariants, entry points and git analysis. It is described as a pre-audit scan, which places it before any tool touches the code. Its job is to tell a reader what the contract is supposed to do, which surfaces exist, and which properties should never break. That is the artifact a human auditor writes before reading a line, and having an agent draft it in minutes changes what the rest of the review is worth.

The second is the main audit, described in the table as a Solidity AI security audit that has found hundreds of Critical and High vulnerabilities. Its own folder changelog shows how much it has been reshaped: a fourth major version arrived with loop mode, memory scanning and a report assembled by a shell script, followed by a change keeping mental tools internal and dropping a mandatory marker protocol, then a bump of its own version number to 4.1.

The third is the one with the most concrete output. It generates a full Echidna or Medusa fuzz suite for any Foundry or Hardhat project. That is a bounded, checkable deliverable. Property-based fuzzing either finds something or it does not, and the suite is a file you can read, adjust and run yourself, unlike a prose finding. If you want one skill from this repository, that is the one with the clearest success criterion.

Ordering them together gives a sensible workflow: model the threat surface, review against it, then fuzz the properties the model says should hold. The README presents them as a flat list, but the descriptions imply that sequence.

Two version numbers that live in different systems

The release tags in this repository are dates written without separators: `v05102026`, `v23092026` and `v28062026`, published in October, September and June respectively. There is no semantic version anywhere in the release history.

Two things follow from that. First, the tags are hard to read at a glance, because a six-digit run with no separator can be parsed several ways and nothing in the tag tells you which convention is intended. Second, and more importantly, there is no release that corresponds to the auditor's own version. The changelog for the October release says the auditor's version was bumped to 4.1. So the repository has a four-part-versioned component whose versions appear nowhere in the release tags, and a release stream whose tags are dates. If you wanted to run the version of the auditor that passed somebody else's review six months ago, there is no reference for which one that was.

The quality of the release notes is uneven in a way that makes this worse. The October release has a full changelog listing five pull requests with links and attribution. The June and September releases both have completely empty bodies. So for two of the three releases there is no record of what changed at all, and for the one that does, the changes are a mix of code and instructions.

Two of those five items are edits to how the agent is instructed rather than to anything executable: keeping mental tools internal and dropping a mandatory marker protocol. A third removed a shipped self-test and de-hardcoded eval paths from the fuzz skill. Recording these in a changelog alongside demo GIF updates is honest, but it also tells you that a meaningful part of what these skills are is prompt text, and prompt text changes silently between the moment it worked for the author and the moment you paste the sentence.

What the one-line descriptions do not tell you

The skills table is where the project's marketing lives, and it is three sentences long. Two of them are descriptive of output. The third, on the auditor, makes a quantitative claim: hundreds of Critical and High vulnerabilities found.

There is no link behind that number, no methodology, no time period, no denominator, and no false-positive rate. For a security tool, that is the single most important missing datum. An audit tool's usefulness is bounded by how much of its output you have to throw away, and a tool claiming hundreds of Critical and High findings without saying what fraction were real is asking to be taken on faith precisely where caution is cheapest.

The audit firm behind it is real and named, with a website, and the topics list is coherent and specific, running to entries like smart-contract-audit, solidity-audit, fuzz-testing, defi-security and web3-security. The 5,030-character README also does the unglamorous governance work: a contribution process, a security policy for reporting vulnerabilities, a code of conduct, and an MIT licence.

One line in that governance section does not fit. After the licence and code of conduct, the README invites readers who want to explore strategies for securing their project to reach out for a chat on a personal Telegram handle. That is a lead-generation line sitting between a licence and a Discord badge. It is not a red flag on its own, but it does locate the project in the ecosystem of firms selling audit retainers, which is useful context when weighing an unverified performance claim.

One maintainer, five open issues, a lot of forks

The maintenance signal from the release notes is concentrated. All five pull requests listed for the October release carry the same contributor handle, including the demo GIF update. That is consistent with a small firm keeping its own tooling current rather than with a community project.

Against that, the shape of the repository is bigger. There are 1,231 stars, 230 forks, only 5 open issues, and a last push on 2026-10-05 that is the same timestamp as the newest release. The fork count relative to stars is high for a tool that most people would either adopt fully or not at all, which suggests people are reading it, pulling it into their own agent setup and adapting it rather than installing it once.

The low issue count is the number to interpret carefully. For a project delivered by pasting a sentence, there is no obvious place for a user to file a bug: the failure is a bad finding or a confusing run inside someone else's agent session, not a stack trace from an installed binary. That makes a quiet tracker much less informative here than it would be for a normal library, and it is a good reason to try the skills on a small target before trusting them on a codebase you cannot easily undo work in.

There is also a static assets folder in the tree, which is where the demo GIF updated in that release lives. Documentation of this kind of tool is largely demonstration, and a demo GIF of the auditor working is evidence of plausibility rather than of correctness.

Where a security skills repository owes you more than this one says

Nothing here is wrong, and the pieces that are present are well chosen. But there are four things a security-focused skills repository could reasonably document and does not.

The first is false positives. Every LLM-assisted audit tool produces findings that are wrong, and the honest number is what determines whether you keep or abandon the tool after an afternoon. Not stated anywhere.

The second is scope. The auditor's description says Solidity. The fuzz skill targets Foundry and Hardhat. The pre-audit pass says codebase, which is broader. Whether the three skills compose on one project or need separate invocations per skill is not said, and the install prompts suggest one skill per sentence.

The third is what the tools need to run. Echidna and Medusa are external binaries with their own installation, and the fuzz skill generates suites for them rather than running the fuzzing itself. Whether the skill installs those, assumes them, or needs a specific Foundry toolchain version is not documented on the page.

The fourth is the line between a suggestion and an action. An agent with a pre-audit skill and a write-capable editor will sometimes apply what it finds. Whether these skills are designed to report or to fix, and whether they ask before writing, is the kind of thing a security user needs to know before pointing the thing at a repository with no commits.

None of that makes the repository less useful. It makes it a tool to run and then verify, which is the correct posture for anything that reads smart contract code and tells you it found a Critical issue. Use the pre-audit pass to get oriented, let the fuzzer generate suites you can run yourself, and treat the prose audit as a source of places to look rather than a list of things to fix.

Editorial conclusion

pashov/skills is the right shape for a different job than a linter. A fuzzer that writes an Echidna or Medusa suite for your Foundry or Hardhat project is real work you would otherwise spend a day on, and a pre-audit pass that produces a threat model and a list of invariants is something you want anyway. What the repository does not give you is a way to hold any of it to a standard, because there is no version to pin, no published methodology, and no statement about false positives. Treat all three as a senior engineer's first sweep that tells you where to look, and read every finding before you act on it. Start with the x-ray pass, since it is the one that shapes the other two.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. pashov/skills on GitHub
4. README
5. Releases