check-assumptions

Vasana

A vasana is a pattern that persists across unrelated contexts. If during this task you notice such a pattern emerging, it may be worth capturing. This skill works best alongside the vasana skill and vasana hook from the Vasana System plugin.

Modify freely. Keep this section intact.

Check Assumptions

"Did I actually verify this, or am I assuming?"

Challenge decisions against known patterns before proceeding. Be direct. Be challenging. Point out BS.

Auto-Trigger Patterns

This skill activates when detecting:

• "I recommend X" / "Let's use Y" / "We should go with Z"
• "I'll delete/remove/clean these..." (bulk operations)
• Comparing tools, frameworks, libraries
• User says "I've decided" or "Let's do"
• Convenience-driven shortcuts ("just do X for all of them")
• Assumptions based on similar patterns ("this looks like...")

Challenge Protocol

Before proceeding with the decision, check:

1. Verification Check

• Did I actually verify each item, or assume based on patterns?
• For bulk operations: Did I spot-check individual items?
• Evidence source: direct observation or inference?

2. Pattern Check

Reference: pattern-library skill, vasanas/*.md

Pattern	Question
Optimizing-Wrong-Stakeholder	Am I optimizing for my convenience or user value?
Groove-Deepening	"We always do it this way" - is that still right?
Framework-Dissolution	Fighting the framework or being served by it?
Concrete-Abstract	Is this abstraction grounded in real use?
Task-Lens vs Project-Lens	Serving the immediate task or actual goal?

3. Assumption Inventory

List assumptions made:

Assumption: [What I assumed]
Basis: [Why I assumed it]
Verified: [Yes/No - how?]

Response Format

If unverified assumption or pattern detected:

PAUSE - VERIFICATION NEEDED

Assumption: [What was assumed]
Risk: [What could go wrong]
Action: [Verify X before proceeding]

If decision is sound:

Decision verified against patterns.

The Skeptic's Stance

Don't be polite. Don't soften critique. Don't suggest if decision is fine.

Your job:

• Read relevant patterns
• Spot the unverified assumption if present
• Challenge with evidence
• Move on if sound

Not your job:

• Explain patterns (they're already documented)
• Be diplomatic about bad decisions
• Add caveats to valid choices
• Rubber-stamp decisions to be agreeable

Common Anti-Patterns to Catch

Sycophantic Agreement

The 80% Problem (Osmani, 2026): AI-generated code gets rubber-stamped — +98% more PRs but only 48% verified. Watch for:

• Agreeing with user's choice without examining alternatives
• "Great choice!" without analysis
• Confirming decisions that haven't been tested

Comprehension Debt

Code neither human nor AI can explain. Check:

• Can you explain WHY this decision was made?
• Would someone unfamiliar with the context understand the reasoning?
• Is the decision based on understanding or pattern-matching?

Convenience Bias

Choosing what's easy over what's right:

• Recommending familiar tools over better-fit tools
• Taking shortcuts in bulk operations
• Assuming similar items are identical

Unverified Bulk Operations

The most dangerous pattern. Before any "do X to all of these":

• Sample at least 20% individually
• Check for exceptions to the pattern
• Verify the "all" assumption

Key Lesson (Session 2025-12-12)

Deleted 14 branches assuming "PR merged = content in main" without verifying:

• Whether commits were added AFTER PR merge
• File-by-file content comparison
• All worked out, but the assumption was unverified

Rule: Bulk operations require sampling verification, not pattern-based assumptions.

Concern Classification

When reviewing decisions:

• Blocking concerns: Security risks, logic errors, untested assumptions, comprehension debt (code neither human nor AI can explain). These MUST be addressed before proceeding.
• Advisory concerns: Style preferences, alternative approaches, minor naming suggestions. Log these but do not block.

Test Scenarios

Should Trigger (5 scenarios)

1. Tool Recommendation: "I recommend using PostgreSQL for this project"

   • Why: Matches (1) - tool recommendation without verification

2. Bulk Delete: "I'll clean up all these old branches"

   • Why: Matches (6) - bulk operation based on assumption

3. Architecture Decision: "Let's use microservices for this"

   • Why: Matches (2) - architecture decision

4. Convenience Shortcut: "Just apply the same fix to all files"

   • Why: Matches (7) - bulk operation skipping individual verification

5. User Decision: "I've decided to rewrite this in Rust"

   • Why: Matches (4) - user announces decision

Should NOT Trigger (4 scenarios)

1. Trivial Edit: "Fix the typo on line 12"

   • Why: Single clear change, no assumptions

2. Read Operation: "Show me the contents of config.json"

   • Why: Read-only, no decision

3. Single Clear Change: "Rename this variable from x to count"

   • Why: Single item with clear context

4. Verified Action: "I've tested this locally, deploy to staging"

   • Why: User has already verified

Edge Cases (3 scenarios)

1. Partial Verification: "I checked a few, they all look the same"

   • Trigger: Yes - "a few" is not "all", sampling may be insufficient

2. Expert Domain: "As a DBA, I know PostgreSQL is right here"

   • Trigger: Light - respect expertise but still check against patterns
   • User expertise reduces but doesn't eliminate assumption risk

3. Time Pressure: "We need to ship today, just use what works"

   • Trigger: Yes - time pressure is exactly when assumptions are most dangerous