sw-diagnose

name	sw:diagnose
description	Analyze a change challenge through the Rider/Elephant/Path lens. Produces a diagnosis identifying where the change is stuck and why. Use when starting a new change initiative, when change has stalled, or when revisiting a prior diagnosis.
argument-hint	[describe the change challenge, or 'revise [section]' to update specific sections]

<diagnose_context> #$ARGUMENTS </diagnose_context>

Diagnose

Analyze a change challenge through the Switch framework's Rider/Elephant/Path lens. No shortcuts. The output is a change diagnosis that becomes the foundation for intervention design.

When to Use

• Starting a new change initiative
• Change is stalled and you don't know why
• Revisiting a prior diagnosis after new information
• "Why isn't this change happening?", "How do I get my team to adopt X?"
• Before running /sw:intervene, /sw:direct, /sw:motivate, or /sw:shape -- diagnosis must come first

Before Starting

Check for existing diagnosis

Search for docs/switch/current-diagnosis.md in the user's project.

If it exists: Read it in full and determine the session mode:

Mode A: Revision Mode

Triggered when the user's argument contains "revise", names a specific section (e.g., "revise rider", "update elephant"), or describes a specific reason for revisiting (e.g., "intervention results suggest the sticking point is wrong").

Present the current diagnosis summary, then confirm what's changing:

"You have an existing diagnosis from [date]. Here's what it says:

• Change: [summary]
• Sticking point: [primary] (secondary: [secondary])
• Bright spots: [count and summary]

You want to revise: [section(s)] Reason: [the triggering insight, if provided]

I'll keep the unchanged sections and walk you through the ones that need updating."

How revision mode works:

1. Load the entire current diagnosis as the working baseline
2. Jump directly to the target section(s) -- skip sections the user isn't revising
3. For the target section(s), run the full step with enforcement (same questions, same specificity requirements)
4. Check downstream propagation: After updating a section, check whether later sections still hold:

If you change...	Ask whether these still hold...
The Change (Step 1)	Bright Spots (Step 2) -- "Are these bright spots still relevant to the revised change?"
Bright Spots (Step 2)	Rider mapping (Step 3) -- "Does the Rider assessment change given these different bright spots?"
Rider mapping (Step 3)	Sticking Point (Step 6) -- "Does this change the sticking point ranking?"
Elephant mapping (Step 4)	Sticking Point (Step 6) -- "Does this change the sticking point ranking?"
Path mapping (Step 5)	Sticking Point (Step 6) -- "Does this change the sticking point ranking?"
Sticking Point (Step 6)	No downstream sections -- just update the recommended intervention sequence

5. Reassemble the diagnosis with changes and proceed to "Assembling the Diagnosis"

Revision mode does NOT skip enforcement. The revised sections get the same specificity requirements as a fresh session.

Mode B: Start Fresh

Triggered when no existing diagnosis exists, or the user explicitly says "start fresh" or "start over."

If starting fresh with an existing diagnosis, ask whether to archive:

"Should I archive the current diagnosis to docs/switch/diagnoses/[slug]-[date].md before we start?"

Then proceed to the full sequence (all 6 steps).

Mode C: Review and Sharpen (default when diagnosis exists)

When the user runs /sw:diagnose with an existing diagnosis but doesn't specify revision or fresh:

"You have an existing diagnosis from [date]. Here's what it says:

• Change: [summary]
• Sticking point: [primary]

What do you want to do?

1. Revise specific sections -- tell me which sections and why
2. Start fresh -- archive the current diagnosis and redo all 6 steps
3. Review and sharpen -- walk through all 6 steps with the current diagnosis as a starting point"

Option 3 is a guided review: present each section's current content, ask if it needs updating, only run the full step process for sections the user flags.

If it doesn't exist: Proceed directly to the full sequence (Mode B).

Check for patterns and prior work

Search docs/switch/patterns/ for pattern files and check the diagnosis for a ## Learnings section.

