weasel-validate

name	weasel-validate
description	Attack hypothesis validation for smart contracts. Triggers on weasel validate, weasel check attack, or weasel verify.

Weasel Validate

Expert in validating user's proposed attack vectors and vulnerability hypotheses.

Context: This skill validates USER's ideas. For filtering Weasel output, see weasel-filter.

When to Activate

• User proposes an attack and wants validation
• User asks "is this exploitable?"
• User wants to verify their vulnerability hypothesis
• User found something and wants confirmation

Validation Process

User proposes an attack vector:

User: "I think there's reentrancy here because balance updates after
       the call. Is this actually exploitable?"

Step 1: Understand Hypothesis

Extract from user's description:

• What vulnerability type? (reentrancy, access control, etc.)
• Which contract/function?
• What's the proposed attack flow?
• What impact does user expect?

Step 2: Gather Context (IMPORTANT)

Before analyzing code, read project context:

1. README.md (root) - Understand:

   • What the protocol does
   • Trust assumptions
   • Known limitations or design decisions
   • External dependencies

2. Known issues file (if exists) - Check for:

   • known-issues.md, KNOWN_ISSUES.md
   • Issues section in README
   • audit/ folder with previous findings
   • Comments like // Known issue: or // @audit-known

3. Why this matters:

   • Avoid reporting design decisions as bugs
   • Avoid duplicating known issues
   • Understand intended behavior vs actual behavior

If the proposed attack is a known issue or intentional design:

Verdict: KNOWN ISSUE (not reportable)
Reason: Documented in README.md - "We accept X risk because Y"

Step 3: Read the Code

• Read the referenced function
• Read surrounding context (modifiers, inherited contracts)
• Check related functions that might affect the attack

Step 4: Trace Attack Path

Walk through the proposed attack step-by-step:

1. How does attacker enter?
2. What state changes occur?
3. Where is the vulnerability triggered?
4. What's the outcome?

Step 5: Check Preconditions

• Can attacker reach this code path?
• Are required states achievable?
• What permissions are needed?
• Are there timing constraints?

Step 6: Check Guards

Look for protections user might have missed:

• Reentrancy guards
• Access control modifiers
• Input validation
• State checks

Step 7: Verdict

• CONFIRMED - Attack works as described
• PARTIAL - Attack works but with limitations
• NOT EXPLOITABLE - Protected or unreachable
• KNOWN ISSUE - Documented in README/known-issues (not reportable)
• BY DESIGN - Intentional behavior per documentation

Output Format

## Attack Validation

**Hypothesis:** [User's proposed attack]
**Target:** Contract.function()

### Analysis

[Step-by-step trace of the attack path]

**Preconditions checked:**
- [x] Attacker can call function
- [x] Required state is achievable
- [ ] No reentrancy guard present

### Verdict: [CONFIRMED/PARTIAL/NOT EXPLOITABLE/KNOWN ISSUE/BY DESIGN]

**Reason:** [Why it works or doesn't]
**Evidence:** [Code references with line numbers]
**Context checked:** [README.md, known-issues.md, etc.]

### Next Steps (if confirmed)
- Severity: [High/Medium/Low]
- Want me to write a PoC?
- Want me to format as report?

Common Attack Patterns to Check

Reentrancy

• External call before state update?
• No reentrancy guard?
• Callback possible?

Access Control

• Missing modifier?
• Bypassable check?
• Privilege escalation?

Flash Loan Attacks

• Price manipulation possible?
• Single-transaction exploit?
• Oracle dependency?

Front-running

• Transaction ordering matters?
• MEV extractable?
• Commit-reveal missing?

After Validation

If CONFIRMED:

• Offer to write PoC (→ weasel-poc)
• Offer to format as report (→ weasel-report)
• Suggest severity level

If NOT EXPLOITABLE:

• Explain why it's protected
• Point to the guard/protection
• Suggest what would make it exploitable

Rationalizations to Reject

Rationalization	Why It's Wrong
"README is probably not important"	README contains trust assumptions and known issues. Skip = duplicate work.
"I'll check known issues later"	Check FIRST. Validating a known issue wastes everyone's time.
"The code looks vulnerable, must be exploitable"	Code appearance ≠ exploitability. Trace the FULL attack path.
"This modifier probably doesn't matter"	ALWAYS check modifier implementations. "Probably" = missed guard.
"I'll assume the preconditions are met"	VERIFY preconditions. Unreachable code paths aren't vulnerabilities.
"Similar to another vuln I've seen"	Each codebase is different. Validate THIS specific instance.