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/commands/define-design.md

@@ -61,7 +61,7 @@ Ask the user about the following. If the user does not provide detailed preferen
 
 - **Target platform**: `web`, `flutter`, `winui3`, or `multi`
 - **Visual style** (e.g. friendly/modern/rounded/calm, dark or light, density)
-- **Main screens** the app must have
+- **Main screens** the app must have (treat the answer as additions and constraints — the complete screen list is derived from the PRD in Step 3, never limited to what the user names here)
 - **Navigation style** (e.g. tab bar, drawer, sidebar, stack)
 - **Branding preferences** (name, colors, tone)
 - **Accessibility requirements** (e.g. WCAG level, minimum contrast, large-touch targets)
@@ -73,7 +73,30 @@ Collect the answers in a single round; do not pause again until generation is co
 - Load the **ui-design skill** (`Skill('ui-design')`) to create `design-brief.md`, `ui-blueprint.json`, and the SVG wireframes.
 - Load the **design-tokens skill** (`Skill('design-tokens')`) to create `design-tokens.json`.
 
-### Step 3: Create the Design Brief
+### Step 3: Build the Screen Inventory (exhaustive — before designing anything)
+
+The most common design failure is a missing screen — e.g. a todo app with a list screen but no screen for adding a new item. To prevent it, enumerate **every** screen the requirements imply and write the list to `docs/design/screen-inventory.md` **before** creating any other design file.
+
+Derive the inventory from the documents read in Step 0. The user's Step 1 answer about main screens is input, never the ceiling.
+
+1. **Walk every user story and requirement** in `docs/product-requirements.md`, and every flow in `docs/functional-design.md`. For each one, write down every screen the user passes through 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 to every entity** the user manages (e.g. todo item, project, profile). For each entity, explicitly decide each of: list/overview, detail, **create/add**, edit, delete confirmation. Include each as an inventory entry unless the requirements clearly exclude it. If create/edit happens in a modal, dialog, or inline form rather than a full page, it is **still an inventory entry** (record its presentation) — it still needs a blueprint entry and a wireframe.
+3. **Add the supporting screens** the requirements imply: authentication (sign in / sign up / password reset), settings, onboarding, search/filter results, empty states, error / not-found.
+
+Write each entry in this format:
+
+```markdown
+- [ ] `screen-id` — Title
+  - Purpose: what the user accomplishes here
+  - Source: the PRD user story / functional-design section it comes from
+  - Reached from: the screens/actions that navigate here
+  - Presentation: page | modal | drawer
+  - Key elements: main components, inputs, and actions on the screen
+```
+
+End the file with a **traceability table**: one row per user story, listing the screen ids that fulfill it. Every user story must map to at least one screen, and every screen must trace back to at least one requirement. Do not proceed to Step 4 until both directions are fully covered.
+
+### Step 4: Create the Design Brief
 
 Create `docs/design/design-brief.md` covering:
 
@@ -87,7 +110,7 @@ Create `docs/design/design-brief.md` covering:
 - Examples of preferred UI style
 - Examples of UI style to avoid
 
-### Step 4: Create the Design Tokens
+### Step 5: Create the Design Tokens
 
 Create `docs/design/design-tokens.json` using a JSON structure inspired by the Design Tokens Community Group format (each token has `$type` and `$value`). Include:
 
@@ -99,7 +122,7 @@ Create `docs/design/design-tokens.json` using a JSON structure inspired by the D
 - Animation durations / easings
 - Breakpoints (if the target includes web)
 
-### Step 5: Create the UI Blueprint (source of truth)
+### Step 6: Create the UI Blueprint (source of truth)
 
 Create `docs/design/ui-blueprint.json`. This is **the** source of truth for UI generation. It must describe:
 
@@ -112,7 +135,9 @@ Create `docs/design/ui-blueprint.json`. This is **the** source of truth for UI g
 - Component hierarchy
 - User actions and navigation behavior
 
