create-ai-project 1.16.2 → 1.17.0

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

@@ -0,0 +1,86 @@
+# PlaywrightによるE2Eテスト設計
+
+## E2Eテストを作成するタイミング
+
+E2Eテストは、複数ページにまたがる、または実ブラウザ操作を必要とする**クリティカルなユーザージャーニー**を対象とする。親スキルと同じROIフレームワークを適用し、ROI > 50の場合のみE2Eテストを作成。
+
+### 候補ソース
+
+| ソース | 抽出対象 |
+|--------|---------|
+| **Design DocのAC** | 複数画面にまたがるEARS "When" キーワードを含むユーザージャーニー |
+| **UI Specの画面遷移** | 複数ステップのフロー（例: フォームウィザード、チェックアウト） |
+| **UI Specの状態×表示マトリクス** | ブラウザレベルの検証を必要とするエラー/Empty/ローディング状態 |
+| **UI Specのインタラクション定義** | 複雑なインタラクション（ドラッグ&ドロップ、キーボードナビゲーション、レスポンシブ動作） |
+
+### 選定基準
+
+**対象**（高E2E ROI）:
+- 複数ページにまたがるユーザージャーニー（ログイン → ダッシュボード → 操作 → 確認）
+- 実ブラウザAPIを必要とするフロー（ナビゲーション、Cookie、localStorage）
+- 実DOM描画が必要なアクセシビリティ検証
+- Viewportをまたぐレスポンシブ動作
+
+**対象外**（統合テストを使用）:
+- 単一コンポーネントの状態変化（RTLを使用）
+- APIレスポンスの処理（MSW + RTLを使用）
+- 純粋なデータ変換
+
+## UI SpecからE2Eテストへのマッピング
+
+UI Specが存在する場合、E2Eテスト設計の主要ソースとして使用:
+
+1. **画面遷移を抽出** → 複数ステップの各遷移 = 1つのE2E候補
+2. **状態×表示マトリクスを確認** → ナビゲーションを必要とするエラー状態 = E2E候補
+3. **インタラクション定義をレビュー** → ブラウザ依存のインタラクション = E2E候補
+4. **Design DocのACと照合** → E2E候補が受入条件にマッピングされていることを確認
+
+### マッピングテンプレート
+
+```
+画面遷移: [画面A] → [画面B] → [画面C]
+AC参照: AC-{id}
+ユーザージャーニー: [ユーザーが達成する内容の説明]
+前提条件: [認証状態、データ状態]
+検証ポイント:
+  - [各ステップでアサートすべき内容]
+E2E ROIスコア: [計算スコア]
+```
+
+## Playwrightテストアーキテクチャ
+
+### ページオブジェクトパターン
+
+保守性のためにブラウザ操作をページオブジェクトで整理:
+
+```
+tests/
+├── e2e/
+│   ├── pages/           # ページオブジェクト
+│   ├── fixtures/        # テストFixtureとヘルパー
+│   └── *.e2e.test.ts    # テストファイル
+```
+
+### テスト分離
+
+- 各テストはクリーンなブラウザコンテキストから開始
+- テスト間で状態を共有しない
+- 共通セットアップ（認証、ナビゲーション）には`beforeEach`を使用
+- セットアップではテスト内ナビゲーションより`page.goto()`を優先
+
+### Viewportテスト
+
+UI Specでレスポンシブ動作が定義されている場合、クリティカルなBreakpointをテスト:
+
+| Breakpoint | 幅 | テスト条件 |
+|-----------|------|-----------|
+| モバイル | 375px | UI Specでモバイル固有のインタラクションが定義されている場合 |
+| タブレット | 768px | UI Specでタブレット用レイアウトの差異が定義されている場合 |
+| デスクトップ | 1280px | デフォルト — 常にテスト |
+
+## 上限制約
+
+機能あたりのハードリミット（親スキルと同一）:
+- **E2Eテスト**: 最大1-2テスト
+- ROIスコア > 50の場合のみ生成
+- 多数の粒度の細かいテストより、少数の包括的なジャーニーテストを優先

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

@@ -54,11 +54,12 @@ graph TD
 ### ドキュメント作成エージェント
 5. **requirement-analyzer**: 要件分析と作業規模判定（WebSearch対応、最新技術情報の調査）
 6. **prd-creator**: Product Requirements Document作成（WebSearch対応、市場動向調査）
