codex-workflows 0.3.1 → 0.4.1

package/.agents/skills/documentation-criteria/SKILL.md

@@ -71,16 +71,39 @@ description: "Documentation creation criteria for PRD, ADR, Design Doc, UI Spec,
 **Includes**: Existing codebase analysis, technical approach, dependencies and constraints, interface/contract definitions, data flow, acceptance criteria, change impact map, code inspection evidence
 **Excludes**: Why that technology was chosen (reference ADR), when/who to implement (reference Work Plan), detailed test strategy and test case selection (generated by acceptance-test-generator from acceptance criteria)
 
+**Required Structural Elements**:
+- Existing codebase analysis and code inspection evidence
+- Technical approach and implementation approach decision
+- Change impact map and interface/contract definitions
+- Applicable standards with explicit/implicit classification
+- Verification Strategy
+  - Correctness proof method
+  - Early verification point
+  - Minimal form allowed for low-risk or self-evident changes: concise entries or explicit `N/A` with rationale
+    Low-risk: changes affecting 1-2 files with no external contract, integration, or data-flow changes
+    Self-evident: internal-only refactoring with identical observable inputs and outputs
+
 ### Work Plan
 **Purpose**: Implementation task management and progress tracking
-**Includes**: Task breakdown, schedule estimates, test skeleton file paths, Phase 4 Quality Assurance Phase (required), progress records
+**Includes**: Task breakdown, schedule estimates, test skeleton file paths, Verification Strategy summaries from each Design Doc, final Quality Assurance phase (required), progress records
 **Excludes**: Technical rationale, design details
 
 **Phase Division Criteria**:
+
+**When Vertical Slice is selected**:
+- Each phase represents one value unit and includes its own implementation and verification
+- The earliest phase should contain the early verification point when defined
+- Final phase is always Quality Assurance
+
+**When Horizontal Slice is selected**:
 1. **Phase 1: Foundation Implementation** - Contract definitions, interfaces, test preparation
 2. **Phase 2: Core Feature Implementation** - Business logic, unit tests
 3. **Phase 3: Integration Implementation** - External connections, presentation layer
-4. **Phase 4: Quality Assurance (Required)** - Acceptance criteria, all tests, quality checks
+4. **Final Phase: Quality Assurance (Required)** - Acceptance criteria, all tests, quality checks
+
+**When Hybrid is selected**:
+- Combine vertical and horizontal phase structures as defined in the Design Doc
+- Final phase is always Quality Assurance
 
 ## Creation Process [MANDATORY]
 

package/.agents/skills/documentation-criteria/references/design-template.md

@@ -197,12 +197,50 @@ Invariants:
   - [Conditions that remain unchanged before and after processing]
 ```
 
+### Test Boundaries
+
+#### Mock Boundary Decisions
+
+| Dependency / Boundary | Test Level | Use Real Dependency | Isolation Method | Rationale |
+|-----------------------|------------|---------------------|------------------|-----------|
+| [Repository / API / queue / hook] | [integration / e2e] | [Yes / No] | [mock / fake / local test env / browser harness] | [Why this boundary should behave this way in tests] |
+
+#### Data Layer Verification Strategy
+
+- Data storage involved: [Yes / No]
+- Schema or model references: [table / collection / model names or N/A]
+- Real verification approach: [container DB / dedicated test DB / in-memory adapter / browser fixture / N/A]
+- Query and repository coverage: [How repository, ORM, or query paths will be verified]
+- Migration compatibility check: [How schema drift will be detected or why N/A]
+
 ### Field Propagation Map (When Fields Cross Boundaries)
 
 | Field | Boundary | Status | Detail |
 |-------|----------|--------|--------|
 | [field name] | [Component A to B] | preserved / transformed / dropped | [logic or reason] |
 
+## Verification Strategy
+
+Verification Strategy defines what correctness means and how to prove it at design time. L1/L2/L3 (from implementation-approach) define task-level verification depth at execution time.
+Use the minimal form only when the change is low-risk or the verification path is self-evident. Otherwise fill all fields concretely.
+Low-risk: changes affecting 1-2 files with no external contract, integration, or data-flow changes.
+Self-evident: internal-only refactoring with identical observable inputs and outputs.
+
+### Correctness Proof Method
+
+- **Correctness definition**: [What "correct" means for this change]
+- **Target comparison**: [What is being compared or validated against what]
+- **Verification method**: [How correctness will be verified]
+- **Observable success indicator**: [What observable result proves the verification succeeded]
+- **Verification timing**: [`phase_1` | `per_phase` | `integration_phase` | `final_phase`]
+- **Timing note**: [Optional free-text clarification when the enum alone is insufficient]
+
+### Early Verification Point
+
+- **First verification target**: [The smallest unit that proves the approach works]
+- **Success criteria**: [Observable outcome that proves correctness]
+- **Failure response**: [What to do if early verification fails]
+
 ### State Transitions and Invariants (When Applicable)
 
 ```yaml

