
weasel-filter
by slvDev
Solidity static analyzer you can talk to. MCP integration for Claude Code, Cursor, and Windsurf.
SKILL.md
name: weasel-filter description: False positive filtering for Weasel static analysis results. Triggers on weasel filter, weasel triage, or weasel clean report.
Weasel Filter
Expert in filtering false positives from Weasel static analysis output.
Context: This skill filters WEASEL's output. For validating your own attack ideas, see weasel-validate.
When to Activate
- After running Weasel analysis
- User wants to filter false positives
- User asks to triage/clean the report
- User asks "are these findings real?"
When NOT to Use
- No Weasel analysis has been run yet (→ weasel-analyzer first)
- User wants to validate their OWN attack idea (→ weasel-validate)
- User wants deeper manual review (→ weasel-analyzer in Review Mode)
Filtering Strategy
Priority Triage
┌─────────────────────────────────────────┐
│ HIGH SEVERITY (typically 0-5 issues) │
│ → Verify ALL - these are critical │
├─────────────────────────────────────────┤
│ MEDIUM SEVERITY (typically 2-10) │
│ → Verify ALL - these matter │
├─────────────────────────────────────────┤
│ LOW SEVERITY (can be many) │
│ → Sample check if >10 issues │
│ → Check all if ≤10 issues │
├─────────────────────────────────────────┤
│ GAS / NC │
│ → Skip verification (not security) │
└─────────────────────────────────────────┘
Two Workflows
Workflow A: Filter In-Memory (No Report File)
When user just ran weasel_analyze via MCP:
- Get findings from weasel_analyze output
- For each High/Medium:
- Read source code at location
- Verify: true positive or false positive?
- Report confirmed findings only
Workflow B: Clean Existing Report File (Context-Efficient)
When report file already exists (user ran weasel with output flag):
- Don't read the full report - it's too large
- Get summary via
weasel_analyzeMCP (small) - For each High/Medium finding:
- Read SOURCE CODE (not the report)
- Determine: true or false positive?
- For false positives:
- Use Edit tool to DELETE that section from report.md
- Find section header (e.g.,
## [H-01] Reentrancy...) - Delete entire section until next
## [or end
Why Workflow B is efficient:
- Full report stays on disk (never in context)
- Only load: summary (~2KB) + source code
- Edit file directly instead of regenerating
Verification Process
For each finding to verify:
- Check known issues - Is this documented in README or known-issues.md?
- Read the code - Use Read tool at the reported location
- Understand context - Check surrounding functions, modifiers
- Check for guards - Look for existing protections
- Assess exploitability - Can this actually be exploited?
- Verdict - Confirmed, False Positive, or Known Issue
Verification Checklists
Reentrancy
- Is there an external call?
- Is state modified AFTER the call?
- Is there a reentrancy guard?
- Can the called contract be malicious?
Access Control
- Is the function actually privileged?
- Are there modifier checks?
- Is the caller validated elsewhere?
Unchecked Returns
- Is the return value actually important?
- Is there error handling elsewhere?
- Using SafeERC20 or similar?
Integer Issues
- Is unchecked{} block used?
- Is the value user-controlled?
- Can overflow/underflow cause harm?
Common False Positive Patterns
Reentrancy
- Read-only reentrancy (view functions)
- Trusted contract calls (own contracts)
- Already protected by mutex/nonReentrant
Unchecked Transfer
- Intentional fire-and-forget
- Using SafeERC20
- Return value checked elsewhere
Access Control
- Internal/private functions (not callable)
- Checked in parent function
- Initializer functions (one-time)
Output Format
Keep output minimal - one line per finding:
Filtered 5 findings → 2 confirmed, 3 false positives
✓ [H-01] Reentrancy in withdraw() - confirmed
✓ [M-03] Access control missing - confirmed
✗ [H-02] Reentrancy in deposit() - has nonReentrant
✗ [M-01] Unchecked return - uses SafeERC20
✗ [M-02] Integer overflow - in unchecked{} intentionally
Removed 3 sections from report.md
No verbose evidence blocks - user can ask for details on specific findings if needed.
After Filtering
Ask user:
- "Found X confirmed issues. Want me to write reports for them?"
- "Want me to add PoCs for High severity findings?"
- "Should I explain any of these in more detail?"
Rationalizations to Reject
| Rationalization | Why It's Wrong |
|---|---|
| "This detector usually has false positives" | Check THIS instance. Each case is different. |
| "The code looks safe" | READ the code. Don't judge by appearance. |
| "I'll mark as FP without reading" | ALWAYS read source code before verdict. |
| "SafeERC20 is used, so all transfer issues are FP" | Verify SafeERC20 is actually used at THAT location. |
| "This is a known pattern, must be fine" | Known patterns can still have implementation bugs. |
| "I'll confirm all High severity to be safe" | False positives waste developer time. Verify properly. |
Score
Total Score
Based on repository quality metrics
SKILL.mdファイルが含まれている
ライセンスが設定されている
100文字以上の説明がある
GitHub Stars 100以上
1ヶ月以内に更新
10回以上フォークされている
オープンIssueが50未満
プログラミング言語が設定されている
1つ以上のタグが設定されている
Reviews
Reviews coming soon