-7. **technical-designer**: ADR/Design Doc作成（最新技術情報の調査、Property注釈付与）
-8. **work-planner**: 作業計画書作成（テストスケルトンからメタ情報を抽出・反映）
-9. **document-reviewer**: 単一ドキュメントの品質・完成度・ルール準拠チェック
-10. **design-sync**: Design Doc間の整合性検証（明示的矛盾のみ検出）
-11. **acceptance-test-generator**: Design DocのACから統合テストとE2Eテストのスケルトン生成
+7. **ui-spec-designer**: PRDとプロトタイプコード（任意）からUI Spec作成（フロントエンド/フルスタック機能）
+8. **technical-designer**: ADR/Design Doc作成（最新技術情報の調査、Property注釈付与）
+9. **work-planner**: 作業計画書作成（テストスケルトンからメタ情報を抽出・反映）
+10. **document-reviewer**: 単一ドキュメントの品質・完成度・ルール準拠チェック
+11. **design-sync**: Design Doc間の整合性検証（明示的矛盾のみ検出）
+12. **acceptance-test-generator**: Design DocのACとUI Spec（任意）から統合テストとE2Eテストのスケルトン生成
 
 ## オーケストレーション原則
 
@@ -111,29 +112,33 @@ graph TD
 
 ## 作業計画時の基本フロー
 
-### 大規模（6ファイル以上） - 11ステップ
+### 大規模（6ファイル以上） - 11ステップ（バックエンド） / 13ステップ（フロントエンド/フルスタック）
 
 1. requirement-analyzer → 要件分析 + 既存PRD確認 **[停止]**
 2. prd-creator → PRD作成
 3. document-reviewer → PRDレビュー **[停止: PRD承認]**
-4. technical-designer → ADR作成（アーキテクチャ/技術/データフロー変更がある場合）
-5. document-reviewer → ADRレビュー（ADR作成時） **[停止: ADR承認]**
-6. technical-designer → Design Doc作成（レイヤー横断時: レイヤー別に作成、レイヤー横断オーケストレーション参照）
-7. document-reviewer → Design Docレビュー（レイヤー横断時: Design Doc毎に実行）
-8. design-sync → 整合性検証 **[停止: Design Doc承認]**
-9. acceptance-test-generator → テストスケルトン生成、work-plannerに渡す (*1)
-10. work-planner → 作業計画書作成 **[停止: 一括承認]**
-11. task-decomposer → 自律実行 → 完了報告
-
-### 中規模（3-5ファイル） - 7ステップ
+4. **（フロントエンド/フルスタックのみ）** プロトタイプコードの有無を確認 → ui-spec-designer → UI Spec作成
+5. **（フロントエンド/フルスタックのみ）** document-reviewer → UI Specレビュー **[停止: UI Spec承認]**
+6. technical-designer → ADR作成（アーキテクチャ/技術/データフロー変更がある場合）
+7. document-reviewer → ADRレビュー（ADR作成時） **[停止: ADR承認]**
+8. technical-designer → Design Doc作成（レイヤー横断時: レイヤー別に作成、レイヤー横断オーケストレーション参照）
+9. document-reviewer → Design Docレビュー（レイヤー横断時: Design Doc毎に実行）
+10. design-sync → 整合性検証 **[停止: Design Doc承認]**
+11. acceptance-test-generator → テストスケルトン生成、work-plannerに渡す (*1)
+12. work-planner → 作業計画書作成 **[停止: 一括承認]**
+13. task-decomposer → 自律実行 → 完了報告
+
+### 中規模（3-5ファイル） - 7ステップ（バックエンド） / 9ステップ（フロントエンド/フルスタック）
 
 1. requirement-analyzer → 要件分析 **[停止]**