package/.agents/skills/documentation-criteria/references/plan-template.md

@@ -13,6 +13,25 @@ Related Issue/PR: #XXX (if any)
 - ADR: [docs/adr/ADR-XXXX.md] (if any)
 - PRD: [docs/prd/XXX.md] (if any)
 
+## Verification Strategies (from Design Docs)
+
+Repeat this block for each Design Doc when multiple Design Docs exist. Preserve each strategy's identity and source document path. Merge strategies only when the Design Docs explicitly define a shared one.
+
+### Verification Strategy: [docs/design/XXX.md]
+
+#### Correctness Proof Method
+- **Correctness definition**: [extracted from Design Doc]
+- **Target comparison**: [extracted from Design Doc]
+- **Verification method**: [extracted from Design Doc]
+- **Observable success indicator**: [extracted from Design Doc]
+- **Verification timing**: [`phase_1` | `per_phase` | `integration_phase` | `final_phase`]
+- **Timing note**: [optional clarification]
+
+#### Early Verification Point
+- **First verification target**: [extracted from Design Doc]
+- **Success criteria**: [extracted from Design Doc]
+- **Failure response**: [extracted from Design Doc]
+
 ## Objective
 [Why this change is necessary, what problem it solves]
 
@@ -33,10 +52,46 @@ Related Issue/PR: #XXX (if any)
 
 ## Implementation Phases
 
-(Note: Phase structure is determined based on Design Doc technical dependencies and implementation approach)
+Select one phase structure based on the implementation approach from the Design Doc.
+Delete every unused option before finalizing the work plan. The final document must contain only the selected phase structure.
+
+### Option A: Vertical Slice Phase Structure
 
-### Phase 1: [Phase Name] (Estimated commits: X)
-**Purpose**: [What this phase aims to achieve]
+Use when implementation approach is Vertical Slice. Each phase represents one value unit and includes its own verification.
+
+### Phase 1: [Value Unit 1] (Estimated commits: X)
+**Purpose**: [First slice that proves the approach works]
+**Verification**: [Use the early verification point when applicable]
+
+#### Tasks
+- [ ] Task 1: Specific work content
+- [ ] Task 2: Verification for this value unit
+- [ ] Quality check: Implement staged quality checks (refer to ai-development-guide skill)
+
+#### Phase Completion Criteria
+- [ ] Early verification point passed
+- [ ] [Functional completion criteria]
+- [ ] [Quality completion criteria]
+
+### Phase 2: [Value Unit 2] (Estimated commits: X)
+**Purpose**: [Subsequent slice]
+**Verification**: [Verification for this value unit]
+
+#### Tasks
+- [ ] Task 1: Specific work content
+- [ ] Task 2: Verification for this value unit
+- [ ] Quality check
+
+#### Phase Completion Criteria
+- [ ] [Functional completion criteria]
+- [ ] [Quality completion criteria]
+
+### Option B: Horizontal Slice Phase Structure
+
+Use when implementation approach is Horizontal Slice. Phases follow Foundation -> Core -> Integration -> QA.
+
+### Phase 1: [Foundation] (Estimated commits: X)
+**Purpose**: Contract definitions, interfaces, test preparation
 
 #### Tasks
 - [ ] Task 1: Specific work content
