choose-pattern

name	choose-pattern
description	Recommends the right UI pattern from Tidwell's "Designing Interfaces" catalog for a given interaction problem — navigation, layout, lists/data, forms, controls, mobile. Auto-activates on "what pattern should I use for X", "how do I let users [do Y]", "what's the best way to show [Z]", or /uix:choose-pattern. Returns primary pattern, 1-2 alternatives, and why each fits or doesn't.
argument-hint	[interaction or problem]
version	0.1.0
allowed-tools	Read, Grep

choose-pattern

Advise on Tidwell-pattern selection. Auto-activates on pattern-selection questions or via /uix:choose-pattern.

Triggers

"what pattern should I use for [X]" · "how do I let users [do Y]" · "what's the best way to show [Z]" · "should I use a modal / tabs / accordion / wizard / dropdown / carousel for this" · "pattern for [navigation / filtering / comparing / multi-step task / large list]".

Process

1. Clarify the interaction problem in one sentence. Focus on the user's goal, not the UI element. "User needs to compare 5 items side by side" is better than "I need a table."

2. Identify the category from ${CLAUDE_PLUGIN_ROOT}/references/UI_MASTER_GUIDE.md Part X:

   • Page / IA · Navigation · Layout · Lists & Data · Forms & Input · Controls & Actions · Mobile

3. Recommend one primary pattern + up to two alternatives. Format:

   ## Pattern recommendation — <problem>
   
   ### Primary: <PatternName>
   **What it is:** one-line definition.
   **Why it fits:** maps to the user behavior at stake (safe exploration / satisficing / incremental construction / etc.).
   **When it wins:** specific conditions under which this beats alternatives.
   
   ### Alternatives
   - **<AlternativePattern>** — fits when [X]; weaker here because [Y].
   - **<AlternativePattern>** — fits when [X]; weaker here because [Y].
   
   ### Anti-patterns (avoid)
   - <AntiPattern> — why it fails.
   
   ### Implementation notes
   - 2-4 bullets: states, accessibility, mobile adaptation, known pitfalls.
   
   ### Next step
   If you want a full component spec, use `design-component` with this pattern.
   

4. Always name the user behavior the pattern serves (Tidwell's palette — see master guide Part III).

5. If the user's problem doesn't map cleanly to a single Tidwell pattern, propose a composite: e.g., "Two-Panel Selector + Cards + Dynamic Queries" and justify each.

6. If the user is asking about a pattern they already chose (e.g., "should I use a modal?"), evaluate their choice honestly. Often the right answer is "no, use X instead because Y."

Ground rules

• Never invent patterns. If no Tidwell pattern fits, say so and name the closest analogs.
• Default to conservative, well-known patterns. Innovation here rarely pays [DMMT].
• Flag patterns that break on mobile or keyboard-only and suggest adaptations.
• Carousels are usually wrong — say so when the user proposes one, unless there's a real linear-sequence reason [RUI][DI].
• Modals are often overused — say so when the user proposes one for non-blocking content [DI].

Reference

Full pattern catalog in ${CLAUDE_PLUGIN_ROOT}/references/UI_MASTER_GUIDE.md Part X. User-behavior palette in Part III.