npx skills add smithery/samarv --skill wrong-but-not-confused-clarity-framework
samarv/shanon
wrong-but-not-confused-clarity-framework
A leadership framework to eliminate organizational hedging and indecision. Use this when teams are stalled by a fear of being wrong, when stakeholders mask disagreement as "misunderstanding," or when resourcing does not align with stated priorities.
Installation
npx skills add samarv/shanon --skill wrong-but-not-confused-clarity-framework
Similar popular skills
Related neighbors and high-traction skills in the same topics — useful to compare before installing.
Containerize an ASP.NET .NET Framework project by creating Dockerfile and .dockerfile files cus…
8.7K installsINVOKE THIS SKILL at the START of any LangChain/LangGraph/Deep Agents project, before writing a…
7.8K installsCreate, update, refactor, explain, or review Microsoft Agent Framework solutions using shared g…
2K installsFull Sentry SDK setup for React Router Framework mode. Use when asked to "add Sentry to React R…
1.6K installsMigrate Terraform provider resources and data sources from Plugin SDKv2 to the Plugin Framework…
16 installsOpt-in recreation of the Bun + TypeScript framework used to build Vapi's landing-page voice age…
229 installsAlso in this package
Other skills from samarv/shanon · top by installs.
npx skills add samarv/shanon
More details
Agent compatibility
Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.
Also listed on
Alternate registries and mirrors of this skill.
Repository health
main
Package contents
Files included with this skill beyond the listing page.
-
skill md
SKILL.md5,239 B -
docs
SUMMARY.md297 B
History
- First seen on skills.sh
- First recorded snapshot · 1 installs
SKILL.md
The "Wrong but Not Confused" framework is a leadership model designed to drive 100% alignment in a single direction. It shifts the focus from "being right" (which encourages hedging) to "being clear" (which enables learning and speed).
Core Principles
- Clarity over Correctness: It is better to move the entire organization in one clear direction and be wrong than to hedge in three directions and be confused. Confusion ensures failure; a clear (even if wrong) direction provides a chance for success and a definitive loop for learning.
- Principles with Teeth: A principle is useless if no one would ever disagree with it (e.g., "we build simple products"). A "principle with teeth" must include a specific trade-off or sacrifice.
- The Socratic Burden: If you cannot articulate the opposing view’s position to their satisfaction, you don't yet have enough clarity to disagree.
Phase 1: Clarity of Thought
Before making a decision, use these tactics to eliminate the "mask of misunderstanding."
1. The Disagreement vs. Misunderstanding Test
When a stakeholder says, "I'm not clear on this" or "I don't understand," determine if they are actually confused or if they are masking a disagreement.
- The Push: Ask: "Are you misunderstanding the proposal, or do you disagree with it?"
- The Resolution:
If they misunderstand: Stop the debate. Spend as much time as necessary until both parties can articulate each other’s points perfectly. If they disagree: Stop the explanation. Acknowledge the difference in opinion/principles and move to a decision-making mechanism (e.g., "Agree to Disagree" or "Escalate").
2. Conduct "Problem Jams"
Instead of high-level brainstorms, hold sessions focused on extreme nuance.
- Avoid: "We want to launch a video product."
- Require: "Exactly what type of video? For which specific audience? What is the unique success criteria? What is the base camp vs. the mountain peak?"
3. Identify the Controversial Opinion
Force teams to state their "principles with teeth."
- The Question: "What are you willing to sacrifice to make this work?"
- The Goal: If the solution doesn't involve a painful trade-off, it isn't a strategy; it’s a wish list.
Phase 2: Clarity of Execution
Once a direction is set, audit the system to ensure there is no "organizational hedging."
1. The Resourcing Audit
Compare stated priorities against actual engineer/talent allocation.
- The Reality Check: If "Project A" is the #1 priority but 60% of the team is working on a legacy migration, then the migration is actually the priority.
- Action: Force the leader to say: "Our number one priority is the migration." This creates the honesty required to fix the confusion.
2. The Top Talent Filter
Check where your "Alpha" players or top performers are assigned.
- The Rule: Your best talent must be on the #1 priority. If they are working on "moonshots" while the core product is at risk, the system is confused.
Examples
Example 1: Product Strategy
- Context: A team is debating between an "engagement-first" or "revenue-first" feed algorithm.
- Input: Multiple stakeholders are "hedging" by trying to optimize for both, leading to a mediocre experience.
- Application: CPO says, "We might be wrong, but we're not confused. For the next six months, we are optimizing 100% for high-value knowledge exchange. We will sacrifice short-term click-through rates."
- Output: The AI team has a single mathematical objective. Even if the move is wrong, the data will be clear, allowing for a fast pivot later.
Example 2: Stakeholder Management
- Context: A PM is presenting a roadmap. An executive says, "I'm not sure I see the vision here."
- Input: The PM tries to re-explain the slides for the third time.
- Application: The PM stops and asks: "Is there a specific part of the data you don't understand, or do you disagree with our focus on the mobile-first cohort?"
- Output: The executive admits they think the desktop cohort is more valuable. The conversation shifts from "explaining" to "deciding on a segment."
Common Pitfalls
- Mistaking Vague Goals for Clarity: Using words like "innovation," "simplicity," or "quality" without defining what you are willing to give up to get them.
- The "Mask of Politeness": Allowing stakeholders to say "I'm not clear" for weeks because it feels more "polite" than saying "I disagree." This creates "minus one to one" drag.
- Leading with Evidence, not Belief: Waiting for 100% data certainty before choosing a direction. You must lead with a conviction-based "Peak" and use evidence only to reach "Base Camp."
- Resourcing the "Loudest" Problem: Allocating engineers to whoever is complaining the most rather than the stated #1 priority.