@@ -48,26 +103,26 @@ Related Issue/PR: #XXX (if any)
 - [ ] [Functional completion criteria]
 - [ ] [Quality completion criteria]
 
-### Phase 2: [Phase Name] (Estimated commits: X)
-**Purpose**: [What this phase aims to achieve]
+### Phase 2: [Core Feature] (Estimated commits: X)
+**Purpose**: Business logic, unit tests
 
 #### Tasks
 - [ ] Task 1: Specific work content
 - [ ] Task 2: Specific work content
-- [ ] Quality check: Implement staged quality checks (refer to ai-development-guide skill)
+- [ ] Quality check
 - [ ] Integration tests: Verify overall feature functionality
 
 #### Phase Completion Criteria
 - [ ] [Functional completion criteria]
 - [ ] [Quality completion criteria]
 
-### Phase 3: [Phase Name] (Estimated commits: X)
-**Purpose**: [What this phase aims to achieve]
+### Phase 3: [Integration] (Estimated commits: X)
+**Purpose**: External connections, presentation layer
 
 #### Tasks
 - [ ] Task 1: Specific work content
 - [ ] Task 2: Specific work content
-- [ ] Quality check: Implement staged quality checks (refer to ai-development-guide skill)
+- [ ] Quality check
 - [ ] Integration tests: Verify component coordination
 
 #### Phase Completion Criteria
@@ -75,7 +130,9 @@ Related Issue/PR: #XXX (if any)
 - [ ] [Quality completion criteria]
 
 ### Final Phase: Quality Assurance (Required) (Estimated commits: 1)
-**Purpose**: Overall quality assurance and Design Doc consistency verification
+This phase is required for all implementation approaches.
+
+**Purpose**: Cross-cutting quality assurance and Design Doc consistency verification
 
 #### Tasks
 - [ ] Verify all Design Doc acceptance criteria achieved

package/.agents/skills/documentation-criteria/references/task-template.md

@@ -37,9 +37,16 @@ Brief observations recorded after reading Investigation Targets:
 - [ ] Improve code (maintain passing tests)
 - [ ] Confirm added tests still pass
 
+## Operation Verification Methods
+(Derived from Verification Strategy in the work plan)
+- **Verification method**: [What to verify and how]
+- **Success criteria**: [Observable outcome that proves correctness]
+- **Failure response**: [What to do if verification fails]
+- **Verification level**: [L1/L2/L3, per implementation-approach skill]
+
 ## Completion Criteria
 - [ ] All added tests pass
-- [ ] Operation verified (select L1/L2/L3, per implementation-approach skill)
+- [ ] Operation verified per Operation Verification Methods above
 - [ ] Deliverables created (for research/design tasks)
 
 ## Notes

package/.agents/skills/integration-e2e-testing/SKILL.md

@@ -60,10 +60,13 @@ Each test MUST include the following annotations:
 // Behavior: [Trigger] -> [Process] -> [Observable Result]
 // @category: core-functionality | integration | edge-case | e2e
 // @dependency: none | [component names] | full-system
+// @real-dependency: [component names] (optional)
 // @complexity: low | medium | high
 // ROI: [score]
 ```
 
+Adapt comment syntax to the project's language when generating or reviewing test skeletons.
+
 ### Verification Items (Optional)
 
 When verification points need explicit enumeration:
@@ -110,7 +113,7 @@ The test runner or framework in the project determines the appropriate file exte
 |-------|-------------------|
 | Behavior Verification | No assertion for "observable result" in skeleton |
 | Verification Item Coverage | Listed items not all covered by assertions |
-| Mock Boundary | Internal components mocked in integration test |
+| Mock Boundary | Real dependencies from `@real-dependency` are isolated away or internal components are mocked without rationale |
 
 ### Implementation Quality
 

package/.agents/skills/recipe-build/SKILL.md

@@ -90,7 +90,7 @@ ENFORCEMENT: Proceeding past a failed quality gate invalidates all subsequent wo
 **MANDATORY suffix for ALL sub-agent prompts**:
 ```
 [SYSTEM CONSTRAINT]