-### Step 6: Create the Platform Mapping
+**Coverage rule**: the blueprint must contain one screen entry for **every** entry in `docs/design/screen-inventory.md` — including modal/drawer entries. As each screen is added, check it off (`[ ]` → `[x]`) in the inventory. Do not finish this step while any inventory entry is unchecked.
+
+### Step 7: Create the Platform Mapping
 
 Create `docs/design/platform-mapping.md` describing how the design spec is converted to each platform:
 
@@ -130,7 +155,7 @@ WinUI 3:
 - ui-blueprint.json → XAML pages, UserControls, styles
 ```
 
-### Step 7: Generate SVG Wireframes (visual references only)
+### Step 8: Generate SVG Wireframes (visual references only)
 
 For each screen in `ui-blueprint.json`, generate a corresponding SVG wireframe under `docs/design/screens/`:
 
@@ -140,10 +165,12 @@ For each screen in `ui-blueprint.json`, generate a corresponding SVG wireframe u
 
 **Important rule**: SVG files are **not** the source of truth. They are generated as visual references for human review only. The source of truth is `ui-blueprint.json`. If the blueprint and an SVG ever disagree, the blueprint wins and the SVG must be regenerated.
 
-### Step 8: Consistency Check
+### Step 9: Consistency Check
 
 Re-read all generated files and confirm:
 
+- Every entry in `docs/design/screen-inventory.md` is checked off and has a matching screen (same id) in `ui-blueprint.json`.
+- Every user story in the PRD can be completed end-to-end using only the screens and actions in the blueprint — in particular, every entity the user can create, edit, or delete has a screen (or modal) for each of those operations.
 - Every screen in `ui-blueprint.json` has a matching SVG in `screens/`.
 - Token names referenced in `ui-blueprint.json` exist in `design-tokens.json`.
 - `platform-mapping.md` covers all target platforms selected in Step 1.
@@ -153,6 +180,7 @@ Fix any inconsistencies found before finishing.
 
 ## Completion Criteria
 
+- `docs/design/screen-inventory.md` exists and every entry is checked off
 - `docs/design/design-brief.md` exists
 - `docs/design/design-tokens.json` exists and is valid JSON
 - `docs/design/ui-blueprint.json` exists and is valid JSON
@@ -164,6 +192,7 @@ Completion message:
 "Design phase is complete!
 
 Design documents created:
+✅ docs/design/screen-inventory.md  (exhaustive screen list — all entries covered)
 ✅ docs/design/design-brief.md
 ✅ docs/design/design-tokens.json
 ✅ docs/design/ui-blueprint.json   (source of truth)

.claude/commands/update-design.md

@@ -38,6 +38,8 @@ Read:
 
 The blueprint is the source of truth, so it is always updated first. Add/modify screens, components, variants, states, routes, and actions to reflect the requested change. Keep the JSON valid and consistent with the existing schema.
 
+If the change adds or removes screens, also update `docs/design/screen-inventory.md` (create it if missing — see the ui-design skill) so it stays the complete screen list: new screens get a checked (`[x]`) entry with purpose, source, and how they are reached; removed screens are deleted from it.
+
 ### Step 2: Update `design-tokens.json` (if needed)
 
 If the change introduces new colors, spacing, typography, radius, shadows, or animations, add the corresponding tokens here. Reuse existing tokens where possible; do not duplicate. Use semantic names. No hard-coded values should be needed downstream.
@@ -57,6 +59,7 @@ For every screen added or modified in `ui-blueprint.json`, generate or regenerat
 ### Step 6: Consistency Check
 
 - Every screen in `ui-blueprint.json` has a matching SVG.
+- `docs/design/screen-inventory.md` (if present) lists exactly the blueprint's screens.
 - Token names referenced in the blueprint exist in `design-tokens.json`.
 - The brief and mapping remain consistent with the blueprint.