principle-exhaust-the-design-space
cursor/plugins
Explore 2-3 competing prototypes before committing to novel UI or architectural decisions.
What is principle-exhaust-the-design-space?
A design principle for novel interactions or architectural choices with no established precedent in the codebase. Build competing prototypes and compare them side by side before implementation, reducing the cost of building the wrong thing.
- Guides when to prototype multiple design alternatives
- Establishes criteria for novel vs. established decisions
- Prevents premature commitment to unvalidated approaches
- Encourages side-by-side comparison of competing solutions
- Applies to UI interactions, architecture, and product design
How to install principle-exhaust-the-design-space
npx skills add https://github.com/cursor/plugins --skill principle-exhaust-the-design-spaceHow to use principle-exhaust-the-design-space
- 1.Identify a novel decision with no clear precedent in your codebase
- 2.Build 2-3 distinct prototypes or sketches exploring different approaches
- 3.Compare the alternatives side by side against your requirements
- 4.Evaluate trade-offs in complexity, maintainability, and user experience
- 5.Commit to the strongest option informed by the comparison
Use cases
- Designing a new modal dialog interaction pattern not used elsewhere in the app
- Choosing between REST, GraphQL, or gRPC for a new service API
- Deciding on a state management approach for a complex feature
- Exploring different navigation structures for a redesigned section
- Evaluating competing layout strategies for a data-heavy interface
- Product engineers
- UI/UX designers
- Architects
- Tech leads making design decisions
principle-exhaust-the-design-space FAQ
A decision is novel when there's no established pattern or precedent in your codebase. If similar interactions or architectural choices already exist, follow the established pattern instead.
No. Sketches, wireframes, or partial implementations are sufficient. The goal is to compare approaches concretely, not build production code.
Skip it for mechanical implementations following established patterns, bug fixes with a clear target state, or decisions where constraints dictate a single viable approach.
Stop when you have 2-3 meaningfully different approaches and can clearly articulate the trade-offs between them.
Full instructions (SKILL.md)
Source of truth, from cursor/plugins.
name: principle-exhaust-the-design-space description: "Apply when facing a novel UI interaction or architectural decision with no precedent in the codebase. Build 2-3 competing prototypes and compare side by side before committing." disable-model-invocation: true
Exhaust the Design Space
When a novel interaction or architectural decision has no established precedent, explore several concrete alternatives before implementation. Building the wrong thing costs more than exploring three options.
The rule. When the right answer is not obvious, build 2-3 competing prototypes or sketches. Compare them side by side. Only then commit. Design it twice is this rule by another name. A second flavor of the first shape does not count.
When it applies:
- Novel UI interactions (no prior art in the codebase)
- Architectural choices with multiple viable approaches
- Product design decisions where user experience depends on feel, not logic
When it doesn't:
- Mechanical implementation where the pattern is established
- Bug fixes or refactors with a clear target state
- Changes where constraints dictate a single viable approach
Related skills
More from cursor/plugins and the wider catalog.
principle-experience-first
Prioritize user delight over implementation convenience—ship fewer polished features instead of many rough ones.
principle-fix-root-causes
Trace bugs to root causes instead of patching symptoms during debugging.
principle-foundational-thinking
Design data structures and core types before writing logic to make downstream code obvious.
principle-guard-the-context-window
Manage finite context by routing bulk data to subagents and keeping summaries in the main thread.
principle-laziness-protocol
Bias toward deletion and minimal changes—apply when refactoring, evaluating diffs, or tempted by abstractions.
principle-make-operations-idempotent
Design operations to converge to correct state regardless of crashes, restarts, or retries.