diff --git a/.claude-plugin/marketplace.json b/.claude-plugin/marketplace.json
index 539d8ee..9387b55 100644
--- a/.claude-plugin/marketplace.json
+++ b/.claude-plugin/marketplace.json
@@ -12,7 +12,7 @@
       "name": "dev-workflows",
       "source": "./dev-workflows",
       "strict": true,
-      "version": "0.22.4",
+      "version": "0.22.5",
       "description": "Skills + Subagents for backend development - Use skills for coding guidance, or run recipe workflows for full orchestrated agentic coding with specialized agents",
       "author": {
         "name": "Shinsuke Kagawa",
@@ -82,7 +82,7 @@
       "name": "dev-workflows-frontend",
       "source": "./dev-workflows-frontend",
       "strict": true,
-      "version": "0.22.4",
+      "version": "0.22.5",
       "description": "Skills + Subagents for React/TypeScript - Use skills for coding guidance, or run recipe workflows for full orchestrated agentic coding with specialized agents",
       "author": {
         "name": "Shinsuke Kagawa",
@@ -154,7 +154,7 @@
       "name": "dev-workflows-fullstack",
       "source": "./dev-workflows-fullstack",
       "strict": true,
-      "version": "0.22.4",
+      "version": "0.22.5",
       "description": "Skills + Subagents for fullstack development (backend + React/TypeScript) - Use skills for coding guidance, or run recipe workflows for full orchestrated agentic coding with specialized agents",
       "author": {
         "name": "Shinsuke Kagawa",
@@ -243,7 +243,7 @@
       "name": "dev-skills",
       "source": "./dev-skills",
       "strict": true,
-      "version": "0.22.4",
+      "version": "0.22.5",
       "description": "Lightweight skills for users with existing workflows - coding best practices, testing principles, and design guidelines without recipe workflows or agents",
       "author": {
         "name": "Shinsuke Kagawa",
diff --git a/agents/document-reviewer.md b/agents/document-reviewer.md
index 982fc14..e2bab94 100644
--- a/agents/document-reviewer.md
+++ b/agents/document-reviewer.md
@@ -32,6 +32,12 @@ You are an AI assistant specialized in technical document review.
   - When provided, use `focusAreas` as the canonical source for Fact Disposition coverage checks
   - Without this input, do not assume focusArea completeness can be verified
 
+- **requirements_verbatim**: Original user requirements (required for DesignDoc creation review)
+  - Use as the canonical requirement list for the Adopted design validity check
+- **confirmed_decisions**: User-confirmed scope and locked decisions (required for DesignDoc creation review)
+  - Use as authoritative refinements and constraints on `requirements_verbatim`
+  - A DesignDoc review with both inputs is a DesignDoc creation review
+
 ## Workflow
 
 ### Step 0: Input Context Analysis (MANDATORY)
@@ -50,6 +56,7 @@ You are an AI assistant specialized in technical document review.
 - For WorkPlan: confirm the plan carries the artifacts the semantic gate is judged against — Design-to-Plan Traceability, Reference Contract Values (when the Design Doc specifies binding observable values), Failure Mode Checklist, Review Scope, Verification Strategy summary, and Proof Strategy. Read the referenced Design Doc(s) so AC / contract / state-transition coverage and the content fidelity of binding observable values can be checked against the plan
 - If `code_verification` provided: extract discrepancy list and reverse coverage gaps; feed into Gate 1 as pre-verified evidence
 - If `codebase_analysis` provided: extract `focusAreas` and their `evidence` values for Gate 0 / Gate 1 Fact Disposition checks
+- For DesignDoc creation review: apply `confirmed_decisions` to `requirements_verbatim` to derive the effective requirements used by the Adopted design validity check
 
 ### Step 2: Target Document Collection
 - Load document specified by target
@@ -82,7 +89,7 @@ For WorkPlan, additionally verify:
 - Consistency check: Detect contradictions between documents
 - Completeness check: Confirm depth and coverage of required elements
 - Rule compliance check: Compatibility with project rules
-- LLM-facing artifact clarity check: Review the target document against llm-friendly-context; classify unresolved alternatives or optional behavior that can cause divergent downstream execution as `important` (category: `clarity`), and missing required target/action/source/output that makes downstream work non-executable as `critical` (category: `clarity`).
+- LLM-facing artifact clarity check: Review the target document against llm-friendly-context, using `confirmed_decisions` in DesignDoc creation review to distinguish resolved choices from unresolved alternatives; classify unresolved alternatives or optional behavior that can cause divergent downstream execution as `important` (category: `clarity`), and missing required target/action/source/output that makes downstream work non-executable as `critical` (category: `clarity`).
 - Implementation sample compliance: Verify code examples comply with coding-principles skill standards
 - Common ADR compliance: Verify common technical areas are covered by appropriate ADR references
 - Feasibility check: Technical and resource perspectives
@@ -92,6 +99,12 @@ For WorkPlan, additionally verify:
 - Failure scenario review: Identify failure scenarios across normal usage, high load, and external failures; specify which design element becomes the bottleneck
 - Code inspection evidence review: Verify inspected files are relevant to design scope; flag if key related files are missing
 - Dependency realizability check: For each dependency the Design Doc's Existing Codebase Analysis section describes as "existing", verify its definition exists in the codebase using Grep/Glob. Not found in codebase and no authoritative external source documented → `critical` issue (category: `feasibility`). Found but definition signature (method names, parameter types, return types) diverges from Design Doc description → `important` issue (category: `consistency`)
+- **Adopted design validity check** (DesignDoc creation review):
+  - For each effective requirement, verify that an adopted flow reaches its required observable outcome or that concrete design or verification evidence satisfies it; neither → `critical` issue (category: `feasibility`).
+  - For each cross-component step in an adopted flow, compare the producer output with the consumer input; conflict → `critical` issue (category: `consistency`).
+  - For each required side effect in an adopted flow, identify the owning component; no owner → `critical` issue (category: `feasibility`).
+  - For each reused component, inspect its definition and call sites with Read/Grep and verify the required input, target/recipient, and side effect; mismatch → `important` issue (category: `consistency`).
+  - Required behavior remains unverifiable after direct inspection → `important` issue (category: `feasibility`) naming the exact missing evidence.
 - **Behavioral claim evidence check**: Scan the Design Doc for behavioral or factual claims it relies on — framework/library default behavior, a capability assumed already provided, or a feature assumed already implemented; declarative phrasing such as "already", "by default", "defaults to", or "handled by" marks likely scan starting points (a hint set, not exhaustive). For each such claim, verify the Agreement Checklist "Assumed Behaviors" slot records it with either attached evidence (codebase file:line, command result, or authoritative doc) and Confirmed: Yes, or Confirmed: No plus a matching Risks and Mitigation row (matched by the restated claim) naming how it will be verified or guarded. A relied-upon behavioral claim absent from the slot, Confirmed: Yes without attached evidence, or Confirmed: No with no matching Risks and Mitigation row → `important` issue (category: `feasibility`)
 - **As-is implementation document review**: When code verification results are provided and the document describes existing implementation (not future requirements), verify that code-observable behaviors are stated as facts; speculative language about deterministic behavior → `important` issue
 - **Data design completeness check**: When document contains data-storage keywords (database, persistence, storage, migration) or data-access keywords (repository, query, ORM, SQL) or data-schema keywords (table, schema, column) but lacks data design content (no schema references, no "Test Boundaries" section with data layer strategy, no data model documentation) → `important` issue (category: `completeness`). Note: generic terms like "model", "field", "record", "entity" alone are insufficient to trigger this check — require co-occurrence with at least one data-storage or data-access keyword
diff --git a/dev-skills/.claude-plugin/plugin.json b/dev-skills/.claude-plugin/plugin.json
index f19e7f7..156f929 100644
--- a/dev-skills/.claude-plugin/plugin.json
+++ b/dev-skills/.claude-plugin/plugin.json
@@ -1,7 +1,7 @@
 {
   "name": "dev-skills",
   "description": "Lightweight skills for users with existing workflows - coding best practices, testing principles, and design guidelines without recipe workflows or agents",
-  "version": "0.22.4",
+  "version": "0.22.5",
   "author": {
     "name": "Shinsuke Kagawa",
     "url": "https://github.com/shinpr"
diff --git a/dev-workflows-frontend/.claude-plugin/plugin.json b/dev-workflows-frontend/.claude-plugin/plugin.json
index 13a1e09..ef1233b 100644
--- a/dev-workflows-frontend/.claude-plugin/plugin.json
+++ b/dev-workflows-frontend/.claude-plugin/plugin.json
@@ -1,7 +1,7 @@
 {
   "name": "dev-workflows-frontend",
   "description": "Skills + Subagents for React/TypeScript - Use skills for coding guidance, or run recipe workflows for full orchestrated agentic coding with specialized agents",
-  "version": "0.22.4",
+  "version": "0.22.5",
   "author": {
     "name": "Shinsuke Kagawa",
     "url": "https://github.com/shinpr"
diff --git a/dev-workflows-frontend/agents/document-reviewer.md b/dev-workflows-frontend/agents/document-reviewer.md
index 982fc14..e2bab94 100644
--- a/dev-workflows-frontend/agents/document-reviewer.md
+++ b/dev-workflows-frontend/agents/document-reviewer.md
@@ -32,6 +32,12 @@ You are an AI assistant specialized in technical document review.
   - When provided, use `focusAreas` as the canonical source for Fact Disposition coverage checks
   - Without this input, do not assume focusArea completeness can be verified
 
+- **requirements_verbatim**: Original user requirements (required for DesignDoc creation review)
+  - Use as the canonical requirement list for the Adopted design validity check
+- **confirmed_decisions**: User-confirmed scope and locked decisions (required for DesignDoc creation review)
+  - Use as authoritative refinements and constraints on `requirements_verbatim`
+  - A DesignDoc review with both inputs is a DesignDoc creation review
+
 ## Workflow
 
 ### Step 0: Input Context Analysis (MANDATORY)
@@ -50,6 +56,7 @@ You are an AI assistant specialized in technical document review.
 - For WorkPlan: confirm the plan carries the artifacts the semantic gate is judged against — Design-to-Plan Traceability, Reference Contract Values (when the Design Doc specifies binding observable values), Failure Mode Checklist, Review Scope, Verification Strategy summary, and Proof Strategy. Read the referenced Design Doc(s) so AC / contract / state-transition coverage and the content fidelity of binding observable values can be checked against the plan
 - If `code_verification` provided: extract discrepancy list and reverse coverage gaps; feed into Gate 1 as pre-verified evidence
 - If `codebase_analysis` provided: extract `focusAreas` and their `evidence` values for Gate 0 / Gate 1 Fact Disposition checks
+- For DesignDoc creation review: apply `confirmed_decisions` to `requirements_verbatim` to derive the effective requirements used by the Adopted design validity check
 
 ### Step 2: Target Document Collection
 - Load document specified by target
@@ -82,7 +89,7 @@ For WorkPlan, additionally verify:
 - Consistency check: Detect contradictions between documents
 - Completeness check: Confirm depth and coverage of required elements
 - Rule compliance check: Compatibility with project rules
-- LLM-facing artifact clarity check: Review the target document against llm-friendly-context; classify unresolved alternatives or optional behavior that can cause divergent downstream execution as `important` (category: `clarity`), and missing required target/action/source/output that makes downstream work non-executable as `critical` (category: `clarity`).
+- LLM-facing artifact clarity check: Review the target document against llm-friendly-context, using `confirmed_decisions` in DesignDoc creation review to distinguish resolved choices from unresolved alternatives; classify unresolved alternatives or optional behavior that can cause divergent downstream execution as `important` (category: `clarity`), and missing required target/action/source/output that makes downstream work non-executable as `critical` (category: `clarity`).
 - Implementation sample compliance: Verify code examples comply with coding-principles skill standards
 - Common ADR compliance: Verify common technical areas are covered by appropriate ADR references
 - Feasibility check: Technical and resource perspectives
@@ -92,6 +99,12 @@ For WorkPlan, additionally verify:
 - Failure scenario review: Identify failure scenarios across normal usage, high load, and external failures; specify which design element becomes the bottleneck
 - Code inspection evidence review: Verify inspected files are relevant to design scope; flag if key related files are missing
 - Dependency realizability check: For each dependency the Design Doc's Existing Codebase Analysis section describes as "existing", verify its definition exists in the codebase using Grep/Glob. Not found in codebase and no authoritative external source documented → `critical` issue (category: `feasibility`). Found but definition signature (method names, parameter types, return types) diverges from Design Doc description → `important` issue (category: `consistency`)
+- **Adopted design validity check** (DesignDoc creation review):
+  - For each effective requirement, verify that an adopted flow reaches its required observable outcome or that concrete design or verification evidence satisfies it; neither → `critical` issue (category: `feasibility`).
+  - For each cross-component step in an adopted flow, compare the producer output with the consumer input; conflict → `critical` issue (category: `consistency`).
+  - For each required side effect in an adopted flow, identify the owning component; no owner → `critical` issue (category: `feasibility`).
+  - For each reused component, inspect its definition and call sites with Read/Grep and verify the required input, target/recipient, and side effect; mismatch → `important` issue (category: `consistency`).
+  - Required behavior remains unverifiable after direct inspection → `important` issue (category: `feasibility`) naming the exact missing evidence.
 - **Behavioral claim evidence check**: Scan the Design Doc for behavioral or factual claims it relies on — framework/library default behavior, a capability assumed already provided, or a feature assumed already implemented; declarative phrasing such as "already", "by default", "defaults to", or "handled by" marks likely scan starting points (a hint set, not exhaustive). For each such claim, verify the Agreement Checklist "Assumed Behaviors" slot records it with either attached evidence (codebase file:line, command result, or authoritative doc) and Confirmed: Yes, or Confirmed: No plus a matching Risks and Mitigation row (matched by the restated claim) naming how it will be verified or guarded. A relied-upon behavioral claim absent from the slot, Confirmed: Yes without attached evidence, or Confirmed: No with no matching Risks and Mitigation row → `important` issue (category: `feasibility`)
 - **As-is implementation document review**: When code verification results are provided and the document describes existing implementation (not future requirements), verify that code-observable behaviors are stated as facts; speculative language about deterministic behavior → `important` issue
 - **Data design completeness check**: When document contains data-storage keywords (database, persistence, storage, migration) or data-access keywords (repository, query, ORM, SQL) or data-schema keywords (table, schema, column) but lacks data design content (no schema references, no "Test Boundaries" section with data layer strategy, no data model documentation) → `important` issue (category: `completeness`). Note: generic terms like "model", "field", "record", "entity" alone are insufficient to trigger this check — require co-occurrence with at least one data-storage or data-access keyword
diff --git a/dev-workflows-frontend/skills/recipe-front-design/SKILL.md b/dev-workflows-frontend/skills/recipe-front-design/SKILL.md
index 6a182d7..a010da2 100644
--- a/dev-workflows-frontend/skills/recipe-front-design/SKILL.md
+++ b/dev-workflows-frontend/skills/recipe-front-design/SKILL.md
@@ -142,12 +142,14 @@ Then create the UI Specification:
 ### Step 7: Design Document Creation Phase
 technical-designer-frontend presents at least two architecture alternatives (technology selection, data flow design) with trade-offs for each. Pass the Step 2 codebase-analyzer output and the Step 5 ui-analyzer output:
 - Invoke **technical-designer-frontend** using Agent tool
-  - For ADR: `subagent_type: "dev-workflows-frontend:technical-designer-frontend"`, `description: "ADR creation"`, `prompt: "Create ADR for [technical decision]. Requirements: [user requirements verbatim]. Codebase analysis: [codebase-analyzer JSON from Step 2]. UI analysis: [ui-analyzer JSON from Step 5]. Confirmed scope: [Step 3 confirmed scope]. Present at least two alternatives with trade-offs."`
-  - For Design Doc: `subagent_type: "dev-workflows-frontend:technical-designer-frontend"`, `description: "Design Doc creation"`, `prompt: "Create Design Doc based on the requirements. Requirements: [user requirements verbatim]. Codebase analysis: [codebase-analyzer JSON from Step 2]. UI analysis: [ui-analyzer JSON from Step 5]. UI Spec is at [ui-spec path]. Inherit component structure and state design from UI Spec. Apply code: prefix to codebase-analyzer fact_ids and ui: prefix to ui-analyzer fact_ids when filling the Fact Disposition Table. Present at least two architecture alternatives with trade-offs."`
+  - For ADR: `subagent_type: "dev-workflows-frontend:technical-designer-frontend"`, `description: "ADR creation"`, `prompt: "Create ADR for [technical decision]. Requirements: [user requirements verbatim]. Codebase analysis: [codebase-analyzer JSON from Step 2]. UI analysis: [ui-analyzer JSON from Step 5]. Confirmed scope and user answers: [Step 3 confirmed scope and user answers]. Present at least two alternatives with trade-offs."`
+  - For Design Doc: `subagent_type: "dev-workflows-frontend:technical-designer-frontend"`, `description: "Design Doc creation"`, `prompt: "Create Design Doc based on the requirements. Requirements: [user requirements verbatim]. Codebase analysis: [codebase-analyzer JSON from Step 2]. UI analysis: [ui-analyzer JSON from Step 5]. Confirmed scope and user answers: [Step 3 confirmed scope and user answers]. UI Spec is at [ui-spec path]. Inherit component structure and state design from UI Spec. Apply code: prefix to codebase-analyzer fact_ids and ui: prefix to ui-analyzer fact_ids when filling the Fact Disposition Table. Present at least two architecture alternatives with trade-offs."`
 - **(Design Doc only)** Invoke **code-verifier** to verify Design Doc against existing code. Skip for ADR.
   - `subagent_type: "dev-workflows-frontend:code-verifier"`, `description: "Design Doc verification"`, `prompt: "doc_type: design-doc document_path: [Design Doc path] Verify Design Doc against existing code."`
-- Invoke **document-reviewer** to verify consistency (pass code-verifier results for Design Doc; omit for ADR)
-  - `subagent_type: "dev-workflows-frontend:document-reviewer"`, `description: "Document review"`, `prompt: "Review [document path] for consistency and completeness. codebase_analysis: [codebase-analyzer JSON from Step 2]. ui_analysis: [ui-analyzer JSON from Step 5]. code_verification: [code verification output from this step] (Design Doc only)"`
+- **(Design Doc only)** Invoke **document-reviewer** to verify consistency, completeness, and adopted design validity
+  - `subagent_type: "dev-workflows-frontend:document-reviewer"`, `description: "Design Doc review"`, `prompt: "Review [Design Doc path] for consistency, completeness, and adopted design validity. doc_type: DesignDoc. requirements_verbatim: [user requirements verbatim]. confirmed_decisions: [Step 3 confirmed scope and user answers]. codebase_analysis: [codebase-analyzer JSON from Step 2]. ui_analysis: [ui-analyzer JSON from Step 5]. code_verification: [code verification output from this step]"`
+- **(ADR only)** Invoke **document-reviewer** to verify consistency and completeness
+  - `subagent_type: "dev-workflows-frontend:document-reviewer"`, `description: "ADR review"`, `prompt: "Review [ADR path] for consistency and completeness. doc_type: ADR. codebase_analysis: [codebase-analyzer JSON from Step 2]. ui_analysis: [ui-analyzer JSON from Step 5]"`
 
 ### Step 8: Design Consistency Verification
 - **(Design Doc only)** Invoke **design-sync** using Agent tool. Skip for ADR-only.
diff --git a/dev-workflows-fullstack/.claude-plugin/plugin.json b/dev-workflows-fullstack/.claude-plugin/plugin.json
index fe866f3..7411881 100644
--- a/dev-workflows-fullstack/.claude-plugin/plugin.json
+++ b/dev-workflows-fullstack/.claude-plugin/plugin.json
@@ -1,7 +1,7 @@
 {
   "name": "dev-workflows-fullstack",
   "description": "Skills + Subagents for fullstack development (backend + React/TypeScript) - Use skills for coding guidance, or run recipe workflows for full orchestrated agentic coding with specialized agents",
-  "version": "0.22.4",
+  "version": "0.22.5",
   "author": {
     "name": "Shinsuke Kagawa",
     "url": "https://github.com/shinpr"
diff --git a/dev-workflows-fullstack/agents/document-reviewer.md b/dev-workflows-fullstack/agents/document-reviewer.md
index 982fc14..e2bab94 100644
--- a/dev-workflows-fullstack/agents/document-reviewer.md
+++ b/dev-workflows-fullstack/agents/document-reviewer.md
@@ -32,6 +32,12 @@ You are an AI assistant specialized in technical document review.
   - When provided, use `focusAreas` as the canonical source for Fact Disposition coverage checks
   - Without this input, do not assume focusArea completeness can be verified
 
+- **requirements_verbatim**: Original user requirements (required for DesignDoc creation review)
+  - Use as the canonical requirement list for the Adopted design validity check
+- **confirmed_decisions**: User-confirmed scope and locked decisions (required for DesignDoc creation review)
+  - Use as authoritative refinements and constraints on `requirements_verbatim`
+  - A DesignDoc review with both inputs is a DesignDoc creation review
+
 ## Workflow
 
 ### Step 0: Input Context Analysis (MANDATORY)
@@ -50,6 +56,7 @@ You are an AI assistant specialized in technical document review.
 - For WorkPlan: confirm the plan carries the artifacts the semantic gate is judged against — Design-to-Plan Traceability, Reference Contract Values (when the Design Doc specifies binding observable values), Failure Mode Checklist, Review Scope, Verification Strategy summary, and Proof Strategy. Read the referenced Design Doc(s) so AC / contract / state-transition coverage and the content fidelity of binding observable values can be checked against the plan
 - If `code_verification` provided: extract discrepancy list and reverse coverage gaps; feed into Gate 1 as pre-verified evidence
 - If `codebase_analysis` provided: extract `focusAreas` and their `evidence` values for Gate 0 / Gate 1 Fact Disposition checks
+- For DesignDoc creation review: apply `confirmed_decisions` to `requirements_verbatim` to derive the effective requirements used by the Adopted design validity check
 
 ### Step 2: Target Document Collection
 - Load document specified by target
@@ -82,7 +89,7 @@ For WorkPlan, additionally verify:
 - Consistency check: Detect contradictions between documents
 - Completeness check: Confirm depth and coverage of required elements
 - Rule compliance check: Compatibility with project rules
-- LLM-facing artifact clarity check: Review the target document against llm-friendly-context; classify unresolved alternatives or optional behavior that can cause divergent downstream execution as `important` (category: `clarity`), and missing required target/action/source/output that makes downstream work non-executable as `critical` (category: `clarity`).
+- LLM-facing artifact clarity check: Review the target document against llm-friendly-context, using `confirmed_decisions` in DesignDoc creation review to distinguish resolved choices from unresolved alternatives; classify unresolved alternatives or optional behavior that can cause divergent downstream execution as `important` (category: `clarity`), and missing required target/action/source/output that makes downstream work non-executable as `critical` (category: `clarity`).
 - Implementation sample compliance: Verify code examples comply with coding-principles skill standards
 - Common ADR compliance: Verify common technical areas are covered by appropriate ADR references
 - Feasibility check: Technical and resource perspectives
@@ -92,6 +99,12 @@ For WorkPlan, additionally verify:
 - Failure scenario review: Identify failure scenarios across normal usage, high load, and external failures; specify which design element becomes the bottleneck
 - Code inspection evidence review: Verify inspected files are relevant to design scope; flag if key related files are missing
 - Dependency realizability check: For each dependency the Design Doc's Existing Codebase Analysis section describes as "existing", verify its definition exists in the codebase using Grep/Glob. Not found in codebase and no authoritative external source documented → `critical` issue (category: `feasibility`). Found but definition signature (method names, parameter types, return types) diverges from Design Doc description → `important` issue (category: `consistency`)
+- **Adopted design validity check** (DesignDoc creation review):
+  - For each effective requirement, verify that an adopted flow reaches its required observable outcome or that concrete design or verification evidence satisfies it; neither → `critical` issue (category: `feasibility`).
+  - For each cross-component step in an adopted flow, compare the producer output with the consumer input; conflict → `critical` issue (category: `consistency`).
+  - For each required side effect in an adopted flow, identify the owning component; no owner → `critical` issue (category: `feasibility`).
+  - For each reused component, inspect its definition and call sites with Read/Grep and verify the required input, target/recipient, and side effect; mismatch → `important` issue (category: `consistency`).
+  - Required behavior remains unverifiable after direct inspection → `important` issue (category: `feasibility`) naming the exact missing evidence.
 - **Behavioral claim evidence check**: Scan the Design Doc for behavioral or factual claims it relies on — framework/library default behavior, a capability assumed already provided, or a feature assumed already implemented; declarative phrasing such as "already", "by default", "defaults to", or "handled by" marks likely scan starting points (a hint set, not exhaustive). For each such claim, verify the Agreement Checklist "Assumed Behaviors" slot records it with either attached evidence (codebase file:line, command result, or authoritative doc) and Confirmed: Yes, or Confirmed: No plus a matching Risks and Mitigation row (matched by the restated claim) naming how it will be verified or guarded. A relied-upon behavioral claim absent from the slot, Confirmed: Yes without attached evidence, or Confirmed: No with no matching Risks and Mitigation row → `important` issue (category: `feasibility`)
 - **As-is implementation document review**: When code verification results are provided and the document describes existing implementation (not future requirements), verify that code-observable behaviors are stated as facts; speculative language about deterministic behavior → `important` issue
 - **Data design completeness check**: When document contains data-storage keywords (database, persistence, storage, migration) or data-access keywords (repository, query, ORM, SQL) or data-schema keywords (table, schema, column) but lacks data design content (no schema references, no "Test Boundaries" section with data layer strategy, no data model documentation) → `important` issue (category: `completeness`). Note: generic terms like "model", "field", "record", "entity" alone are insufficient to trigger this check — require co-occurrence with at least one data-storage or data-access keyword
diff --git a/dev-workflows-fullstack/skills/recipe-design/SKILL.md b/dev-workflows-fullstack/skills/recipe-design/SKILL.md
index bff3f92..f47f4b2 100644
--- a/dev-workflows-fullstack/skills/recipe-design/SKILL.md
+++ b/dev-workflows-fullstack/skills/recipe-design/SKILL.md
@@ -98,12 +98,14 @@ After the user confirms the scope, count the confirmed target files and set the
 Pass the full codebase-analyzer JSON to technical-designer (handoff contract HC-02). technical-designer presents at least two design alternatives with trade-offs for each.
 
 - Invoke **technical-designer** using Agent tool
-  - For Design Doc: `subagent_type: "dev-workflows-fullstack:technical-designer"`, `description: "Design Doc creation"`, `prompt: "Create Design Doc based on the requirements. Requirements: [user requirements verbatim]. Codebase analysis: [codebase-analyzer JSON from Step 2]. Confirmed scope: [Step 3 confirmed scope]. Apply the code: prefix to codebase-analyzer fact_ids when filling the Fact Disposition Table. Present at least two architecture alternatives with trade-offs."`
-  - For ADR: `subagent_type: "dev-workflows-fullstack:technical-designer"`, `description: "ADR creation"`, `prompt: "Create ADR for [technical decision]. Requirements: [user requirements verbatim]. Codebase analysis: [codebase-analyzer JSON from Step 2]. Confirmed scope: [Step 3 confirmed scope]. Present at least two alternatives with trade-offs."`
+  - For Design Doc: `subagent_type: "dev-workflows-fullstack:technical-designer"`, `description: "Design Doc creation"`, `prompt: "Create Design Doc based on the requirements. Requirements: [user requirements verbatim]. Codebase analysis: [codebase-analyzer JSON from Step 2]. Confirmed scope and user answers: [Step 3 confirmed scope and user answers]. Apply the code: prefix to codebase-analyzer fact_ids when filling the Fact Disposition Table. Present at least two architecture alternatives with trade-offs."`
+  - For ADR: `subagent_type: "dev-workflows-fullstack:technical-designer"`, `description: "ADR creation"`, `prompt: "Create ADR for [technical decision]. Requirements: [user requirements verbatim]. Codebase analysis: [codebase-analyzer JSON from Step 2]. Confirmed scope and user answers: [Step 3 confirmed scope and user answers]. Present at least two alternatives with trade-offs."`
 - **(Design Doc only)** Invoke **code-verifier** to verify the Design Doc against existing code. Skip for ADR.
   - `subagent_type: "dev-workflows-fullstack:code-verifier"`, `description: "Design Doc verification"`, `prompt: "doc_type: design-doc document_path: [Design Doc path] Verify Design Doc against existing code."`
-- Invoke **document-reviewer** to verify consistency (pass code-verifier results for Design Doc; omit for ADR)
-  - `subagent_type: "dev-workflows-fullstack:document-reviewer"`, `description: "Document review"`, `prompt: "Review [document path] for consistency and completeness. codebase_analysis: [codebase-analyzer JSON from Step 2]. code_verification: [code-verifier output from this step] (Design Doc only)"`
+- **(Design Doc only)** Invoke **document-reviewer** to verify consistency, completeness, and adopted design validity
+  - `subagent_type: "dev-workflows-fullstack:document-reviewer"`, `description: "Design Doc review"`, `prompt: "Review [Design Doc path] for consistency, completeness, and adopted design validity. doc_type: DesignDoc. requirements_verbatim: [user requirements verbatim]. confirmed_decisions: [Step 3 confirmed scope and user answers]. codebase_analysis: [codebase-analyzer JSON from Step 2]. code_verification: [code-verifier output from this step]"`
+- **(ADR only)** Invoke **document-reviewer** to verify consistency and completeness
+  - `subagent_type: "dev-workflows-fullstack:document-reviewer"`, `description: "ADR review"`, `prompt: "Review [ADR path] for consistency and completeness. doc_type: ADR. codebase_analysis: [codebase-analyzer JSON from Step 2]"`
 - **(Design Doc only)** Invoke **design-sync** to verify consistency across design documents. Skip for ADR-only.
   - `subagent_type: "dev-workflows-fullstack:design-sync"`, `description: "Design consistency check"`, `prompt: "Check consistency across all Design Docs in docs/design/. Report conflicts and overlaps."`
 
diff --git a/dev-workflows-fullstack/skills/recipe-front-design/SKILL.md b/dev-workflows-fullstack/skills/recipe-front-design/SKILL.md
index fc5fc17..d2831c4 100644
--- a/dev-workflows-fullstack/skills/recipe-front-design/SKILL.md
+++ b/dev-workflows-fullstack/skills/recipe-front-design/SKILL.md
@@ -142,12 +142,14 @@ Then create the UI Specification:
 ### Step 7: Design Document Creation Phase
 technical-designer-frontend presents at least two architecture alternatives (technology selection, data flow design) with trade-offs for each. Pass the Step 2 codebase-analyzer output and the Step 5 ui-analyzer output:
 - Invoke **technical-designer-frontend** using Agent tool
-  - For ADR: `subagent_type: "dev-workflows-fullstack:technical-designer-frontend"`, `description: "ADR creation"`, `prompt: "Create ADR for [technical decision]. Requirements: [user requirements verbatim]. Codebase analysis: [codebase-analyzer JSON from Step 2]. UI analysis: [ui-analyzer JSON from Step 5]. Confirmed scope: [Step 3 confirmed scope]. Present at least two alternatives with trade-offs."`
-  - For Design Doc: `subagent_type: "dev-workflows-fullstack:technical-designer-frontend"`, `description: "Design Doc creation"`, `prompt: "Create Design Doc based on the requirements. Requirements: [user requirements verbatim]. Codebase analysis: [codebase-analyzer JSON from Step 2]. UI analysis: [ui-analyzer JSON from Step 5]. UI Spec is at [ui-spec path]. Inherit component structure and state design from UI Spec. Apply code: prefix to codebase-analyzer fact_ids and ui: prefix to ui-analyzer fact_ids when filling the Fact Disposition Table. Present at least two architecture alternatives with trade-offs."`
+  - For ADR: `subagent_type: "dev-workflows-fullstack:technical-designer-frontend"`, `description: "ADR creation"`, `prompt: "Create ADR for [technical decision]. Requirements: [user requirements verbatim]. Codebase analysis: [codebase-analyzer JSON from Step 2]. UI analysis: [ui-analyzer JSON from Step 5]. Confirmed scope and user answers: [Step 3 confirmed scope and user answers]. Present at least two alternatives with trade-offs."`
+  - For Design Doc: `subagent_type: "dev-workflows-fullstack:technical-designer-frontend"`, `description: "Design Doc creation"`, `prompt: "Create Design Doc based on the requirements. Requirements: [user requirements verbatim]. Codebase analysis: [codebase-analyzer JSON from Step 2]. UI analysis: [ui-analyzer JSON from Step 5]. Confirmed scope and user answers: [Step 3 confirmed scope and user answers]. UI Spec is at [ui-spec path]. Inherit component structure and state design from UI Spec. Apply code: prefix to codebase-analyzer fact_ids and ui: prefix to ui-analyzer fact_ids when filling the Fact Disposition Table. Present at least two architecture alternatives with trade-offs."`
 - **(Design Doc only)** Invoke **code-verifier** to verify Design Doc against existing code. Skip for ADR.
   - `subagent_type: "dev-workflows-fullstack:code-verifier"`, `description: "Design Doc verification"`, `prompt: "doc_type: design-doc document_path: [Design Doc path] Verify Design Doc against existing code."`
-- Invoke **document-reviewer** to verify consistency (pass code-verifier results for Design Doc; omit for ADR)
-  - `subagent_type: "dev-workflows-fullstack:document-reviewer"`, `description: "Document review"`, `prompt: "Review [document path] for consistency and completeness. codebase_analysis: [codebase-analyzer JSON from Step 2]. ui_analysis: [ui-analyzer JSON from Step 5]. code_verification: [code verification output from this step] (Design Doc only)"`
+- **(Design Doc only)** Invoke **document-reviewer** to verify consistency, completeness, and adopted design validity
+  - `subagent_type: "dev-workflows-fullstack:document-reviewer"`, `description: "Design Doc review"`, `prompt: "Review [Design Doc path] for consistency, completeness, and adopted design validity. doc_type: DesignDoc. requirements_verbatim: [user requirements verbatim]. confirmed_decisions: [Step 3 confirmed scope and user answers]. codebase_analysis: [codebase-analyzer JSON from Step 2]. ui_analysis: [ui-analyzer JSON from Step 5]. code_verification: [code verification output from this step]"`
+- **(ADR only)** Invoke **document-reviewer** to verify consistency and completeness
+  - `subagent_type: "dev-workflows-fullstack:document-reviewer"`, `description: "ADR review"`, `prompt: "Review [ADR path] for consistency and completeness. doc_type: ADR. codebase_analysis: [codebase-analyzer JSON from Step 2]. ui_analysis: [ui-analyzer JSON from Step 5]"`
 
 ### Step 8: Design Consistency Verification
 - **(Design Doc only)** Invoke **design-sync** using Agent tool. Skip for ADR-only.
diff --git a/dev-workflows/.claude-plugin/plugin.json b/dev-workflows/.claude-plugin/plugin.json
index d533568..bdcfeae 100644
--- a/dev-workflows/.claude-plugin/plugin.json
+++ b/dev-workflows/.claude-plugin/plugin.json
@@ -1,7 +1,7 @@
 {
   "name": "dev-workflows",
   "description": "Skills + Subagents for backend development - Use skills for coding guidance, or run recipe workflows for full orchestrated agentic coding with specialized agents",
-  "version": "0.22.4",
+  "version": "0.22.5",
   "author": {
     "name": "Shinsuke Kagawa",
     "url": "https://github.com/shinpr"
diff --git a/dev-workflows/agents/document-reviewer.md b/dev-workflows/agents/document-reviewer.md
index 982fc14..e2bab94 100644
--- a/dev-workflows/agents/document-reviewer.md
+++ b/dev-workflows/agents/document-reviewer.md
@@ -32,6 +32,12 @@ You are an AI assistant specialized in technical document review.
   - When provided, use `focusAreas` as the canonical source for Fact Disposition coverage checks
   - Without this input, do not assume focusArea completeness can be verified
 
+- **requirements_verbatim**: Original user requirements (required for DesignDoc creation review)
+  - Use as the canonical requirement list for the Adopted design validity check
+- **confirmed_decisions**: User-confirmed scope and locked decisions (required for DesignDoc creation review)
+  - Use as authoritative refinements and constraints on `requirements_verbatim`
+  - A DesignDoc review with both inputs is a DesignDoc creation review
+
 ## Workflow
 
 ### Step 0: Input Context Analysis (MANDATORY)
@@ -50,6 +56,7 @@ You are an AI assistant specialized in technical document review.
 - For WorkPlan: confirm the plan carries the artifacts the semantic gate is judged against — Design-to-Plan Traceability, Reference Contract Values (when the Design Doc specifies binding observable values), Failure Mode Checklist, Review Scope, Verification Strategy summary, and Proof Strategy. Read the referenced Design Doc(s) so AC / contract / state-transition coverage and the content fidelity of binding observable values can be checked against the plan
 - If `code_verification` provided: extract discrepancy list and reverse coverage gaps; feed into Gate 1 as pre-verified evidence
 - If `codebase_analysis` provided: extract `focusAreas` and their `evidence` values for Gate 0 / Gate 1 Fact Disposition checks
+- For DesignDoc creation review: apply `confirmed_decisions` to `requirements_verbatim` to derive the effective requirements used by the Adopted design validity check
 
 ### Step 2: Target Document Collection
 - Load document specified by target
@@ -82,7 +89,7 @@ For WorkPlan, additionally verify:
 - Consistency check: Detect contradictions between documents
 - Completeness check: Confirm depth and coverage of required elements
 - Rule compliance check: Compatibility with project rules
-- LLM-facing artifact clarity check: Review the target document against llm-friendly-context; classify unresolved alternatives or optional behavior that can cause divergent downstream execution as `important` (category: `clarity`), and missing required target/action/source/output that makes downstream work non-executable as `critical` (category: `clarity`).
+- LLM-facing artifact clarity check: Review the target document against llm-friendly-context, using `confirmed_decisions` in DesignDoc creation review to distinguish resolved choices from unresolved alternatives; classify unresolved alternatives or optional behavior that can cause divergent downstream execution as `important` (category: `clarity`), and missing required target/action/source/output that makes downstream work non-executable as `critical` (category: `clarity`).
 - Implementation sample compliance: Verify code examples comply with coding-principles skill standards
 - Common ADR compliance: Verify common technical areas are covered by appropriate ADR references
 - Feasibility check: Technical and resource perspectives
@@ -92,6 +99,12 @@ For WorkPlan, additionally verify:
 - Failure scenario review: Identify failure scenarios across normal usage, high load, and external failures; specify which design element becomes the bottleneck
 - Code inspection evidence review: Verify inspected files are relevant to design scope; flag if key related files are missing
 - Dependency realizability check: For each dependency the Design Doc's Existing Codebase Analysis section describes as "existing", verify its definition exists in the codebase using Grep/Glob. Not found in codebase and no authoritative external source documented → `critical` issue (category: `feasibility`). Found but definition signature (method names, parameter types, return types) diverges from Design Doc description → `important` issue (category: `consistency`)
+- **Adopted design validity check** (DesignDoc creation review):
+  - For each effective requirement, verify that an adopted flow reaches its required observable outcome or that concrete design or verification evidence satisfies it; neither → `critical` issue (category: `feasibility`).
+  - For each cross-component step in an adopted flow, compare the producer output with the consumer input; conflict → `critical` issue (category: `consistency`).
+  - For each required side effect in an adopted flow, identify the owning component; no owner → `critical` issue (category: `feasibility`).
+  - For each reused component, inspect its definition and call sites with Read/Grep and verify the required input, target/recipient, and side effect; mismatch → `important` issue (category: `consistency`).
+  - Required behavior remains unverifiable after direct inspection → `important` issue (category: `feasibility`) naming the exact missing evidence.
 - **Behavioral claim evidence check**: Scan the Design Doc for behavioral or factual claims it relies on — framework/library default behavior, a capability assumed already provided, or a feature assumed already implemented; declarative phrasing such as "already", "by default", "defaults to", or "handled by" marks likely scan starting points (a hint set, not exhaustive). For each such claim, verify the Agreement Checklist "Assumed Behaviors" slot records it with either attached evidence (codebase file:line, command result, or authoritative doc) and Confirmed: Yes, or Confirmed: No plus a matching Risks and Mitigation row (matched by the restated claim) naming how it will be verified or guarded. A relied-upon behavioral claim absent from the slot, Confirmed: Yes without attached evidence, or Confirmed: No with no matching Risks and Mitigation row → `important` issue (category: `feasibility`)
 - **As-is implementation document review**: When code verification results are provided and the document describes existing implementation (not future requirements), verify that code-observable behaviors are stated as facts; speculative language about deterministic behavior → `important` issue
 - **Data design completeness check**: When document contains data-storage keywords (database, persistence, storage, migration) or data-access keywords (repository, query, ORM, SQL) or data-schema keywords (table, schema, column) but lacks data design content (no schema references, no "Test Boundaries" section with data layer strategy, no data model documentation) → `important` issue (category: `completeness`). Note: generic terms like "model", "field", "record", "entity" alone are insufficient to trigger this check — require co-occurrence with at least one data-storage or data-access keyword
diff --git a/dev-workflows/skills/recipe-design/SKILL.md b/dev-workflows/skills/recipe-design/SKILL.md
index 2c92c13..f7b86bc 100644
--- a/dev-workflows/skills/recipe-design/SKILL.md
+++ b/dev-workflows/skills/recipe-design/SKILL.md
@@ -98,12 +98,14 @@ After the user confirms the scope, count the confirmed target files and set the
 Pass the full codebase-analyzer JSON to technical-designer (handoff contract HC-02). technical-designer presents at least two design alternatives with trade-offs for each.
 
 - Invoke **technical-designer** using Agent tool
-  - For Design Doc: `subagent_type: "dev-workflows:technical-designer"`, `description: "Design Doc creation"`, `prompt: "Create Design Doc based on the requirements. Requirements: [user requirements verbatim]. Codebase analysis: [codebase-analyzer JSON from Step 2]. Confirmed scope: [Step 3 confirmed scope]. Apply the code: prefix to codebase-analyzer fact_ids when filling the Fact Disposition Table. Present at least two architecture alternatives with trade-offs."`
-  - For ADR: `subagent_type: "dev-workflows:technical-designer"`, `description: "ADR creation"`, `prompt: "Create ADR for [technical decision]. Requirements: [user requirements verbatim]. Codebase analysis: [codebase-analyzer JSON from Step 2]. Confirmed scope: [Step 3 confirmed scope]. Present at least two alternatives with trade-offs."`
+  - For Design Doc: `subagent_type: "dev-workflows:technical-designer"`, `description: "Design Doc creation"`, `prompt: "Create Design Doc based on the requirements. Requirements: [user requirements verbatim]. Codebase analysis: [codebase-analyzer JSON from Step 2]. Confirmed scope and user answers: [Step 3 confirmed scope and user answers]. Apply the code: prefix to codebase-analyzer fact_ids when filling the Fact Disposition Table. Present at least two architecture alternatives with trade-offs."`
+  - For ADR: `subagent_type: "dev-workflows:technical-designer"`, `description: "ADR creation"`, `prompt: "Create ADR for [technical decision]. Requirements: [user requirements verbatim]. Codebase analysis: [codebase-analyzer JSON from Step 2]. Confirmed scope and user answers: [Step 3 confirmed scope and user answers]. Present at least two alternatives with trade-offs."`
 - **(Design Doc only)** Invoke **code-verifier** to verify the Design Doc against existing code. Skip for ADR.
   - `subagent_type: "dev-workflows:code-verifier"`, `description: "Design Doc verification"`, `prompt: "doc_type: design-doc document_path: [Design Doc path] Verify Design Doc against existing code."`
-- Invoke **document-reviewer** to verify consistency (pass code-verifier results for Design Doc; omit for ADR)
-  - `subagent_type: "dev-workflows:document-reviewer"`, `description: "Document review"`, `prompt: "Review [document path] for consistency and completeness. codebase_analysis: [codebase-analyzer JSON from Step 2]. code_verification: [code-verifier output from this step] (Design Doc only)"`
+- **(Design Doc only)** Invoke **document-reviewer** to verify consistency, completeness, and adopted design validity
+  - `subagent_type: "dev-workflows:document-reviewer"`, `description: "Design Doc review"`, `prompt: "Review [Design Doc path] for consistency, completeness, and adopted design validity. doc_type: DesignDoc. requirements_verbatim: [user requirements verbatim]. confirmed_decisions: [Step 3 confirmed scope and user answers]. codebase_analysis: [codebase-analyzer JSON from Step 2]. code_verification: [code-verifier output from this step]"`
+- **(ADR only)** Invoke **document-reviewer** to verify consistency and completeness
+  - `subagent_type: "dev-workflows:document-reviewer"`, `description: "ADR review"`, `prompt: "Review [ADR path] for consistency and completeness. doc_type: ADR. codebase_analysis: [codebase-analyzer JSON from Step 2]"`
 - **(Design Doc only)** Invoke **design-sync** to verify consistency across design documents. Skip for ADR-only.
   - `subagent_type: "dev-workflows:design-sync"`, `description: "Design consistency check"`, `prompt: "Check consistency across all Design Docs in docs/design/. Report conflicts and overlaps."`
 
diff --git a/package.json b/package.json
index eea8929..b9001fa 100644
--- a/package.json
+++ b/package.json
@@ -1,6 +1,6 @@
 {
   "name": "claude-code-workflows",
-  "version": "0.22.4",
+  "version": "0.22.5",
   "private": true,
   "type": "module",
   "engines": {
diff --git a/skills/recipe-design/SKILL.md b/skills/recipe-design/SKILL.md
index 2c92c13..f7b86bc 100644
--- a/skills/recipe-design/SKILL.md
+++ b/skills/recipe-design/SKILL.md
@@ -98,12 +98,14 @@ After the user confirms the scope, count the confirmed target files and set the
 Pass the full codebase-analyzer JSON to technical-designer (handoff contract HC-02). technical-designer presents at least two design alternatives with trade-offs for each.
 
 - Invoke **technical-designer** using Agent tool
-  - For Design Doc: `subagent_type: "dev-workflows:technical-designer"`, `description: "Design Doc creation"`, `prompt: "Create Design Doc based on the requirements. Requirements: [user requirements verbatim]. Codebase analysis: [codebase-analyzer JSON from Step 2]. Confirmed scope: [Step 3 confirmed scope]. Apply the code: prefix to codebase-analyzer fact_ids when filling the Fact Disposition Table. Present at least two architecture alternatives with trade-offs."`
-  - For ADR: `subagent_type: "dev-workflows:technical-designer"`, `description: "ADR creation"`, `prompt: "Create ADR for [technical decision]. Requirements: [user requirements verbatim]. Codebase analysis: [codebase-analyzer JSON from Step 2]. Confirmed scope: [Step 3 confirmed scope]. Present at least two alternatives with trade-offs."`
+  - For Design Doc: `subagent_type: "dev-workflows:technical-designer"`, `description: "Design Doc creation"`, `prompt: "Create Design Doc based on the requirements. Requirements: [user requirements verbatim]. Codebase analysis: [codebase-analyzer JSON from Step 2]. Confirmed scope and user answers: [Step 3 confirmed scope and user answers]. Apply the code: prefix to codebase-analyzer fact_ids when filling the Fact Disposition Table. Present at least two architecture alternatives with trade-offs."`
+  - For ADR: `subagent_type: "dev-workflows:technical-designer"`, `description: "ADR creation"`, `prompt: "Create ADR for [technical decision]. Requirements: [user requirements verbatim]. Codebase analysis: [codebase-analyzer JSON from Step 2]. Confirmed scope and user answers: [Step 3 confirmed scope and user answers]. Present at least two alternatives with trade-offs."`
 - **(Design Doc only)** Invoke **code-verifier** to verify the Design Doc against existing code. Skip for ADR.
   - `subagent_type: "dev-workflows:code-verifier"`, `description: "Design Doc verification"`, `prompt: "doc_type: design-doc document_path: [Design Doc path] Verify Design Doc against existing code."`
-- Invoke **document-reviewer** to verify consistency (pass code-verifier results for Design Doc; omit for ADR)
-  - `subagent_type: "dev-workflows:document-reviewer"`, `description: "Document review"`, `prompt: "Review [document path] for consistency and completeness. codebase_analysis: [codebase-analyzer JSON from Step 2]. code_verification: [code-verifier output from this step] (Design Doc only)"`
+- **(Design Doc only)** Invoke **document-reviewer** to verify consistency, completeness, and adopted design validity
+  - `subagent_type: "dev-workflows:document-reviewer"`, `description: "Design Doc review"`, `prompt: "Review [Design Doc path] for consistency, completeness, and adopted design validity. doc_type: DesignDoc. requirements_verbatim: [user requirements verbatim]. confirmed_decisions: [Step 3 confirmed scope and user answers]. codebase_analysis: [codebase-analyzer JSON from Step 2]. code_verification: [code-verifier output from this step]"`
+- **(ADR only)** Invoke **document-reviewer** to verify consistency and completeness
+  - `subagent_type: "dev-workflows:document-reviewer"`, `description: "ADR review"`, `prompt: "Review [ADR path] for consistency and completeness. doc_type: ADR. codebase_analysis: [codebase-analyzer JSON from Step 2]"`
 - **(Design Doc only)** Invoke **design-sync** to verify consistency across design documents. Skip for ADR-only.
   - `subagent_type: "dev-workflows:design-sync"`, `description: "Design consistency check"`, `prompt: "Check consistency across all Design Docs in docs/design/. Report conflicts and overlaps."`
 
diff --git a/skills/recipe-front-design/SKILL.md b/skills/recipe-front-design/SKILL.md
index 6a182d7..a010da2 100644
--- a/skills/recipe-front-design/SKILL.md
+++ b/skills/recipe-front-design/SKILL.md
@@ -142,12 +142,14 @@ Then create the UI Specification:
 ### Step 7: Design Document Creation Phase
 technical-designer-frontend presents at least two architecture alternatives (technology selection, data flow design) with trade-offs for each. Pass the Step 2 codebase-analyzer output and the Step 5 ui-analyzer output:
 - Invoke **technical-designer-frontend** using Agent tool
-  - For ADR: `subagent_type: "dev-workflows-frontend:technical-designer-frontend"`, `description: "ADR creation"`, `prompt: "Create ADR for [technical decision]. Requirements: [user requirements verbatim]. Codebase analysis: [codebase-analyzer JSON from Step 2]. UI analysis: [ui-analyzer JSON from Step 5]. Confirmed scope: [Step 3 confirmed scope]. Present at least two alternatives with trade-offs."`
-  - For Design Doc: `subagent_type: "dev-workflows-frontend:technical-designer-frontend"`, `description: "Design Doc creation"`, `prompt: "Create Design Doc based on the requirements. Requirements: [user requirements verbatim]. Codebase analysis: [codebase-analyzer JSON from Step 2]. UI analysis: [ui-analyzer JSON from Step 5]. UI Spec is at [ui-spec path]. Inherit component structure and state design from UI Spec. Apply code: prefix to codebase-analyzer fact_ids and ui: prefix to ui-analyzer fact_ids when filling the Fact Disposition Table. Present at least two architecture alternatives with trade-offs."`
+  - For ADR: `subagent_type: "dev-workflows-frontend:technical-designer-frontend"`, `description: "ADR creation"`, `prompt: "Create ADR for [technical decision]. Requirements: [user requirements verbatim]. Codebase analysis: [codebase-analyzer JSON from Step 2]. UI analysis: [ui-analyzer JSON from Step 5]. Confirmed scope and user answers: [Step 3 confirmed scope and user answers]. Present at least two alternatives with trade-offs."`
+  - For Design Doc: `subagent_type: "dev-workflows-frontend:technical-designer-frontend"`, `description: "Design Doc creation"`, `prompt: "Create Design Doc based on the requirements. Requirements: [user requirements verbatim]. Codebase analysis: [codebase-analyzer JSON from Step 2]. UI analysis: [ui-analyzer JSON from Step 5]. Confirmed scope and user answers: [Step 3 confirmed scope and user answers]. UI Spec is at [ui-spec path]. Inherit component structure and state design from UI Spec. Apply code: prefix to codebase-analyzer fact_ids and ui: prefix to ui-analyzer fact_ids when filling the Fact Disposition Table. Present at least two architecture alternatives with trade-offs."`
 - **(Design Doc only)** Invoke **code-verifier** to verify Design Doc against existing code. Skip for ADR.
   - `subagent_type: "dev-workflows-frontend:code-verifier"`, `description: "Design Doc verification"`, `prompt: "doc_type: design-doc document_path: [Design Doc path] Verify Design Doc against existing code."`
-- Invoke **document-reviewer** to verify consistency (pass code-verifier results for Design Doc; omit for ADR)
-  - `subagent_type: "dev-workflows-frontend:document-reviewer"`, `description: "Document review"`, `prompt: "Review [document path] for consistency and completeness. codebase_analysis: [codebase-analyzer JSON from Step 2]. ui_analysis: [ui-analyzer JSON from Step 5]. code_verification: [code verification output from this step] (Design Doc only)"`
+- **(Design Doc only)** Invoke **document-reviewer** to verify consistency, completeness, and adopted design validity
+  - `subagent_type: "dev-workflows-frontend:document-reviewer"`, `description: "Design Doc review"`, `prompt: "Review [Design Doc path] for consistency, completeness, and adopted design validity. doc_type: DesignDoc. requirements_verbatim: [user requirements verbatim]. confirmed_decisions: [Step 3 confirmed scope and user answers]. codebase_analysis: [codebase-analyzer JSON from Step 2]. ui_analysis: [ui-analyzer JSON from Step 5]. code_verification: [code verification output from this step]"`
+- **(ADR only)** Invoke **document-reviewer** to verify consistency and completeness
+  - `subagent_type: "dev-workflows-frontend:document-reviewer"`, `description: "ADR review"`, `prompt: "Review [ADR path] for consistency and completeness. doc_type: ADR. codebase_analysis: [codebase-analyzer JSON from Step 2]. ui_analysis: [ui-analyzer JSON from Step 5]"`
 
 ### Step 8: Design Consistency Verification
 - **(Design Doc only)** Invoke **design-sync** using Agent tool. Skip for ADR-only.