design-an-interface

Name: design-an-interface
Author: softspark

161stars21forks

How to install design-an-interface?

softspark/ai-toolkit/design-an-interface

$npx -y skills add softspark/ai-toolkit --skill design-an-interface

Installs into the current project.

Summary

Generates and compares parallel interface designs (Ousterhout 'Design It Twice'). Triggers: design API, interface options, compare modules, design it twice.

Files · 1

View on GitHub

SKILL.md

1	# Design an Interface
2
3	$ARGUMENTS
4
5	Generate 3+ radically different interface designs using parallel sub-agents, then compare. Based on "Design It Twice" from "A Philosophy of Software Design."
6
7	## Usage
8
9	```
10	/design-an-interface [module or interface to design]
11	```
12
13	## What This Command Does
14
15	1. Gathers requirements and constraints
16	2. Spawns 3+ parallel sub-agents with different design constraints
17	3. Presents each design with signatures, usage examples, and trade-offs
18	4. Compares on simplicity, depth, efficiency, and correctness
19	5. Synthesizes best elements into final recommendation
20
21	## Process
22
23	### 1. Gather Requirements
24
25	Before designing, understand:
26
27	- [ ] What problem does this module solve?
28	- [ ] Who are the callers? (other modules, external users, tests)
29	- [ ] What are the key operations?
30	- [ ] Any constraints? (performance, compatibility, existing patterns)
31	- [ ] What should be hidden inside vs exposed?
32
33	### 2. Generate Designs (Parallel Sub-Agents)
34
35	Spawn 3+ sub-agents simultaneously using Agent tool. Each gets a radically different constraint:
36
37	\| Agent \| Constraint \|
38	\|-------\|-----------\|
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 a specific paradigm/library \|
43
44	Each agent outputs:
45	1. Interface signature (types/methods)
46	2. Usage example (how caller uses it)
47	3. What this design hides internally
48	4. Trade-offs of this approach
49
50	### 3. Present Designs
51
52	Show each design sequentially so user can absorb each approach before comparison:
53	1. Interface signature — types, methods, params
54	2. Usage examples — how callers actually use it
55	3. What it hides — complexity kept internal
56
57	### 4. Compare Designs
58
59	Compare in prose (not tables) on:
60
61	\| Criterion \| Description \|
62	\|-----------\|-------------\|
63	\| Interface simplicity \| Fewer methods, simpler params \|
64	\| General-purpose vs specialized \| Flexibility vs focus \|
65	\| Implementation efficiency \| Does shape allow efficient internals? \|
66	\| Depth \| Small interface hiding significant complexity (good) vs large interface with thin implementation (bad) \|
67	\| Ease of correct use \| vs ease of misuse \|
68
69	### 5. Synthesize
70
71	Often the best design combines insights from multiple options. Give an opinionated recommendation. Ask:
72	- Which design best fits the primary use case?
73	- Any elements from other designs worth incorporating?
74
75	## Visual Companion (Optional)
76
77	When upcoming design explorations will involve visual content (mockups, layout comparisons, architecture diagrams), offer the browser companion:
78
79	> "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?"
80
81	This offer MUST be its own message. Do not combine with other questions. Wait for response.
82
83	If accepted, start the server and use it for visual comparisons only. Text/conceptual questions stay in terminal.
84
85	See [../write-a-prd/reference/visual-companion.md](../write-a-prd/reference/visual-companion.md) for details.
86
87	## Anti-Patterns
88
89	- Don't let sub-agents produce similar designs — enforce radical difference
90	- Don't skip comparison — the value is in contrast
91	- Don't implement — this is purely about interface shape
92	- Don't evaluate based on implementation effort
93
94	## READ-ONLY
95
96	This skill designs interfaces. It does NOT write implementation code.

People who liked this also viewed

6 picks

Type

