create-ai-project 1.11.2 → 1.12.1

package/{docs/rules-en/frontend/technical-spec.md → .claude/skills-en/frontend/technical-spec/SKILL.md}

@@ -1,3 +1,8 @@
+---
+name: frontend/technical-spec
+description: Frontend technical design rules including environment variables, architecture design, data flow, and build/testing commands.
+---
+
 # Technical Design Rules (Frontend)
 
 ## Basic Technology Stack Policy
@@ -12,13 +17,13 @@ TypeScript-based React application implementation. Architecture patterns should
 - Properly implement default value settings and mandatory checks
 
 ```typescript
-// ✅ Build tool environment variables (public values only)
+// Build tool environment variables (public values only)
 const config = {
   apiUrl: import.meta.env.API_URL || 'http://localhost:3000',
   appName: import.meta.env.APP_NAME || 'My App'
 }
 
-// ❌ Does not work in frontend
+// Does not work in frontend
 const apiUrl = process.env.API_URL
 ```
 
@@ -31,23 +36,22 @@ const apiUrl = process.env.API_URL
 
 **Correct Approach for Secrets**:
 ```typescript
-// ❌ Security risk: API key exposed in browser
+// Security risk: API key exposed in browser
 const apiKey = import.meta.env.API_KEY
 const response = await fetch(`https://api.example.com/data?key=${apiKey}`)
 
-// ✅ Correct: Backend manages secrets, frontend accesses via proxy
+// Correct: Backend manages secrets, frontend accesses via proxy
 const response = await fetch('/api/data') // Backend handles API key authentication
 ```
 
 ## Architecture Design
 
 ### Frontend Architecture Patterns
-Strictly adhere to selected project patterns. Project-specific details reference `docs/rules/architecture/`.
 
 **React Component Architecture**:
 - **Function Components**: Mandatory, class components deprecated
 - **Custom Hooks**: For logic reuse and dependency injection
-- **Component Hierarchy**: Atoms → Molecules → Organisms → Templates → Pages
+- **Component Hierarchy**: Atoms -> Molecules -> Organisms -> Templates -> Pages
 - **Props-driven**: Components receive all necessary data via props
 - **Co-location**: Place tests, styles, and related files alongside components
 
@@ -69,26 +73,26 @@ Maintain consistent data flow throughout the React application:
 
 - **Unidirectional Flow**: Data flows top-down via props
   ```
-  API Response → State → Props → Render → UI
-  User Input → Event Handler → State Update → Re-render
+  API Response -> State -> Props -> Render -> UI
+  User Input -> Event Handler -> State Update -> Re-render
   ```
 
 - **Immutable Updates**: Use immutable patterns for state updates
   ```typescript
-  // ✅ Immutable state update
+  // Immutable state update
   setUsers(prev => [...prev, newUser])
 
-  // ❌ Mutable state update
+  // Mutable state update (avoid)
   users.push(newUser)
   setUsers(users)
   ```
 
 ### Type Safety in Data Flow
-- **Frontend → Backend**: Props/State (Type Guaranteed) → API Request (Serialization)
-- **Backend → Frontend**: API Response (`unknown`) → Type Guard → State (Type Guaranteed)
+- **Frontend -> Backend**: Props/State (Type Guaranteed) -> API Request (Serialization)
+- **Backend -> Frontend**: API Response (`unknown`) -> Type Guard -> State (Type Guaranteed)
 
 ```typescript
