Initial commit

skills/role-switch/SKILL.md

@@ -0,0 +1,204 @@
+---
+name: role-switch
+description: Use when stakeholders have conflicting priorities and need alignment, suspect decision blind spots from single perspective, need to pressure-test proposals before presenting, want empathy for different viewpoints (eng vs PM vs legal vs user), building consensus across functions, evaluating tradeoffs with multi-dimensional impact, or when user mentions "what would X think", "stakeholder alignment", "see from their perspective", "blind spots", or "conflicting interests".
+---
+
+# Role Switch
+
+## Table of Contents
+1. [Purpose](#purpose)
+2. [When to Use](#when-to-use)
+3. [What Is It](#what-is-it)
+4. [Workflow](#workflow)
+5. [Role Selection Patterns](#role-selection-patterns)
+6. [Synthesis Principles](#synthesis-principles)
+7. [Common Patterns](#common-patterns)
+8. [Guardrails](#guardrails)
+9. [Quick Reference](#quick-reference)
+
+## Purpose
+
+Role Switch helps uncover blind spots, align stakeholders, and make better decisions by systematically analyzing from multiple perspectives. It transforms single-viewpoint analysis into multi-stakeholder synthesis with explicit tradeoffs and alignment paths.
+
+## When to Use
+
+**Invoke this skill when you need to:**
+- Align stakeholders with conflicting priorities (eng vs PM vs sales vs legal)
+- Uncover blind spots in decisions by viewing from multiple angles
+- Pressure-test proposals before presenting to diverse audiences
+- Build empathy for perspectives different from your own
+- Navigate cross-functional tradeoffs (cost vs quality, speed vs thoroughness)
+- Evaluate decisions with multi-dimensional impact (technical, business, user, regulatory)
+- Find consensus paths when positions seem incompatible
+- Validate assumptions by seeing what different roles would challenge
+
+**User phrases that trigger this skill:**
+- "What would [stakeholder] think about this?"
+- "How do we get alignment across teams?"
+- "I'm worried we're missing something"
+- "See this from their perspective"
+- "Conflicting priorities between X and Y"
+- "Stakeholder buy-in strategy"
+
+## What Is It
+
+A structured analysis that:
+1. **Identifies relevant roles** (stakeholders with different goals, constraints, incentives)
+2. **Adopts each perspective** (inhabits mindset, priorities, success criteria of that role)
+3. **Articulates viewpoint** (what this role cares about, fears, values, measures)
+4. **Surfaces tensions** (where perspectives conflict, tradeoffs emerge)
+5. **Synthesizes alignment** (finds common ground, proposes resolutions, sequences decisions)
+
+**Quick example (API versioning decision):**
+- **Engineer**: "Deprecate v1 now—maintaining two versions doubles complexity and slows new features"
+- **Product Manager**: "Keep v1 for 12 months—customers need migration time or we risk churn"
+- **Customer Success**: "Offer v1→v2 migration service—customers value hand-holding over self-service docs"
+- **Finance**: "Charge for extended v1 support—converts maintenance burden into revenue stream"
+- **Synthesis**: Deprecate v1 in 12 months with 6-month free support + paid extended support option, PM owns migration docs + webinars, CS offers premium service
+
+## Workflow
+
+Copy this checklist and track your progress:
+
+```
+Role Switch Progress:
+- [ ] Step 1: Frame the decision or situation
+- [ ] Step 2: Select relevant roles
+- [ ] Step 3: Inhabit each role's perspective
+- [ ] Step 4: Surface tensions and tradeoffs
+- [ ] Step 5: Synthesize alignment and path forward
+```
+
+**Step 1: Frame the decision or situation**
+
+Clarify what's being decided, key constraints (time, budget, scope), and why alignment matters. See [Common Patterns](#common-patterns) for decision framing by type.
+
+**Step 2: Select relevant roles**
+
+Choose 3-6 roles with different goals, incentives, or constraints. See [Role Selection Patterns](#role-selection-patterns) for stakeholder mapping. For complex multi-stakeholder decisions → Study [resources/methodology.md](resources/methodology.md) for RACI + power-interest analysis.
+
+**Step 3: Inhabit each role's perspective**
+
+For each role, articulate: what they optimize for, what they fear, how they measure success, what constraints they face. Use [resources/template.md](resources/template.md) for structured analysis. For realistic roleplay → See [resources/methodology.md](resources/methodology.md) for cognitive empathy techniques.
+
+**Step 4: Surface tensions and tradeoffs**
+
+Identify where perspectives conflict, map incompatible goals, articulate explicit tradeoffs. See [Synthesis Principles](#synthesis-principles) for tension analysis.
+
+**Step 5: Synthesize alignment and path forward**
+
+Find common ground, propose resolutions that address core concerns, sequence decisions to build momentum. Self-check using [resources/evaluators/rubric_role_switch.json](resources/evaluators/rubric_role_switch.json). Minimum standard: Average score ≥ 3.5.
+
+## Role Selection Patterns
+
+**Classic product triad (most common):**
+- **Engineering**: Feasibility, technical debt, system complexity, maintainability
+- **Product**: User value, roadmap prioritization, market timing, feature completeness
+- **Design**: User experience, accessibility, consistency, delight
+
+**Business decision quads:**
+- **Finance**: Cost, ROI, cash flow, unit economics, margin
+- **Sales**: Customer acquisition, deal closure, competitive positioning, quota attainment
+- **Marketing**: Brand perception, customer lifetime value, positioning, conversion funnel
+- **Operations**: Scalability, process efficiency, risk management, resource utilization
+
+**Regulatory/compliance contexts:**
+- **Legal**: Risk mitigation, liability, contract terms, IP protection
+- **Compliance**: Regulatory adherence, audit trail, policy enforcement, certification
+- **Privacy/Security**: Data protection, threat model, access control, incident response
+- **Ethics**: Fairness, transparency, stakeholder impact, values alignment
+
+**External stakeholders:**
+- **End Users**: Usability, reliability, cost, privacy, delight
+- **Customers** (B2B): Integration ease, support quality, vendor stability, total cost of ownership
+- **Partners**: Revenue share, mutual value, integration burden, strategic alignment
+- **Regulators**: Public interest, safety, competition, transparency
+
+## Synthesis Principles
+
+**Finding common ground:**
+1. **Shared goals**: What do all roles ultimately want? (e.g., company success, customer satisfaction)
+2. **Compatible sub-goals**: Where do objectives align even if paths differ?
+3. **Mutual fears**: What do all roles want to avoid? (e.g., reputational damage, security breach)
+
+**Resolving conflicts:**
+- **Sequential decisions**: "Do X first (satisfies role A), then Y (satisfies role B)" (e.g., pilot then scale)
+- **Hybrid approaches**: Combine elements from multiple perspectives (e.g., freemium = marketing + finance)
+- **Constraints as creativity**: Use one role's limits to sharpen another's solution (e.g., budget constraint forces prioritization)
+- **Risk mitigation**: Address fears with safeguards (e.g., eng fears tech debt → schedule refactoring sprint)
+
+**When perspectives are truly incompatible:**
+- **Escalate decision**: Flag for leadership with clear tradeoff framing
+- **Run experiment**: Pilot to gather data, convert opinions to evidence
+- **Decouple decisions**: Split into multiple decisions with different owners
+- **Accept tradeoff explicitly**: Document the choice and reasoning for future reference
+
+## Common Patterns
+
+**Pattern 1: Build vs Buy Decisions**
+- **Roles**: Engineering (control, customization), Finance (TCO), Product (time-to-market), Legal (vendor risk), Operations (support burden)
+- **Typical tensions**: Eng wants control, Finance sees build cost underestimation, PM sees opportunity cost of delay
+- **Synthesis paths**: Pilot buy option with build fallback, build core/buy periphery, time-box build with buy backstop
+
+**Pattern 2: Feature Prioritization**
+- **Roles**: PM (roadmap vision), Engineering (technical feasibility), Design (UX quality), Sales (customer requests), Users (actual need)
+- **Typical tensions**: Sales wants everything promised, Eng sees scope creep, Users want simplicity, PM balances all
+- **Synthesis paths**: MoSCoW prioritization (must/should/could/won't), release in phases, v1 vs v2 scoping
+
+**Pattern 3: Pricing Strategy**
+- **Roles**: Finance (margin), Marketing (positioning), Sales (close rate), Customers (value perception), Product (feature gating)
+- **Typical tensions**: Finance wants premium, Sales wants competitive, Marketing wants simple, Product wants value-based tiers
+- **Synthesis paths**: Tiered pricing (serves multiple segments), usage-based (aligns value), anchoring (premium + standard)
+
+**Pattern 4: Organizational Change (e.g., return-to-office)**
+- **Roles**: Leadership (collaboration), Employees (flexibility), HR (retention), Finance (real estate cost), Managers (productivity)
+- **Typical tensions**: Leadership sees serendipity loss, Employees see autonomy loss, Finance sees sunk cost, HR sees turnover
+- **Synthesis paths**: Hybrid model (balance), role-based policy (nuance), trial periods (data-driven), opt-in incentives (voluntary)
+
+**Pattern 5: Technical Migration**
+- **Roles**: Engineering (technical improvement), PM (feature freeze), Users (potential downtime), DevOps (operational risk), Finance (ROI)
+- **Typical tensions**: Eng sees long-term benefit, PM sees short-term cost, Users fear disruption, Finance wants ROI proof
+- **Synthesis paths**: Incremental migration (reduce risk), feature parity first (minimize disruption), ROI projection (justify investment)
+
+## Guardrails
+
+**Avoid strawman perspectives:**
+- Don't caricature roles (e.g., "Finance only cares about cost cutting")
+- Inhabit perspective charitably—what's the *strongest* version of this viewpoint?
+- Seek conflicting evidence to your own bias
+
+**Distinguish position from interest:**
+- **Position**: What they say they want (surface demand)
+- **Interest**: Why they want it (underlying need)
+- Example: "I want this feature" (position) because "customers are churning" (interest = retention)
+- Synthesis works at interest level, not position level
+
+**Acknowledge information asymmetry:**
+- Some roles have context others lack (e.g., Legal sees confidential liability exposure)
+- Flag assumptions: "If Legal has info we don't, that could change this analysis"
+- Invite real stakeholders to validate your perspective-taking
+
+**Don't replace actual stakeholder input:**
+- Role-switch is for *preparing* conversations, not *replacing* them
+- Use to pressure-test before presenting, not as substitute for gathering input
+- Best used when stakeholder access is limited or to refine proposals before socializing
+
+**Power dynamics matter:**
+- Not all perspectives carry equal weight in decision-making (hierarchy, expertise, accountability)
+- Synthesis should acknowledge who has decision authority
+- Don't assume consensus is always possible or desirable
+
+## Quick Reference
+
+**Resources:**
+- **Quick analysis**: [resources/template.md](resources/template.md)
+- **Complex stakeholder mapping**: [resources/methodology.md](resources/methodology.md)
+- **Quality rubric**: [resources/evaluators/rubric_role_switch.json](resources/evaluators/rubric_role_switch.json)
+
+**5-Step Process**: Frame Decision → Select Roles → Inhabit Perspectives → Surface Tensions → Synthesize Alignment
+
+**Role selection**: Choose 3-6 roles with different goals, incentives, constraints
+
+**Synthesis principles**: Find shared goals, resolve conflicts (sequential, hybrid, constraints as creativity), escalate when incompatible
+
+**Avoid**: Strawman perspectives, position vs interest confusion, replacing actual stakeholder input