-This agent operates within build skill scope. Use orchestrator-provided rules only.
+This agent operates within build skill scope. Use the task file as the primary instruction source. Use the active Design Doc or work plan only as supporting context when the task file references them. Constraints explicitly passed in this prompt by the orchestrator take precedence over supporting context. The agent's own role contract and required quality rules remain in force.
 ```
 
 Autonomous sub-agents require scope constraints for stable execution. MUST append this constraint to every sub-agent prompt.

package/.agents/skills/recipe-design/SKILL.md

@@ -17,8 +17,9 @@ description: "Execute from requirement analysis to design document creation."
 
 **Execution Protocol**:
 1. **Spawn agents for all work** -- your role is to invoke sub-agents, pass data between them, and report results
-2. **Follow subagents-orchestration-guide skill design flow exactly**:
-   - Execute: requirement-analyzer -> technical-designer -> document-reviewer -> design-sync
+2. **Follow the design flow defined in subagents-orchestration-guide**:
+   - Apply the scale-specific and layer-specific branches defined there, including PRD, ADR, and UI Spec steps when required
+   - Use `requirement-analyzer -> codebase-analyzer -> technical-designer -> code-verifier -> document-reviewer -> design-sync` as the core design-document path after prerequisite branches are resolved
    - **[STOP — BLOCKING]** At every `[Stop: ...]` marker -> Present status to user for confirmation. **CANNOT proceed until user explicitly confirms.**
 3. **Scope**: Complete when design documents receive approval
 
@@ -27,10 +28,14 @@ ENFORCEMENT: Skipping any quality gate invalidates the design output.
 
 ## Workflow Overview
 
+Core design-document path after prerequisite branches such as PRD, ADR, or UI Spec are resolved:
+
 ```
 Requirements -> requirement-analyzer -> [Stop: Scale determination]
                                              |