-// ✅ Type-safe data flow
+// Type-safe data flow
 async function fetchUser(id: string): Promise<User> {
   const response = await fetch(`/api/users/${id}`)
   const data: unknown = await response.json()

package/{docs/rules-en/frontend/typescript.md → .claude/skills-en/frontend/typescript-rules/SKILL.md}

@@ -1,8 +1,13 @@
-# TypeScript Development Rules
+---
+name: frontend/typescript-rules
+description: React/TypeScript frontend development rules including type safety, component design, state management, and error handling.
+---
+
+# TypeScript Development Rules (Frontend)
 
 ## Frontend-Specific Anti-patterns
 
-In addition to universal anti-patterns in coding-standards.md, watch for these Frontend-specific issues:
+In addition to universal anti-patterns in coding-standards skill, watch for these Frontend-specific issues:
 
 - **Prop drilling through 3+ levels** - Should use Context API or state management
 - **Massive components (300+ lines)** - Split into smaller components
@@ -10,8 +15,8 @@ In addition to universal anti-patterns in coding-standards.md, watch for these F
 ## Type Safety in Frontend Implementation
 
 **Type Safety in Data Flow**
-- **Frontend → Backend**: Props/State (Type Guaranteed) → API Request (Serialization)
-- **Backend → Frontend**: API Response (`unknown`) → Type Guard → State (Type Guaranteed)
+- **Frontend -> Backend**: Props/State (Type Guaranteed) -> API Request (Serialization)
+- **Backend -> Frontend**: API Response (`unknown`) -> Type Guard -> State (Type Guaranteed)
 
 **Frontend-Specific Type Scenarios**:
 - **React Props/State**: TypeScript manages types, unknown unnecessary
@@ -38,7 +43,7 @@ In addition to universal anti-patterns in coding-standards.md, watch for these F
 **Function Design**
 - **0-2 parameters maximum**: Use object for 3+ parameters
   ```typescript
-  // ✅ Object parameter
+  // Object parameter
   function createUser({ name, email, role }: CreateUserParams) {}
   ```
 
@@ -65,10 +70,10 @@ In addition to universal anti-patterns in coding-standards.md, watch for these F
 - Imports use absolute paths (`src/`)
 
 **Clean Code Principles**
-- ✅ Delete unused code immediately
-- ✅ Delete debug `console.log()`
-- ❌ Commented-out code (manage history with version control)
-- ✅ Comments explain "why" (not "what")
+- Delete unused code immediately
+- Delete debug `console.log()`
+- No commented-out code (manage history with version control)
+- Comments explain "why" (not "what")
 
 ## Error Handling
 
@@ -76,12 +81,12 @@ In addition to universal anti-patterns in coding-standards.md, watch for these F
 
 **Fail-Fast Principle**: Fail quickly on errors to prevent continued processing in invalid states
 ```typescript
-// ❌ Prohibited: Unconditional fallback
+// Prohibited: Unconditional fallback
 catch (error) {
   return defaultValue // Hides error
 }
 
-// ✅ Required: Explicit failure
+// Required: Explicit failure
 catch (error) {
   logger.error('Processing failed', error)
   throw error // Handle with Error Boundary or higher layer
@@ -128,4 +133,4 @@ Never include sensitive information (password, token, apiKey, secret, creditCard
 - Component Memoization: Use React.memo for expensive components
 - State Optimization: Minimize re-renders with proper state structure
 - Lazy Loading: Use React.lazy and Suspense for code splitting
-- Bundle Size: Monitor with the `build` script (use the appropriate run command based on the `packageManager` field in package.json) and keep under 500KB
+- Bundle Size: Monitor with the `build` script and keep under 500KB

package/{docs/rules-en/frontend/typescript-testing.md → .claude/skills-en/frontend/typescript-testing/SKILL.md}

@@ -1,4 +1,9 @@
-# TypeScript Testing Rules
+---
+name: frontend/typescript-testing
+description: Frontend testing rules with Vitest, React Testing Library, and MSW. Includes coverage requirements, test design principles, and quality criteria.
+---
+
+# TypeScript Testing Rules (Frontend)
 
 ## Test Framework
 - **Vitest**: This project uses Vitest
@@ -43,7 +48,7 @@
 3. **Cross-functional Verification in E2E Tests**
    - Mandatory verification of impact on existing features when adding new features
    - Cover integration points with "High" and "Medium" impact levels from Design Doc's "Integration Point Map"
-   - Verification pattern: Existing feature operation → Enable new feature → Verify continuity of existing features
+   - Verification pattern: Existing feature operation -> Enable new feature -> Verify continuity of existing features
    - Success criteria: No change in displayed content, rendering time within 5 seconds
    - Designed for automatic execution in CI/CD pipelines
 
@@ -72,11 +77,11 @@ src/
 
 ### Test Code Quality Rules
 
-✅ **Recommended: Keep all tests always active**
+**Recommended: Keep all tests always active**
 - Merit: Guarantees test suite completeness
 - Practice: Fix problematic tests and activate them
 
-❌ **Avoid: test.skip() or commenting out**
+**Avoid: test.skip() or commenting out**
 - Reason: Creates test gaps and incomplete quality checks
 - Solution: Completely delete unnecessary tests
 
@@ -84,7 +89,7 @@ src/
 
 ### MSW (Mock Service Worker) Setup
 ```typescript
-// ✅ Type-safe MSW handler
+// Type-safe MSW handler
 import { rest } from 'msw'
 
 const handlers = [
@@ -96,7 +101,7 @@ const handlers = [
 
 ### Component Mock Type Safety
 ```typescript
-// ✅ Only required parts
+// Only required parts
 type TestProps = Pick<ButtonProps, 'label' | 'onClick'>
 const mockProps: TestProps = { label: 'Click', onClick: vi.fn() }
 

package/{docs/rules-en/architecture/implementation-approach.md → .claude/skills-en/implementation-approach/SKILL.md}

@@ -1,3 +1,8 @@
+---
+name: implementation-approach
+description: Implementation strategy selection framework with meta-cognitive approach, verification levels, and integration point definitions.
+---
+
 # Implementation Strategy Selection Framework (Meta-cognitive Approach)
 
 ## Meta-cognitive Strategy Selection Process
@@ -21,7 +26,7 @@ Historical Context Understanding: Current form rationale, past decision validity
 
 ### Phase 2: Strategy Exploration and Creation
 
-**Core Question**: "When determining before → after, what implementation patterns or strategies should be referenced?"
+**Core Question**: "When determining before -> after, what implementation patterns or strategies should be referenced?"
 
 #### Strategy Discovery Process
 ```yaml
@@ -133,4 +138,4 @@ Define integration points according to selected strategy:
 3. **Apply 5 Whys**: Pursue root causes to grasp essence
 4. **Multi-perspective Evaluation**: Comprehensively evaluate from each Phase 1-4 perspective
 5. **Creative Thinking**: Consider sequential application of multiple strategies and designs leveraging project-specific constraints
-6. **Clarify Decision Rationale**: Make strategy selection rationale explicit in design documents
+6. **Clarify Decision Rationale**: Make strategy selection rationale explicit in design documents

package/{docs/rules-en/integration-e2e-testing.md → .claude/skills-en/integration-e2e-testing/SKILL.md}

@@ -1,3 +1,8 @@
+---
+name: integration-e2e-testing
+description: Integration and E2E test design principles, ROI calculation, test skeleton specification, and review criteria.
+---
+
 # Integration Test & E2E Test Design/Implementation Rules
 
 ## Test Types and Limits
@@ -31,7 +36,7 @@
 ```typescript
 // AC: "[Acceptance criteria original text]"
 // ROI: [0-100] | Business Value: [0-10] | Frequency: [0-10]
-// Behavior: [Trigger] → [Process] → [Observable Result]
+// Behavior: [Trigger] -> [Process] -> [Observable Result]
 // @category: core-functionality | integration | edge-case | ux | e2e
 // @dependency: none | [component name] | full-system
 // @complexity: low | medium | high
@@ -49,7 +54,7 @@ it.todo('[AC number]-property: [Invariant description]')
 ### ROI Calculation
 
 ```
-ROI = (Business Value × Frequency + Legal Requirement × 10 + Defect Detection) / Total Cost
+ROI = (Business Value x Frequency + Legal Requirement x 10 + Defect Detection) / Total Cost
 ```
 
 | Type | Total Cost | E2E Generation Condition |
@@ -87,7 +92,7 @@ it('AC2-property: Model name is always gemini-3-pro-image-preview', () => {
 
 | Step Type | Verification Target | Example |
 |-----------|--------------------| --------|
-| Trigger | Reproduce in Arrange | API failure → mockResolvedValue({ ok: false }) |
+| Trigger | Reproduce in Arrange | API failure -> mockResolvedValue({ ok: false }) |
 | Process | Intermediate state or call | Function call, state change |
 | Observable Result | Final output value | Return value, error message, log output |
 
@@ -101,27 +106,19 @@ it('AC2-property: Model name is always gemini-3-pro-image-preview', () => {
 | No `// Verification items:` | Derive from "observable result" in "Behavior" description |
 | Both present | Prioritize verification items, use behavior as supplement |
 
-**Derivation Example from Behavior**:
-```
-// Behavior: User completes payment → Order created in DB → Order confirmation screen displayed
-↓ Derived
-- Order is created in DB (or creation function is called)
-- Order confirmation screen data is returned
-```
-
 ### Integration Test Mock Boundaries
 
 | Judgment Criteria | Mock | Actual |
 |-------------------|------|--------|
-| Part of test target? | No → Can mock | Yes → Actual required |
-| Is call verification target of test? | No → Can mock | Yes → Actual or verifiable mock |
-| External network communication? | Yes → Mock required | No → Actual recommended |
+| Part of test target? | No -> Can mock | Yes -> Actual required |
+| Is call verification target of test? | No -> Can mock | Yes -> Actual or verifiable mock |
+| External network communication? | Yes -> Mock required | No -> Actual recommended |
 
 **Judgment Flow**:
-1. External API (HTTP communication) → Mock required
-2. Component interaction under test → Actual required
-3. Log output verification needed → Use verifiable mock (vi.fn())
-4. Log output verification not needed → Actual or ignore
+1. External API (HTTP communication) -> Mock required
+2. Component interaction under test -> Actual required
+3. Log output verification needed -> Use verifiable mock (vi.fn())
+4. Log output verification not needed -> Actual or ignore
 
 ### E2E Test Execution Conditions
 

package/{docs/rules-en/project-context.md → .claude/skills-en/project-context/SKILL.md}

@@ -1,3 +1,8 @@
+---
+name: project-context
+description: Project-specific context including project nature, technology stack, and implementation principles. Customize for each project.
+---
+
 # Project Context
 
 ## Basic Configuration
@@ -30,9 +35,8 @@ When using this template for new projects:
    - Technical constraint conditions
 
 2. **Architecture Selection**
-   - Select appropriate patterns from `docs/rules/architecture/`
-   - Place project-specific designs in `docs/rules/architecture/`
+   - Select appropriate patterns from architecture skills
 
 3. **Environment Configuration**
    - Implement environment variable management methods suitable for the project
-   - Add project-specific configuration files
+   - Add project-specific configuration files

package/.claude/skills-en/subagents-orchestration-guide/SKILL.md

@@ -0,0 +1,224 @@
+---
+name: subagents-orchestration-guide
+description: Orchestration guide for coordinating subagents through implementation workflows. Defines scale determination, document requirements, stop points, and autonomous execution mode.
+---
+
+# Sub-agents Practical Guide - Orchestration Guidelines for Claude (Me)
+
+This document provides practical behavioral guidelines for me (Claude) to efficiently process tasks by utilizing subagents.
+
+## Core Principle: I Am an Orchestrator
+
+**Role Definition**: I am an orchestrator, not an executor.
+
+### Required Actions
+- **New tasks**: ALWAYS start with requirement-analyzer
+- **During flow execution**: STRICTLY follow scale-based flow
+- **Each phase**: DELEGATE to appropriate subagent
+- **Stop points**: ALWAYS wait for user approval
+
+### Prohibited Actions
+- Executing investigation directly with Grep/Glob/Read
+- Performing analysis or design without subagent delegation
+- Saying "Let me first investigate" then starting work directly
+- Skipping or postponing requirement-analyzer
+
+**Execution Rule**: New tasks -> requirement-analyzer FIRST. After flow starts -> follow scale determination.
+
+## Decision Flow When Receiving Tasks
+
+```mermaid
+graph TD
+    Start[Receive New Task] --> RA[Analyze requirements with requirement-analyzer]
+    RA --> Scale[Scale assessment]
+    Scale --> Flow[Execute flow based on scale]
+```
+
+**During flow execution, determine next subagent according to scale determination table**
+
+### Requirement Change Detection During Flow
+
+**During flow execution**, if detecting the following in user response, stop flow and go to requirement-analyzer:
+- Mentions of new features/behaviors (additional operation methods, display on different screens, etc.)
+- Additions of constraints/conditions (data volume limits, permission controls, etc.)
+- Changes in technical requirements (processing methods, output format changes, etc.)
+
+**If any one applies -> Restart from requirement-analyzer with integrated requirements**
+
+## Subagents I Can Utilize
+
+### Implementation Support Agents
+1. **quality-fixer**: Self-contained processing for overall quality assurance and fixes until completion
+2. **task-decomposer**: Appropriate task decomposition of work plans
+3. **task-executor**: Individual task execution and structured response
+4. **integration-test-reviewer**: Review integration/E2E tests for skeleton compliance
+
+### Document Creation Agents
+5. **requirement-analyzer**: Requirement analysis and work scale determination (WebSearch enabled, latest technical information research)
+6. **prd-creator**: Product Requirements Document creation (WebSearch enabled, market trend research)
+7. **technical-designer**: ADR/Design Doc creation (latest technology research, Property annotation assignment)
+8. **work-planner**: Work plan creation (extracts and reflects meta information from test skeletons)
+9. **document-reviewer**: Single document quality, completeness, and rule compliance check
+10. **design-sync**: Design Doc consistency verification (detects explicit conflicts only)
+11. **acceptance-test-generator**: Generate separate integration and E2E test skeletons from Design Doc ACs (EARS format, Property annotations, fast-check support)
+
+## My Orchestration Principles
+
+### Task Assignment with Responsibility Separation
+
+I understand each subagent's responsibilities and assign work appropriately:
+
+**task-executor Responsibilities** (DELEGATE these):
+- Implementation work and test addition
+- Confirmation that ONLY added tests pass (existing tests are NOT in scope)
+- DO NOT delegate quality assurance to task-executor
+
+**quality-fixer Responsibilities** (DELEGATE these):
+- Overall quality assurance (type check, lint, ALL test execution)
+- Complete execution of quality error fixes
+- Self-contained processing until fix completion
+- Final approved judgment (ONLY after all fixes are complete)
+
+### Standard Flow I Manage
+
+**Basic Cycle**: I manage the 4-step cycle of `task-executor -> escalation judgment/follow-up -> quality-fixer -> commit`.
+I repeat this cycle for each task to ensure quality.
+
+## Constraints Between Subagents
+
+**Important**: Subagents cannot directly call other subagents. When coordinating multiple subagents, the main AI (Claude) operates as the orchestrator.
+
+## Scale Determination and Document Requirements
+
+| Scale | File Count | PRD | ADR | Design Doc | Work Plan |
+|-------|------------|-----|-----|------------|-----------|
+| Small | 1-2 | Update[^1] | Not needed | Not needed | Simplified (inline comments only) |
+| Medium | 3-5 | Update[^1] | Conditional[^2] | **Required** | **Required** |
+| Large | 6+ | **Required**[^3] | Conditional[^2] | **Required** | **Required** |
+
+[^1]: Update existing PRD if one exists for the relevant feature
+[^2]: Required when: architecture changes, new technology introduction, OR data flow changes
+[^3]: Create new PRD, update existing PRD, or create reverse PRD (when no existing PRD)
+
+## My Basic Flow for Work Planning
+
+When receiving new features or change requests, I first request requirement analysis from requirement-analyzer.
+According to scale determination:
+
+### Large Scale (6+ Files)
+1. requirement-analyzer -> Requirement analysis + Check existing PRD **[Stop: Requirement confirmation/question handling]**
+2. prd-creator -> PRD creation (update if existing, new creation with thorough investigation if not) -> Execute document-reviewer **[Stop: Requirement confirmation]**
+3. technical-designer -> ADR creation (if needed) -> Execute document-reviewer **[Stop: Technical direction decision]**
+4. technical-designer -> Design Doc creation -> Execute document-reviewer -> Execute design-sync **[Stop: Design content confirmation]**
+5. acceptance-test-generator -> Integration and E2E test skeleton generation
+   -> Main AI: Verify generation, then pass information to work-planner
+6. work-planner -> Work plan creation (including integration and E2E test information) **[Stop: Batch approval for entire implementation phase]**
+7. **Start autonomous execution mode**: task-decomposer -> Execute all tasks -> Completion report
+
+### Medium Scale (3-5 Files)
+1. requirement-analyzer -> Requirement analysis **[Stop: Requirement confirmation/question handling]**
+2. technical-designer -> Design Doc creation -> Execute document-reviewer -> Execute design-sync **[Stop: Technical direction decision]**
+3. acceptance-test-generator -> Integration and E2E test skeleton generation
+   -> Main AI: Verify generation, then pass information to work-planner
+4. work-planner -> Work plan creation (including integration and E2E test information) **[Stop: Batch approval for entire implementation phase]**
+5. **Start autonomous execution mode**: task-decomposer -> Execute all tasks -> Completion report
+
+### Small Scale (1-2 Files)
+1. Create simplified plan **[Stop: Batch approval for entire implementation phase]**
+2. **Start autonomous execution mode**: Direct implementation -> Completion report
+
+## Autonomous Execution Mode
+
+### Authority Delegation
+
+**After starting autonomous execution mode**:
+- Batch approval for entire implementation phase delegates authority to subagents
+- task-executor: Implementation authority (can use Edit/Write)
+- quality-fixer: Fix authority (automatic quality error fixes)
+
+### Definition of Autonomous Execution Mode
+After "batch approval for entire implementation phase" with work-planner, autonomously execute the following processes without human approval:
+
+```mermaid
+graph TD
+    START[Batch approval for entire implementation phase] --> AUTO[Start autonomous execution mode]
+    AUTO --> TD[task-decomposer: Task decomposition]
+    TD --> PHASE[Register phase management Todo]
+    PHASE --> PSTART[Phase start: Expand task Todo]
+    PSTART --> TE[task-executor: Implementation]
+    TE --> ESC{Escalation judgment}
+    ESC -->|No issue| FOLLOW[Follow-up processing]
+    ESC -->|Issue found| STOP[Escalate to user]
+    FOLLOW --> QF[quality-fixer: Quality check and fixes]
+    QF --> COMMIT[Execute git commit]
+    COMMIT --> TCHECK{Tasks remaining?}
+    TCHECK -->|Yes| TE
+    TCHECK -->|No| PCHECK{Phases remaining?}
+    PCHECK -->|Yes| PSTART
+    PCHECK -->|No| REPORT[Completion report]
+
+    TE --> INTERRUPT{User input?}
+    INTERRUPT -->|Requirement change| STOP2[Stop autonomous execution]
+    STOP2 --> RA[Re-analyze with requirement-analyzer]
+```
+
+### Conditions for Stopping Autonomous Execution
+Stop autonomous execution and escalate to user in the following cases:
+
+1. **Escalation from subagent**
+   - When receiving response with `status: "escalation_needed"`
+   - When receiving response with `status: "blocked"`
+
+2. **When requirement change detected**
+   - Any match in requirement change detection checklist
+   - Stop autonomous execution and re-analyze with integrated requirements in requirement-analyzer
+
+3. **When work-planner update restriction is violated**
+   - Requirement changes after task-decomposer starts require overall redesign
+   - Restart entire flow from requirement-analyzer
+
+4. **When user explicitly stops**
+   - Direct stop instruction or interruption
+
+## My Main Roles as Orchestrator
+
+1. **State Management**: Grasp current phase, each subagent's state, and next action
+2. **Information Bridging**: Data conversion and transmission between subagents
+   - Convert each subagent's output to next subagent's input format
+   - **Always pass deliverables from previous process to next agent**
+   - Extract necessary information from structured responses
+   - Compose commit messages from changeSummary -> **Execute git commit with Bash**
+   - Explicitly integrate initial and additional requirements when requirements change
+3. **Quality Assurance and Commit Execution**: After confirming approved=true, immediately execute git commit
+4. **Autonomous Execution Mode Management**: Start/stop autonomous execution after approval, escalation decisions
+5. **ADR Status Management**: Update ADR status after user decision (Accepted/Rejected)
+
+## Important Constraints
+
+- **Quality check is MANDATORY**: quality-fixer approval REQUIRED before commit
+- **Structured response is MANDATORY**: Information transmission between subagents MUST use JSON format
+- **Approval management**: Document creation -> Execute document-reviewer -> Get user approval BEFORE proceeding
+- **Flow confirmation**: After getting approval, ALWAYS check next step with work planning flow (large/medium/small scale)
+- **Consistency verification**: IF subagent determinations contradict -> prioritize these guidelines
+
+## Required Dialogue Points with Humans
+
+### Basic Principles
+- **Stopping is mandatory**: Always wait for human response at the following timings
+- **Confirmation -> Agreement cycle**: After document generation, proceed to next step after agreement or fix instructions in update mode
+- **Specific questions**: Make decisions easy with options (A/B/C) or comparison tables
+- **Dialogue over efficiency**: Get confirmation at early stages to prevent rework
+
+### Main Stop Points
+- **After requirement-analyzer completion**: Confirm requirement analysis results and questions
+- **After PRD creation -> document-reviewer execution**: Confirm requirement understanding and consistency (confirm with question list)
+- **After ADR creation -> document-reviewer execution**: Confirm technical direction and consistency (present multiple options with comparison table)
+  - On user approval: Main AI (me) updates Status to Accepted
+  - On user rejection: Main AI (me) updates Status to Rejected
+- **After Design Doc creation -> document-reviewer execution**: Confirm design content and consistency
+- **After work plan creation**: Batch approval for entire implementation phase (confirm with plan summary)
+
+### Stop Points During Autonomous Execution
+- **When requirement change detected**: Match in requirement change checklist -> Return to requirement-analyzer
+- **When critical error occurs**: Report error content -> Wait for response instructions
+- **When user interrupts**: Explicit stop instruction -> Confirm situation