mirror of
https://github.com/prdlk/dotfiles.git
synced 2026-11-02 19:32:43 +00:00
shell: fish functions -> ~/.local/bin executables + bash/zsh ports; manage ~/.agents
- 16 cross-shell utilities converted to sh/bash chezmoi executables: ai c2p cp-appid extract_agents fab gdc gh-sonr-org-migrate ghg-clone ghn gho git-summary launch_omp_livediff_overlay lc-elir mdcp mdp pj (ghg-clone not named ghg: unrelated cargo binary owns that name) - cwd/history helpers stay per-shell: yy c cd clip-last + ghg/ghn/gho cd-wrappers in bash/functions/ and zsh/functions/, loaded by rc files - fish keeps only shell-state functions; converted ones now hit PATH - cp-appid ignore gating moved to .local/bin path - dot_agents/skills: 82 skills materialized from dotstate storage so dot_claude skill symlinks resolve on fresh bootstrap; dotstate profile/symlinks.json released .agents/skills .bashrc .zshrc
This commit is contained in:
1 parent
6776366ce6
commit
6406208b35
637 files changed
+100297
-497
No files matched your search
@@ -0,0 +1,94 @@
|
||||
---
|
||||
name: design-an-interface
|
||||
description: 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".
|
||||
---
|
||||
|
||||
# Design an Interface
|
||||
|
||||
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.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 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?
|
||||
|
||||
Ask: "What does this module need to do? Who will use it?"
|
||||
|
||||
### 2. Generate Designs (Parallel Sub-Agents)
|
||||
|
||||
Spawn 3+ sub-agents simultaneously using Task tool. Each must produce a **radically different** approach.
|
||||
|
||||
```
|
||||
Prompt template for each sub-agent:
|
||||
|
||||
Design an interface for: [module description]
|
||||
|
||||
Requirements: [gathered requirements]
|
||||
|
||||
Constraints for this design: [assign a different constraint to each agent]
|
||||
- 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 [specific paradigm/library]"
|
||||
|
||||
Output format:
|
||||
1. Interface signature (types/methods)
|
||||
2. Usage example (how caller uses it)
|
||||
3. What this design hides internally
|
||||
4. Trade-offs of this approach
|
||||
```
|
||||
|
||||
### 3. Present Designs
|
||||
|
||||
Show each design with:
|
||||
|
||||
1. **Interface signature** - types, methods, params
|
||||
2. **Usage examples** - how callers actually use it in practice
|
||||
3. **What it hides** - complexity kept internal
|
||||
|
||||
Present designs sequentially so user can absorb each approach before comparison.
|
||||
|
||||
### 4. Compare Designs
|
||||
|
||||
After showing all designs, compare them on:
|
||||
|
||||
- **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**
|
||||
|
||||
Discuss trade-offs in prose, not tables. Highlight where designs diverge most.
|
||||
|
||||
### 5. Synthesize
|
||||
|
||||
Often the best design combines insights from multiple options. Ask:
|
||||
|
||||
- "Which design best fits your primary use case?"
|
||||
- "Any elements from other designs worth incorporating?"
|
||||
|
||||
## Evaluation Criteria
|
||||
|
||||
From "A Philosophy of Software Design":
|
||||
|
||||
**Interface simplicity**: Fewer methods, simpler params = easier to learn and use correctly.
|
||||
|
||||
**General-purpose**: Can handle future use cases without changes. But beware over-generalization.
|
||||
|
||||
**Implementation efficiency**: Does interface shape allow efficient implementation? Or force awkward internals?
|
||||
|
||||
**Depth**: Small interface hiding significant complexity = deep module (good). Large interface with thin implementation = shallow module (avoid).
|
||||
|
||||
## 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
|
||||
Reference in new issue
Block a user