Windsurf rules

1---
2name: design-interface
3model: opus
4description: "Generate multiple radically different interface designs for a module using parallel sub-agents, then compare trade-offs. Based on \"Design It Twice\" from A Philosophy of Software Design. Use when user wants to design an API, explore interface options, compare module shapes, or mentions \"design it twice\"."
5---
6 
7# Design Interface
8 
9Based on "Design It Twice" from "A Philosophy of Software Design": your first idea is unlikely to be the best. Generate multiple radically different designs, then compare.
10 
11> **HARD GATE** — Multiple design options must be explored. Do NOT settle on first idea. Compare trade-offs (UX, complexity, extensibility, performance) before committing.
12 
13## Workflow
14 
15### 1. Gather Requirements
16 
17Before designing, understand:
18 
19- [ ] What problem does this module solve?
20- [ ] Who are the callers? (other modules, external users, tests)
21- [ ] What are the key operations?
22- [ ] Any constraints? (performance, compatibility, existing patterns)
23- [ ] What should be hidden inside vs exposed?
24 
25Ask: "What does this module need to do? Who will use it?"
26 
27### 2. Generate Designs (Parallel Sub-Agents)
28 
29Spawn 3+ sub-agents simultaneously using Task tool. Each must produce a **radically different** approach.
30 
31```
32Prompt template for each sub-agent:
33 
34Design an interface for: [module description]
35 
36Requirements: [gathered requirements]
37 
38Constraints for this design: [assign a different constraint to each agent]
39- Agent 1: "Minimize method count - aim for 1-3 methods max"
40- Agent 2: "Maximize flexibility - support many use cases"
41- Agent 3: "Optimize for the most common case"
42- Agent 4: "Take inspiration from [specific paradigm/library]"
43 
44Output format:
451. Interface signature (types/methods)
462. Usage example (how caller uses it)
473. What this design hides internally
484. Trade-offs of this approach
49```
50 
51### 3. Present Designs
52 
53Show each design with:
54 
551. **Interface signature** — types, methods, params
562. **Usage examples** — how callers actually use it in practice
573. **What it hides** — complexity kept internal
58 
59Present designs sequentially so user can absorb each approach before comparison.
60 
61### 4. Compare Designs
62 
63After showing all designs, compare them on:
64 
65- **Interface simplicity**: fewer methods, simpler params
66- **General-purpose vs specialized**: flexibility vs focus
67- **Implementation efficiency**: does shape allow efficient internals?
68- **Depth**: small interface hiding significant complexity (good) vs large interface with thin implementation (bad)
69- **Ease of correct use** vs **ease of misuse**
70 
71Discuss trade-offs in prose, not tables. Highlight where designs diverge most.
72 
73### 5. Synthesize
74 
75Often the best design combines insights from multiple options. Ask:
76 
77- "Which design best fits your primary use case?"
78- "Any elements from other designs worth incorporating?"
79 
80## Evaluation Criteria
81 
82From "A Philosophy of Software Design":
83 
84**Interface simplicity**: Fewer methods, simpler params = easier to learn and use correctly.
85 
86**General-purpose**: Can handle future use cases without changes. But beware over-generalization.
87 
88**Implementation efficiency**: Does interface shape allow efficient implementation? Or force awkward internals?
89 
90**Depth**: Small interface hiding significant complexity = deep module (good). Large interface with thin implementation = shallow module (avoid).
91 
92## Anti-Patterns
93 
94- Don't let sub-agents produce similar designs — enforce radical difference
95- Don't skip comparison — the value is in contrast
96- Don't implement — this is purely about interface shape
97- Don't evaluate based on implementation effort
98