Add design-first workflow aligned with opencode boilerplate

- New commands: /define-design, /update-design, /generate-app (web | flutter | winui3)
- New skills: ui-design, design-tokens, platform-ui-generation
- /add-feature: check design spec before implementation (Step 3.5) and reconcile all six persistent docs after implementation (Step 8)
- /setup-project: automatic document creation with self-check checkpoints
- CLAUDE.md: document docs/design/, .claude/ configuration, and the design phase in the development process
- Enrich subagent descriptions; allowlist new skills in settings.json
- Add docs/design/README.md

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

.claude/commands/add-feature.md

@@ -6,14 +6,14 @@ description: Implement a new feature following existing patterns, fully autonomo
 
 **Important:** This workflow is designed to run fully automatically from start to finish without user intervention. After completing each step, immediately move on to the next step. Do not ask the user for confirmation mid-thought or interrupt the work.
 
-**Argument:** feature name (e.g. `/add-feature User profile editing`)
+**Feature name**: `$ARGUMENTS` (e.g. `/add-feature User profile editing`)
 
 ---
 
 ## Step 1: Preparation and Context Setup
 
 1. Establish the current task context:
-  - Feature name: `[the feature name given as an argument]`
+  - Feature name: `$ARGUMENTS`
   - Date: `[get the current date in YYYYMMDD format]`
   - Steering directory path: `.steering/[date]-[feature name]/`
 2. Create the steering directory above.
@@ -35,6 +35,30 @@ description: Implement a new feature following existing patterns, fully autonomo
   ```
 2. Analyze the search results to identify existing implementation patterns, naming conventions, and how components are used.
 
+## Step 3.5: Check the Design Specification (Before Implementation)
+
+Before implementing any feature, respect the UI/UX design specification.
+
+1. Check whether the design files exist:
+   - `docs/design/design-brief.md`
+   - `docs/design/design-tokens.json`
+   - `docs/design/ui-blueprint.json`
+   - `docs/design/platform-mapping.md`
+
+2. **If the design files do not exist**, warn the user and suggest running `/define-design` before continuing. Do not silently proceed without a design spec.
+
+3. **If the design files exist**, read all four of them before implementation:
+   1. `docs/design/design-brief.md`
+   2. `docs/design/design-tokens.json`
+   3. `docs/design/ui-blueprint.json` (source of truth)
+   4. `docs/design/platform-mapping.md`
+
+4. **If the feature changes the UI**, update the design files first, following the `/update-design` order:
+   - `ui-blueprint.json` → `design-tokens.json` → `design-brief.md` → `platform-mapping.md` → regenerate affected `screens/*.svg`
+   - The blueprint is the source of truth; SVGs are visual references only.
+
+5. Then implement the feature according to the selected platform mapping in `platform-mapping.md`, using tokens from `design-tokens.json` (no hard-coded values) and the component tree from `ui-blueprint.json`.
+
 ## Step 4: Planning Phase (Automatic Generation of Steering Files)
 
 1. Run `Skill('steering')` in **planning mode** to generate the contents of the three files created in Step 1 (`requirements.md`, `design.md`, `tasklist.md`).
@@ -116,9 +140,18 @@ If any of the following situations occur while the implementation loop is runnin
   - Lessons learned
   - Improvement suggestions for next time
 
-2. Determine whether this change affects the project's fundamental design or architecture.
+2. **Reconcile all six persistent documents in `docs/` with the feature just implemented.** For each document, read its current content, then use the `Edit` tool to update it so it reflects the new feature. An update may be skipped **only** when the document genuinely requires no change for this feature — in that case, leave the document untouched and note the skip reason in the retrospective.
 
-3. If there is an impact, use the `Edit` tool to update the relevant persistent documents in `docs/`.
+   - ✅ `docs/product-requirements.md` — add/update user stories, acceptance criteria, non-functional requirements, and success metrics for the feature
+   - ✅ `docs/functional-design.md` — add/update functional modules, screens, data flows, and state changes introduced by the feature
+   - ✅ `docs/architecture.md` — add/update components, layers, data models, APIs, and non-functional decisions affected by the feature
+   - ✅ `docs/repository-structure.md` — add/update any new directories, files, or modules created for the feature
+   - ✅ `docs/development-guidelines.md` — add/update any new conventions, patterns, or standards established during the feature
+   - ✅ `docs/glossary.md` — add/update any new domain terms introduced by the feature
+
+3. **Consistency check**: re-read each updated document and confirm it is consistent with the other documents and with the implemented code. Fix any inconsistencies found.
+
+4. **Once this step completes successfully, never stop; immediately proceed to the Completion Criteria.**
 
 ## Completion Criteria
 
@@ -126,6 +159,6 @@ This workflow completes automatically once all of the following conditions are m
 - Step 5: All tasks in `tasklist.md` are complete (`[x]` or skipped for a valid reason).
 - Step 6: The `implementation-validator` subagent's validation passes.
 - Step 7: The `test`, `lint`, and `typecheck` commands all succeed without errors.
-- Step 8: Handover notes are recorded in `tasklist.md`.
+- Step 8: Handover notes are recorded in `tasklist.md`, and all six persistent documents in `docs/` have been reconciled with the feature (updates applied, or a skip reason noted for each).
 
 Until these completion criteria are met, continue to think autonomously, solve problems, and carry on the work.