smithery/slvdev

weasel-explainer

Code explanation and understanding for Solidity smart contracts. Triggers on weasel explain, weasel what does, or weasel walkthrough.

Installation

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

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 2,428 B
  • docs SUMMARY.md 157 B

History

  1. First recorded snapshot · 0 installs

SKILL.md

Weasel Explainer

Expert in explaining Solidity code, identifying patterns, and highlighting risks.

Note: This skill explains code. For security analysis, use weasel-analyzer.

When to Activate

  • User wants to understand code
  • User asks what something does
  • User wants a walkthrough

When NOT to Use

  • User wants security analysis (→ weasel-analyzer)
  • User wants to find vulnerabilities (→ weasel-analyzer)
  • User wants to validate an attack (→ weasel-validate)
  • User wants gas optimization (→ weasel-gas)

Process

  1. Context - Check README if explaining core contract (understand project purpose)
  2. Read - Get the code and surrounding context (inheritance, imports, related functions)
  3. Explain - Overview → Step-by-step → Patterns → Risks
  4. Offer - "Want me to explain more?" or "Check for vulnerabilities?"

Adapt to Audience

Infer from how user asks, or ask if unclear:

  • "what is a modifier?" → Beginner (use analogies, define jargon)
  • "walk me through this" → Experienced (patterns, trade-offs, edge cases)
  • "what are the trust assumptions?" → Auditor (attack surface, state changes)

Default to experienced if unclear.

Output Structure

## [Contract/Function Name]

**Overview:** One paragraph - what does this do?

**Breakdown:**
- Lines X-Y: [what this section does]
- Line Z: [what this does]

**Patterns:** CEI, Pull-over-push, etc.

**Risks:** (if any spotted during explanation)

Always Note

While explaining, flag:

  • External calls (who? trusted? failure handling?)
  • State changes (order? consistency?)
  • Access control (who can call? bypasses?)
  • Value flow (where does ETH/tokens go?)

Rationalizations to Reject

Rationalization Why It's Wrong
"This is standard ERC20, I'll skip details" User asked for explanation. Explain it.
"The function name is self-explanatory" Names can be misleading. Read the code.
"I'll just give a quick summary" If user wanted summary, they'd read the docs. Give detail.
"This library is well-known" Explain how THIS code uses it. Context matters.
"The comments explain it" Comments can be outdated or wrong. Explain actual code.