softspark Design an Interface
$ARGUMENTS
Generate 3+ radically different interface designs using parallel sub-agents, then compare. Based on "Design It Twice" from "A Philosophy of Software Design."
Usage
/design-an-interface [module or interface to design]
What This Command Does
- Gathers requirements and constraints
- Spawns 3+ parallel sub-agents with different design constraints
- Presents each design with signatures, usage examples, and trade-offs
- Compares on simplicity, depth, efficiency, and correctness
- Synthesizes best elements into final recommendation
Process
1. Gather Requirements
Before designing, understand:
- What problem does this module solve?
- Who are the callers? (other modules, external users, tests)
- What are the key operations?
- Any constraints? (performance, compatibility, existing patterns)
- What should be hidden inside vs exposed?
2. Generate Designs (Parallel Sub-Agents)
Spawn 3+ sub-agents simultaneously using Agent tool. Each gets a radically different constraint:
| Agent | Constraint |
|---|---|
| Agent 1 | Minimize method count — aim for 1-3 methods max |
| Agent 2 | Maximize flexibility — support many use cases |
| Agent 3 | Optimize for the most common case |
| Agent 4 | Take inspiration from a specific paradigm/library |
Each agent outputs:
- Interface signature (types/methods)
- Usage example (how caller uses it)
- What this design hides internally
- Trade-offs of this approach
3. Present Designs
Show each design sequentially so user can absorb each approach before comparison:
- Interface signature — types, methods, params
- Usage examples — how callers actually use it
- What it hides — complexity kept internal
4. Compare Designs
Compare in prose (not tables) on:
| Criterion | Description |
|---|---|
| Interface simplicity | Fewer methods, simpler params |
| General-purpose vs specialized | Flexibility vs focus |
| Implementation efficiency | Does shape allow efficient internals? |
| Depth | Small interface hiding significant complexity (good) vs large interface with thin implementation (bad) |
| Ease of correct use | vs ease of misuse |
5. Synthesize
Often the best design combines insights from multiple options. Give an opinionated recommendation. Ask:
- Which design best fits the primary use case?
- Any elements from other designs worth incorporating?
Visual Companion (Optional)
When upcoming design explorations will involve visual content (mockups, layout comparisons, architecture diagrams), offer the browser companion:
"Some of these interface designs might be easier to compare visually. I can show diagrams and side-by-side comparisons in a browser. Want to try it?"
This offer MUST be its own message. Do not combine with other questions. Wait for response.
If accepted, start the server and use it for visual comparisons only. Text/conceptual questions stay in terminal.
See ../write-a-prd/reference/visual-companion.md for details.
Anti-Patterns
- Don't let sub-agents produce similar designs — enforce radical difference
- Don't skip comparison — the value is in contrast
- Don't implement — this is purely about interface shape
- Don't evaluate based on implementation effort
READ-ONLY
This skill designs interfaces. It does NOT write implementation code.