create-ai-project 1.16.2 → 1.17.0

package/.claude/skills-en/documentation-criteria/references/design-template.md

@@ -4,6 +4,10 @@
 
 [Explain the purpose and overview of this feature in 2-3 sentences]
 
+### Referenced UI Spec (when feature includes frontend)
+- UI Spec path: [docs/ui-spec/xxx-ui-spec.md]
+- Component structure and state design are inherited from UI Spec
+
 ## Design Summary (Meta)
 
 ```yaml
@@ -196,6 +200,26 @@ Invariants:
 - [Condition that must always hold true]
 - [Constraints on valid state transitions]
 
+### UI Error State Design (when feature includes frontend)
+
+| Component / Screen | Loading | Empty | Error | Partial |
+|-------------------|---------|-------|-------|---------|
+| [Component name] | [Skeleton / spinner] | [Empty state + CTA] | [Error message + Retry] | [Cached display + Banner] |
+
+### Client State Design (when feature includes frontend)
+
+| State Category | State | Management Method | Sync Strategy |
+|---------------|-------|-------------------|---------------|
+| Server state | [Fetched data] | [Cache library / custom hook] | [Polling / WebSocket / manual refresh] |
+| Local UI state | [Modal open, tab selection] | [useState / useReducer] | - |
+| Temporary state | [Form input, draft] | [useState / form library] | [Auto-save / manual save] |
+
+### UI Action - API Contract Mapping (when feature includes frontend)
+
+| UI Action | API Endpoint | Request | Response | Error Contract |
+|-----------|-------------|---------|----------|----------------|
+| [Button click / form submit] | [POST /api/xxx] | [Request body fields] | [Response fields] | [Error codes and UI handling] |
+
 ### Error Handling
 
 [Types of errors and how to handle them]

package/.claude/skills-en/documentation-criteria/references/prd-template.md

@@ -60,6 +60,12 @@ So that [expected value/benefit]
 ### Scalability
 - [Considerations for future scaling]
 
+### Accessibility (when feature includes UI)
+- Compliance standard: [Default: WCAG 2.1 AA (use organization standard if available)]
+- Target assistive technologies: [Screen reader, keyboard operation, voice control, etc.]
+- Platform requirements: [e.g., app store review requirements]
+- Known constraints: [e.g., external library limitations]
+
 ## Success Criteria
 
 ### Quantitative Metrics
@@ -71,6 +77,10 @@ So that [expected value/benefit]
 1. [User experience metric 1]
 2. [User experience metric 2]
 
+### UI Quality Metrics (when feature includes UI)
+1. [Key operation completion rate / error recovery rate / retry success rate]
+2. [Accessibility audit target score]
+
 ## Technical Considerations
 
 ### Dependencies

package/.claude/skills-en/documentation-criteria/references/ui-spec-template.md

@@ -0,0 +1,145 @@
+# [Feature Name] UI Specification
+
+## Overview
+
+[Purpose and scope of this UI Specification in 2-3 sentences]
+
+### Target PRD
+- PRD path: [docs/prd/xxx-prd.md | "N/A — based on requirement-analyzer output"]
+- Feature scope: [Which PRD requirements this UI Spec covers | Summary of analyzed requirements]
+
+### Design Source
+| Source | Path | Version |
+|--------|------|---------|
+| Prototype code | [docs/ui-spec/assets/xxx/] | [commit SHA / tag] |
+
+## Prototype Management
+
+Prototype code is an **attachment** to this UI Spec. The canonical specification is always this document + the Design Doc.
+
+- **Attachment path**: [docs/ui-spec/assets/{feature-name}/]
+- **Version identification**: [commit SHA / tag]
+- **Compliance premise**: [e.g., design system compliance, component library usage]
+- **Relationship to canonical spec**: Differences between prototype and this spec are resolved in favor of this document. Prototype serves as visual/behavioral reference only.
+
+## AC Traceability (Prototype)
+
+Map PRD acceptance criteria to prototype references. Skip this section if no prototype is provided.
+
+| AC ID | AC Summary | Screen / State | Prototype Reference (element ID / path) | Adoption Decision |
+|-------|-----------|----------------|----------------------------------------|-------------------|
+| AC-01 | [EARS AC summary] | [Screen / state name] | [element or file reference] | Adopted / Not adopted / On hold |
+
+## Screen List and Transitions
+
+### Screen List
+
+| Screen ID | Screen Name | Description | Entry Condition |
+|-----------|------------|-------------|-----------------|
+| S-01 | [Screen name] | [Purpose] | [How user reaches this screen] |
+
+### Transition Conditions
+
+| Source | Destination | Trigger | Guard Condition |
+|--------|------------|---------|-----------------|
+| S-01 | S-02 | [User action] | [Precondition if any] |
+
+## Component Decomposition
+
+### Component Tree
+
+```
+[Page/Screen]
+  +-- [Container Component]
+  |   +-- [Presentational Component A]
+  |   +-- [Presentational Component B]
+  +-- [Container Component]
+      +-- [Presentational Component C]
+```
+
+### Component: [ComponentName]
+
+#### State x Display Matrix
+
+| State | Default | Loading | Empty | Error | Partial |
+|-------|---------|---------|-------|-------|---------|
+| Display | [Normal display] | [Skeleton / spinner] | [Empty state + CTA] | [Error message + recovery action] | [Cached / partial display] |
+
+#### Interaction Definition
+
+| AC ID | EARS Condition | User Action | System Response | State Transition | Error Handling |
+|-------|---------------|-------------|-----------------|-----------------|----------------|
+| AC-01 | When [trigger] | [Click / input / etc.] | [Expected behavior] | [From state -> To state] | [Retry / Reset / Fallback] |
+
+### Component: [ComponentName2]
+
+[Repeat State x Display Matrix and Interaction Definition for each component]
+
+## Design Tokens and Component Map
+
+### Environment Constraints
+- Target browsers: [e.g., Chrome 120+, Safari 17+]
+- Responsive breakpoints: [e.g., 768px, 1024px, 1280px]
+- Theme support: [e.g., light/dark, system preference]
+
+### Existing Component Reuse Map
+
+| UI Element | Decision | Existing Component | Notes |
+|-----------|----------|-------------------|-------|
+| [Button] | Reuse | [components/ui/Button] | [No modifications needed] |
+| [DataTable] | Extend | [components/ui/Table] | [Add sorting support] |
+| [FeatureCard] | New | - | [No similar component exists] |
+
+### Design Tokens
+
+| Token | Value | Usage |
+|-------|-------|-------|
+| [color-primary] | [value] | [Primary actions] |
+| [spacing-md] | [value] | [Component spacing] |
+
+## Visual Acceptance
+
+### Golden States
+Define the key visual states that serve as acceptance benchmarks:
+
+1. **[State name]**: [Description of what should be visually confirmed]
+2. **[State name]**: [Description]
+
+### Layout Constraints
+- [Min/max width, height constraints]
+- [Spacing rules between components]
+- [Overflow behavior]
+
+## Accessibility Requirements
+
+### Keyboard Navigation
+
+| Component | Tab Order | Key Binding | Behavior |
+|-----------|-----------|-------------|----------|
+| [Component] | [Order number] | [Enter / Space / Arrow] | [Expected behavior] |
+
+### Screen Reader
+
+| Component | Role | Accessible Name | Live Region |
+|-----------|------|-----------------|-------------|
+| [Component] | [ARIA role] | [aria-label / aria-labelledby] | [polite / assertive / none] |
+
+### Contrast Requirements
+
+| Element | Foreground | Background | Ratio Target |
+|---------|-----------|------------|-------------|
+| [Text element] | [Color] | [Color] | [4.5:1 for normal text / 3:1 for large text] |
+
+## Open Items
+
+| ID | Description | Owner | Deadline |
+|----|-------------|-------|----------|
+| TBD-01 | [Unresolved question or decision] | [Who resolves] | [Target date] |
+
+*All TBDs must have an owner and deadline. Resolve before Design Doc creation.*
+
+## Update History
+
+| Date | Version | Changes | Author |
+|------|---------|---------|--------|
+| YYYY-MM-DD | 1.0 | Initial version | [Name] |

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

@@ -1,5 +1,5 @@
 ---
-name: frontend/technical-spec
+name: frontend-technical-spec
 description: Defines frontend environment variables, component design, and data flow patterns. Use when configuring React environment.
 ---
 
@@ -109,10 +109,10 @@ async function fetchUser(id: string): Promise<User> {
 Use the appropriate run command based on the `packageManager` field in package.json.
 
 ### Build Commands
-- `dev` - Development server
-- `build` - Production build
-- `preview` - Preview production build
-- `type-check` - Type check (no emit)
+- Auto-detect and execute the following from package.json scripts:
+  - Development server
+  - Production build
+  - Type check (no emit)
 
 ### Testing Commands
 - `test` - Run tests

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

@@ -1,5 +1,5 @@
 ---
-name: frontend/typescript-rules
+name: frontend-typescript-rules
 description: Applies React/TypeScript type safety, component design, and state management rules. Use when implementing React components.
 ---
 

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

@@ -1,10 +1,17 @@
 ---
-name: frontend/typescript-testing
-description: Designs tests with React Testing Library and MSW. Applies component testing patterns.
+name: frontend-typescript-testing
+description: Designs tests with React Testing Library, MSW, and Playwright E2E. Applies component testing and E2E testing patterns.
 ---
 
 # TypeScript Testing Rules (Frontend)
 
+## References
+
+| Test Type | Reference | When to Use |
+|-----------|-----------|-------------|
+| **Unit / Integration** | This document | Implementing React component tests with RTL + Vitest + MSW |
+| **E2E** | [references/e2e.md](references/e2e.md) | Implementing browser-level E2E tests with Playwright |
+
 ## Test Framework
 - **Vitest**: This project uses Vitest
 - **React Testing Library**: For component testing

package/.claude/skills-en/frontend-typescript-testing/references/e2e.md

@@ -0,0 +1,185 @@
+# E2E Test Implementation with Playwright
+
+## Test Framework
+- **Playwright Test**: `@playwright/test`
+- Test imports: `import { test, expect } from '@playwright/test'`
+
+## Test Structure
+
+### Directory Layout
+```
+tests/
+└── e2e/
+    ├── pages/              # Page objects
+    │   ├── login.page.ts
+    │   └── dashboard.page.ts
+    ├── fixtures/           # Test fixtures
+    │   └── auth.fixture.ts
+    └── *.e2e.test.ts       # Test files
+```
+
+### Naming Conventions
+- Test files: `{FeatureName}.e2e.test.ts`
+- Page objects: `{PageName}.page.ts`
+- Fixtures: `{Purpose}.fixture.ts`
+
+## Page Object Pattern
+
+Encapsulate page interactions for reusability and maintainability:
+
+```typescript
+import { type Page, type Locator } from '@playwright/test'
+
+export class LoginPage {
+  readonly emailInput: Locator
+  readonly passwordInput: Locator
+  readonly submitButton: Locator
+
+  constructor(private page: Page) {
+    this.emailInput = page.getByLabel('Email')
+    this.passwordInput = page.getByLabel('Password')
+    this.submitButton = page.getByRole('button', { name: 'Sign in' })
+  }
+
+  async login(email: string, password: string) {
+    await this.emailInput.fill(email)
+    await this.passwordInput.fill(password)
+    await this.submitButton.click()
+  }
+}
+```
+
+## Test Patterns
+
+### Basic Test
+```typescript
+import { test, expect } from '@playwright/test'
+
+test('user can navigate to dashboard after login', async ({ page }) => {
+  // Arrange
+  await page.goto('/login')
+
+  // Act
+  await page.getByLabel('Email').fill('user@example.com')
+  await page.getByLabel('Password').fill('password')
+  await page.getByRole('button', { name: 'Sign in' }).click()
+
+  // Assert
+  await expect(page).toHaveURL('/dashboard')
+  await expect(page.getByRole('heading', { name: 'Dashboard' })).toBeVisible()
+})
+```
+
+### With Page Objects
+```typescript
+import { test, expect } from '@playwright/test'
+import { LoginPage } from './pages/login.page'
+import { DashboardPage } from './pages/dashboard.page'
+
+test('user completes purchase flow', async ({ page }) => {
+  const loginPage = new LoginPage(page)
+  const dashboardPage = new DashboardPage(page)
+
+  await page.goto('/login')
+  await loginPage.login('user@example.com', 'password')
+  await expect(dashboardPage.heading).toBeVisible()
+})
+```
+
+### Auth Fixture
+```typescript
+import { test as base } from '@playwright/test'
+
+export const test = base.extend<{ authenticatedPage: Page }>({
+  authenticatedPage: async ({ page }, use) => {
+    await page.goto('/login')
+    await page.getByLabel('Email').fill('user@example.com')
+    await page.getByLabel('Password').fill('password')
+    await page.getByRole('button', { name: 'Sign in' }).click()
+    await page.waitForURL('/dashboard')
+    await use(page)
+  },
+})
+```
+
+## Locator Strategy
+
+Prefer accessible locators in this order:
+1. `page.getByRole()` — best for accessibility
+2. `page.getByLabel()` — form elements
+3. `page.getByText()` — visible text
+4. `page.getByTestId()` — last resort
+
+```typescript
+// Preferred
+await page.getByRole('button', { name: 'Submit' }).click()
+
+// Avoid
+await page.locator('#submit-btn').click()
+await page.locator('.btn-primary').click()
+```
+
+## Assertions
+
+```typescript
+// Visibility
+await expect(page.getByText('Success')).toBeVisible()
+await expect(page.getByText('Error')).not.toBeVisible()
+
+// Navigation
+await expect(page).toHaveURL('/dashboard')
+await expect(page).toHaveTitle('Dashboard')
+
+// Element state
+await expect(page.getByRole('button')).toBeEnabled()
+await expect(page.getByRole('button')).toBeDisabled()
+
+// Content
+await expect(page.getByRole('heading')).toHaveText('Welcome')
+```
+
+## Viewport Testing
+
+When UI Spec defines responsive behavior:
+
+```typescript
+test.describe('responsive navigation', () => {
+  test('shows hamburger menu on mobile', async ({ page }) => {
+    await page.setViewportSize({ width: 375, height: 667 })
+    await page.goto('/')
+    await expect(page.getByRole('button', { name: 'Menu' })).toBeVisible()
+    await expect(page.getByRole('navigation')).not.toBeVisible()
+  })
+
+  test('shows full navigation on desktop', async ({ page }) => {
+    await page.setViewportSize({ width: 1280, height: 720 })
+    await page.goto('/')
+    await expect(page.getByRole('navigation')).toBeVisible()
+  })
+})
+```
+
+## Test Isolation
+
+- Each test starts from a clean browser context
+- No shared state between tests
+- Use `beforeEach` for common setup (auth, navigation)
+- Prefer `page.goto()` over in-test navigation for setup steps
+
+## Skeleton Comment Format
+
+E2E test skeletons follow the same annotation format as integration tests:
+
+```typescript
+// AC: [Original acceptance criteria text]
+// Behavior: [User action] → [System response] → [Observable result]
+// @category: e2e
+// @dependency: full-system
+// @complexity: high
+// ROI: [score]
+test('AC1: [Description]', async ({ page }) => {
+  // Arrange: [Setup description]
+  // Act: [Action description]
+  // Assert: [Verification description]
+})
+```

package/.claude/skills-en/integration-e2e-testing/SKILL.md

@@ -5,6 +5,10 @@ description: Designs integration and E2E tests with mock boundaries and behavior
 
 # Integration Test & E2E Test Design/Implementation Rules
 
+## References
+
+- **[references/e2e-design.md](references/e2e-design.md)** - E2E test design principles with Playwright (candidate sources, selection criteria, UI Spec mapping)
+
 ## Test Types and Limits
 
 | Type | Purpose | File Format | Limit |

package/.claude/skills-en/integration-e2e-testing/references/e2e-design.md

@@ -0,0 +1,86 @@
+# E2E Test Design with Playwright
+
+## When to Create E2E Tests
+
+E2E tests target **critical user journeys** that span multiple pages or require real browser interaction. Apply the same ROI framework from the parent skill — only create E2E tests when ROI > 50.
+
+### Candidate Sources
+
+| Source | What to Extract |
+|--------|----------------|
+| **Design Doc ACs** | User journeys with EARS "When" keyword spanning multiple screens |
+| **UI Spec Screen Transitions** | Multi-step flows (e.g., form wizard, checkout) |
+| **UI Spec State x Display Matrix** | Error/empty/loading states requiring browser-level verification |
+| **UI Spec Interaction Definitions** | Complex interactions (drag-drop, keyboard navigation, responsive behavior) |
+
+### Selection Criteria
+
+**Include** (high E2E ROI):
+- Multi-page user journeys (login → dashboard → action → confirmation)
+- Flows requiring real browser APIs (navigation, cookies, localStorage)
+- Accessibility verification requiring actual DOM rendering
+- Responsive behavior across viewports
+
+**Exclude** (use integration tests instead):
+- Single-component state changes (use RTL)
+- API response handling (use MSW + RTL)
+- Pure data transformations
+
+## UI Spec to E2E Test Mapping
+
+When a UI Spec exists, use it as the primary source for E2E test design:
+
+1. **Extract screen transitions** → Each multi-step transition = 1 E2E candidate
+2. **Check state x display matrix** → Error states requiring navigation = E2E candidate
+3. **Review interaction definitions** → Browser-dependent interactions = E2E candidate
+4. **Cross-reference with Design Doc ACs** → Ensure E2E candidates map to acceptance criteria
+
+### Mapping Template
+
+```
+Screen Transition: [Screen A] → [Screen B] → [Screen C]
+AC Reference: AC-{id}
+User Journey: [Description of what the user accomplishes]
+Preconditions: [Auth state, data state]
+Verification Points:
+  - [What to assert at each step]
+E2E ROI Score: [calculated score]
+```
+
+## Playwright Test Architecture
+
+### Page Object Pattern
+
+Organize browser interactions through page objects for maintainability:
+
+```
+tests/
+├── e2e/
+│   ├── pages/           # Page objects
+│   ├── fixtures/        # Test fixtures and helpers
+│   └── *.e2e.test.ts    # Test files
+```
+
+### Test Isolation
+
+- Each test starts from a clean browser context
+- No shared state between tests
+- Use `beforeEach` for common setup (auth, navigation)
+- Prefer `page.goto()` over in-test navigation for setup
+
+### Viewport Testing
+
+When UI Spec defines responsive behavior, test critical breakpoints:
+
+| Breakpoint | Width | When to Test |
+|-----------|-------|-------------|
+| Mobile | 375px | If UI Spec defines mobile-specific interactions |
+| Tablet | 768px | If UI Spec defines tablet layout differences |
+| Desktop | 1280px | Default — always test |
+
+## Budget Enforcement
+
+Hard limits per feature (same as parent skill):
+- **E2E Tests**: MAX 1-2 tests
+- Only generate if ROI score > 50
+- Prefer fewer, comprehensive journey tests over many granular tests

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

@@ -56,11 +56,12 @@ graph TD
 ### 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)
+7. **ui-spec-designer**: UI Specification creation from PRD and optional prototype code (frontend/fullstack features)
+8. **technical-designer**: ADR/Design Doc creation (latest technology research, Property annotation assignment)
+9. **work-planner**: Work plan creation from Design Doc and test skeletons
+10. **document-reviewer**: Single document quality, completeness, and rule compliance check
+11. **design-sync**: Design Doc consistency verification (detects explicit conflicts only)
+12. **acceptance-test-generator**: Generate separate integration and E2E test skeletons from Design Doc ACs and optional UI Spec
 
 ## My Orchestration Principles
 
@@ -118,29 +119,33 @@ Subagents respond in JSON format. Key fields for orchestrator decisions:
 When receiving new features or change requests, I first request requirement analysis from requirement-analyzer.
 According to scale determination:
 
-### Large Scale (6+ Files) - 11 Steps
+### Large Scale (6+ Files) - 11 Steps (backend) / 13 Steps (frontend/fullstack)
 
 1. requirement-analyzer → Requirement analysis + Check existing PRD **[Stop]**
 2. prd-creator → PRD creation
 3. document-reviewer → PRD review **[Stop: PRD Approval]**
-4. technical-designer → ADR creation (if architecture/technology/data flow changes)
-5. document-reviewer → ADR review (if ADR created) **[Stop: ADR Approval]**
-6. technical-designer → Design Doc creation (cross-layer: per layer, see Cross-Layer Orchestration)
-7. document-reviewer → Design Doc review (cross-layer: per Design Doc)
-8. design-sync → Consistency verification **[Stop: Design Doc Approval]**
-9. acceptance-test-generator → Test skeleton generation, pass to work-planner (*1)
-10. work-planner → Work plan creation **[Stop: Batch approval]**
-11. task-decomposer → Autonomous execution → Completion report
-
-### Medium Scale (3-5 Files) - 7 Steps
+4. **(frontend/fullstack only)** Ask user for prototype code → ui-spec-designer → UI Spec creation
+5. **(frontend/fullstack only)** document-reviewer → UI Spec review **[Stop: UI Spec Approval]**
+6. technical-designer → ADR creation (if architecture/technology/data flow changes)
+7. document-reviewer → ADR review (if ADR created) **[Stop: ADR Approval]**
+8. technical-designer → Design Doc creation (cross-layer: per layer, see Cross-Layer Orchestration)
+9. document-reviewer → Design Doc review (cross-layer: per Design Doc)
+10. design-sync → Consistency verification **[Stop: Design Doc Approval]**
+11. acceptance-test-generator → Test skeleton generation, pass to work-planner (*1)
+12. work-planner → Work plan creation **[Stop: Batch approval]**
+13. task-decomposer → Autonomous execution → Completion report
+
+### Medium Scale (3-5 Files) - 7 Steps (backend) / 9 Steps (frontend/fullstack)
 
 1. requirement-analyzer → Requirement analysis **[Stop]**
-2. technical-designer → Design Doc creation (cross-layer: per layer, see Cross-Layer Orchestration)
-3. document-reviewer → Design Doc review (cross-layer: per Design Doc)
-4. design-sync → Consistency verification **[Stop: Design Doc Approval]**
-5. acceptance-test-generator → Test skeleton generation, pass to work-planner (*1)
-6. work-planner → Work plan creation **[Stop: Batch approval]**
-7. task-decomposer → Autonomous execution → Completion report
+2. **(frontend/fullstack only)** Ask user for prototype code → ui-spec-designer → UI Spec creation
+3. **(frontend/fullstack only)** document-reviewer → UI Spec review **[Stop: UI Spec Approval]**
+4. technical-designer → Design Doc creation (cross-layer: per layer, see Cross-Layer Orchestration)
+5. document-reviewer → Design Doc review (cross-layer: per Design Doc)
+6. design-sync → Consistency verification **[Stop: Design Doc Approval]**
+7. acceptance-test-generator → Test skeleton generation, pass to work-planner (*1)
+8. work-planner → Work plan creation **[Stop: Batch approval]**
+9. task-decomposer → Autonomous execution → Completion report
 
 ### Small Scale (1-2 Files) - 2 Steps
 
@@ -225,6 +230,22 @@ Stop autonomous execution and escalate to user in the following cases:
    - 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
+
+   #### *1 acceptance-test-generator → work-planner
+
+   **Pass to acceptance-test-generator**:
+   - Design Doc: [path]
+   - UI Spec: [path] (if exists)
+
+   **Orchestrator verification items**:
+   - Verify integration test file path retrieval and existence
+   - Verify E2E test file path retrieval and existence
+
+   **Pass to work-planner**:
+   - Integration test file: [path] (create and execute simultaneously with each phase implementation)
+   - E2E test file: [path] (execute only in final phase)
+
+   **On error**: Escalate to user if files are not generated
 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)
@@ -249,6 +270,7 @@ Stop autonomous execution and escalate to user in the following cases:
 ### 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 UI Spec creation -> document-reviewer execution** (frontend/fullstack): Confirm UI specification completeness and consistency
 - **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