Cynefin Classifier

Classify problems into the correct Cynefin domain and recommend the appropriate response strategy. This prevents applying the wrong cognitive approach to problems.

Triggers

Activate when the user:

• "classify this problem"
• "cynefin analysis"
• "which domain is this"
• "what approach should we take"
• "how should we tackle this"
• "problem classification"
• "should we analyze or experiment"
• "is this complex or complicated"

The Cynefin Framework

                    UNORDERED                          ORDERED
              ┌─────────────────────────────────┬─────────────────────────────────┐
              │         COMPLEX                 │        COMPLICATED              │
              │                                 │                                 │
              │  Cause-effect visible only      │  Cause-effect discoverable      │
              │  in retrospect                  │  through expert analysis        │
              │                                 │                                 │
              │  Response: PROBE-SENSE-RESPOND  │  Response: SENSE-ANALYZE-RESPOND│
              │  • Safe-to-fail experiments     │  • Expert consultation          │
 NOVEL        │  • Emergent practice            │  • Root cause analysis          │   KNOWN
              │  • Amplify what works           │  • Good practice                │
              ├─────────────────────────────────┼─────────────────────────────────┤
              │         CHAOTIC                 │          CLEAR                  │
              │                                 │                                 │
              │  No discernible cause-effect    │  Cause-effect obvious to all    │
              │  No time for analysis           │                                 │
              │                                 │  Response: SENSE-CATEGORIZE-    │
              │  Response: ACT-SENSE-RESPOND    │           RESPOND               │
              │  • Stabilize first              │  • Apply best practice          │
              │  • Novel practice               │  • Follow procedures            │
              │  • Then move to complex         │  • Standardize                  │
              └─────────────────────────────────┴─────────────────────────────────┘

                                    CONFUSION (center)
                              Domain unknown - gather information

Classification Process

Step 1: Identify Cause-Effect Relationship

Ask: "Can we predict the outcome of an action?"

If...	Then Domain is Likely...
Anyone can predict outcome	Clear
Experts can predict outcome	Complicated
Outcome only knowable after action	Complex
No one can predict, crisis mode	Chaotic
Insufficient information to determine	Confusion

Step 2: Check Temporal State

Problems can move between domains:

• Crisis → Stabilization: Chaotic → Complex (after immediate action)
• Learning → Optimization: Complex → Complicated (after patterns emerge)
• Maturity → Commoditization: Complicated → Clear (after expertise codified)
• Disruption → Uncertainty: Clear → Complex/Chaotic (black swan event)

Step 3: Validate with Diagnostic Questions

Clear Domain Indicators:

• Is there a documented procedure?
• Would a junior developer handle this the same way?
• Is this a "solved problem"?

Complicated Domain Indicators:

• Do we need an expert to analyze this?
• Are there multiple valid approaches requiring evaluation?
• Can we predict the outcome with sufficient analysis?

Complex Domain Indicators:

• Are multiple independent variables interacting?
• Has similar analysis failed to predict outcomes before?
• Do we need to "try and see"?

Chaotic Domain Indicators:

• Is there immediate harm occurring?
• Do we lack time for any analysis?
• Is the situation unprecedented?

Output Format

## Cynefin Classification

**Problem**: [Restate the problem concisely]

### Domain: [CLEAR | COMPLICATED | COMPLEX | CHAOTIC | CONFUSION]

**Confidence**: [HIGH | MEDIUM | LOW]

### Rationale

[2-3 sentences explaining why this domain based on cause-effect relationship]

### Response Strategy

**Approach**: [Sense-Categorize-Respond | Sense-Analyze-Respond | Probe-Sense-Respond | Act-Sense-Respond | Gather Information]

### Recommended Actions

1. [First specific action]
2. [Second specific action]
3. [Third specific action]

### Pitfall Warning

[Domain-specific anti-pattern to avoid]

### Related Considerations

- **Temporal**: [Will domain likely shift? When?]
- **Boundary**: [Is this near a domain boundary?]
- **Compound**: [Are sub-problems in different domains?]

Domain-Specific Guidance

Clear Domain

When you see it: Bug with known fix, style violation, typo, standard CRUD operation.

Response: Apply best practice immediately. Don't over-engineer.

Pitfall: Over-complicating simple problems. Creating abstractions where none needed.

Software Examples:

• Fixing a null reference with documented pattern
• Adding a missing import
• Correcting a typo in documentation
• Following established coding standards

Complicated Domain

When you see it: Performance issue, security vulnerability assessment, architecture evaluation.

Response: Gather experts, analyze thoroughly, then act decisively.

Pitfall: Analysis paralysis OR acting without sufficient expertise.

Software Examples:

• Debugging a memory leak
• Evaluating database schema design
• Security audit of authentication flow
• Choosing between well-documented frameworks with clear trade-offs

Complex Domain

When you see it: User behavior prediction, team dynamics, new technology adoption, architectural decisions with uncertainty.

Response: Run safe-to-fail experiments. Probe, sense patterns, respond. Amplify what works.

Pitfall: Trying to fully analyze before acting. Expecting predictable outcomes.