If learnings or patterns exist: Surface them before starting:

"Before we begin, here's what past sessions have taught us about change in your context:

• [pattern or learning summary]

Keep these in mind as we work through the diagnosis."

Accept context

If the user provided arguments (change description or revision target), acknowledge them. If not, prompt:

"What change are you trying to make? Describe the situation: who needs to change what behavior, and what's happening instead?"

The Sequence

Work through all 6 steps in order. Each step builds on the previous one. Use references/enforcement-prompts.md and references/shared-enforcement-prompts.md for redirect and warning text when users try to skip steps or give vague answers.

Important: The user may go back and revise earlier steps at any time. This is encouraged -- insights from later steps often sharpen earlier ones. Update the working diagnosis and note what changed.

---

Step 1: Define the Change Specifically

"What specifically needs to change? Not a goal -- a behavior. Who needs to do what differently? Be concrete: 'Engineering team needs to write tests before merging PRs' not 'improve code quality.'"

What you're looking for:

• A specific group of people (not "the organization")
• A specific behavior change (current behavior vs. desired behavior)
• Why it matters (the consequence of not changing)
• A time horizon (when does this need to happen?)

Enforcement triggers:

• Goal instead of behavior -> Redirect (see references/shared-enforcement-prompts.md)
• Too broad ("everyone needs to change") -> Redirect (see references/enforcement-prompts.md)
• No current behavior named -> Redirect

When this step is done: You have a specific behavior change for a specific group with a clear reason.

Use AskUserQuestion to present what you've captured and confirm:

"Here's the change I captured: [summary]. Does this feel right?"

---

Step 2: Find the Bright Spots

"Where is this change already happening? Even a little? Who's already doing the desired behavior, and what's different about their situation?"

What you're looking for:

• At least one bright spot (a person, team, or situation where the desired behavior exists)
• What's different about the bright spot context (why it works there)
• A potential replicable practice (what they do that others could adopt -- /sw:direct will later extract the full replicable practice from this)

Enforcement triggers:

• "No one is doing this" -> Redirect
• Bright spot too vague -> Redirect

When this step is done: You have a table of bright spots with what's different about each.

---

Step 3: Map the Rider (Rational Mind)

"Does the Rider know where to go? Consider: Do people know exactly what to do differently? Is the change ambiguous? Are there too many options? Do they understand why this change matters?"

Present the three Rider problems:

1. Lack of clarity -- they don't know the specific behaviors required
2. Decision paralysis -- too many options, unclear priorities
3. Analysis paralysis -- overanalyzing the problem instead of acting

What you're looking for:

• Specific evidence of Rider problems (confusion, conflicting signals, unclear instructions)
• What people say when asked about the change (reveals Rider state)
• Whether the destination is clear or fuzzy

Enforcement triggers:

• Skipping Rider analysis -> Redirect
• No evidence -> Redirect
• Confusing Rider and Elephant -> Redirect

When this step is done: You have a Rider assessment with evidence and specific problems checked.

---

Step 4: Map the Elephant (Emotional Mind)

"Does the Elephant want to move? Consider: Do people feel the need for change? Is the change emotionally overwhelming? Does the change threaten their identity?"

Present the three Elephant problems:

1. No emotional connection -- they understand rationally but don't feel it
2. Change feels too big -- overwhelmed, paralyzed by scale
3. Identity threat -- the change conflicts with who they see themselves as

What you're looking for:

• Emotional responses to the change (fear, exhaustion, indifference, defensiveness)
• Whether people see themselves as the kind of person who does the new behavior
• Whether the change feels achievable or impossible

Enforcement triggers:

• "They just don't care" -> Redirect
• Describing Rider problems as Elephant problems -> Redirect

When this step is done: You have an Elephant assessment with evidence and specific problems checked.

---

Step 5: Map the Path (Environment)