web-design-guidelinesReview UI code for Web Interface Guidelines compliance. Use when asked to "review my UI", "check accessibility", "audit design", "review UX", or "check my site against best practices".SkillsJul 2026483k29k
lark-slides飞书幻灯片：创建和编辑幻灯片。创建演示文稿、读取幻灯片内容、管理幻灯片页面（创建、删除、读取、局部替换）。当用户需要创建或编辑幻灯片、读取或修改单个页面时使用。当用户给出 doubao.com 的 /slides/ URL/token 时，也应直接使用本 skill，不要因为域名不是飞书而回退到 WebFetch；路由依据是 URL 路径模式和 token，而不是域名。不负责：云文档内容编辑（走 SkillsJul 2026332k16k
design-taste-frontendTaste-Skill - gives your AI good taste. stops the AI from generating boring, generic slop SkillsJul 2026280k66k
ui-ux-pro-maxUI/UX design intelligence for web and mobile. Searchable local database with 84 styles, 192 color palettes, 74 font pairings, 192 product types, 98 UX guidelines, 104 icon entries, 16 GSAP motion presSkillsJul 2026280k109k
caveman-helpQuick-reference card for all caveman modes, skills, and commands. One-shot display, not a persistent mode. Trigger: /caveman-help, "caveman help", "what caveman commands", "how do I use caveman".SkillsJul 2026249k92k
codebase-designShared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-nSkillsJul 2026225k182k

design-an-interface

161stars21forks

View on GitHub

How to install design-an-interface?

softspark/ai-toolkit/design-an-interface

$npx -y skills add softspark/ai-toolkit --skill design-an-interface

Installs into the current project.

Summary

Generates and compares parallel interface designs (Ousterhout 'Design It Twice'). Triggers: design API, interface options, compare modules, design it twice.

Files · 1

View on GitHub

SKILL.md

1	# Design an Interface
2
3	$ARGUMENTS
4
5	Generate 3+ radically different interface designs using parallel sub-agents, then compare. Based on "Design It Twice" from "A Philosophy of Software Design."
6
7	## Usage
8
9	```
10	/design-an-interface [module or interface to design]
11	```
12
13	## What This Command Does
14
15	1. Gathers requirements and constraints
16	2. Spawns 3+ parallel sub-agents with different design constraints
17	3. Presents each design with signatures, usage examples, and trade-offs
18	4. Compares on simplicity, depth, efficiency, and correctness
19	5. Synthesizes best elements into final recommendation
20
21	## Process
22
23	### 1. Gather Requirements
24
25	Before designing, understand:
26
27	- [ ] What problem does this module solve?
28	- [ ] Who are the callers? (other modules, external users, tests)
29	- [ ] What are the key operations?
30	- [ ] Any constraints? (performance, compatibility, existing patterns)
31	- [ ] What should be hidden inside vs exposed?
32
33	### 2. Generate Designs (Parallel Sub-Agents)
34
35	Spawn 3+ sub-agents simultaneously using Agent tool. Each gets a radically different constraint:
36
37	\| Agent \| Constraint \|
38	\|-------\|-----------\|
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 a specific paradigm/library \|
43
44	Each agent outputs:
45	1. Interface signature (types/methods)
46	2. Usage example (how caller uses it)
47	3. What this design hides internally
48	4. Trade-offs of this approach
49
50	### 3. Present Designs
51
52	Show each design sequentially so user can absorb each approach before comparison:
53	1. Interface signature — types, methods, params
54	2. Usage examples — how callers actually use it
55	3. What it hides — complexity kept internal
56
57	### 4. Compare Designs
58
59	Compare in prose (not tables) on:
60
61	\| Criterion \| Description \|
62	\|-----------\|-------------\|
63	\| Interface simplicity \| Fewer methods, simpler params \|
64	\| General-purpose vs specialized \| Flexibility vs focus \|
65	\| Implementation efficiency \| Does shape allow efficient internals? \|
66	\| Depth \| Small interface hiding significant complexity (good) vs large interface with thin implementation (bad) \|
67	\| Ease of correct use \| vs ease of misuse \|
68
69	### 5. Synthesize
70
71	Often the best design combines insights from multiple options. Give an opinionated recommendation. Ask:
72	- Which design best fits the primary use case?
73	- Any elements from other designs worth incorporating?
74
75	## Visual Companion (Optional)
76
77	When upcoming design explorations will involve visual content (mockups, layout comparisons, architecture diagrams), offer the browser companion:
78
79	> "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?"
80
81	This offer MUST be its own message. Do not combine with other questions. Wait for response.
82
83	If accepted, start the server and use it for visual comparisons only. Text/conceptual questions stay in terminal.
84
85	See [../write-a-prd/reference/visual-companion.md](../write-a-prd/reference/visual-companion.md) for details.
86
87	## Anti-Patterns
88
89	- Don't let sub-agents produce similar designs — enforce radical difference
90	- Don't skip comparison — the value is in contrast
91	- Don't implement — this is purely about interface shape
92	- Don't evaluate based on implementation effort
93
94	## READ-ONLY
95
96	This skill designs interfaces. It does NOT write implementation code.

People who liked this also viewed

6 picks

Type