Frame-Problem to Experiment Handoff

Thinking Trail

• Considered: {what approaches were weighed during framing}
• Rejected: {why structured domains didn’t fit — constraints are absent}
• Surprised by: {chaos signals — urgency, incoherence, novel disruption}
• Triangulation: T1={Keogh level}, T2={predictability}, T3={disassembly} — {convergence}
• Models used: Cynefin triangulation (Keogh + Predictability + Disassembly)
• Constraints discovered: None — that’s the point. Constraints are absent.

Decisions

1. Domain: Chaotic (absent constraints — crisis or deliberate disruption)
2. Route: experiment → stabilize → frame-problem
3. Rationale: {no analysis possible — must act first to impose minimal structure}

Actions Taken

• Classified via Q1: absent constraints identified
• Scale: not applicable (Chaotic bypasses scale assessment)

Output

🎯 Chaotic → Act → /experiment → stabilize → /frame-problem | OpenSpec: no

Domain Transition

From: Confused → To: Chaotic Constraint shift: unknown → absent. No cause-effect relationships visible. Must act to impose minimal constraints before any analysis is possible.

For /experiment

• Chaos type assessment: Determine accidental (crisis — something broke) vs deliberate (innovation — intentionally disrupting)
• Initial action: {first safe action to impose minimal structure}
• Gate requirement: Human gates after EVERY action — human IS the constraint
• Exit watch: Look for emerging structure → transition to probe when patterns appear
• Do NOT: Attempt analysis or planning — act first, sense second

Accumulated Context

Token guidance: target 300 tokens inline. For depth, use references — point to thinking artifact files rather than embedding full content. Soft cap: 600 tokens inline per handoff. If you need more, move detail to a knowledge file and reference it. Accumulated cap: 800 tokens across a chain — compress to 200 at cap (keep: decisions, constraints, rejected paths). References to thinking files do NOT count toward the cap.

Frame-Problem to Investigate Handoff

Thinking Trail

• Considered: {what approaches were weighed during framing}
• Rejected: {why complex/chaotic didn’t fit — governing constraints exist}
• Surprised by: {signals that this is evolving, not degraded}
• Triangulation: T1={Keogh level}, T2={predictability}, T3={disassembly} — {convergence}
• Models used: Cynefin triangulation (Keogh + Predictability + Disassembly)
• Constraints discovered: {governing constraints — experts/best practices apply, system evolving}

Decisions

1. Domain: Complicated (governing constraints, evolving system)
2. Route: investigate → openspec-plan
3. Rationale: {expertise can solve this — needs deep analysis, not experimentation}

Actions Taken

• Classified via Q1: governing constraints identified
• Q1.1: evolving (capacity growing, system improving)
• Scale determined: {boulder|pebble}

Output

🎯 Complicated → Analyze → /investigate → /openspec-plan | OpenSpec: {yes if boulder} | Scale: {scale}

Domain Transition

From: Confused → To: Complicated Constraint shift: unknown → governing. Best practices exist, experts can solve this. System is evolving — growing capacity, not failing.

For /investigate

• Problem focus: {specific technical question to investigate}
• Known constraints: {governing constraints — what rules/patterns apply}
• Expertise needed: {what domain knowledge is relevant}
• Expected output: Analysis + recommendation → feeds openspec-plan if boulder
• Do NOT: Experiment — this domain has known good practices. Analyze, don’t probe.

Accumulated Context

Token guidance: target 300 tokens inline. For depth, use references — point to thinking artifact files rather than embedding full content. Soft cap: 600 tokens inline per handoff. If you need more, move detail to a knowledge file and reference it. Accumulated cap: 800 tokens across a chain — compress to 200 at cap (keep: decisions, constraints, rejected paths). References to thinking files do NOT count toward the cap.

Frame-Problem to Probe (Liminal) Handoff

Thinking Trail

• Considered: {what approaches were weighed during framing}
• Rejected: {why pure Complicated or pure Complex didn’t fit}
• Triangulation: T1={result}, T2={result}, T3={result} — {which disagreed and why}
• Liminal signal: {specific test that pointed to adjacent domain}
• Models used: Cynefin triangulation (Keogh + Predictability + Disassembly)
• Constraints discovered: {mix of governing + enabling constraints}

Decisions

1. Domain: Liminal Complicated↔Complex (boundary state)
2. Route: probe first (resolve boundary) → re-frame with evidence
3. Rationale: {can’t tell if expertise applies or experimentation needed — probe to find out}

Actions Taken

• Triangulated: 2/3 tests or split signal detected
• Liminal state identified — not forcing a binary classification
• Scale determined: {boulder|pebble}

Output