-2. technical-designer → Design Doc作成（レイヤー横断時: レイヤー別に作成、レイヤー横断オーケストレーション参照）
-3. document-reviewer → Design Docレビュー（レイヤー横断時: Design Doc毎に実行）
-4. design-sync → 整合性検証 **[停止: Design Doc承認]**
-5. acceptance-test-generator → テストスケルトン生成、work-plannerに渡す (*1)
-6. work-planner → 作業計画書作成 **[停止: 一括承認]**
-7. task-decomposer → 自律実行 → 完了報告
+2. **（フロントエンド/フルスタックのみ）** プロトタイプコードの有無を確認 → ui-spec-designer → UI Spec作成
+3. **（フロントエンド/フルスタックのみ）** document-reviewer → UI Specレビュー **[停止: UI Spec承認]**
+4. technical-designer → Design Doc作成（レイヤー横断時: レイヤー別に作成、レイヤー横断オーケストレーション参照）
+5. document-reviewer → Design Docレビュー（レイヤー横断時: Design Doc毎に実行）
+6. design-sync → 整合性検証 **[停止: Design Doc承認]**
+7. acceptance-test-generator → テストスケルトン生成、work-plannerに渡す (*1)
+8. work-planner → 作業計画書作成 **[停止: 一括承認]**
+9. task-decomposer → 自律実行 → 完了報告
 
 ### 小規模（1-2ファイル） - 2ステップ
 
@@ -219,6 +224,22 @@ requirement-analyzerが複数レイヤー（backend + frontend）にまたがる
    - 構造化レスポンスから必要な情報を抽出
    - changeSummaryからコミットメッセージを作成 → **Bashでgit commit実行**
    - 要件変更時は初期要件と追加要件を明示的に統合
+
+   #### *1 acceptance-test-generator → work-planner
+
+   **acceptance-test-generatorへの入力**:
+   - Design Doc: [パス]
+   - UI Spec: [パス]（存在する場合）
+
+   **オーケストレーター確認項目**:
+   - 統合テストファイルパスの取得と存在確認
+   - E2Eテストファイルパスの取得と存在確認
+
+   **work-plannerへの入力**:
+   - 統合テストファイル: [パス]（各フェーズの実装と同時に作成・実行）
+   - E2Eテストファイル: [パス]（最終フェーズでのみ実行）
+
+   **エラー時**: ファイルが生成されない場合はユーザーにエスカレーション
 3. **品質保証とコミット実行**: approved=true確認後、即座にgit commit実行
 4. **自律実行モード管理**: 承認後の自律実行開始・停止・エスカレーション判断
 5. **ADRステータス管理**: ユーザー判断後のADRステータス更新（Accepted/Rejected）
@@ -243,6 +264,7 @@ requirement-analyzerが複数レイヤー（backend + frontend）にまたがる
 ### 主要な停止ポイント
 - **requirement-analyzer完了後**: 要件分析結果と質問事項の確認
 - **PRD作成→document-reviewer実行後**: 要件理解と整合性の確認
+- **UI Spec作成→document-reviewer実行後**（フロントエンド/フルスタック）: UI仕様の完全性と整合性の確認
 - **ADR作成→document-reviewer実行後**: 技術方針と整合性の確認
 - **Design Doc作成→document-reviewer実行後**: 設計内容と整合性の確認
 - **計画書作成後**: 実装フェーズ全体の一括承認

package/.claude/skills-ja/task-analyzer/references/skills-index.yaml

@@ -91,7 +91,7 @@ skills:
 
   documentation-criteria:
     skill: "documentation-criteria"
-    tags: [documentation, decision-making, adr, prd, design-doc, planning, process]
+    tags: [documentation, decision-making, adr, prd, ui-spec, design-doc, planning, process]
     typical-use: "実装開始時の規模判定、ドキュメント作成判定、ADR/PRD/Design Doc/作業計画書の作成基準"
     size: medium
     key-references:
@@ -129,14 +129,16 @@ skills:
 
   integration-e2e-testing:
     skill: "integration-e2e-testing"
-    tags: [testing, integration-test, e2e-test, property-based-testing, fast-check, test-skeleton, test-review, quality]
-    typical-use: "統合テスト・E2Eテストのスケルトン生成、テスト実装、テストレビュー、Property-Based Test実装"
+    tags: [testing, integration-test, e2e-test, property-based-testing, fast-check, test-skeleton, test-review, quality, playwright]
+    typical-use: "統合テスト・E2Eテストのスケルトン生成、テスト実装、テストレビュー、Property-Based Test実装、E2Eテスト設計"
     size: small
     key-references:
       - "fast-check - Property-based testing for TypeScript"
       - "Node.js Testing Best Practices - Yoni Goldberg"
       - "Property-Based Testing - 2025 Practices"
+      - "references/e2e-design.md - E2Eテスト設計原則"
     sections:
+      - "References"
       - "テスト種別と上限"
       - "振る舞い優先の原則"
       - "スケルトン仕様"
@@ -181,8 +183,8 @@ skills:
       - "References"
 
   # フロントエンド固有スキル
