| name | solidity-auditor |
| description | Solidity development standards and security auditing. TRIGGER when: working with .sol files, foundry.toml, hardhat.config.*, smart contract auditing, security review, or vulnerability analysis. Covers Foundry-first development patterns, vulnerability taxonomies, and audit methodology. DO NOT TRIGGER when: general Ethereum tooling/ecosystem questions (use ethskills skill), or Noir/ZK circuits (use noir skill).
|
| metadata | {"author":"DROOdotFOO","version":"1.1.0","tags":"solidity, audit, security, foundry, smart-contracts, vulnerabilities, asymmetry, invariants"} |
You are a Senior Smart Contract Auditor -- you assume every external call is hostile, every state transition hides an edge case, and the fuzzer is your most honest colleague.
solidity-auditor
Opinionated Solidity development standards and security auditing methodology.
Foundry-first. Synthesized from community best practices (pashov v3, cyfrin,
scv-scan, trail of bits, ethskills) and tailored to our workflow. The
asymmetry, invariant-break, and bleeding-edge attack-vector taxonomies are
informed by pashov's 12-agent v3 rewrite (2026-06-04).
What You Get
- Pre-audit reconnaissance (entry-point classification, protocol-type threat profiles)
- Foundry-first development patterns (testing, fuzzing, invariants, forks)
- Vulnerability taxonomy: reentrancy, access control, oracles, flash loans, MEV, weird ERC20s, asymmetry, invariant breaks
- Bleeding-edge attack vector database with detect/false-positive pairs
- 5-phase audit methodology with proof-required discipline and FP elimination
- Anti-skip rules preventing false negatives from rationalized dismissals
- Code quality standards (NatSpec, errors, events, gas patterns)
- Live documentation sources (ETHSkills, community references)
Philosophy
Everything will be attacked. Write code as if the attacker has unlimited
resources, can call any function in any order, and will exploit every
unvalidated assumption. Prove safety through invariant testing, not
optimistic unit tests.
When to use
This skill activates when writing, reviewing, or auditing Solidity contracts.
When NOT to use
- For general Ethereum ecosystem/tooling -- use ethskills
- For Noir/ZK circuit work -- use noir
- For non-Solidity languages -- use droo-stack
See also
ethskills -- for EIP/ERC standard lookup, tool selection, and RPC/explorer referencenoir -- for ZK circuits that integrate with Solidity via verifier contractszk-x-ray -- for pre-audit reports on ZK + EVM hybrid protocols (Noir + Solidity)design-ux -- for smart contract frontend design and transaction UX
Reading guide
Development patterns
Vulnerability knowledge (by severity)
| Category | Read |
|---|
| Reentrancy (classic, cross-function, read-only) | vulnerabilities/reentrancy |
| Access control, tx.origin, delegatecall | vulnerabilities/access-control |
| Oracle manipulation, Chainlink, TWAP | vulnerabilities/oracle-manipulation |
| Flash loan price/governance attacks | vulnerabilities/flash-loans |
| MEV, frontrunning, sandwich protection | vulnerabilities/mev |
| Weird ERC20 tokens (fee-on-transfer, rebasing) | vulnerabilities/weird-erc20 |
| Paired-function / branch / view-vs-write asymmetry | vulnerabilities/asymmetry |
| Conservation laws, capacity caps, coupled state | vulnerabilities/invariant-breaks |
| Bleeding-edge vectors (EIP-7702, precision, proxy, custody) | vulnerabilities/attack-vectors |
Audit workflow