🎯 Liminal Comp↔Complex → Probe → resolve boundary → /frame-problem | OpenSpec: deferred | Scale: {scale}

Domain Transition

From: Confused → To: Liminal Complicated↔Complex Constraint shift: unknown → mixed governing/enabling. Cannot yet determine if expertise resolves this or experimentation is needed.

For /probe

• Hypothesis: “This problem is analyzable by expertise” (probe to confirm or refute)
• Enabling constraints: {what bounds this probe}
• Confirm criteria: Expert analysis produces consistent, actionable recommendations → Complicated, route to investigate
• Refute criteria: Expert analysis produces contradictory or untestable recommendations → Complex, route to brainstorm or probe
• Do NOT: Skip Phase 1 entry gate. This probe resolves the domain boundary, not the problem itself.

Accumulated Context

Token guidance: target 300 tokens inline. For depth, use references — point to thinking artifact files rather than embedding full content. Soft cap: 600 tokens inline per handoff. If you need more, move detail to a knowledge file and reference it. Accumulated cap: 800 tokens across a chain — compress to 200 at cap (keep: decisions, constraints, rejected paths). References to thinking files do NOT count toward the cap.

Frame-Problem to Probe Handoff

Thinking Trail

• Considered: {what approaches were weighed during framing}
• Rejected: {why other domains didn’t fit}
• Surprised by: {unexpected signals}
• Triangulation: T1={Keogh level}, T2={predictability}, T3={disassembly} — {convergence}
• Models used: Cynefin triangulation (Keogh + Predictability + Disassembly)
• Constraints discovered: {enabling constraints — cause-effect unclear but hypothesis exists}

Decisions

1. Domain: Complex (enabling constraints, user has hypothesis)
2. Route: probe → sense → openspec-plan
3. Rationale: {hypothesis already exists — skip brainstorm, go direct to probe}

Actions Taken

• Classified via Q1: enabling constraints identified
• Hypothesis detected in $ARGUMENTS
• Scale determined: {boulder|pebble}

Output

🎯 Complex → Probe → /probe → /openspec-plan | OpenSpec: yes | Scale: {scale}

Domain Transition

From: Confused → To: Complex Constraint shift: unknown → enabling. User has a hypothesis ready to test — direct probe without divergent brainstorm.

For /probe

• Hypothesis: {extracted or user-stated hypothesis}
• Enabling constraints: {what bounds this probe — codebase scope, time, tooling}
• Suggested confirm/refute criteria: {what would confirm or refute the hypothesis}
• Prior exploration: None (first probe) or {summary of brainstorm output if chained}
• Do NOT: Skip Phase 1 entry gate — qualify even if hypothesis looks complete

Accumulated Context

Token guidance: target 300 tokens inline. For depth, use references — point to thinking artifact files rather than embedding full content. Soft cap: 600 tokens inline per handoff. If you need more, move detail to a knowledge file and reference it. Accumulated cap: 800 tokens across a chain — compress to 200 at cap (keep: decisions, constraints, rejected paths). References to thinking files do NOT count toward the cap.

Frame-Problem to Troubleshoot Handoff

Thinking Trail

• Considered: {what approaches were weighed during framing}
• Rejected: {why complex/chaotic didn’t fit — governing constraints exist}
• Surprised by: {degradation signals — errors, declining quality}
• Triangulation: T1={Keogh level}, T2={predictability}, T3={disassembly} — {convergence}
• Models used: Cynefin triangulation (Keogh + Predictability + Disassembly)
• Constraints discovered: {governing constraints — known system, degrading behavior}

Decisions

1. Domain: Complicated (governing constraints, degraded system)
2. Route: troubleshoot → stabilize → re-frame
3. Rationale: {system was working, now failing — diagnostic expertise applies}

Actions Taken

• Classified via Q1: governing constraints identified
• Q1.1: degraded (quality declining, system failing)
• Scale determined: {boulder|pebble}

Output

🎯 Complicated → Analyze → /troubleshoot → stabilize → re-frame | OpenSpec: no | Scale: {scale}

Domain Transition

From: Confused → To: Complicated Constraint shift: unknown → governing. System has known good state — it’s degrading from that state. Diagnostic expertise applies.

For /troubleshoot

• Symptom: {what’s broken or degrading}
• Known good state: {what it looked like when working}
• Recent changes: {what changed before degradation started}
• Diagnostic approach: Search-first — check learnings database, then systematic diagnosis
• Do NOT: Redesign — stabilize first, then re-frame if deeper changes needed

Accumulated Context