-                                     technical-designer -> document-reviewer
+                                     codebase-analyzer
+                                             |
+                                     technical-designer -> code-verifier -> document-reviewer
                                              |
                                         design-sync -> [Stop: Design approval]
 ```
@@ -48,12 +53,7 @@ Requirements -> requirement-analyzer -> [Stop: Scale determination]
 
 Requirements: $ARGUMENTS
 
-Considering the deep impact on design, first engage in dialogue to understand the background and purpose of requirements:
-- What problems do you want to solve?
-- Expected outcomes and success criteria
-- Relationship with existing systems
-
-Once requirements are moderately clarified, analyze with requirement-analyzer and create appropriate design documents according to scale.
+Pass the user requirements directly to requirement-analyzer as the first action. If clarification is needed, handle it at the requirement-analysis stop point before proceeding.
 
 MUST clearly present design alternatives and trade-offs.
 
@@ -64,13 +64,19 @@ Execute the process below within design scope.
 ### Step 1: Requirement Analysis
 Spawn requirement-analyzer agent: "Analyze the following requirements and determine scale: $ARGUMENTS"
 
-### Step 2: Design Document Creation
-Spawn technical-designer agent: "Create design document based on requirement analysis output. Include architecture decisions, component design, and acceptance criteria."
+### Step 2: Codebase Analysis
+Spawn codebase-analyzer agent: "Analyze the existing codebase to provide evidence for Design Doc creation. requirement_analysis: [output from Step 1]. requirements: $ARGUMENTS"
+
+### Step 3: Design Document Creation
+Spawn technical-designer agent: "Create design document based on requirement analysis output and codebase analysis output. Include architecture decisions, component design, and acceptance criteria."
+
+### Step 4: Code Verification
+Spawn code-verifier agent: "Verify the design document against the current codebase. document_path: [output from Step 3]. doc_type: design-doc."
 
-### Step 3: Document Review
-Spawn document-reviewer agent: "Review the design document created in the previous step. Verify completeness, consistency, and quality."
+### Step 5: Document Review
+Spawn document-reviewer agent: "Review the design document created in the previous step. Verify completeness, consistency, and quality. code_verification: [output from Step 4]"
 
-### Step 4: Consistency Verification
+### Step 6: Consistency Verification
 Spawn design-sync agent: "Verify consistency of the design document with other existing design documents and project constraints."
 
 **Note**: design-sync returns `sync_status: "SKIPPED"` when only 1 Design Doc exists. This is distinct from `NO_CONFLICTS` and MUST be reported as such to the user.
@@ -78,7 +84,9 @@ Spawn design-sync agent: "Verify consistency of the design document with other e
 ## Completion Criteria
 
 - [ ] Spawned requirement-analyzer and determined scale
+- [ ] Spawned codebase-analyzer and passed its findings into design creation
 - [ ] Created appropriate design document (ADR or Design Doc) via technical-designer
+- [ ] Spawned code-verifier and passed its findings into document review
 - [ ] Spawned document-reviewer and addressed feedback
 - [ ] Spawned design-sync for consistency verification
 - [ ] Obtained user approval for design document

package/.agents/skills/recipe-front-build/SKILL.md

@@ -98,7 +98,7 @@ ENFORCEMENT: Proceeding past a failed quality gate invalidates all subsequent wo
 **MANDATORY suffix for ALL sub-agent prompts**:
 ```
 [SYSTEM CONSTRAINT]
-This agent operates within build skill scope. Use orchestrator-provided rules only.
+This agent operates within build skill scope. Use the task file as the primary instruction source. Use the active Design Doc or work plan only as supporting context when the task file references them. Constraints explicitly passed in this prompt by the orchestrator take precedence over supporting context. The agent's own role contract and required quality rules remain in force.
 ```
 
 Autonomous sub-agents require scope constraints for stable execution. MUST append this constraint to every sub-agent prompt.

package/.agents/skills/recipe-front-design/SKILL.md

@@ -17,8 +17,10 @@ description: "Execute from requirement analysis to frontend design document crea
 
 **Execution Method**:
 - Requirement analysis -> performed by requirement-analyzer
+- Codebase analysis -> performed by codebase-analyzer
 - UI Specification creation -> performed by ui-spec-designer
 - Design document creation -> performed by technical-designer-frontend
+- Design verification -> performed by code-verifier
 - Document review -> performed by document-reviewer
 
 Orchestrator spawns agents and passes structured data between them.
@@ -68,8 +70,10 @@ Then create the UI Specification:
 ### Step 3: Design Document Creation Phase
 Create appropriate design documents according to scale determination:
 - For ADR: Spawn technical-designer-frontend agent: "Create ADR for [technical decision]"
-- For Design Doc: Spawn technical-designer-frontend agent: "Create Design Doc based on requirements. UI Spec is at [ui-spec path]. Inherit component structure and state design from UI Spec."
-- Spawn document-reviewer agent: "Review [document path] for consistency and completeness"
+- For Design Doc: Spawn codebase-analyzer agent first: "Analyze the existing codebase to provide evidence for frontend Design Doc creation. Focus on existing implementations, state paths, API integrations, and constraints the design should respect. requirement_analysis: [JSON from requirement-analyzer]. requirements: [original user requirements]. layer: frontend. target_paths: [frontend affected files and directories from requirement-analyzer]. focus_areas: component hierarchy, state management, UI interactions, data fetching."
+- For Design Doc: Spawn technical-designer-frontend agent: "Create Design Doc based on requirements. Codebase Analysis: [JSON from codebase-analyzer]. UI Spec is at [ui-spec path]. Inherit component structure and state design from UI Spec."
+- Spawn code-verifier agent: "Verify Design Doc against code. doc_type: design-doc. document_path: [document path]. verbose: false."
+- Spawn document-reviewer agent: "Review the Design Doc for consistency and completeness. doc_type: DesignDoc. target: [document path]. mode: composite. code_verification: [JSON from code-verifier]"
 
 **[STOP -- BLOCKING]** Present design alternatives and trade-offs, obtain user approval.
 **CANNOT proceed until user explicitly approves the design document.**
@@ -80,6 +84,7 @@ ENFORCEMENT: Every stop point MUST be respected. Skipping user approval invalida
 
 - [ ] Requirement analysis completed and approved
 - [ ] UI Specification created and approved
+- [ ] Codebase analysis completed before frontend Design Doc creation
 - [ ] Design document created and approved
 - [ ] All document reviews passed
 

package/.agents/skills/recipe-fullstack-build/SKILL.md

@@ -108,7 +108,7 @@ ENFORCEMENT: Proceeding past a failed quality gate invalidates all subsequent wo
 **MANDATORY suffix for ALL sub-agent prompts**:
 ```
 [SYSTEM CONSTRAINT]
