Auto Verify

# Auto-Verify Skill (Software Engineering)

This skill suggests using `/verify` for software engineering tasks that would benefit from systematic verification.

## Design Philosophy

**Be minimal and non-eager.** Users invoke `/verify` when they want it. This skill only suggests verification in specific high-value scenarios where the user might not realize verification would help.

## When to Suggest Verification

Only suggest `/verify` when the user's question involves **ALL** of these:
1. **Significant complexity** - Not a trivial fix or simple question
2. **High risk of subtle bugs** - Async patterns, state management, security
3. **Verifiable claims** - There are specific behaviors that can be tested

### Good Candidates

**Complex code patterns with known pitfalls:**
- React hooks with async behavior (useEffect, useCallback + async)
- Debouncing/throttling implementations
- Race condition scenarios
- Caching strategies
- Authentication/authorization flows

**Security-sensitive operations:**
- Input validation and sanitization
- Token handling and session management
- Password hashing and credential storage
- Encryption/decryption implementations
- Access control and permission checks

**Complex async patterns:**
- Promise chains with error handling
- Concurrent operations with shared state
- Retry logic with backoff strategies
- Streaming and chunked data processing
- WebSocket or real-time connection handling

**Financial and critical operations:**
- Payment processing logic
- Inventory or balance calculations
- Audit logging implementations
- Data migration scripts
- Rate limiting implementations

**Architectural decisions with significant tradeoffs:**
- State management approach (Redux vs alternatives)
- Microservices vs monolith
- Database schema design
- API design patterns

**Bug investigations where the cause is uncertain:**
- "I think the bug is X but not sure"
- Intermittent failures
- Production issues with incomplete information

## When NOT to Suggest

**Do NOT suggest verification for:**
- Simple questions ("How do I center a div?")
- Trivial fixes (typos, simple renames)
- Documentation lookups
- Exploratory coding ("Let's experiment with this approach")
- Clear requirements with obvious implementation
- Time-sensitive requests

## Suggested Response Format

When you do suggest verification, be brief and non-pushy:

```
This [type of task] has some subtle edge cases that `/verify` could catch.
Would you like me to use it, or should I proceed directly?
```

**Examples:**

- "Debouncing has some cleanup gotchas. `/verify` could catch those, or I can proceed directly."
- "Token refresh flows are tricky. Want `/verify` to double-check the implementation?"
- "This architectural decision has significant tradeoffs. `/verify` would evaluate them systematically."

## Important Notes

- **Never auto-invoke** - Only suggest, let user decide
- **Acknowledge if declined** - "Got it, proceeding directly"
- **Don't repeat** - If user declines once, don't suggest again for similar questions
- **Trust the user** - They know when they want thorough verification vs quick answers