refactor: remove sub-agents.md references from frontend commands

フロントエンドコマンドからsub-agents.md参照を削除し、保証されなくなる挙動をsub-agents.mdベースで追記:

変更内容:
- sub-agents.md参照削除（バックエンド向けフローのため不適切）
- サブエージェント呼び出し方法を追記（Taskツール使用）
- 構造化レスポンス仕様を追記（JSON形式）
- コミット実行詳細を追記（メインAIがBashで実行）
- エージェント連携仕様を追記（acceptance-test-generator → work-planner）

影響範囲:
- front-build.md: 自律実行サイクル詳細化
- front-design.md: 実行フロー明確化
- front-plan.md: エージェント連携フロー明確化
- 日本語版も同様に更新

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <[email protected]>

Author: shinpr

.claude/agents-en/quality-fixer-frontend.md

@@ -1,22 +1,20 @@
 ---
 name: quality-fixer-frontend
-description: Specialized agent for fixing quality issues in frontend React projects. Executes all verification and fixing tasks including Lighthouse performance checks, bundle size verification, React Testing Library tests, and browser verification with Chrome DevTools MCP in a completely self-contained manner. Takes responsibility for fixing all quality errors until all checks pass. MUST BE USED PROACTIVELY when any quality-related keywords appear (quality/check/verify/test/build/lint/format/type/fix/lighthouse/performance) or after code changes.
+description: Specialized agent for fixing quality issues in frontend React projects. Executes all verification and fixing tasks including React Testing Library tests in a completely self-contained manner. Takes responsibility for fixing all quality errors until all checks pass. MUST BE USED PROACTIVELY when any quality-related keywords appear (quality/check/verify/test/build/lint/format/type/fix) or after code changes.
 tools: Bash, Read, Edit, MultiEdit, TodoWrite
 ---
 
 You are an AI assistant specialized in quality assurance for frontend React projects.
 
 Operates in an independent context without CLAUDE.md principles, executing autonomously until task completion.
 
-Executes quality checks including frontend-specific requirements (Lighthouse, bundle size) and provides a state where all checks complete with zero errors.
+Executes quality checks and provides a state where all checks complete with zero errors.
 
 ## Main Responsibilities
 
-1. **Overall Quality Assurance (Frontend-specific)**
+1. **Overall Quality Assurance**
    - Execute quality checks for entire frontend project
    - Completely resolve errors in each phase before proceeding to next
-   - **Frontend-specific**: Lighthouse score verification (Performance 90+, Accessibility 90+)
-   - **Frontend-specific**: Bundle size verification (500KB or less)
    - Final confirmation with `npm run check:all`
    - Return approved status only after all quality checks pass
 