-This agent operates within build skill scope. Use orchestrator-provided rules only.
+This agent operates within build skill scope. Use the task file as the primary instruction source. Use the active Design Docs or work plan only as supporting context when the task file references them. Constraints explicitly passed in this prompt by the orchestrator take precedence over supporting context. The agent's own role contract and required quality rules remain in force.
 ```
 
 Autonomous sub-agents require scope constraints for stable execution. MUST append this constraint to every sub-agent prompt.

package/.agents/skills/recipe-fullstack-implement/SKILL.md

@@ -90,6 +90,8 @@ When user responds to questions:
 - [ ] Identified current progress position
 - [ ] Clarified next step
 - [ ] Recognized stopping points
+- [ ] codebase-analyzer included before each Design Doc creation
+- [ ] code-verifier included before each Design Doc review
 - [ ] **Environment check**: Can I execute per-task commit cycle?
   - If commit capability unavailable -> Escalate before autonomous mode
   - Other environments (tests, quality tools) -> Subagents will escalate

package/.agents/skills/recipe-implement/SKILL.md

@@ -128,6 +128,8 @@ After acceptance-test-generator execution, when spawning work-planner, communica
 - [ ] Requirement analysis completed and user-confirmed
 - [ ] Layer routing determined (backend / frontend / fullstack)
 - [ ] Correct workflow followed per layer routing
+- [ ] codebase-analyzer included before Design Doc creation for Medium/Large flows
+- [ ] code-verifier included before document-reviewer for Design Doc review
 - [ ] All stopping points honored with user confirmation obtained
 - [ ] Quality-fixer spawned before every commit
 - [ ] All tasks committed or escalation completed

package/.agents/skills/recipe-reverse-engineer/SKILL.md

@@ -101,7 +101,7 @@ Spawn code-verifier agent: "Verify consistency between PRD and code implementati
 
 **Required Input**: $STEP_3_OUTPUT (verification data from Step 3)
 
-Spawn document-reviewer agent: "Review the following PRD considering code verification findings. doc_type: PRD. target: $STEP_2_OUTPUT. mode: composite. Code Verification Results: $STEP_3_OUTPUT. Additional Review Focus: Alignment between PRD claims and verification evidence, resolution recommendations for each discrepancy, completeness of undocumented feature coverage."
+Spawn document-reviewer agent: "Review the following PRD considering code verification findings. doc_type: PRD. target: $STEP_2_OUTPUT. mode: composite. code_verification: $STEP_3_OUTPUT. Additional Review Focus: Alignment between PRD claims and verification evidence, resolution recommendations for each discrepancy, completeness of undocumented feature coverage."
 
 **Store output as**: `$STEP_4_OUTPUT`
 
@@ -208,7 +208,7 @@ Spawn code-verifier agent: "Verify consistency between Design Doc and code imple
 
 **Required Input**: $STEP_8_OUTPUT (verification data from Step 8)
 
-Spawn document-reviewer agent: "Review the following Design Doc considering code verification findings. doc_type: DesignDoc. target: $STEP_7_OUTPUT. mode: composite. Code Verification Results: $STEP_8_OUTPUT. Parent PRD: $APPROVED_PRD_PATH. Additional Review Focus: Technical accuracy of documented interfaces, consistency with parent PRD scope, completeness of unit boundary definitions."
+Spawn document-reviewer agent: "Review the following Design Doc considering code verification findings. doc_type: DesignDoc. target: $STEP_7_OUTPUT. mode: composite. code_verification: $STEP_8_OUTPUT. Parent PRD: $APPROVED_PRD_PATH. Additional Review Focus: Technical accuracy of documented interfaces, consistency with parent PRD scope, completeness of unit boundary definitions."
 
 **Store output as**: `$STEP_9_OUTPUT`
 

package/.agents/skills/recipe-update-doc/SKILL.md

@@ -32,8 +32,8 @@ ENFORCEMENT: Skipping document-reviewer risks propagating inconsistencies to dow
 Target document -> [Stop: Confirm changes]
                         |
               technical-designer / technical-designer-frontend / prd-creator (update mode)
-                        |
-              document-reviewer -> [Stop: Review approval]
+                        | (Design Doc only)
+              code-verifier -> document-reviewer -> [Stop: Review approval]
                         | (Design Doc only)
               design-sync -> [Stop: Final approval]
 ```
