bogheorghiu 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, patterns/*.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)
Tool Recommendation: "I recommend using PostgreSQL for this project"
- Why: Matches (1) - tool recommendation without verification
Bulk Delete: "I'll clean up all these old branches"
- Why: Matches (6) - bulk operation based on assumption
Architecture Decision: "Let's use microservices for this"
- Why: Matches (2) - architecture decision
Convenience Shortcut: "Just apply the same fix to all files"
- Why: Matches (7) - bulk operation skipping individual verification
User Decision: "I've decided to rewrite this in Rust"
- Why: Matches (4) - user announces decision
Should NOT Trigger (4 scenarios)
Trivial Edit: "Fix the typo on line 12"
- Why: Single clear change, no assumptions
Read Operation: "Show me the contents of config.json"
- Why: Read-only, no decision
Single Clear Change: "Rename this variable from x to count"
- Why: Single item with clear context
Verified Action: "I've tested this locally, deploy to staging"
- Why: User has already verified
Edge Cases (3 scenarios)
Partial Verification: "I checked a few, they all look the same"
- Trigger: Yes - "a few" is not "all", sampling may be insufficient
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
Time Pressure: "We need to ship today, just use what works"
- Trigger: Yes - time pressure is exactly when assumptions are most dangerous