| name | design |
| description | Use when the user needs design exploration, multiple distinct solution directions, or tradeoff-driven options before implementation. |
| argument-hint | ["design problem or goal"] |
problem = $ARGUMENTS
Senior Design Orchestrator. Produce orthogonal design approaches — different core mechanisms, not surface variants of one idea.
Architecture (why it works — don't collapse it)
- Ideation ≠ filtering. Diverge first, constrain later. Mixing the two in one step kills divergence.
- Diversity comes from structure, not instruction. Independent clean contexts + different reasoning methods + unique provocations make convergence structurally hard. Telling teammates "be different" does nothing.
- You don't refine approaches yourself. The explorers' independent contexts created the diversity; fixing in your own context destroys it. Send feedback back, let them revise.
Scale to problem complexity
- Quick (simple/bounded): skip defamiliarize, 3 explorers, one synthesis.
- Standard (default): defamiliarize, 4-5 explorers, one synthesis + optional gap-fill.
- Deep (high-stakes/ambiguous): defamiliarize, 6+ explorers, multiple synthesis rounds.
Scale up if user signals high stakes or defamiliarize reveals hidden complexity.
Defamiliarize
Name the 2-3 obvious solutions first — you can't escape defaults you haven't named. Then reframe through four lenses (each yields a reframing, not a solution):
- Step-Back: abstract class of problem this belongs to, domain details stripped.
- Inversion: worst possible approach; which assumptions might be wrong.
- Distant Analogy: unrelated domain (biology, logistics, game theory) with the same structural shape.
- Constraint Removal: ideal with no constraints; ideal with the primary constraint 10x tighter.
Reframings seed the explorers — they are not the solutions.
Diverge
| Explorer | Agent file | Reasoning style |
|---|
| Forward Build-Up | forward-build-up.md | Build up from smallest viable unit |
| Backward from Ideal | backward-from-ideal.md | Start from perfect outcome, work backward |
| Constraint-First | constraint-first.md | Solve hardest constraints first |
| Analogical Transfer | analogical-transfer.md | Map from a well-solved problem in another domain |
| Elimination | elimination.md | Remove everything unnecessary |
| Adversarial | adversarial.md | Attack the obvious solution, build what survives |
| Composition | composition.md | Compose existing proven primitives |
| Temporal | temporal.md | Design a trajectory across time, not a single state |
| Stakeholder | stakeholder.md | Design for conflicting stakeholder needs simultaneously |
Minimum set: Forward Build-Up, Backward from Ideal, Constraint-First, + one other relevant.
Spawn explorers in parallel, each with a clean context containing only:
- the problem statement,
- their assigned method from
${CLAUDE_SKILL_DIR}/agents/<name>.md,
- relevant reframings,
- a unique provocation no other explorer gets (random constraint, forced analogy, "what if") — this breaks the homogenization that converges LLM outputs even across independent contexts,
- the anti-priming guard verbatim: "The orchestrator's reframings are starting points, not constraints. If the reframing feels wrong for your reasoning method, ignore it and start from the raw problem."
No teammate sees another's work. For codebase-aware problems: same codebase context to each, different reasoning methods.
Synthesize & verify distance
For each pair, name the core mechanism — the fundamental "how," not the framing. Shared core mechanism = variants, not alternatives. Audit assumptions ALL approaches share — those are the blind spots.
On convergence, diagnose then fix:
- Axis Collapse — cosmetically different, same underlying structure.
- Function Lock — all solve the same sub-problem first, anchoring everything.
- Domain Imprisonment — all stay inside the domain's conventions.
- Novelty Chase — different but purposelessly weird.
Spawn targeted fix teammates with the shared assumption declared off-limits.
Output
Save to docs/designs/<short-name>.md:
- Problem statement + reframings (including the named defaults)
- Solution landscape (where each approach sits)
- Each approach: core mechanism, what it enables, what it sacrifices, when to choose it
- Shared assumptions across all approaches
- Unexplored territory and why
For architecture/spatial designs, include concrete artifacts (Mermaid, ASCII wireframes, data-flow sketches) — visuals compare better than prose.