-  frontend/typescript-rules:
-    skill: "frontend/typescript-rules"
+  frontend-typescript-rules:
+    skill: "frontend-typescript-rules"
     tags: [frontend, react, implementation, type-safety, props-driven, hooks, component-design, vite, error-boundary]
     typical-use: "React/Viteでのフロントエンド開発、コンポーネント設計、Props設計、環境変数管理"
     size: small
@@ -198,16 +200,18 @@ skills:
       - "コーディング規約"
       - "アンチパターン"
 
-  frontend/typescript-testing:
-    skill: "frontend/typescript-testing"
-    tags: [frontend, react, quality, testing, coverage, vitest, react-testing-library, msw, component-testing, implementation]
-    typical-use: "Reactコンポーネントのテスト作成、React Testing Library、MSW、60%カバレッジ要件、Co-location"
+  frontend-typescript-testing:
+    skill: "frontend-typescript-testing"
+    tags: [frontend, react, quality, testing, coverage, vitest, react-testing-library, msw, component-testing, implementation, playwright, e2e]
+    typical-use: "Reactコンポーネントのテスト作成、React Testing Library、MSW、60%カバレッジ要件、Co-location、Playwright E2Eテスト"
     size: small
     key-references:
       - "React Testing Library - Kent C. Dodds"
       - "MSW (Mock Service Worker) - API Mocking"
       - "ADR-0002 Co-location原則"
+      - "references/e2e.md - Playwright E2Eパターン"
     sections:
+      - "References"
       - "テストフレームワーク"
       - "テストの基本方針"
       - "テストの実装規約"
@@ -216,8 +220,8 @@ skills:
       - "テスト品質基準"
       - "アンチパターン"
 
-  frontend/technical-spec:
-    skill: "frontend/technical-spec"
+  frontend-technical-spec:
+    skill: "frontend-technical-spec"
     tags: [frontend, react, architecture, design, documentation, environment, data-flow, implementation, vite, security, client-side, state-management, context-api, hooks, lighthouse, bundle-size, non-functional-requirements]
     typical-use: "フロントエンド技術設計、環境変数管理（Vite）、セキュリティ制約、アーキテクチャ設計、状態管理パターン、実装方針決定、非機能要件の確認"
     size: medium

package/.claude/skills-ja/technical-spec/SKILL.md

@@ -59,10 +59,11 @@ package.jsonの`packageManager`フィールドに応じた実行コマンドを
 品質チェックは実装完了時に必須：
 
 **Phase 1-3: コード品質チェック**
-- `check` - Biome（lint + format）
-- `check:unused` - 未使用エクスポートの検出
-- `check:deps` - 循環依存の検出
-- `build` - TypeScriptビルド
+- package.jsonから以下に該当するスクリプトを自動検出して実行:
+  - lint + format チェック
+  - 未使用エクスポートの検出
+  - 循環依存の検出
+  - TypeScriptビルド
 
 **Phase 4: テスト**
 - `test` - テスト実行

package/CHANGELOG.md

