ux:explore

Compatibility: If AskUserQuestion is unavailable, present options as a numbered list and wait for the user's reply. If Task is unavailable, run parallel steps sequentially. The context: fork and agent: frontmatter fields are Claude Code-specific — on OpenCode and VS Code Copilot they are ignored and the skill runs inline using the current model.

Critical Principles

• "Wireframes fail at the edges, not the happy path." — Every wireframe that shows only idealized data is incomplete. Before finishing any screen, ask: what does this look like with zero items (empty state), with an error, and with maximum content? These are not optional — they are the most design-critical states.
• "Schematic until the interaction model is validated." — Wireframes exist to test ideas, not to demonstrate visual polish. Color choices, font weights, and spacing precision are noise at this stage. If the wireframe is beautiful but the interaction model is unresolved, the wrong thing has been optimized.
• "Specify what the developer would otherwise guess." — Any element that is ambiguous in the wireframe will be implemented with the developer's best guess. Click targets, form validation behavior, loading states, and navigation transitions must be described in comments or labeled annotations — not left implicit.

Anti-Patterns

• ❌ Designing only for ideal-case data: Rendering lists with exactly 3 well-named items, forms with short inputs, and tables with uniform row heights. → Ask the user: "How many items at maximum? What's the longest realistic text string? What happens at zero?" Add at least one empty state and one overflow/error state per screen.
• ❌ Omitting loading and error states: Showing only the success path through a flow. → Any screen that involves data fetching, form submission, or async action must include a loading variant and an error variant. These states determine the actual UX quality more than the happy path.
• ❌ Adding brand colors and visual polish prematurely: Using specific hex values, custom fonts, or drop shadows in an early-exploration wireframe. → The wireframe aesthetic (gray scale, simple borders, no shadows) is a constraint, not a default style. Premature visual fidelity anchors stakeholders to a visual direction before the interaction model is validated.
• ❌ Multi-step flows without transition labels: Building anchor-linked multi-step flows where the link between screens is a button label but the navigation semantics are unspecified. → Each navigation action between screens must be labeled with its trigger (button, link, swipe) and its condition (always available, disabled until form is valid, only on mobile). Unlabeled transitions produce ambiguous prototypes.
• ❌ No content scale constraints gathered: Building the wireframe before asking about real data volumes. → Before Step 3 (Build), confirm: max list items, character limits for labels and body text, and whether any field can be absent/null. A wireframe that breaks at real data sizes wastes a review cycle.