parallel-design-exploration

---
name: parallel-design-exploration
description: "Spawn 3+ sub-agents in parallel to explore radically different designs for the same problem. Use when 'design this twice', 'explore alternative interfaces', 'compare architectures', 'try multiple approaches in parallel', '/atlas design-twice', or before locking a non-obvious architectural decision. Distinct from subagent-dispatch (which parallelizes INDEPENDENT tasks) — this skill produces N alternatives for the SAME task."
mode: [engineering]
effort: medium
version: 1.0.0
tier: [dev]
attribution: "Authored 2026-05-03. Pattern derived from John Ousterhout 'Design It Twice' (A Philosophy of Software Design) and from Matt Pocock's improve-codebase-architecture/INTERFACE-DESIGN.md (mattpocock/skills MIT). Generalized into a reusable atlas skill so any module facing an architectural decision can invoke it, not just deepening candidates."
see_also: [improve-codebase-architecture, plan-builder, brainstorming, subagent-dispatch, execution-strategy, decision-log]
thinking_mode: adaptive
references:
  - references/agent-brief-template.md
---

# Parallel Design Exploration

> Your first design is unlikely to be the best. — *Ousterhout, "Design It Twice"*

Spawn 3+ sub-agents in parallel, each constrained to produce a **radically different** design for the same problem. Compare in prose. Recommend one (or a hybrid). Be opinionated.

## Distinction from sibling skills

| Skill | Concern | Output |
|---|---|---|
| `subagent-dispatch` | Run N **independent** tasks in parallel for speed | N **completed** tasks (different problems) |
| `execution-strategy` | Decide which tasks should be parallel + cost analysis | Execution Manifest (no agents spawned yet) |
| **`parallel-design-exploration`** (this skill) | Explore N **alternatives** for the **same** problem | N **proposals**, comparison + recommendation |

This skill is invoked when the task itself is *not yet decided*. It's a design tool, not an execution tool.

## When to invoke

### Manual triggers
- "design this twice", "design it three ways"
- "explore alternative interfaces"
- "compare architectures for X"
- "try N approaches in parallel"
- `/atlas design-twice`
- Inside `improve-codebase-architecture` Step 3 (grilling loop, INTERFACE-DESIGN.md flow)
- Inside `plan-builder` Section B (Architecture) when the chosen approach is non-obvious

### Automatic triggers (agent self-detection)
- The user is locked between 2+ approaches and is asking the agent to choose
- A plan's Section B has only one alternative listed but the decision is reversibly load-bearing (later phases depend on it)
- The agent is about to commit to an interface design but recognizes "this is my first idea — I should design it twice"

