design-discovery

Lock user-visible UI direction before architecture planning.

1|Updated Mar 6, 2026
One-click install
npx skills add https://github.com/SeoJaeWan/try-claude-code --skill design-discovery-seojaewan
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: design-discovery
Source: https://github.com/SeoJaeWan/try-claude-code/tree/main/.codex/skills/design-discovery
Command: npx skills add https://github.com/SeoJaeWan/try-claude-code --skill design-discovery-seojaewan

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

UI direction is often ambiguous after brainstorming, causing planners to guess hierarchy, state, and responsive behavior. design-discovery provides a consultation-first workflow to lock the user-visible direction before planning, reducing drift and rework.

Core Features & Use Cases

  • Consultation-driven direction locking between brainstorm and architect to stabilize planning.
  • Support for shotgun exploration when multiple UI directions remain viable, with explicit criteria and risks.
  • Design-direction snapshots and guardrails to hand off clear expectations to the architect.

Quick Start

Consult with design-discovery to lock the UI direction for the current task before planning.

Frequently Asked Questions about design-discovery

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

FAQPage Schema
How do I lock UI direction before planning to prevent hierarchy guessing?

Locking UI direction before planning requires a consultation-first workflow to define user-visible states and responsive behavior, creating a design-direction snapshot that stops planners from guessing hierarchy. This stabilizes the subsequent architect phase.

What is the best way to compare multiple UI directions before committing to a plan?

Comparing multiple UI directions uses shotgun exploration to evaluate plausible options with explicit criteria and risks. This generates a design-direction snapshot that hands off clear expectations to the architect before committing.

When do I need to define UI states and responsive behavior before architecture?

Defining UI states and responsive behavior is needed when the UI direction remains fuzzy after brainstorming. It prevents the architect from guessing hierarchy and state presentation, reducing drift and rework.

Does design-discovery require a consultation before locking the UI direction?

Yes, an explicit consultation-first workflow is required to lock the UI direction. This ensures hierarchy, state presentation, and responsive behavior are clearly defined before planning begins.

Can I use shotgun exploration if multiple viable UI directions remain after brainstorming?

Yes, shotgun exploration is supported when multiple viable UI directions remain. It applies explicit criteria and risks to compare options, producing a design-direction snapshot to guide the architect.