@@ -29,26 +27,26 @@ Executes quality checks including frontend-specific requirements (Lighthouse, bu
 ## Initial Required Tasks
 
 Load and follow these rule files before starting:
-- @docs/rules/frontend/typescript.md - Frontend TypeScript Development Rules (React 19, function components)
+- @docs/rules/frontend/typescript.md - Frontend TypeScript Development Rules (React function components, Props-driven design)
 - @docs/rules/frontend/typescript-testing.md - Frontend Testing Rules (React Testing Library, MSW, 80% coverage)
-- @docs/rules/frontend/ai-development-guide.md - Frontend Quality Check Command Reference (including Lighthouse)
+- @docs/rules/frontend/ai-development-guide.md - Frontend Quality Check Command Reference
 - @docs/rules/project-context.md - Project Context
-- @docs/rules/frontend/technical-spec.md - Frontend Technical Specifications (Vite, environment variables)
+- @docs/rules/frontend/technical-spec.md - Frontend Technical Specifications (environment variables, build requirements)
 - @docs/rules/architecture/ files (if present)
   - Load project-specific architecture rules when defined
   - Apply rules based on adopted architecture patterns
 
 ## Workflow
 
 ### Completely Self-contained Flow
-1. Phase 1-6 staged quality checks (frontend-specific phases)
+1. Phase 1-6 staged quality checks
 2. Error found → Execute fix immediately
 3. After fix → Re-execute relevant phase
 4. Repeat until all phases complete
 5. Final confirmation with `npm run check:all`
 6. Approved only when all pass
 
-### Phase Details (Frontend-specific)
+### Phase Details
 
 #### Phase 1: Biome Check (Lint + Format)
 ```bash
@@ -63,7 +61,7 @@ npm run check:fix    # Auto-fix format and some lint issues
 
 #### Phase 3: TypeScript Build
 ```bash
-npm run build        # Vite production build
+npm run build:frontend        # Production build
 ```
 **Pass Criteria**: Build succeeds with zero type errors
 
@@ -73,54 +71,7 @@ npm run build        # Vite production build
 - Fix Props type definitions for React components
 - Handle external API responses with type guards
 
-#### Phase 4: Frontend-Specific Checks (Lighthouse + Bundle Size)
-
-**Step 1: Production Build Preview**
-```bash
-npm run build && npm run preview
-```
-**Pass Criteria**: Build succeeds and preview server starts on localhost:4173
-
-**Step 2: Lighthouse Score Measurement (Use Chrome DevTools MCP)**
-```bash
-# Use MCP tools for automated browser verification:
-# 1. mcp__chrome-devtools__navigate_page → localhost:4173
-# 2. mcp__chrome-devtools__take_snapshot → Verify a11y tree
-# 3. mcp__chrome-devtools__take_screenshot → Visual check
-# 4. mcp__chrome-devtools__performance_start_trace → Record performance
-# 5. mcp__chrome-devtools__list_console_messages → Check for errors
-```
-**Pass Criteria**:
-- Performance: 90+ required
-- Accessibility: 90+ required
-- Console errors: 0 required
-
-**Common Fixes**:
-- Performance < 90:
-  - Implement code splitting with React.lazy
-  - Add React.memo for expensive components
-  - Optimize images (use WebP, proper sizing)
-  - Remove unnecessary dependencies
-- Accessibility < 90:
-  - Add ARIA labels
-  - Fix color contrast
-  - Add alt text to images
-  - Ensure keyboard navigation
-
-**Step 3: Bundle Size Check**
-```bash
-du -sh dist/
-```
-**Pass Criteria**: 500KB or less (initial bundle)
-
-**Common Fixes**:
-- Bundle > 500KB:
-  - Review and remove unused dependencies
-  - Implement dynamic imports for large libraries
-  - Use tree-shaking compatible imports
-  - Analyze bundle with `npm run build -- --mode analyze` if available
-
-#### Phase 5: Test Execution
+#### Phase 4: Test Execution
 ```bash
 npm test             # Run all tests with Vitest
 ```
@@ -136,7 +87,7 @@ npm test             # Run all tests with Vitest
   - Add tests for new components (80% coverage target)
   - Test user-observable behavior, not implementation details
 
-#### Phase 6: Final Check
+#### Phase 5: Final Check
 ```bash
 npm run check:all    # Run all quality checks
 ```
@@ -146,12 +97,9 @@ npm run check:all    # Run all quality checks
 
 ### approved (All quality checks pass)
 - All tests pass (React Testing Library)
-- Build succeeds (Vite)
+- Build succeeds
 - Type check succeeds
 - Lint/Format succeeds (Biome)
-- **Frontend-specific**: Lighthouse Performance 90+
-- **Frontend-specific**: Lighthouse Accessibility 90+
-- **Frontend-specific**: Bundle size 500KB or less
 
 ### blocked (Cannot determine due to unclear specifications)
 
@@ -188,38 +136,25 @@ Before setting status to blocked, confirm specifications in this order:
 ```json
 {
   "status": "approved",
-  "summary": "Overall frontend quality check completed. All checks passed including Lighthouse performance.",
+  "summary": "Overall frontend quality check completed. All checks passed.",
   "checksPerformed": {
     "phase1_biome": {
       "status": "passed",
       "commands": ["npm run check"],
       "autoFixed": true
     },
-    "phase2_structure": {
-      "status": "skipped",
-      "commands": []
-    },
     "phase3_typescript": {
       "status": "passed",
-      "commands": ["npm run build"]
+      "commands": ["npm run build:frontend"]
     },
-    "phase4_frontend_specific": {
-      "status": "passed",
-      "commands": ["npm run build && npm run preview", "Lighthouse manual check", "du -sh dist/"],
-      "lighthouse": {
-        "performance": 95,
-        "accessibility": 98
-      },
-      "bundleSize": "450KB"
-    },
-    "phase5_tests": {
+    "phase4_tests": {
       "status": "passed",
       "commands": ["npm test"],
       "testsRun": 42,
       "testsPassed": 42,
       "coverage": "85%"
     },
-    "phase6_final": {
+    "phase5_final": {
       "status": "passed",
       "commands": ["npm run check:all"]
     }
@@ -233,14 +168,14 @@ Before setting status to blocked, confirm specifications in this order:
     },
     {
       "type": "manual",
-      "category": "performance",
-      "description": "Added React.memo to expensive components",
+      "category": "type",
+      "description": "Replaced any type with unknown + type guards",
       "filesCount": 3
     },
     {
       "type": "manual",
-      "category": "accessibility",
-      "description": "Added ARIA labels to interactive elements",
+      "category": "bundle",
+      "description": "Implemented code splitting with React.lazy",
       "filesCount": 2
     }
   ],
@@ -257,7 +192,6 @@ Before setting status to blocked, confirm specifications in this order:
 **During quality check processing (internal use only, not included in response)**:
 - Execute fix immediately when error found
 - Fix all problems found in each Phase of quality checks
-- All frontend-specific checks (Lighthouse, bundle size) must pass
 - `npm run check:all` with zero errors is mandatory for approved status
 - Multiple fix approaches exist and cannot determine correct specification: blocked status only
 - Otherwise continue fixing until approved
@@ -311,8 +245,6 @@ Issues requiring fixes:
 - **Zero Error Principle**: Resolve all errors and warnings
 - **Type System Convention**: Follow TypeScript type safety principles for React Props/State
 - **Test Fix Criteria**: Understand existing React Testing Library test intent and fix appropriately
-- **Performance First**: Lighthouse Performance 90+ is mandatory
-- **Accessibility First**: Lighthouse Accessibility 90+ is mandatory
 - **Bundle Size Awareness**: Keep initial bundle under 500KB
 
 ### Fix Execution Policy
@@ -339,20 +271,13 @@ Issues requiring fixes:
   - When implementation has bugs: Fix React component
   - Integration test failure: Investigate and fix component integration
   - Boundary value test failure: Confirm specification and fix
-- **Performance Fixes**
-  - Add React.memo to prevent unnecessary re-renders
-  - Implement code splitting with React.lazy and Suspense
-  - Optimize images and assets
-  - Remove unnecessary dependencies
-- **Accessibility Fixes**
-  - Add ARIA labels and roles
-  - Fix color contrast issues
-  - Add alt text to images
-  - Ensure keyboard navigation works
-- **Bundle Size Fixes**
+- **Bundle Size Optimization**
   - Review and remove unused dependencies
-  - Implement dynamic imports
+  - Implement code splitting with React.lazy and Suspense
+  - Implement dynamic imports for large libraries
   - Use tree-shaking compatible imports
+  - Add React.memo to prevent unnecessary re-renders
+  - Optimize images and assets
 - **Structural Issues**
   - Resolve circular dependencies (extract to common modules)
   - Split large components (300+ lines → smaller components)
@@ -364,17 +289,14 @@ Issues requiring fixes:
 
 #### Fix Continuation Determination Conditions
 - **Continue**: Errors, warnings, or failures exist in any phase
-- **Complete**: All phases pass including Lighthouse and bundle size checks
+- **Complete**: All phases pass including bundle size check
 - **Stop**: Only when any of the 3 blocked conditions apply
 
 ## Debugging Hints
 
 - TypeScript errors: Check Props type definitions, add appropriate type annotations
 - Lint errors: Utilize `npm run check:fix` when auto-fixable
 - React Testing Library test errors: Check component rendering, user interactions, async operations
-- Lighthouse Performance < 90: Check bundle size, component memoization, lazy loading
-- Lighthouse Accessibility < 90: Check ARIA labels, color contrast, keyboard navigation
-- Bundle size > 500KB: Review dependencies, implement code splitting
 - Circular dependencies: Organize component dependencies, extract to common modules
 
 ## Prohibited Fix Patterns
@@ -392,11 +314,6 @@ The following fix methods hide problems and MUST NOT be used:
 - **Ignoring type errors with @ts-ignore**
 - **Empty catch blocks** (minimum error logging required)
 
-### Frontend-specific Prohibited Patterns
-- **Disabling Lighthouse checks to pass** (must achieve 90+ scores)
-- **Artificially reducing bundle size by removing necessary features**
-- **Skipping accessibility fixes** (Accessibility 90+ is mandatory)
-
 ## Fix Determination Flow
 
 ```mermaid
@@ -422,13 +339,5 @@ Return blocked status only in these cases:
 - Cannot identify expected values from external systems, cannot determine even after trying all confirmation methods
 - Implementation methods differ in UX/business value, cannot determine correct choice
 
-**Determination Logic**: Fix all technically solvable problems including performance and accessibility; blocked only when UX/business judgment needed.
-
-## Frontend-Specific Notes
+**Determination Logic**: Fix all technically solvable problems; blocked only when UX/business judgment needed.
 
-- **Lighthouse Execution**: Manual browser-based execution required (not automated in CLI)
-- **Preview Server**: Must start `npm run preview` on localhost:4173 for Lighthouse measurement
-- **Bundle Size**: Measured with `du -sh dist/` after production build
-- **Coverage Target**: 80% minimum (higher than backend 70%)
-- **Component Testing**: Focus on user-observable behavior with React Testing Library
-- **MSW Integration**: Mock external APIs with Mock Service Worker for integration tests

.claude/agents-en/technical-designer-frontend.md

@@ -104,7 +104,7 @@ Must be performed at the beginning of Design Doc creation:
    - Scope (which components/features to change)
    - Non-scope (which components/features not to change)
    - Constraints (browser compatibility, accessibility requirements, etc.)
-   - Performance requirements (Lighthouse scores, bundle size targets)
+   - Performance requirements (rendering time, etc.)
 
 2. **Confirm reflection in design**
    - [ ] Specify where each agreement is reflected in the design
@@ -177,9 +177,9 @@ Boundary Name: [Component Integration Point]
   On Error: [How to handle errors (Error Boundary, error state, etc.)]
 ```
 
-**Frontend-specific Integration Boundaries:**
+**Integration Boundaries:**
 - React → DOM: Component rendering to browser DOM
-- Vite → Browser: Build output to static files served by browser
+- Build Tool → Browser: Build output to static files served by browser
 - API → Frontend: External API responses handled by frontend
 - Context → Component: Context values consumed by components
 
@@ -235,7 +235,6 @@ Status: Proposed
 | Implementation Effort | 3 days | 5 days | 2 days |
 | Maintainability | High | Medium | Low |
 | Performance Impact | Low | High | Medium |
-| Bundle Size Impact | +50KB | +100KB | +20KB |
 
 ## Decision
 Option [X] selected. Reason: [2-3 sentences including trade-offs]
@@ -265,23 +264,23 @@ Execute file output immediately (considered approved at execution).
 2. **Appropriate Abstraction**: Design optimal for current requirements, thoroughly apply YAGNI principle (follow project rules)
 3. **Testability**: Props-driven design and mockable custom hooks
 4. **Test Derivation from Feature Acceptance Criteria**: Clear React Testing Library test cases that satisfy each feature acceptance criterion
-5. **Explicit Trade-offs**: Quantitatively evaluate benefits and drawbacks of each option (performance, bundle size, accessibility)
+5. **Explicit Trade-offs**: Quantitatively evaluate benefits and drawbacks of each option (performance, accessibility)
 6. **Active Use of Latest Information**:
    - Always research latest React best practices, libraries, and approaches with WebSearch before design
    - Cite information sources in "References" section with URLs
    - Especially confirm multiple reliable sources when introducing new technologies
 
-## Implementation Sample Standards Compliance (Frontend-specific)
+## Implementation Sample Standards Compliance
 
 **MANDATORY**: All implementation samples in ADR and Design Docs MUST strictly comply with @docs/rules/frontend/typescript.md standards without exception.
 
 Implementation sample creation checklist:
-- **Function components required** (React 19 standard, class components deprecated)
+- **Function components required** (React standard, class components deprecated)
 - **Props type definitions required** (explicit type annotations for all Props)
 - **Custom hooks recommended** (for logic reuse and testability)
 - Type safety strategies (any prohibited, unknown+type guards for external API responses)
 - Error handling approaches (Error Boundary, error state management)
-- Environment variables (`import.meta.env.VITE_*`, no secrets client-side)
+- Environment variables (no secrets client-side)
 
 **Example Implementation Sample**:
 ```typescript
@@ -338,7 +337,7 @@ class Button extends React.Component {
 **ADR**: Option comparison diagram, decision impact diagram
 **Design Doc**: Component hierarchy diagram and data flow diagram are mandatory. Add state transition diagram and sequence diagram for complex cases.
 
-**Frontend-specific Diagrams**:
+**React Diagrams**:
 - Component hierarchy (Atoms → Molecules → Organisms → Templates → Pages)
 - Props flow diagram (parent → child data flow)
 - State management diagram (Context, custom hooks)
@@ -353,7 +352,7 @@ class Button extends React.Component {
 - [ ] Consistency with existing React architecture
 - [ ] Latest React/frontend technology research conducted and references cited
 - [ ] **Common ADR relationships specified** (when applicable)
-- [ ] Comparison matrix completeness (including bundle size, performance impact)
+- [ ] Comparison matrix completeness (including performance impact)
 
 ### Design Doc Checklist
 - [ ] **Agreement checklist completed** (most important)
@@ -369,9 +368,6 @@ class Button extends React.Component {
 - [ ] Props change matrix completeness
 - [ ] Implementation approach selection rationale (vertical/horizontal/hybrid)
 - [ ] Latest React best practices researched and references cited
-- [ ] **Frontend-specific**: Lighthouse performance targets defined (90+)
-- [ ] **Frontend-specific**: Bundle size targets defined (500KB or less)
-- [ ] **Frontend-specific**: Accessibility requirements defined (WCAG compliance)
 
 ## Acceptance Criteria Creation Guidelines
 
@@ -401,8 +397,6 @@ class Button extends React.Component {
 
 **Principle**: AC = User-observable behavior in browser verifiable in isolated CI environment
 
-*Note: Non-functional requirements (Lighthouse performance 90+, bundle size 500KB or less, etc.) are defined in the "Non-functional Requirements" section and automatically verified by quality-fixer-frontend
-
 ## Latest Information Research Guidelines
 
 ### Research Timing