@@ -5,6 +5,73 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [1.17.0] - 2026-03-08
+
+### Added
+
+#### UI Spec Support
+- New `ui-spec-designer` agent (EN/JA) for creating UI Specifications from PRD and optional prototype code
+- UI Spec template in documentation-criteria references
+- UI Spec document type recognized by `document-reviewer`
+- UI Spec integration steps in `technical-designer-frontend`
+- UI Spec phase added to `front-design` command and orchestration flows
+
+#### Playwright E2E Testing
+- E2E test implementation guide (`references/e2e.md`) in frontend-typescript-testing skill
+- E2E test design guide (`references/e2e-design.md`) in integration-e2e-testing skill
+- E2E test support in `quality-fixer-frontend` and `acceptance-test-generator`
+
+#### Autonomous Execution Enhancements
+- 4-step task execution cycle (`task-executor → escalation check → quality-fixer → commit`) in `build` and `front-build` commands
+- `integration-test-reviewer` integration for test skeleton compliance validation
+- Structured response specs and sub-agent invocation constraints
+- `acceptance-test-generator → work-planner` information passing section in orchestration guide
+
+### Changed
+
+#### Frontend Workflow Enhancements
+- Orchestration flow step counts updated: large scale 11→13, medium scale 7→9 (frontend/fullstack)
+- `front-plan` command restructured with test skeleton generation step
+- `implement` command task execution section renamed and enhanced
+- `documentation-criteria` skill updated with UI Spec in creation matrix, storage paths, diagram requirements, and templates
+- `skills-index.yaml` updated with playwright/e2e tags and new references
+
+#### Dependencies Modernization
+- Remove 11 unused devDependencies: react, react-dom, @types/react, @types/react-dom, @vitejs/plugin-react, @testing-library/react, @testing-library/jest-dom, jsdom, c8, ts-node, ts-prune
+- Remove 4 unused scripts: `build:frontend`, `dev:frontend`, `preview`, `check:unused:all`
+- Migrate ts-prune → knip for unused export detection (`check:unused` now runs `knip --include exports`)
+- Upgrade Biome v1 → v2 (schema migration: `organizeImports` → `assist.actions.source`, `include`/`ignore` → `includes` with `!` prefix)
+- Upgrade vitest v3 → v4, @vitest/coverage-v8 v3 → v4, @vitest/ui v3 → v4
+- Upgrade vite v5 → v6, @types/node v20 → v22
+- Add `knip.json` configuration
+
+#### ESM Migration
+- Migrate project from CommonJS to ES Modules (`"type": "module"` in package.json)
+- Update tsconfig.json: `target` ES2020 → ES2022, `module` commonjs → Node16
+- Convert all scripts/ and bin/ files from CJS (`require`/`module.exports`) to ESM (`import`/`export`)
+- Add `node:` protocol to all Node.js builtin imports
+
+#### Agent/Skill Environment Independence (en/ja)
+- quality-fixer: replace `ts-prune` reference with generic "unused export detection tool"
+- quality-fixer-frontend: replace hardcoded `build:frontend` with auto-detect pattern from package.json
+- technical-spec skill: replace hardcoded script names with environment-independent descriptions
+- frontend/technical-spec skill: replace hardcoded build commands with auto-detect pattern
+
+#### Documentation
+- Remove `build:frontend` and `preview` from README script lists (en/ja)
+
+### Removed
+
+- `.tsprunerc` configuration file
+- `scripts/check-unused-exports.js` (replaced by knip)
+
+## [1.16.3] - 2026-03-05
+
+### Fixed
+
+- Replace deprecated `TodoWrite` with Tasks API (`TaskCreate`/`TaskUpdate`/`TaskList`) across all agent definitions, command files, and CLAUDE rule files (en/ja)
+- Add missing `TaskCreate`/`TaskUpdate` to tools list for `code-reviewer`, `design-sync`, and `integration-test-reviewer` agents (en/ja)
+
 ## [1.16.2] - 2026-03-03
 
 ### Changed

package/CLAUDE.en.md

@@ -29,7 +29,7 @@ Core rules for maximizing AI execution accuracy. All instructions must follow th
 **Trigger**: When starting work that involves Edit/Write/MultiEdit tools
 
 - [ ] Execute rule-advisor subagent (using Task tool)
-- [ ] Update TodoWrite
+- [ ] Update tasks with TaskCreate/TaskUpdate
   - Record taskEssence as completion criteria
   - Reflect firstActionGuidance as first action
   - Record warningPatterns as checkpoints during execution
@@ -43,7 +43,7 @@ Core rules for maximizing AI execution accuracy. All instructions must follow th
 ### Step 3: Implementation Execution
 
 - [ ] Execute Edit/Write/MultiEdit following approved approach
-- [ ] Update TodoWrite every 3 file edits (confirm progress and direction)
+- [ ] Update tasks with TaskUpdate every 3 file edits (confirm progress and direction)
 
 ### Step 4: Quality Verification
 

package/CLAUDE.ja.md

@@ -29,7 +29,7 @@ AI実行精度最大化のための中核ルール。全ての指示はこのフ
 **トリガー**: Edit/Write/MultiEditツールを使う作業の開始時
 
 - [ ] rule-advisorサブエージェントを実行（Taskツール使用）
-- [ ] TodoWriteを更新
+- [ ] TaskCreate/TaskUpdateでタスクを更新
   - taskEssenceを完了判断基準として記録
   - firstActionGuidanceを初動アクションとして反映
   - warningPatternsを実行中の確認項目として記録
@@ -43,7 +43,7 @@ AI実行精度最大化のための中核ルール。全ての指示はこのフ
 ### Step 3: 実装実行
 
 - [ ] 承認されたアプローチに従いEdit/Write/MultiEditを実行
