ui-composition

Provide the screenshot (and optionally the HTML) as input; the skill walks the artifact, marks each visible boundary, and classifies it into Route Shell, Section, Component, Leaf, Dialog, or Form. It then emits a seven-part UI Composition section with an ASCII layout map, component tree, data cards, and a build hand-off table.

A boundary is a Section only if it orchestrates at least three distinct sub-components or is the sole data-fetching root of a screen region. Standalone search inputs, pagination controls, tab strips, and single stat cards are Components, not Sections.

A dialog used by one route stays in that route's -components folder; a dialog opened from two or more routes moves to the shared @/components/Dialogs/ directory with a barrel export. All dialogs open via useDialogStore.show() and never receive open/onOpenChange props.

Filters, pagination, tabs, and selected IDs must live in URL search params so they are bookmarkable and survive refresh. useState is reserved for ephemeral local state, and Zustand stores hold shared ephemeral state like typing indicators or presence.

Skip it for pure backend work, for creating a single primitive component in isolation, and for implementing components that are already classified — use the downstream route, component, form, or store skills instead. It is also not for generating mockups from user stories, which is the inverse direction.