smithery/slvdev

weasel-overview

Project overview and audit preparation for smart contract security. Triggers on weasel overview, weasel scope, or weasel onboard.

Installation

$ npx skills add smithery/slvdev --skill weasel-overview

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from smithery/slvdev.

npx skills add smithery/slvdev

Browse all from smithery/slvdev

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 4,409 B
  • docs SUMMARY.md 152 B

History

  1. First recorded snapshot · 0 installs

SKILL.md

Weasel Overview

Project overview and audit scoping for security engineers starting a new audit.

When to Activate

  • Starting a new audit
  • User asks "what does this project do?"
  • User wants to scope/understand a codebase

When NOT to Use

  • User wants to run static analysis (→ weasel-analyzer)
  • User wants to explain specific code (→ weasel-explainer)
  • User already understands the project and wants to audit

Process

1. Read Documentation

  • README.md - project description, architecture
  • docs/ folder if exists
  • Comments in main contracts
  • Previous audits - Check for audit/, audits/, or audit reports
  • Known issues - Check known-issues.md, issue tracker links

2. Map Project Structure

  • List all .sol files
  • Identify: core contracts vs libraries vs interfaces
  • Map inheritance hierarchy
  • Note external dependencies (OpenZeppelin, Chainlink, etc.)

3. Identify Entry Points

User Functions (highest risk - untrusted input):

  • deposit(), withdraw(), swap(), transfer()...
  • Any external/public that handles value

Admin Functions (check access control):

  • setFee(), pause(), upgrade()...
  • Note: what permissions? onlyOwner? Multisig?

Callbacks (reentrancy risk):

  • onFlashLoan(), uniswapV3Callback()...
  • Any function called by external contracts

4. Trace Value Flow

  • Inbound: How does ETH/tokens enter? (deposit, swap, mint)
  • Outbound: How does ETH/tokens exit? (withdraw, claim, burn)
  • Internal: How does value move between contracts?

5. Map Trust Boundaries

Untrusted - assume malicious:

  • Users, external contracts, oracles

Privileged - trusted but verify:

  • Owner/Admin, Governance, Keepers

Internal - trusted:

  • Protocol's own contracts, libraries

6. Identify Focus Areas

Project Type High-Risk Areas
DeFi/Lending Liquidation, interest calc, oracles, flash loans
DEX/AMM Price calc, slippage, LP math, fees
Staking/Vaults Deposit/withdraw, rewards, share accounting
NFT/Gaming Minting, randomness, marketplace
Governance Voting, timelock, proposal execution

Output Structure

# [Project Name] Overview

## Summary
[2-3 sentences: what does this project do?]

## Architecture
- Contract list with purpose
- Key inheritance (ERC4626, Ownable, etc.)
- External dependencies

## Entry Points

### User Functions (Priority: High)
| Function | Contract | Risk |
|----------|----------|------|
| deposit() | Vault.sol:45 | Handles ETH |
| withdraw() | Vault.sol:89 | Sends ETH |

### Admin Functions (Check Access Control)
| Function | Contract | Permission |
|----------|----------|------------|
| setFee() | Vault.sol:120 | onlyOwner |

### Callbacks (Reentrancy Risk)
- onFlashLoan() called by flash lender

## Value Flow
- **In:** ETH via deposit(), tokens via depositToken()
- **Out:** ETH via withdraw(), rewards via claim()

## Trust Model
- **Owner:** Can pause, set fees (max X%)
- **External:** Chainlink oracle (single price feed)

## Audit Focus (Prioritized)
1. [High] Reentrancy in withdraw() - external call before state update
2. [High] Oracle manipulation - single feed, no TWAP
3. [Med] Share inflation - first depositor attack?

## Recommended Audit Order
1. Vault.sol - core logic, highest risk
2. Router.sol - entry point, input validation
3. Token.sol - standard ERC20, lower priority

After Overview

Offer:

  • "Run Weasel static analysis?"
  • "Deep dive into [highest risk contract]?"
  • "Explain specific function?"

Rationalizations to Reject

Rationalization Why It's Wrong
"I'll skip the libraries, they're standard" Libraries can be modified or misused. Note them.
"This looks like a simple project" Simple projects can have complex bugs. Be thorough.
"README explains everything" README can be outdated. Verify against actual code.
"I'll focus only on the main contract" Entry points can be anywhere. Map ALL external functions.
"Previous audit means it's safe" Previous audits miss things. Note them, don't rely on them.
"I understand the pattern, no need to map it" Every implementation differs. Map THIS codebase.