Software Examples:

• Deciding microservices vs monolith for new product
• Predicting which features users will adopt
• Evaluating emerging frameworks with limited production data
• Team restructuring impacts on productivity
• A/B testing user experience changes

Chaotic Domain

When you see it: Production outage, data breach, critical security incident.

Response: Act immediately to stabilize. Restore order first. Analyze later.

Pitfall: Forming committees. Waiting for consensus. Deep analysis during crisis.

Software Examples:

• Database corruption with active users
• Active security breach
• Complete service outage
• Cascading infrastructure failure

Confusion Domain

When you see it: Insufficient information to classify. Contradictory signals. Unknown unknowns.

Response: Gather information. Break problem into smaller pieces. Reclassify components.

Pitfall: Assuming a domain without evidence. Paralysis from uncertainty.

Software Examples:

• Vague requirement that could be simple or complex
• Bug report without reproduction steps
• Performance issue without metrics
• "System is slow" without specifics

Integration with Other Skills

Skill	Integration Point
decision-critic	After classifying as Complicated, use decision-critic to validate analysis
planner	After classifying as Complex, use planner to design experiments
architect	Complicated architectural decisions benefit from ADR process
analyst	Confusion domain benefits from analyst investigation

Compound Problems

When a problem spans multiple domains:

1. Decompose the problem into sub-problems
2. Classify each sub-problem independently
3. Sequence work by domain priority:
   • Chaotic first (stabilize)
   • Clear next (quick wins)
   • Complicated then (expert analysis)
   • Complex last (experiments need stable foundation)

Scripts

classify.py

Structured classification with validation.

python3 .claude/skills/cynefin-classifier/scripts/classify.py \
  --problem "Description of the problem" \
  --context "Additional context about constraints, environment"

Exit Codes:

• 0: Classification complete
• 1: Invalid arguments
• 2: Insufficient information (Confusion domain)

Escalation Criteria

Escalate to human or senior decision-maker when:

• Confidence is LOW
• Problem is on domain boundary
• Stakes are high (production, security, data)
• Classification contradicts team consensus
• Chaotic domain with no runbook

Examples

Example 1: CI Test Failures

Input: "Tests pass locally but fail randomly in CI"

Classification: COMPLEX

Rationale: Multiple interacting factors (timing, environment, dependencies, parallelism) make cause-effect unclear. Analysis alone won't solve this.

Strategy: Probe-Sense-Respond

1. Add instrumentation to failing tests
2. Run experiments with different configurations
3. Look for patterns, amplify what works

Pitfall: Don't spend weeks trying to "root cause" before experimenting.

Example 2: Production Database Down

Input: "Production database is unresponsive, customers cannot access the site"

Classification: CHAOTIC

Rationale: Active harm occurring. No time for analysis. Stabilization required.

Strategy: Act-Sense-Respond

1. Execute failover runbook immediately
2. Restore service using backup/replica
3. Only after stable: investigate root cause

Pitfall: Don't form a committee. Don't start analyzing before acting.

Example 3: Framework Choice

Input: "Should we use React or Vue for our new frontend?"

Classification: COMPLEX

Rationale: Team dynamics, learning curves, ecosystem fit, and long-term maintainability only emerge through experience. Trade-off analysis alone is insufficient.

Strategy: Probe-Sense-Respond

1. Build small prototype with each (timeboxed)
2. Measure team velocity and satisfaction
3. Let experience inform decision

Pitfall: Don't try to "perfectly analyze" all trade-offs in spreadsheet.

Example 4: Memory Leak

Input: "Application memory grows steadily over 24 hours"

Classification: COMPLICATED

Rationale: Cause-effect is discoverable through expert analysis. Heap dumps, profiling, and code review will reveal the source.

Strategy: Sense-Analyze-Respond

1. Collect heap dumps at intervals
2. Analyze object retention with profiler
3. Expert review of suspected areas

Pitfall: Don't guess and patch. Systematic analysis will find root cause.

Example 5: Vague Bug Report

Input: "The app feels slow sometimes"

Classification: CONFUSION

Rationale: Insufficient information to determine domain. Could be Clear (known fix), Complicated (needs profiling), or Complex (user perception).

Strategy: Gather Information

1. What operations feel slow?
2. What device/network conditions?
3. Can it be reproduced?
4. What does "slow" mean (seconds? milliseconds?)

Next Step: Reclassify once information gathered.

References

• Cynefin Framework - Dave Snowden's original framework
• Domain Transitions - How problems move between domains
• Software Engineering Applications - Domain patterns in software

Anti-Patterns

Anti-Pattern	Description	Consequence
Complicated-izing Complexity	Applying analysis to emergent problems	Analysis paralysis, wasted effort
Simplifying Complicated	Skipping expert analysis for nuanced problems	Rework, technical debt
Analyzing Chaos	Forming committees during crisis	Prolonged outage, increased damage
Experimenting on Clear	Running A/B tests on solved problems	Wasted time, unnecessary risk
Guessing Confusion	Assuming domain without evidence	Wrong approach, compounded problems