ux-design

Produces UX decision blocks for new UI surfaces in the D&D Kids Resources repo.

Updated Mar 24, 2026
One-click install
npx skills add https://github.com/skyrocoster/dnd-kids-resources --skill ux-design-skyrocoster
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: ux-design
Source: https://github.com/skyrocoster/dnd-kids-resources/tree/main/.opencode/skills/ux-design
Command: npx skills add https://github.com/skyrocoster/dnd-kids-resources --skill ux-design-skyrocoster

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? New UI surfaces in this repo often ship without settled interaction decisions — empty states, save behavior, failure handling, and mode (prep vs play) get improvised by whoever writes the code. This Skill forces those decisions to be made at planning time and recorded in a structured block before any implementation begins. ## Core Features & Use Cases - Mode classification: Assigns each surface a prep or play mode, driving density, target size, and interruption-safety decisions. - Structured UX decisions block: Emits a fill-every-line template covering focal point, route shape, edit style, save behavior, empty/error copy strings, keyboard, and touch targets. - Convention enforcement: Checks decisions against the binding rules in docs/UX_PATTERNS.md and reuses existing components like Dialog, StatePanel, and RemoteState instead of inventing new controls. - Use Case: When planning a new quest tracker dialog, run this Skill to decide its mode, exact empty-state copy, save behavior, and keyboard flow, then hand the block to the planning step that generates work orders. ## Quick Start Ask the assistant to use the ux-design skill to decide how the new encounter builder surface should behave before writing any code.

Frequently Asked Questions about ux-design

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

FAQPage Schema
How do I plan the UX for a new UI surface before coding?▼

Read docs/UX_PATTERNS.md first, classify the surface as prep or play mode, then fill every line of the UX decisions block template — focal point, route shape, edit style, save behavior, and exact copy strings. The block goes into the Plan, not into code.

What is the difference between prep mode and play mode surfaces?▼

Prep mode is for authoring between games and favors density, throughput, and keyboard efficiency. Play mode is for running a game at the table and requires glanceability, large touch targets, few steps, and never losing work when interrupted.

Does this skill produce implementation code or CSS?▼

No. It operates at planning time and produces a UX decisions block only. Visual tokens like color, type, and spacing are already settled in frontend/src/theme.css and docs/DESIGN_SYSTEM.md, and proposing new ones is explicitly out of scope.

Can I introduce a new custom component in a UX design?▼

Only as a last resort. The repo already provides Dialog, ConfirmDialog, StatePanel, SearchList, BrowserLayout, SplitPane, and form fields with focus management and ARIA built in. Specifying a hand-rolled equivalent of an existing component is treated as a defect.

What happens if a UX decision conflicts with an IN FORCE rule?▼

You must either change the design to comply or state plainly in the Plan that you are proposing to change the rule in UX_PATTERNS.md. Quietly deviating from an IN FORCE rule is not allowed.