design-an-interface

Name: design-an-interface
Author: stevesolun

560stars68forks

How to install design-an-interface?

stevesolun/ctx/design-an-interface

$npx -y skills add stevesolun/ctx --skill design-an-interface

Installs into the current project.

Summary

Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".

Files · 1

View on GitHub

SKILL.md

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

People who liked this also viewed

6 picks

Type

design-an-interface

560stars68forks

View on GitHub

How to install design-an-interface?

stevesolun/ctx/design-an-interface

$npx -y skills add stevesolun/ctx --skill design-an-interface

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

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

People who liked this also viewed

6 picks

Type