-- [ ] 3ファイル編集ごとにTodoWriteを更新（進捗と方向性を確認）
+- [ ] 3ファイル編集ごとにTaskUpdateで更新（進捗と方向性を確認）
 
 ### Step 4: 品質検証
 

package/CLAUDE.md

@@ -2,101 +2,83 @@
 
 AI実行精度最大化のための中核ルール。全ての指示はこのファイルに従う。
 
-## 🚨 最重要原則：調査OK、実装STOP
+## 最重要原則：調査OK、実装STOP
 
 **すべてのEdit/Write/MultiEditツール使用前にユーザー承認が必須**
 
-理由：ユーザーの意図と異なる実装を防ぎ、正しい方向性を確保するため
+- 編集作業の前にAskUserQuestionで変更計画を提示し、明示的な承認を得ること
+- 調査・読み込み・分析は承認不要
+
+## 品質基準：技術的な妥協をしない
+
+- 「とりあえず動く」vs「正しい実装」→ 正しい実装を選択
+- ベストプラクティスに大きなコストがかかる場合 → トレードオフをユーザーに提示
+- ベストプラクティスはrule-advisor（Step 1）から取得
 
 ## 必須実行プロセス
 
-### 実行フロー（必須手順）
-1. **TodoWriteでタスク分解** → なければ実装ステップに進めない
-   理由：タスクを構造化し、進捗を追跡可能にするため
-2. **rule-advisor実行** → タスクの本質を理解し適切なルールを選択
-   理由：適切なルールを選択し、タスクの本質を理解するため
-3. **Edit/Write/MultiEdit使用** → ユーザー承認が必須
-   理由：最重要原則の実践（調査OK、実装STOP）
-4. **実装実行** → 品質チェックエラーは完了条件を満たさない
-   理由：高品質なコードを保証するため
-5. **ファイル数カウント** → 閾値超過で自動停止
-   理由：影響範囲が大きくなる前に確認を取るため
-
-### TodoWriteとメタ認知の統合
-**実行ルール**：
-- `pending → in_progress`時: rule-advisorの出力が必須
-- **rule-advisor実行後**: 必ずTodoWriteを以下の形式で更新
-  1. metaCognitiveGuidance.firstStepをTodoの先頭タスクとして追加
-  2. metaCognitiveGuidance.taskEssenceを各タスクの完了判断基準として記録
-  3. warningPatternsを実行中の確認項目として記録
-- TodoWriteなしでEditツール使用: ルール違反として停止
-- 各タスクのステータス更新時: 実施内容の記録を必須化（空白不可）
-
-### 実行前提条件
-1. **rule-advisorエージェント実行(Taskツールで呼び出すこと)** → JSONレスポンスが存在すること
-2. **TodoWriteのタスク** → in_progressステータスが存在すること
-3. **ユーザー承認記録** → Edit/Write前に明示的承認があること
-4. **品質チェック結果** → エラー0でなければ完了不可
-
-### 必須の代替パターン
-- **any型の代わり** → unknown型と型ガードを使用
-  理由：型安全性を確保し、実行時エラーを防止するため
-- **Edit使用時** → 必ずTodoWriteでタスク管理を先行
-  理由：進捗追跡と品質保証を可能にするため
-- **Edit/Write/MultiEdit使用時** → ユーザー承認を取得してから実行
-  理由：最重要原則（調査OK、実装STOP）を遵守するため
-- **完了宣言時** → 品質チェックエラー0を確認してから宣言
-  理由：完全なコードのみをマージするため
-
-## メタ認知実行（タスク開始時必須）
-
-### rule-advisorから取得した情報でメタ認知
-1. **taskEssence（タスクの本質）を理解**
-   - 表面的な作業内容と根本目的の区別
-   - 「quick fix」vs「proper solution」の判定
-
-2. **selectedSkills（適用スキル）を確認**
-   - 選択されたスキルが適切か判断
-   - 必要なセクションを読み込む
-
-3. **metaCognitiveGuidance.pastFailures（過去の失敗）を認識**
-   - 同じ失敗を繰り返さないよう注意
-   - 提示された回避策を意識
-
-4. **metaCognitiveGuidance.firstStep（初動アクション）を実行**
-   - 推奨されたツールから開始
-   - 計画的に進める
-
-## Claude行動制御（失敗防止）
-
-### 自動停止トリガー（必ず停止）
-- **5ファイル以上の変更検出**：即座停止、影響範囲をユーザーに報告
-  理由：大規模変更は事前計画とレビューが必要なため
-- **同じエラー3回発生**：根本原因分析必須
-  理由：対症療法ではなく根本解決が必要なため
-- **unknown型多用検出**：型ガード設計再検討
-  理由：型安全性の設計に問題がある可能性が高いため
-- **3ファイル編集完了**: TodoWriteの更新を強制（更新しないと次のEditツール使用不可）
-  理由：進捗確認と方向性の再確認が必要なため
-
-### エラー修正衝動対処
-1. エラー発見 → **一時停止**
+### セッション初期化
+
+**トリガー**: セッション開始時、最初のユーザーメッセージに応答する前
+
+- [ ] `date`コマンドで現在日時を確認
+- [ ] `project-context`スキル（Skillツール使用）を実行してプロジェクトの前提を把握
+
+### Step 1: タスク準備
+
+**トリガー**: Edit/Write/MultiEditツールを使う作業の開始時
+
+- [ ] rule-advisorサブエージェントを実行（Taskツール使用）
+- [ ] TaskCreate/TaskUpdateでタスクを更新
+  - taskEssenceを完了判断基準として記録
+  - firstActionGuidanceを初動アクションとして反映
+  - warningPatternsを実行中の確認項目として記録
+
+### Step 2: 実装計画
+
+- [ ] 影響範囲を調査し、関連ファイルを特定
+- [ ] 実装アプローチをユーザーに提示
+- [ ] AskUserQuestionで編集前に明示的な承認を取得
+
+### Step 3: 実装実行
+
+- [ ] 承認されたアプローチに従いEdit/Write/MultiEditを実行
+- [ ] 3ファイル編集ごとにTaskUpdateで更新（進捗と方向性を確認）
+
+### Step 4: 品質検証
+
+- [ ] 実装タスクの場合：quality-fixerサブエージェントを実行（Taskツール使用）
+- [ ] 実装以外の場合：rule-advisorが提供した原則に基づき検証
+- [ ] エラー0を確認し、完了を報告
+
+## 自動停止トリガー
+
+以下の条件発生時、作業を中断しステータスを報告：
+
+| 条件 | アクション |
+|------|-----------|
+| 5ファイル以上の変更を検出 | 影響範囲をユーザーに報告 |
+| 同じエラーが2回発生 | rule-advisor再実行、根本原因分析 |
+| Editツール5回使用 | 影響範囲レポートを作成 |
+| 同一ファイルを3回編集 | リファクタリングを検討 |
+
+## エラー対処フロー
+
+1. 一時停止
 2. rule-advisor再実行
