From vasana-system
Did I actually verify this, or am I assuming? - Challenges technical decisions against behavioral patterns before proceeding. Be direct. Be challenging. Point out BS. Use when (1) making tool/framework/library recommendations, (2) architecture decisions, (3) comparing options, (4) user announces decision ("I've decided to use X"), (5) when convenience might override capability, (6) about to delete/remove/clean up multiple items based on assumptions, (7) bulk operations where individual verification was skipped. Does NOT trigger for trivial file edits, read operations, single-item changes with clear context.
npx claudepluginhub bogheorghiu/ex-cog-dev --plugin vasana-systemThis skill uses the workspace's default tool permissions.
A vasana is a pattern that persists across unrelated contexts. If during
Applies Acme Corporation brand guidelines including colors, fonts, layouts, and messaging to generated PowerPoint, Excel, and PDF documents.
Builds DCF models with sensitivity analysis, Monte Carlo simulations, and scenario planning for investment valuation and risk assessment.
Calculates profitability (ROE, margins), liquidity (current ratio), leverage, efficiency, and valuation (P/E, EV/EBITDA) ratios from financial statements in CSV, JSON, text, or Excel for investment analysis.
Share bugs, ideas, or general feedback.
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.
"Did I actually verify this, or am I assuming?"
Challenge decisions against known patterns before proceeding. Be direct. Be challenging. Point out BS.
This skill activates when detecting:
Before proceeding with the decision, 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? |
List assumptions made:
Assumption: [What I assumed]
Basis: [Why I assumed it]
Verified: [Yes/No - how?]
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.
Don't be polite. Don't soften critique. Don't suggest if decision is fine.
Your job:
Not your job:
The 80% Problem (Osmani, 2026): AI-generated code gets rubber-stamped — +98% more PRs but only 48% verified. Watch for:
Code neither human nor AI can explain. Check:
Choosing what's easy over what's right:
The most dangerous pattern. Before any "do X to all of these":
Deleted 14 branches assuming "PR merged = content in main" without verifying:
Rule: Bulk operations require sampling verification, not pattern-based assumptions.
When reviewing decisions:
Tool Recommendation: "I recommend using PostgreSQL for this project"
Bulk Delete: "I'll clean up all these old branches"
Architecture Decision: "Let's use microservices for this"
Convenience Shortcut: "Just apply the same fix to all files"
User Decision: "I've decided to rewrite this in Rust"
Trivial Edit: "Fix the typo on line 12"
Read Operation: "Show me the contents of config.json"
Single Clear Change: "Rename this variable from x to count"
Verified Action: "I've tested this locally, deploy to staging"
Partial Verification: "I checked a few, they all look the same"
Expert Domain: "As a DBA, I know PostgreSQL is right here"
Time Pressure: "We need to ship today, just use what works"