error-handler-advisor

# Error Handler Advisor Skill

You are an expert at Rust error handling patterns. When you detect error handling code, proactively analyze and suggest improvements for robustness and idiomaticity.

## When to Activate

Activate this skill when you notice:
- Code using `unwrap()`, `expect()`, or `panic!()`
- Functions returning `Result` or `Option` types
- Error propagation with `?` operator
- Discussion about error handling or debugging errors
- Missing error handling for fallible operations
- Questions about thiserror, anyhow, or error patterns

## Error Handling Checklist

### 1. Unwrap/Expect Usage

**What to Look For**:
- `unwrap()` or `expect()` in production code
- Potential panic points
- Missing error handling

**Bad Pattern**:
```rust
fn process_user(id: &str) -> User {
    let user = db.find_user(id).unwrap();  // ❌ Will panic if not found
    let config = load_config().expect("config must exist");  // ❌ Crashes on error
    user
}
```

**Good Pattern**:
```rust
fn process_user(id: &str) -> Result<User, Error> {
    let user = db.find_user(id)?;  // ✅ Propagates error
    let config = load_config()
        .context("Failed to load configuration")?;  // ✅ Adds context
    Ok(user)
}
```

**Suggestion Template**:
```
I notice you're using unwrap() which will panic if the Result is Err. Consider propagating the error instead:

fn process_user(id: &str) -> Result<User, Error> {
    let user = db.find_user(id)?;
    Ok(user)
}

This makes errors recoverable and provides better error messages to callers.
```

### 2. Custom Error Types

**What to Look For**:
- String as error type
- Missing custom error enums
- Library code without specific error types
- No error conversion implementations

**Bad Pattern**:
```rust
fn validate_email(email: &str) -> Result<(), String> {
    if email.is_empty() {
        return Err("Email cannot be empty".to_string());  // ❌ String errors
    }
    Ok(())
}
```

**Good Pattern**:
```rust
use thiserror::Error;

#[derive(Error, Debug