weasel-validate

# 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?

###