Instructions

Identify Your Assumptions

Before proposing a solution, list what you're assuming:

## Assumptions

1. [The function X exists and does Y]
2. [The error is caused by Z]
3. [This file is imported by W]
4. [The config value is set to V]

Verify Before Building

Assumption	Verification	Status
Function X does Y	Read the function	Verified / Wrong
Error caused by Z	Check error logs	Verified / Wrong
File imported by W	Grep for imports	Verified / Wrong

Stop if any key assumption is wrong. Don't patch - reassess.

Types of Assumptions

Existence assumptions:

"There's probably a config file for this"
"The API endpoint likely exists"
Verify: find, grep, ls

Behavior assumptions:

"This function probably validates input"
"The middleware likely checks auth"
Verify: Read the actual code

Causation assumptions:

"The error is probably from X"
"This is likely failing because Y"
Verify: Reproduce, check logs, trace execution

State assumptions:

"The database probably has this column"
"The env var is likely set"
Verify: Check schema, check actual values

The Assumption Cascade

Wrong assumption: "Auth is handled by middleware"
    ↓
Build solution: "Just call the protected endpoint"
    ↓
Solution fails: "Auth not working"
    ↓
Wrong diagnosis: "Middleware must be misconfigured"
    ↓
Deeper hole: "Let me fix the middleware..."
    ↓
Reality: Auth was in the route handler all along

Break the cascade early. Verify before building.

Output Format

When working on non-trivial problems:

## Sanity Check

**Key assumptions:**
1. [assumption] → Verified by [how]
2. [assumption] → Verified by [how]
3. [assumption] → ⚠️ NOT verified, checking...

**Proceeding with:** [list verified assumptions]

NEVER

Say "probably" or "likely" without then verifying
Diagnose bugs without reproducing or checking logs
Build multi-step solutions on unverified assumptions
Explain code behavior without reading the code
Assume error messages are accurate (verify root cause)

ALWAYS

List assumptions explicitly before building on them
Verify existence before assuming something exists
Read code before explaining what it does
Reproduce issues before diagnosing them
Stop and reassess when an assumption proves wrong

Example

User: "The user signup isn't sending confirmation emails"

Bad approach (assumption cascade):

"The email service probably isn't configured correctly. Let me check the SMTP settings... Actually, the email template might be wrong... Let me also check if the queue is processing..."

Good approach (sanity check):

## Sanity Check

**Assumptions to verify:**
1. Signup actually triggers email sending
2. Email sending code exists and is called
3. Email service is configured
4. No errors in logs

**Verifying #1:**
Reading signup handler... Found: `sendConfirmationEmail(user)` on line 45.
Verified: signup does call email function.

**Verifying #2:**
Reading sendConfirmationEmail... Found: it calls `emailService.send()`.
But wait - there's a `if (config.emailEnabled)` check on line 12.

**Verifying #3:**
Checking config... `emailEnabled: false` in development.

**Root cause found:** Emails disabled in config, not a bug.

No assumption cascade. Verified each step. Found real cause.

sanity-check

Sanity Check

When To Activate