### When NOT to invoke
- The decision is reversible AND cheap to undo (just pick one and ship)
- The decision is well-precedented in the codebase (existing pattern is fine, don't re-litigate)
- The user has already declared a preference (don't second-guess them — invoke `decision-log` to record it instead)

## Process

### 1. Frame the problem space

Before spawning sub-agents, write a single user-facing explanation of the problem space:

- What is the **module** or **system** being designed? Use [improve-codebase-architecture/LANGUAGE.md](../improve-codebase-architecture/LANGUAGE.md) vocabulary if applicable.
- What constraints must any design satisfy? (functional + non-functional)
- What dependencies will it rely on? Categorize per [DEEPENING.md](../improve-codebase-architecture/DEEPENING.md): pure / I/O at a seam / cross-seam.
- A rough illustrative code sketch to ground the constraints — NOT a proposal, just to make the problem concrete.

Show this to the user. Then **immediately** proceed to Step 2 — the user reads while sub-agents work in parallel.

### 2. Spawn sub-agents (parallel, single message)

Spawn 3-4 sub-agents using the `Agent` tool, **all in a single message** (otherwise they execute sequentially and you lose the speedup).

Each sub-agent gets a **separate technical brief** + a **different design constraint**:

| Agent | Constraint | Asks |
|---|---|---|
| **Agent 1: Minimal** | "Minimize the interface — aim for 1–3 entry points max. Maximise leverage per entry point." | What is the smallest interface that still does the job? |
| **Agent 2: Flexible** | "Maximise flexibility — support many use cases and extension." | What interface accommodates the broadest set of callers? |
| **Agent 3: Default-case-trivial** | "Optimise for the most common caller — make the default case trivial, edge cases verbose." | What does the 80% caller want, and what would make their code one line? |
| **Agent 4 (optional): Ports & Adapters** | "Design around ports & adapters for cross-seam dependencies (DB, network, time, randomness)." | Where do the seams go? What's the test posture? |

The brief MUST include:
- Existing file paths + coupling details (where the module fits today, who calls it, what it depends on)
- Domain glossary vocabulary (CLAUDE.md / CONTEXT.md / `.blueprint/PRD-*.md` glossary)
- Architecture vocabulary (LANGUAGE.md: Module / Interface / Implementation / Depth / Seam / Adapter / Leverage / Locality)
- Plan SSoT reference if this design fits within a plan: `.blueprint/plans/<plan>.md`

See [references/agent-brief-template.md](references/agent-brief-template.md) for the briefing template.

Each sub-agent outputs:

1. **Interface** — types, methods, params + invariants, ordering, error modes (the full surface a caller must learn)
2. **Usage example** — show how callers use it; include the most common case
3. **Implementation hidden behind the seam** — what the module owns
4. **Dependency strategy and adapters** — pure / seam / cross-seam (per DEEPENING.md)
5. **Trade-offs** — where leverage is high, where it's thin, what constraint this design fails to handle

### 3. Present and compare

Present designs **sequentially** (Design 1, Design 2, Design 3) so the user can absorb each one before the comparison.

Then compare in prose, contrasting on these axes:

| Axis | Question |
|---|---|
| **Depth** | Which design has the highest leverage at the interface? |
| **Locality** | Which design concentrates change/bugs/knowledge most tightly? |
| **Seam placement** | Where does the seam live in each? Which placement is most stable? |
| **Test posture** | What does each design's test surface look like? Which is easiest to test through the interface (no mocking past it)? |
| **Caller cost** | What does the 80% caller write in each? |
| **Failure modes** | What caller mistakes does each design make impossible vs possible? |

After comparing, give your **own recommendation**: which design is strongest and why. If elements from different designs combine well, propose a **hybrid** — name it explicitly and describe the splice. Be opinionated. The user wants a strong read, not a menu.

### 4. (Optional) Record the decision

If the user picks one and the rationale is load-bearing (would bother future Claude/explorer if not preserved), invoke `decision-log` skill to record the ADR. Frame it: "Want me to record this as an ADR so future architecture reviews don't re-suggest the alternatives?" Skip ephemeral reasons.

## Output format

```markdown
# Parallel Design Exploration: <module name>

## Problem space
<1-2 paragraphs: what's being designed, constraints, dependencies>

## Code sketch (constraint anchor — NOT a proposal)
<illustrative pseudocode>

## Design 1 — Minimal interface
- Interface: ...
- Usage: ...
- Trade-offs: ...

## Design 2 — Flexible
- Interface: ...
- Usage: ...
- Trade-offs: ...

## Design 3 — Default-case-trivial
- Interface: ...
- Usage: ...
- Trade-offs: ...

## Comparison
| Axis | Design 1 | Design 2 | Design 3 |
|---|---|---|---|
| Depth | ... | ... | ... |
| Locality | ... | ... | ... |
| Seam placement | ... | ... | ... |

## Recommendation
**<chosen design>** because <rationale>. <hybrid notes if applicable>.

## Decision log entry (if accepted)
<via decision-log skill>
```

## Atlas integration patterns

### Pattern A: invoked from `improve-codebase-architecture`

When the user picks a deepening candidate from improve-codebase-architecture Step 2, INTERFACE-DESIGN.md tells the agent to spawn parallel design sub-agents. That flow IS this skill — improve-codebase-architecture's INTERFACE-DESIGN.md is a thin wrapper. When invoked from there, just follow the 4-step process above.

### Pattern B: invoked from `plan-builder` Section B (Architecture)

When a plan's Section B has multiple viable architectures, plan-builder invokes this skill to materialize each as a sub-agent design proposal. Output: 3 sketched architectures with comparison, fed back into Section B.

### Pattern C: invoked manually mid-conversation

User says "design this three ways" or recognizes design-twice as the right move. Run the full 4-step process inline.

## Sibling skills (cross-reference)

- `improve-codebase-architecture` — primary caller via INTERFACE-DESIGN.md
- `plan-builder` — caller for Section B
- `brainstorming` — broader divergent-thinking skill (this skill is the **converge-on-design** specialization)
- `subagent-dispatch` — for parallel **execution** of independent tasks (different concern)
- `execution-strategy` — decides whether parallelism applies BEFORE this skill spawns
- `decision-log` — record the chosen design as an ADR