Fix /define-design missing screens: exhaustive screen inventory before design

/define-design now builds docs/design/screen-inventory.md first — derived
from every PRD user story walked end-to-end, CRUD coverage per entity
(list/detail/create/edit/delete, modals included), and supporting screens —
then requires one blueprint entry per inventory item, checked off as added.
Consistency check verifies inventory coverage and end-to-end story
completability. /update-design keeps the inventory in sync; ui-design
skill documents the inventory rules.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

.claude/skills/ui-design/SKILL.md

@@ -16,11 +16,12 @@ Prefer describing **what a component is and how it behaves** over describing **w
 
 ## Outputs
 
-This skill produces three kinds of artifacts under `docs/design/`:
+This skill produces four kinds of artifacts under `docs/design/`:
 
-1. `design-brief.md` — the UI/UX direction (human-readable, but concrete)
-2. `ui-blueprint.json` — the source of truth for UI generation (machine-readable)
-3. `screens/*.svg` — visual wireframes for human review (derived from the blueprint)
+1. `screen-inventory.md` — an exhaustive checklist of every screen the requirements imply (always created first)
+2. `design-brief.md` — the UI/UX direction (human-readable, but concrete)
+3. `ui-blueprint.json` — the source of truth for UI generation (machine-readable)
+4. `screens/*.svg` — visual wireframes for human review (derived from the blueprint)
 
 ## Prerequisites
 
@@ -32,6 +33,18 @@ Before creating the design, read:
 
 The design must serve the product requirements and stay consistent with the functional design.
 
+## Creating `screen-inventory.md` (always first)
+
+Never design screens from memory of the requirements — a screen that is not on a written list will be forgotten (the classic miss: a list screen exists but the create/add screen does not). Build the inventory before the brief or the blueprint:
+
+1. **Walk every user story** in the PRD and every flow in the functional design; list every screen the user needs to complete it end-to-end. If a story cannot be completed with the screens listed so far, the missing screens go on the list.
+2. **Apply CRUD coverage per entity**: for each domain object the user manages, explicitly decide list/overview, detail, **create/add**, edit, and delete confirmation — include each unless the requirements clearly exclude it. Modal/dialog/inline forms count as inventory entries too (record the presentation); they still need blueprint entries and wireframes.
+3. **Add supporting screens**: authentication, settings, onboarding, search results, empty states, error / not-found — wherever the requirements imply them.
+
+Each entry is a checkbox item with `screen-id`, title, purpose, source requirement, how it is reached, presentation (page / modal / drawer), and key elements. End the file with a traceability table mapping every user story to the screen ids that fulfill it — both directions must be covered (no story without screens, no screen without a source).
+
+Check entries off (`[x]`) as their screens are added to `ui-blueprint.json`. The blueprint is not complete while any entry is unchecked.
+
 ## Creating `design-brief.md`
 
 A concrete, opinionated document. Avoid vague phrases like "modern and clean" without elaboration. Include every section below:
@@ -150,6 +163,8 @@ Each node has:
 
 Before finishing:
 
+- [ ] Every entry in `screen-inventory.md` is checked off and exists in the blueprint (same id).
+- [ ] Every user story can be completed end-to-end using only blueprint screens and actions — every entity that can be created, edited, or deleted has a screen or modal for each operation.
 - [ ] Every screen in the blueprint has a matching SVG.
 - [ ] Every `variant` used in a screen is declared in `components`.
 - [ ] Every token name used in the blueprint exists in `design-tokens.json`.