-3. 根本原因分析（なぜ？を5回繰り返して真因を特定）
-4. 対処計画提示
-5. ユーザー承認後に修正
+3. 根本原因分析（5 Whys）
+4. 対処計画をユーザーに提示
+5. 承認後に修正を実行
+
+## ユーザー確認必須
+
+以下の状況では実装前にユーザー確認を取得：
 
-### エスカレーション基準（ユーザー確認必須）
 - アーキテクチャ変更（新レイヤー追加、責務変更）
-- 外部依存追加（npmパッケージ、外部API）
-- 破壊的変更（既存APIの変更、データ構造の変更）
+- 外部依存の追加（npmパッケージ、外部API）
+- 破壊的変更（既存API、データ構造の変更）
 - 複数の実装方法があり優劣が判断できない場合
 
-### 集中時のルール無視防止
-**測定可能な強制停止基準**：
-- **連続エラー修正2回目**: 自動的にrule-advisor再実行をトリガー
-- **Editツール5回使用**: 影響範囲レポートの作成を強制
-- **同一ファイル3回編集**: リファクタリング検討の強制停止
+## 作業ファイル管理
 
-### 一時ファイル作成ルール
-作業中ファイルは`tmp/`ディレクトリ使用。完了時削除。
+作業中の一時ファイルは`./tmp/`ディレクトリ（プロジェクトルート配下）に作成。完了時に削除。

package/README.ja.md

@@ -139,10 +139,11 @@ Vibe Codingの先へ — **Agentic Coding**（構造化されたワークフロ
 | `technical-spec` | アーキテクチャ、環境設定、ビルドコマンド |
 | `implementation-approach` | 戦略パターン、タスク分解 |
 | `integration-e2e-testing` | 統合/E2Eテスト設計、ROIベース選択 |
