Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add commands/omermaksutii/rugproof/audit-livegit clone --depth 1 https://github.com/omermaksutii/RugProofWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/commands/omermaksutii/rugproof/audit-live)<a href="https://agentmods.dev/commands/omermaksutii/rugproof/audit-live"><img src="https://agentmods.dev/badge/commands/omermaksutii/rugproof/audit-live.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00027 | $0.00847 |
| Opus 5 | $0.00014 | $0.00424 |
| Sonnet 5 | $0.00005 | $0.00169 |
| Haiku 4.5 | $0.00003 | $0.00085 |
Grade A, and why
audit-live scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 5d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 91 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/audit-live — audit a deployed contract
$ARGUMENTS typically: 0xABC... --chain berachain --block 12345678
Supported chains: ethereum, berachain, arbitrum, base, optimism, polygon, bsc, linea, zksync, scroll.
Procedure
Step 1 — Pull verified source
Use the block-explorer MCP:
mcp__block-explorer__get_source_code(chain=<chain>, address=<addr>)
mcp__block-explorer__get_abi(chain=<chain>, address=<addr>)
mcp__block-explorer__get_constructor_args(chain=<chain>, address=<addr>)
If not verified, abort and tell the user to either verify the contract or supply a local copy of the source.
Step 2 — Snapshot deployment state
- Owner / admin addresses.
- Total supply, key balances.
- Token addresses the contract holds.
Step 3 — Identify proxy/upgrade situation
Resolve the proxy pattern in one call (reads EIP-1967/1822 slots for you):
mcp__block-explorer__resolve_proxy(chain=<chain>, address=<addr>)
It returns { isProxy, pattern, implementation, admin, beacon }. If isProxy:
- Pull the implementation's source too (
get_source_codeonimplementation). - Check
_authorizeUpgrade/ admin for centralization (see [[centralization-risk]]). - Check storage layout for collisions across the upgrade (see [[storage-layout]]).
- For a beacon, audit the beacon's upgrade authority; for a Diamond (EIP-2535), inventory facets (see [[diamond-eip2535]]).
Step 4 — Run /audit on the source
Run the full /audit flow with the pulled source. Add deployment-specific findings:
- Owner is an EOA, not a multi-sig.
- Proxy admin overlaps with operational owner.
- Token approvals from the contract to other addresses (audit each).
- On-chain balances inconsistent with state vars (smells like accounting bug or external donation).
- Was this contract's bytecode matched against any historical vulnerable bytecode? Check
c4-history/sherlock-history.
Step 5 — Live-state simulation (optional)
If --simulate is passed or critical findings need verification, spawn an anvil fork:
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 5d ago First seen · 91 lines · 27 tokens per session scan A d26dcd95c69f
audit-live is a command published in the GitHub repository omermaksutii/RugProof (9 stars, last pushed 1mo ago), licensed MIT. It adds 27 tokens to every session and 847 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other commands, from other repositories
krait-fuzz
Run an invariant-based fuzzing campaign: Understand → Extract Invariants → Generate Foundry Tests → Run & Fix Iteratively → Report.
krait-poc
Write and run a valid Foundry proof-of-concept that proves (or disproves) a Solidity exploit by asserting the actual harm on a forked chain or against local source.
verify-e2e-flow
Verify that the E2E scripts for the specified chain follow the documented transaction flow.
watch-wallet
Watch Wallet operates online and manages public keys only. It creates unsigned transactions, sends signed transactions, and monitors transaction status.
keygen-wallet
Keygen Wallet operates offline as a cold wallet. It generates keys, creates multisig addresses, and provides the first signature for multisig transactions.
fix-btc-e2e-p2
Fix errors in BTC E2E test (Pattern 2: P2PKH 2-of-3 Multisig).