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/exploit-chaingit clone --depth 1 https://github.com/omermaksutii/RugProofWhat 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 | $0.00022 | $0.00647 |
| Opus 5 | $0.00011 | $0.00324 |
| Sonnet 5 | $0.00004 | $0.00129 |
| Haiku 4.5 | $0.00002 | $0.00065 |
Grade A, and why
exploit-chain 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 2d 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 — 72 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/exploit-chain — combine findings into a chain
Some findings are amplifiers, not standalone exploits. This command chains them.
Procedure
Step 1 — Pull all findings
Read each finding ID. Map each to the relevant code site and the vuln class.
Step 2 — Plan the chain
Dispatch the attacker subagent with all findings as input. Ask it to:
- Sequence the findings in attack order.
- Identify the bridge state changes between each step (what state must one finding leave for the next to work?).
- Estimate the value extractable and the cost (gas, capital).
Step 3 — Write a multi-step PoC
Same as /exploit, but the test executes multiple steps:
function test_ChainExploit_GovernanceDrain() public {
// Step 1: flash-loan governance tokens (FLASH-001 + GOV-002)
flashLender.borrow(GOV_TOKEN, 1_000_000e18);
// Step 2: propose+vote+queue all in one block (GOV-003 — missing voting delay)
uint256 propId = governor.propose([address(treasury)], [0], [drainCalldata]);
governor.castVote(propId, 1);
governor.queue(propId);
// Step 3: wait timelock-bypass — TIMELOCK-001 — eta is ignored
vm.warp(block.timestamp + 1); // ← was supposed to be 2 days
governor.execute(propId);
// Step 4: repay flash loan, keep the drained treasury
flashLender.repay(GOV_TOKEN, 1_000_000e18);
assertGt(attacker.balance, treasuryStartBalance);
}
Step 4 — Run and verify
Same as /exploit — the test must pass.
Step 5 — Output
- The full chained PoC.
- A bullet-point summary of the chain:
Exploit chain:
1. FLASH-001 borrow governance token via flash loan
2. GOV-002 vote with spot balance (no snapshot, no delay)
3. GOV-003 queue + execute in same block (timelock bypass)
4. TREAS-001 drain treasury via approved proposal
→ Net value extracted: $4.2M (assuming 1M flash loan source)
Notes
- Don't claim a chain works without proving it via
forge-runner. - If the chain requires an unrealistic external dependency (a specific flash-loan source, a specific oracle behavior), call that out as a precondition.
- Best output when 2-4 findings combine; chains of 5+ findings tend to be theoretical.
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.
- 2d ago First seen · 72 lines · 22 tokens per session scan A 2275f9315fb0
exploit-chain is a command published in the GitHub repository omermaksutii/RugProof (9 stars, last pushed 1mo ago), licensed MIT. It adds 22 tokens to every session and 647 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
phase6-start
Command "phase6-start" from kota1026/quantum-shield, covering phase 6 $arguments 開始, step 1: 進捗状況を確認, step 2: 未完了画面を特定, step 3: 必須ファイルを読み込む and step 4: インフラ確認.
codespace-verify
Command "codespace-verify" from kota1026/quantum-shield, covering codespaces ui確認コマンド, 1. codespaces起動確認, サービス起動状態確認, postgresql, redis, rabbitmqが起動していない場合 and フロントエンド起動.
pr-merge
Command "pr-merge" from kota1026/quantum-shield, covering pr作成・マージコマンド, 1. 変更確認, 2. コミット(未コミットがある場合), 3. pr作成 and 4. マージ.
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.
worktree-check
Audit every git worktree for uncommitted, unpushed, or stashed work at risk before any reset/merge/cleanup. Usage: /worktree-check.