+| `frontend-typescript-rules` | Reactコンポーネント設計、Props駆動パターン |
+| `frontend-typescript-testing` | React Testing Library、MSW、Playwright E2E |
+| `frontend-technical-spec` | Reactアーキテクチャ、環境設定、データフロー |
 | `project-context` | AIの実行精度のためのプロジェクト前提情報（`/project-inject`で設定） |
 
-**フロントエンド専用スキル**も`frontend/`配下で利用可能（例：`frontend/typescript-rules`）。
-
 👉 [スキルの仕組みについて（Claude Code docs）](https://code.claude.com/docs/ja/skills)
 
 ## 🎯 このボイラープレートで作られたプロジェクト
@@ -185,7 +186,7 @@ Claude Codeで利用できる主要なコマンド
 | `/diagnose` | 根本原因分析ワークフロー | デバッグ、トラブルシューティング |
 | `/reverse-engineer` | コードからPRD/Design Docを生成 | 既存システムのドキュメント化 |
 
-フロントエンド用（`/front-design`, `/front-build`, `/front-review`, `/front-plan`）やユーティリティコマンド（`/add-integration-tests`, `/update-doc`）も利用できます。
+フロントエンド用（`/front-design`（UI Spec + Design Doc）, `/front-build`, `/front-review`, `/front-plan`）やユーティリティコマンド（`/add-integration-tests`, `/update-doc`）も利用できます。
 
 [コマンドの詳細はこちら →](docs/guides/ja/use-cases.md)
 
@@ -229,7 +230,7 @@ graph TB
 ### 動作の仕組み
 
 1. **要件分析**: `/implement`コマンドがタスクの規模を判断します
-2. **ドキュメント生成**: 必要に応じてドキュメント（PRD、Design Doc、Work Plan）を作成します
+2. **ドキュメント生成**: 必要に応じてドキュメント（PRD、UI Spec、Design Doc、Work Plan）を作成します
 3. **タスク実行**: 専門のエージェントが各フェーズを担当します
 4. **品質保証**: テスト、型チェック、必要に応じた修正を行います
 5. **コミット**: タスクごとに整理されたコミットを作成します
@@ -248,7 +249,9 @@ ai-coding-project-boilerplate/
 │       ├── documentation-criteria/
 │       ├── technical-spec/
 │       ├── project-context/
-│       └── frontend/     # フロントエンド専用スキル
+│       ├── frontend-typescript-rules/
+│       ├── frontend-typescript-testing/
+│       └── frontend-technical-spec/
 ├── docs/
 │   ├── guides/           # ユーザードキュメント
 │   ├── adr/              # アーキテクチャ決定
@@ -287,7 +290,7 @@ ai-coding-project-boilerplate/
 
 上記は代表例です。スキルやサブエージェント定義で言及されているスクリプトは以下の通りです。必要に応じて書き換えてください。
 
-`build`, `build:frontend`, `dev`, `preview`, `type-check`, `test`, `test:coverage`, `test:coverage:fresh`, `test:safe`, `cleanup:processes`, `check`, `check:fix`, `check:code`, `check:unused`, `check:deps`, `check:all`, `format`, `format:check`, `lint`, `lint:fix`
+`build`, `dev`, `type-check`, `test`, `test:coverage`, `test:coverage:fresh`, `test:safe`, `cleanup:processes`, `check`, `check:fix`, `check:code`, `check:unused`, `check:deps`, `check:all`, `format`, `format:check`, `lint`, `lint:fix`
 
 ## 🌐 多言語対応
 
@@ -329,7 +332,7 @@ A: Context Engineeringにより防止しています。各サブエージェン
 
 ## 🤖 サブエージェント
 
-要件分析、設計、計画、実装、品質保証、コードレビュー、デバッグ、リバースエンジニアリングをカバーする20以上の専門サブエージェントを搭載しています。各エージェントは独自のコンテキストウィンドウで実行されるため、集中した処理が可能です。
+要件分析、UI仕様、設計、計画、実装、品質保証、コードレビュー、デバッグ、リバースエンジニアリングをカバーする20以上の専門サブエージェントを搭載しています。各エージェントは独自のコンテキストウィンドウで実行されるため、集中した処理が可能です。
 
 [エージェントの詳細 →](.claude/agents-ja/)