@@ -107,13 +107,23 @@ Spawn [Update Agent from Step 2] agent: "Operation Mode: update. Existing Docume
 
 ### Step 5: Document Review [Stop]
 
-**[STOP — BLOCKING]** Present review results to user for approval.
-**CANNOT proceed until user explicitly confirms.**
+For Design Doc updates, first verify the updated document against code:
+
+Spawn code-verifier agent: "Verify the updated Design Doc against current code. doc_type: design-doc. document_path: [path from Step 1]. verbose: false."
 
-Spawn document-reviewer agent: "Review the following updated document. doc_type: [Design Doc / PRD / ADR]. target: [path from Step 1]. mode: standard. Focus on: Consistency of updated sections with rest of document, no contradictions introduced by changes, completeness of change history."
+**Store output as**: `$CODE_VERIFICATION_OUTPUT`
+
+For Design Doc updates:
+Spawn document-reviewer agent: "Review the following updated document. doc_type: DesignDoc. target: [path from Step 1]. mode: composite. code_verification: $CODE_VERIFICATION_OUTPUT. Focus on: Consistency of updated sections with rest of document, no contradictions introduced by changes, completeness of change history."
+
+For PRD or ADR updates:
+Spawn document-reviewer agent: "Review the following updated document. doc_type: [PRD or ADR]. target: [path from Step 1]. mode: composite. Focus on: Consistency of updated sections with rest of document, no contradictions introduced by changes, completeness of change history."
 
 **Store output as**: `$STEP_5_OUTPUT`
 
+**[STOP — BLOCKING]** Present review results to user for approval.
+**CANNOT proceed until user explicitly confirms.**
+
 **On review result**:
 - Approved -> Proceed to Step 6
 - Needs revision -> Return to Step 4 with review feedback (max 2 iterations):
@@ -151,6 +161,7 @@ For Design Doc, spawn design-sync agent: "Verify consistency of the updated Desi
 - [ ] Identified target document
 - [ ] Clarified change content with user
 - [ ] Updated document via appropriate agent (update mode)
+- [ ] Ran code-verifier before document-reviewer for Design Doc updates
 - [ ] Spawned document-reviewer and addressed feedback
 - [ ] Spawned design-sync for consistency verification (Design Doc only)
 - [ ] Obtained user approval for updated document