{"kind":"Skill","metadata":{"namespace":"community","name":"thinking-cynefin","version":"0.1.0"},"spec":{"description":"Classify problems by complexity domain (clear, complicated, complex, chaotic) and match approach to domain. Use for choosing methodologies, problem framing, and process design.","files":{"SKILL.md":"---\nname: thinking-cynefin\ndescription: Classify problems by complexity domain (clear, complicated, complex, chaotic) and match approach to domain. Use for choosing methodologies, problem framing, and process design.\n---\n\n# Cynefin Framework\n\n## Overview\n\nThe Cynefin framework, developed by Dave Snowden, classifies problems into domains based on the relationship between cause and effect. Different domains require fundamentally different approaches. Using the wrong approach for the domain leads to failure—agile doesn't fix truly complex problems, and detailed planning doesn't help in chaos.\n\n**Core Principle:** The nature of the problem determines the nature of the solution. Match your approach to the domain.\n\n## When to Use\n\n- Choosing the right methodology for a project\n- Understanding why an approach isn't working\n- Designing processes for different problem types\n- Deciding how much to plan vs. experiment\n- Understanding organizational challenges\n- Incident response and crisis management\n\nDecision flow:\n\n```\nFacing a problem?\n  → What's the relationship between cause and effect?\n    → Obvious? → CLEAR DOMAIN\n    → Requires analysis? → COMPLICATED DOMAIN\n    → Only visible in retrospect? → COMPLEX DOMAIN\n    → Cannot perceive? → CHAOTIC DOMAIN\n```\n\n## The Five Domains\n\n### 1. Clear (formerly Simple/Obvious)\n\n**Characteristics:**\n- Cause and effect are obvious to everyone\n- Best practices exist and work\n- Repeatable processes\n\n**Approach: Sense → Categorize → Respond**\n\n```\nProblem: Server disk is full\nSense: Alert shows disk at 100%\nCategorize: Known issue with known fix\nRespond: Clear old logs, add monitoring\n\nAppropriate method:\n- Standard operating procedures\n- Checklists\n- Best practices\n- Automation\n```\n\n**Failure mode:** Complacency. Treating complex problems as clear leads to oversimplification.\n\n### 2. Complicated\n\n**Characteristics:**\n- Cause and effect require expertise to see\n- Multiple right answers exist\n- Good practices (not \"best\" practices)\n- Expert analysis needed\n\n**Approach: Sense → Analyze → Respond**\n\n```\nProblem: Application performance degradation\nSense: Response times increased 3x\nAnalyze: Profile, trace, identify bottleneck (requires expertise)\nRespond: Apply appropriate fix based on analysis\n\nAppropriate method:\n- Expert analysis\n- Waterfall/planning\n- Detailed specifications\n- Engineering analysis\n- Multiple valid solutions\n```\n\n**Failure mode:** Analysis paralysis. Over-analyzing when action is needed, or treating complicated problems as if they're clear.\n\n### 3. Complex\n\n**Characteristics:**\n- Cause and effect only visible in retrospect\n- Emergent behavior\n- Cannot predict outcomes\n- Patterns emerge from interactions\n\n**Approach: Probe → Sense → Respond**\n\n```\nProblem: User engagement is declining\nProbe: Run experiments, try interventions\nSense: See what patterns emerge\nRespond: Amplify what works, dampen what doesn't\n\nAppropriate method:\n- Safe-to-fail experiments\n- Agile/iterative\n- Prototyping\n- A/B testing\n- Emergent strategy\n```\n\n**Failure mode:** Trying to analyze/plan your way through complexity. The system is too interconnected for analysis; you must probe and learn.\n\n### 4. Chaotic\n\n**Characteristics:**\n- No perceivable cause and effect\n- High turbulence\n- Need to act first to create stability\n- No time for analysis\n\n**Approach: Act → Sense → Respond**\n\n```\nProblem: Production is down, cause unknown\nAct: Take immediate action to stabilize (rollback, failover)\nSense: Once stable, assess what happened\nRespond: Move to complex/complicated domain for investigation\n\nAppropriate method:\n- Command and control\n- Decisive action\n- Rapid response\n- Crisis management\n```\n\n**Failure mode:** Trying to analyze during chaos. The priority is stability, not understanding.\n\n### 5. Disorder (Center)\n\n**Characteristics:**\n- Don't know which domain you're in\n- Multiple stakeholders perceive different domains\n- Confusion and disagreement about approach\n\n**Approach:** Break the problem into parts, classify each part\n\n```\nProblem: \"We need to fix our development process\"\nReality: Some parts are clear (coding standards)\n         Some parts are complicated (architecture decisions)\n         Some parts are complex (team dynamics)\n\nSolution: Break apart, apply appropriate approach to each\n```\n\n## Domain Assessment\n\n### Step 1: Assess Cause-Effect Relationship\n\n```markdown\n## Domain Assessment: [Problem]\n\nCan you see clear cause-effect?\n- [ ] Yes, obvious to everyone → CLEAR\n- [ ] Yes, but requires expertise → COMPLICATED\n- [ ] No, only visible after the fact → COMPLEX\n- [ ] No, completely turbulent → CHAOTIC\n- [ ] Unsure, mixed signals → DISORDER\n```\n\n### Step 2: Test Your Assessment\n\n| Domain | Test | If yes, stay | If no, reconsider |\n|--------|------|--------------|-------------------|\n| Clear | Do best practices exist and work reliably? | Clear | Maybe Complicated |\n| Complicated | Can experts predict outcomes? | Complicated | Maybe Complex |\n| Complex | Can you run safe-to-fail experiments? | Complex | Maybe Chaotic |\n| Chaotic | Is the situation too turbulent to experiment? | Chaotic | Maybe Complex |\n\n### Step 3: Match Approach\n\n```markdown\n## Approach Selection\n\nDomain: [Assessment result]\n\nAppropriate approach:\n- Decision-making style: [Best practice / Expert analysis / Experimentation / Crisis response]\n- Planning depth: [Detailed / Moderate / Minimal / None]\n- Methodology: [Process / Analysis / Agile / Command]\n- Success measure: [Efficiency / Quality / Learning / Stability]\n```\n\n## Common Mismatches\n\n### Treating Complex as Complicated\n\n```\nSymptom: Extensive planning, but outcomes keep surprising\nExample: Detailed user research, perfect spec, but users don't engage\nWhy it fails: You can't analyze your way to understanding emergent behavior\nFix: Probe with experiments, sense patterns, iterate\n```\n\n### Treating Complicated as Clear\n\n```\nSymptom: \"Just do it\" approach to expert problems\nExample: \"Build it like they did at [Company]\" without understanding why\nWhy it fails: Context matters; expertise reveals nuances\nFix: Engage experts, analyze the specific situation\n```\n\n### Treating Chaotic as Complex\n\n```\nSymptom: Running experiments during a crisis\nExample: \"Let's A/B test during the outage\"\nWhy it fails: Chaos requires immediate stability, not learning\nFix: Act decisively first, learn later\n```\n\n### Treating Clear as Complicated\n\n```\nSymptom: Over-engineering simple problems\nExample: Designing an architecture for \"Hello World\"\nWhy it fails: Wasted effort, delayed delivery\nFix: Apply best practice, don't over-analyze\n```\n\n## Domain-Appropriate Practices\n\n### For Clear Domain\n\n```markdown\n## Clear Domain Practices\n\n- Standard operating procedures\n- Checklists (like the surgical checklist)\n- Automation and scripting\n- Documentation\n- Training and certification\n- Process compliance\n\nExample applications:\n- Deployment procedures\n- Coding standards\n- Basic incident response\n- Onboarding checklists\n```\n\n### For Complicated Domain\n\n```markdown\n## Complicated Domain Practices\n\n- Expert analysis and consultation\n- Structured problem-solving\n- Architecture reviews\n- Root cause analysis\n- Design specifications\n- Scenario planning\n\nExample applications:\n- System architecture\n- Performance optimization\n- Security review\n- Technology selection\n```\n\n### For Complex Domain\n\n```markdown\n## Complex Domain Practices\n\n- Safe-to-fail experiments\n- Iterative development\n- Retrospectives\n- Emergent design\n- Short feedback loops\n- Feature flags\n\nExample applications:\n- Product development\n- Team process improvement\n- User experience design\n- Organizational change\n```\n\n### For Chaotic Domain\n\n```markdown\n## Chaotic Domain Practices\n\n- Decisive leadership\n- Clear command\n- Rapid triage\n- Communication of actions\n- Post-incident review (later)\n\nExample applications:\n- Major outages\n- Security incidents\n- Crisis response\n- Emergency triage\n```\n\n## Cynefin Template\n\n```markdown\n# Cynefin Analysis: [Problem/Situation]\n\n## Problem Statement\n[Describe the problem]\n\n## Domain Assessment\n\n### Cause-Effect Analysis\nRelationship: [Clear / Requires expertise / Retrospective / Turbulent]\nEvidence: [What makes you believe this]\n\n### Domain Classification\nDomain: [Clear / Complicated / Complex / Chaotic / Disorder]\n\n### Confidence Check\nCould this be a different domain? [Assessment]\n\n## Approach\n\nBased on [domain], the appropriate approach is:\n\n| Aspect | Approach |\n|--------|----------|\n| Decision style | [Best practice / Analysis / Experimentation / Crisis response] |\n| Planning | [Detailed / Moderate / Minimal / None] |\n| Methodology | [Process / Waterfall / Agile / Command] |\n| Success metric | [Efficiency / Quality / Learning / Stability] |\n\n## Specific Actions\nGiven the domain, I will:\n1. [Action]\n2. [Action]\n```\n\n## Verification Checklist\n\n- [ ] Assessed cause-effect relationship honestly\n- [ ] Considered if domain assessment might be wrong\n- [ ] Matched approach to domain\n- [ ] Not applying complicated solutions to clear problems\n- [ ] Not planning detailed solutions for complex problems\n- [ ] Not experimenting during chaos\n- [ ] Ready to reassess as situation evolves\n\n## Key Questions\n\n- \"What's the relationship between cause and effect here?\"\n- \"Can experts reliably predict the outcome?\"\n- \"Am I applying the right approach for this domain?\"\n- \"Is this actually complex, or am I avoiding the analysis?\"\n- \"Is this actually complicated, or am I over-planning?\"\n- \"Has the situation moved to a different domain?\"\n\n## Snowden's Wisdom\n\n\"Complex systems are not causal—they're dispositional. You can't predict what will happen; you can only influence what might happen.\"\n\n\"The only way to understand a complex system is to probe it and see how it responds.\"\n\nDifferent problems require different thinking. The failure isn't in your methodology—it's in applying the wrong methodology to the wrong domain. Match the approach to the problem, not the other way around.\n"},"import":{"commit_sha":"a31e22d4445ad8fef7cd771d32af537aebb68c49","imported_at":"2026-05-22T21:14:39Z","license_text":"MIT License\n\nCopyright (c) 2025 TJ Boudreaux\n\nPermission is hereby granted, free of charge, to any person obtaining a copy\nof this software and associated documentation files (the \"Software\"), to deal\nin the Software without restriction, including without limitation the rights\nto use, copy, modify, merge, publish, distribute, sublicense, and/or sell\ncopies of the Software, and to permit persons to whom the Software is\nfurnished to do so, subject to the following conditions:\n\nThe above copyright notice and this permission notice shall be included in all\ncopies or substantial portions of the Software.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\nIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\nFITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\nAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\nLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\nOUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE\nSOFTWARE.\n","owner":"tjboudreaux","repo":"tjboudreaux/cc-thinking-skills","source_url":"https://github.com/tjboudreaux/cc-thinking-skills/tree/a31e22d4445ad8fef7cd771d32af537aebb68c49/skills/thinking-cynefin"}},"content_hash":[244,211,175,164,204,121,113,108,60,118,191,158,65,208,210,213,213,57,43,0,230,188,86,134,152,61,102,215,68,182,196,33],"trust_level":"unsigned","yanked":false}