/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