Token guidance: target 300 tokens inline. For depth, use references — point to thinking artifact files rather than embedding full content. Soft cap: 600 tokens inline per handoff. If you need more, move detail to a knowledge file and reference it. Accumulated cap: 800 tokens across a chain — compress to 200 at cap (keep: decisions, constraints, rejected paths). References to thinking files do NOT count toward the cap.

Triangulation Tests

Exact wording for Step 1 of the skill. Ask every applicable question in one AskUserQuestion call. Never ask the user to pick a Cynefin domain or a constraint type: people misclassify their own situation, so ask what they can observe and derive the domain yourself.

T1: “Who’s done this before?” (Keogh scale)

T1 measures whether expertise exists. It says nothing about whether the outcome is predictable, so it must never decide alone.

T2: “Same inputs, same result?” (predictability)

T3: “Can you take it apart?” (disassembly)

Q-Scale (skip when T2 is Chaotic)

• Boulder: multi-step, ambiguous or architectural.
• Pebble: a single file with an obvious implementation.
• Not sure: treat as a boulder until decomposition says otherwise.

Q-Complicated sub (only when T1=2 and T2=ordered)

• Evolving: the system is improving or growing capacity. Route to investigate.
• Degraded: it was working and is now failing. Route to troubleshoot.
• Both: improving on one dimension and degrading on another. Route to investigate with a troubleshoot sub-task.

Reading the answers

Misclassification traps

• Expertise bias. An engineer answers T1=2 and T2=ordered while T3 is entangled. The honest reading is Complex, not Complicated, because the expertise covers the parts and not the interactions.
• Overwhelm. A stressed team answers T2=chaotic when the situation is Complex with enabling constraints available. Slow down and decompose before routing to experiment.
• Contradiction. “Nobody has done this” together with “the result is predictable” cannot both be true. The parts sit in different domains, so decompose.
• Solution-shaped answers. If the user describes the problem as a missing technology (“we need Kafka”), restate it as a need before asking T1 to T3, or the tests measure the solution instead of the problem.

Worked Examples

Three end-to-end framings. Each shows the signal that drove the classification, the check that guarded against a wrong route, and the handoff template used.

1. Degraded service: auto-classify, challenge, route

Input: “Our API endpoint /v2/payments has been returning 500 errors since the deploy at 14:30. It was working fine this morning.”

1. The phrase “was working, now failing” with a time-bound trigger is explicit Degraded language. Confidence is above 80%, so Step 0 proposes Complicated, Degraded.
2. Adjacent Domain Challenge: could this be Complex, with an unpredictable failure mode? No. The system is known, the inputs are repeatable and the regression follows a deploy, so cause and effect are discoverable by analysis.
3. Route: troubleshoot → stabilise → re-frame, OpenSpec No. Fill frame-problem-to-troubleshoot-llm.md, then confirm.

Wrong turns to avoid: routing to brainstorm because the cause is unknown (an unknown cause is not an unknowable one), or classifying Complex because the word “errors” sounds alarming.

2. Solution-shaped request with expertise bias

Input: “We need a microservice for notifications. We have built three of these.”

1. Restate the problem first: “Notifications are coupled to the order flow and block releases” is a need; “a microservice” is a solution. Ask the user to confirm the restatement.
2. Triangulate. T1=2 (the team has built these), T2=unordered (delivery behaviour varies heavily by customer segment), T3=entangled (preferences, channels and rate limits depend on each other).
3. Two of three tests say Complex. T1 alone cannot override them, so the verdict is Complex with a liminal note that some governing constraints exist.
4. No hypothesis exists yet, so route brainstorm → probe → openspec-plan, OpenSpec Yes. Fill frame-problem-to-brainstorm-llm.md.

Wrong turn to avoid: accepting Complicated because “we have done this three times”. Three prior builds prove that expertise exists, not that this build is predictable.

3. Composite request

Input: “Improve developer experience, cut CI build times, fix auth service tech debt, and maybe move database.”

1. Auto-classification confidence is low and the scope is broad. Write 2-3 clarifying sub-questions (“Which developers? What is the current build time and the target? What is driving the database question?”) and ask them with T1 to T3 and Q-Scale in one call.
2. The answers disagree across the parts, so decompose:

🧩 Composite problem, sub-parts in different domains:
├── Database move: Complex, no hypothesis → brainstorm → probe → openspec-plan
├── Developer experience: Complex, enabling constraints → probe
├── CI build times: Complicated, Degraded → troubleshoot
└── Auth tech debt: Complicated, Evolving → investigate
Proposed sequence: nothing blocks anything else, so Complex parts first

3. Confirm the decomposition with the user before routing, then invoke the first skill with the first sub-problem only.

Sequencing rule: a blocker goes first (for example a failing build that stops all other work), otherwise the Complex parts go first because probes take longest to return signal.