decompose

Decompose

Break a multi-faceted problem into focused brainstorm sessions that can each go through the full GROUND → SHIP flow independently.

When to Use

• Problem has 3+ independent dimensions (e.g., "redesign auth AND migrate DB AND change API")
• Explore phase surfaces options that don't compare — apples to oranges
• User keeps context-switching between unrelated concerns
• Stress-test reveals the "decision" is actually multiple bundled decisions

Flow

1. Identify Dimensions

List the distinct sub-problems. Each should be independently brainstormable:

Sub-sessions identified:
1. [Problem A] — [core tension in 1 sentence]
2. [Problem B] — [core tension in 1 sentence]
3. [Problem C] — [core tension in 1 sentence]

2. Find Dependencies

Which sub-problems depend on decisions from others?

Dependencies:
- Problem B depends on Problem A (schema choice affects migration)
- Problem C is independent

3. Recommend Order

Recommended order:
1. Problem A (others depend on it)
2. Problem C (independent — can run in parallel)
3. Problem B (blocked by A)

4. Focus Current Session

Ask the user which sub-problem to tackle first. Continue the current session on that one only. Other sub-problems are parked — not forgotten, just deferred.

5. Reference Prior Decisions

In later sessions, reference prior session outputs from context/exports/ for decisions that carry forward. This is how sub-sessions compose into a coherent whole.

Response Style

Concise. Present the decomposition as a structured list, not a wall of text. Let the user react and choose.

Anti-Pattern

Don't decompose problems that are genuinely coupled. If changing one dimension necessarily changes the others, it's one problem — not three. Ask: "Can I decide A without knowing B?" If not, they stay together.