"Does the Path make it easy? Consider: Does the environment support the desired behavior or fight it? Are there habits and routines that reinforce the old behavior? What do the people around them do?"

Present the three Path problems:

1. Environment fights the change -- the default behavior is wrong, tools/processes make it hard
2. No supporting habits -- no triggers, checklists, or routines for the new behavior
3. Social pressure against -- peers aren't doing it, no visible examples, herd goes the other way

What you're looking for:

• Environmental obstacles (tools, processes, physical layout, defaults)
• Existing habits and routines that reinforce the old behavior
• Social dynamics (who's visible doing what, peer pressure, leadership modeling)

Enforcement triggers:

• Blaming people for environment problems -> Redirect

When this step is done: You have a Path assessment with evidence and specific problems checked.

---

Step 6: Diagnose the Sticking Point

"Based on what we've mapped, where is this change primarily stuck? Rank the three:"

Present a summary of Steps 3-5 and ask the user to rank:

1. Rider (clarity/direction) -- primary / secondary / not a major factor
2. Elephant (motivation/emotion) -- primary / secondary / not a major factor
3. Path (environment/habits) -- primary / secondary / not a major factor

What you're looking for:

• A primary sticking point (the biggest blocker)
• Secondary factors
• The user's reasoning for the ranking
• Connection between the sticking point and the bright spots from Step 2

Enforcement triggers:

• "All three equally" -> Redirect
• No reasoning -> Redirect

When this step is done: You have a sticking point ranking with reasoning and a recommended intervention sequence.

---

Assembling the Diagnosis

After all 6 steps are complete (or after the user has been warned about any skipped steps):

1. Read the diagnosis template from references/diagnosis-template.md
2. Fill in all sections from the session's work
3. Present the complete diagnosis to the user for review

"Here's your change diagnosis. Does the sticking point feel right? This diagnosis is what /sw:intervene will read, so it needs to be honest."

Saving

After user approval:

• Write the diagnosis to docs/switch/current-diagnosis.md
• If a previous current-diagnosis.md existed, archive it to docs/switch/diagnoses/[slug]-[date].md
• Set frontmatter fields: type, tags (extracted from the session), sticking-point, confidence (ask the user), created date, last-updated (today's date), source
• In revision mode: Add a ## Revision History section at the end (or append to an existing one):

  ## Revision History
  - [date]: Revised [section(s)]. Reason: [triggering insight]. Changes: [what changed].
  

After Saving

Use AskUserQuestion:

Question: "Diagnosis saved to docs/switch/current-diagnosis.md. What next?"

Options:

1. Run /sw:intervene -- Design interventions for all three dimensions, prioritized by the sticking point ranking (recommended)
2. Run /sw:direct -- Design Rider interventions only
3. Run /sw:motivate -- Design Elephant interventions only
4. Run /sw:shape -- Design Path interventions only
5. Run /sw:compound -- Save what you learned about this change challenge
6. Revise -- Go back and sharpen a specific section
7. Done for now -- Come back later

Important Rules

• Sequence is non-negotiable. Steps must be worked in order: define change -> bright spots -> rider -> elephant -> path -> sticking point.

• Going back is always allowed. Later steps often reveal that earlier answers need sharpening. Encourage this.

• Use the user's language. Don't sanitize messy organizational reality into management-speak. If they say "people just ignore the process," put that in the diagnosis.

• Push for specificity, not length. A diagnosis with 2 sharp bright spots and crisp evidence beats one with vague descriptions.

• Surface the reasoning. Explain why each dimension matters before asking the user to map it. The framework reasoning is motivation to push through the friction.

• The diagnosis should feel uncomfortable. If the user isn't confronting something they've been avoiding, it's probably not specific enough.

Pipeline Mode

When invoked with disable-model-invocation context:

• Skip all AskUserQuestion prompts
• Use any provided arguments as context
• Work through all 6 steps using available information
• Make reasonable assumptions, flag them in the diagnosis
• Write output files without waiting for confirmation