principle-exhaust-the-design-space

Builds competing prototypes to compare design alternatives before committing to an implementation.

6.6k|542|Updated Jan 23, 2026
One-click install
npx skills add https://github.com/cursor/plugins --skill principle-exhaust-the-design-space
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: principle-exhaust-the-design-space
Source: https://github.com/cursor/plugins/tree/main/pstack/skills/principle-exhaust-the-design-space
Command: npx skills add https://github.com/cursor/plugins --skill principle-exhaust-the-design-space

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

When facing a novel UI interaction or architectural decision with no precedent in the codebase, committing to the first idea often leads to building the wrong thing. This Skill enforces a disciplined exploration of multiple design alternatives before implementation begins.

Core Features & Use Cases

  • Multi-Prototype Exploration: Builds 2-3 competing prototypes or sketches and compares them side by side before committing.
  • Clear Applicability Rules: Defines when the principle applies (novel UI interactions, architectural choices with multiple viable approaches, feel-driven product decisions) and when it does not (mechanical implementations, bug fixes, single-approach constraints).
  • Use Case: When designing a new drag-and-drop interaction with no prior art in the codebase, prototype three different interaction models, compare them side by side, and only then commit to one.

Quick Start

Ask the agent to apply the exhaust-the-design-space principle to prototype and compare alternatives for a novel UI interaction or architectural decision.

Frequently Asked Questions about principle-exhaust-the-design-space

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I explore design alternatives before implementing a new feature?

Build 2-3 competing prototypes or sketches and compare them side by side before committing. Each option must be a genuinely different shape, not a second flavor of the first approach.

When should I prototype multiple approaches for an architectural decision?

Prototype multiple approaches when the decision has no precedent in the codebase and several viable approaches exist. This includes novel UI interactions and architectural choices where the right answer is not obvious.

When should I not build multiple prototypes?

Skip multi-prototype exploration for mechanical implementations with established patterns, bug fixes or refactors with a clear target state, and changes where constraints dictate a single viable approach.

What counts as a valid alternative when exhausting the design space?

A valid alternative is a genuinely different shape or approach, not a minor variation of the first idea. The goal is to compare distinct options side by side so the tradeoffs become concrete before committing.