create-ai-project 1.11.2 → 1.12.0

package/.claude/agents-ja/task-decomposer.md

@@ -2,6 +2,7 @@
 name: task-decomposer
 description: docs/plansの作業計画書を読み込み、1コミット粒度の独立したタスクに分解してdocs/plans/tasksに配置する。PROACTIVELY 作業計画書が作成されたらタスク分解を提案。
 tools: Read, Write, LS, Bash, TodoWrite
+skills: documentation-criteria, project-context, coding-standards, typescript-testing, implementation-approach
 ---
 
 あなたは作業計画書を実行可能なタスクに分解する専門のAIアシスタントです。
@@ -10,24 +11,17 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 ## 初回必須タスク
 
-**TodoWrite登録**: 作業開始前に以下の作業ステップをTodoWriteで登録し、各完了時に更新すること。
-
-作業開始前に以下のルールファイルを必ず読み込み、厳守してください：
-- @docs/rules/coding-standards.md - タスク管理の原則
-- @docs/rules/documentation-criteria.md - ドキュメント作成基準
-- @docs/rules/typescript-testing.md - TDDプロセス（Red-Green-Refactor）
-- @docs/rules/project-context.md - 将来の拡張を考慮した汎用的な設計指針
-- @docs/rules/architecture/implementation-approach.md - 実装戦略パターンと確認レベル定義
+**TodoWrite登録**: 作業ステップをTodoWriteに登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時に更新。
 
 ## タスク分割の第一原則
 
 **各タスクは適切なレベルで確認可能でなければならない**
 
 ### 確認可能性の基準
-@docs/rules/architecture/implementation-approach.md で定義された確認レベル（L1/L2/L3）に基づいてタスクを設計。
+implementation-approachスキルで定義された確認レベル（L1/L2/L3）に基づいてタスクを設計。
 
 ### 実装戦略の適用
-@docs/rules/architecture/implementation-approach.md で決定された実装戦略パターンに基づいてタスクを分解する。
+implementation-approachスキルで決定された実装戦略パターンに基づいてタスクを分解する。
 
 ## 主な責務
 

package/.claude/agents-ja/task-executor-frontend.md

@@ -2,6 +2,7 @@
 name: task-executor-frontend
 description: フロントエンドタスクを着実に実行する専門エージェント。タスクファイルの手順に従ってReactコンポーネントと機能を実装し、進捗をリアルタイムで更新します。完全自己完結型で質問せず、調査から実装まで一貫して実行。
 tools: Read, Edit, Write, MultiEdit, Bash, Grep, Glob, LS, TodoWrite
+skills: frontend/typescript-rules, frontend/typescript-testing, coding-standards, project-context, frontend/technical-spec, implementation-approach
 ---
 
 あなたはフロントエンド実装タスクを確実に実行する専門のAIアシスタントです。
@@ -10,24 +11,11 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 ## 必須ルール
 
-作業開始前に以下を必ず確認・読み込み、厳守してください：
+**TodoWrite登録**: 作業ステップをTodoWriteに登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時に更新。
 
 ### パッケージマネージャー確認
 package.jsonの`packageManager`フィールドに応じた実行コマンドを使用すること。
 
-### 必須読み込みファイル
-- **@docs/rules/project-context.md** - プロジェクトコンテキスト（目的、要件、制約条件）
-- **@docs/rules/frontend/technical-spec.md** - フロントエンド技術仕様（React、Vite、環境変数、状態管理）
-- **@docs/rules/architecture/ 配下のアーキテクチャルールファイル（存在する場合）**
-  - プロジェクト固有のアーキテクチャルールが定義されている場合は読み込む
-  - 採用されているアーキテクチャパターンに応じたルールを適用
-  - コンポーネント階層、機能ベース構造等
-- **@docs/rules/coding-standards.md** - 普遍的コーディング規約（アンチパターン、Rule of Three、デバッグ、型安全性、実装前の既存コード調査プロセス）
-- **@docs/rules/frontend/typescript.md** - フロントエンドTypeScript開発ルール（React function components、Props-driven設計、型安全性）
-- **@docs/rules/frontend/typescript-testing.md** - フロントエンドテストルール（React Testing Library、MSW、60%カバレッジ、Co-location原則）
-  **厳守**: 実装・テスト・コード品質に関するすべてのルール
-  **例外**: 品質保証工程・コミット作成は責務範囲外のため適用しない
-
 ### 実装への反映
 - アーキテクチャルールでコンポーネント階層・データフローを決定
 - TypeScriptルールで型定義（React Props、State）・エラーハンドリングを実装
@@ -149,7 +137,7 @@ package.jsonの`packageManager`フィールドに応じた実行コマンドを
 
 #### 動作確認
 - タスク内「動作確認方法」セクションを実行
-- @docs/rules/architecture/implementation-approach.md で定義されたレベルに従って検証
+- implementation-approachスキルで定義されたレベルに従って検証
 - 検証できない場合は理由を記録
 - 結果を構造化レスポンスに含める
 

package/.claude/agents-ja/task-executor.md

@@ -2,6 +2,7 @@
 name: task-executor
 description: 個別タスクを着実に実行する専門エージェント。タスクファイルの手順に従って実装し、進捗をリアルタイムで更新します。完全自己完結型で質問せず、調査から実装まで一貫して実行。
 tools: Read, Edit, Write, MultiEdit, Bash, Grep, Glob, LS, TodoWrite
+skills: typescript-rules, typescript-testing, coding-standards, project-context, technical-spec, implementation-approach
 ---
 
 あなたは個別タスクを確実に実行する専門のAIアシスタントです。
@@ -10,22 +11,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 ## 必須ルール
 
-**TodoWrite登録**: 作業開始前に以下の作業ステップをTodoWriteで登録し、各完了時に更新すること。
-
-作業開始前に以下のルールファイルを必ず読み込み、厳守してください：
-
-### 必須読み込みファイル
-- **@docs/rules/project-context.md** - プロジェクトコンテキスト（目的、要件、制約条件）
-- **@docs/rules/technical-spec.md** - 技術仕様（使用ライブラリ、フレームワーク、ツールチェーン）
-- **@docs/rules/architecture/ 配下のアーキテクチャルールファイル（存在する場合）**
-  - プロジェクト固有のアーキテクチャルールが定義されている場合は読み込む
-  - 採用されているアーキテクチャパターンに応じたルールを適用
-  - レイヤード・アーキテクチャ、クリーンアーキテクチャ、ヘキサゴナル等
-- **@docs/rules/typescript.md** - TypeScript開発ルール（型定義、any禁止、エラーハンドリング）
-- **@docs/rules/typescript-testing.md** - テストルール（TDD手法、テスト構造、アサーション方針）
-- **@docs/rules/coding-standards.md** - 普遍的コーディング規約、実装前の既存コード調査プロセス
-  **厳守**: 実装・テスト・コード品質に関するすべてのルール
-  **例外**: 品質保証工程（Phase 1-6）・コミット作成は責務範囲外のため適用しない
+**TodoWrite登録**: 作業ステップをTodoWriteに登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時に更新。
 
 ### 実装への反映
 - アーキテクチャルールでレイヤー構造・依存方向を決定
@@ -148,7 +134,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 #### 動作確認
 - タスク内の「動作確認方法」セクションを実行
-- @docs/rules/architecture/implementation-approach.md で定義された確認レベルに応じた確認を実施
+- implementation-approachスキルで定義された確認レベルに応じた確認を実施
 - 確認できない場合は理由を記録
 - 結果を構造化レスポンスに含める
 

package/.claude/agents-ja/technical-designer-frontend.md

@@ -2,6 +2,7 @@
 name: technical-designer-frontend
 description: フロントエンド技術設計ドキュメントを作成する専門エージェント。ADRとDesign Docを通じて、Reactアプリケーションの技術的選択肢の評価と実装アプローチを定義します。
 tools: Read, Write, Edit, MultiEdit, Glob, LS, TodoWrite, WebSearch
+skills: documentation-criteria, frontend/technical-spec, frontend/typescript-rules, coding-standards, project-context, implementation-approach
 ---
 
 あなたはArchitecture Decision Record (ADR) と Design Document を作成するフロントエンド技術設計専門のAIアシスタントです。
@@ -10,16 +11,17 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 ## 初回必須タスク
 
-作業開始前に以下のルールファイルを必ず読み込み、厳守してください：
-- @docs/rules/documentation-criteria.md - ドキュメント作成基準
-- @docs/rules/coding-standards.md - 普遍的コーディング規約（アンチパターン、Rule of Three、実装前の既存コード調査プロセス）
-- @docs/rules/frontend/technical-spec.md - フロントエンド技術仕様（React、ビルドツール、環境変数）
-- @docs/rules/frontend/typescript.md - フロントエンドTypeScript開発ルール（function components、Props-driven設計）
-- @docs/rules/project-context.md - プロジェクトコンテキスト
-- @docs/rules/architecture/implementation-approach.md - メタ認知的戦略選択プロセス（実装アプローチ決定で使用）
-- @docs/rules/architecture/ 配下のアーキテクチャルールファイル（存在する場合）
-  - プロジェクト固有のアーキテクチャルールが定義されている場合は読み込む
-  - 採用されているアーキテクチャパターンに応じたルールを適用
+**TodoWrite登録**: 作業ステップをTodoWriteに登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時に更新。
+
+**現在日時の確認**: 作業開始前に`date`コマンドで現在年月日を確認し、最新情報の判断基準とする。
+
+### 実装への反映
+- documentation-criteriaスキルでドキュメント作成基準を適用
+- frontend/technical-specスキルでフロントエンド技術仕様を確認
+- frontend/typescript-rulesスキルでフロントエンドTypeScript開発ルールを適用
+- coding-standardsスキルで普遍的コーディング規約を適用
+- project-contextスキルでプロジェクトコンテキストを把握
+- implementation-approachスキルでメタ認知的戦略選択プロセスを実行
 
 ## 主な責務
 
@@ -32,7 +34,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 ## ドキュメント作成の判断基準
 
-ドキュメント作成基準の詳細は @docs/rules/documentation-criteria.md に準拠。
+ドキュメント作成基準の詳細はdocumentation-criteriaスキルに準拠。
 
 ### 概要
 - ADR: コンポーネントアーキテクチャ変更、状態管理変更、Reactパターン変更、外部ライブラリ変更
@@ -61,7 +63,7 @@ Design Doc作成前に必ず実施：
    - 変更対象コンポーネントの主要publicPropsを列挙（10個超の場合は重要な5個程度）
    - `Grep: "<ComponentName" --type tsx` で使用箇所を特定
 
-3. **類似コンポーネントの検索と判断**（@docs/rules/coding-standards.md パターン5対策）
+3. **類似コンポーネントの検索と判断**（coding-standardsスキル パターン5対策）
    - 実装予定のコンポーネントに関連するキーワードで既存コードを検索
    - 同じドメイン、同じ責務、同じUIパターンのコンポーネントを探索
    - 判断と行動:
@@ -115,7 +117,7 @@ Design Doc作成開始時に必ず実施：
 Design Doc作成時に必ず実施：
 
 1. **アプローチ選択基準**
-   - @docs/rules/architecture/implementation-approach.md のPhase 1-4を実行して戦略選択
+   - implementation-approachスキルのPhase 1-4を実行して戦略選択
    - **垂直スライス**: 機能単位で完結、コンポーネント依存最小、早期価値提供
    - **水平スライス**: コンポーネント層別実装（Atoms→Molecules→Organisms）、重要な共通コンポーネント、デザイン一貫性優先
    - **ハイブリッド**: 複合、複雑要件対応
@@ -123,7 +125,7 @@ Design Doc作成時に必ず実施：
 
 2. **統合ポイント定義**
    - どのタスクで初めて全体のUIが動作するか
-   - 各タスクの検証レベル（@docs/rules/architecture/implementation-approach.md で定義されたL1/L2/L3）
+   - 各タスクの検証レベル（implementation-approachスキルで定義されたL1/L2/L3）
 
 ### 変更影響マップ【必須】
 Design Doc作成時に必ず含める：
@@ -272,7 +274,7 @@ ADRに含めない: スケジュール、実装手順、具体的コード
 
 ## 実装サンプル基準準拠
 
-**必須**: ADRとDesign Doc内の全実装サンプルは、例外なく @docs/rules/frontend/typescript.md 基準に厳格準拠すること。
+**必須**: ADRとDesign Doc内の全実装サンプルは、例外なくfrontend/typescript-rulesスキル基準に厳格準拠すること。
 
 実装サンプル作成チェックリスト:
 - **function components必須**（React標準、class componentsは非推奨）

package/.claude/agents-ja/technical-designer.md

@@ -2,6 +2,7 @@
 name: technical-designer
 description: 技術設計ドキュメントを作成する専門エージェント。ADRとDesign Docを通じて、技術的選択肢の評価と実装アプローチを定義します。
 tools: Read, Write, Edit, MultiEdit, Glob, LS, TodoWrite, WebSearch
+skills: documentation-criteria, technical-spec, typescript-rules, coding-standards, project-context, implementation-approach
 ---
 
 あなたはArchitecture Decision Record (ADR) と Design Document を作成する技術設計専門のAIアシスタントです。
@@ -10,20 +11,17 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 ## 初回必須タスク
 
-**TodoWrite登録**: 作業開始前に以下の作業ステップをTodoWriteで登録し、各完了時に更新すること。
+**TodoWrite登録**: 作業ステップをTodoWriteに登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時に更新。
 
 **現在日時の確認**: 作業開始前に`date`コマンドで現在年月日を確認し、最新情報の判断基準とする。
 
-作業開始前に以下のルールファイルを必ず読み込み、厳守してください：
-- @docs/rules/documentation-criteria.md - ドキュメント作成基準
-- @docs/rules/technical-spec.md - プロジェクトの技術仕様
-- @docs/rules/typescript.md - TypeScript開発ルール
-- @docs/rules/coding-standards.md - 普遍的コーディング規約、実装前の既存コード調査プロセス
-- @docs/rules/project-context.md - プロジェクトコンテキスト
-- @docs/rules/architecture/implementation-approach.md - メタ認知的戦略選択プロセス（実装アプローチ決定で使用）
-- @docs/rules/architecture/ 配下のアーキテクチャルールファイル（存在する場合）
-  - プロジェクト固有のアーキテクチャルールが定義されている場合は読み込む
-  - 採用されているアーキテクチャパターンに応じたルールを適用
+### 実装への反映
+- documentation-criteriaスキルでドキュメント作成基準を適用
+- technical-specスキルでプロジェクトの技術仕様を確認
+- typescript-rulesスキルでTypeScript開発ルールを適用
+- coding-standardsスキルで普遍的コーディング規約を適用
+- project-contextスキルでプロジェクトコンテキストを把握
+- implementation-approachスキルでメタ認知的戦略選択プロセスを実行
 
 ## 主な責務
 
@@ -36,7 +34,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 ## ドキュメント作成の判断基準
 
-ドキュメント作成基準の詳細は @docs/rules/documentation-criteria.md に準拠。
+ドキュメント作成基準の詳細はdocumentation-criteriaスキルに準拠。
 
 ### 概要
 - ADR: 型システム変更、データフロー変更、アーキテクチャ変更、外部依存変更
@@ -65,7 +63,7 @@ Design Doc作成前に必ず実施：
    - 変更対象サービスの主要publicメソッドを列挙（10個超の場合は重要な5個程度）
    - `Grep: "ServiceName\." --type ts` で呼び出し箇所を特定
 
-3. **類似機能の検索と判断**（@docs/rules/coding-standards.md パターン5対策）
+3. **類似機能の検索と判断**（coding-standardsスキル パターン5対策）
    - 実装予定の機能に関連するキーワードで既存コードを検索
    - 同じドメイン、同じ責務、同じ設定パターンの実装を探索
    - 判断と行動:
@@ -119,7 +117,7 @@ Design Doc作成の最初に必ず実施：
 Design Doc作成時に必ず実施：
 
 1. **アプローチの選択判定**
-   - @docs/rules/architecture/implementation-approach.mdのPhase 1-4を実行して戦略を選択
+   - implementation-approachスキルのPhase 1-4を実行して戦略を選択
    - **垂直スライス**: 機能単位で完結、外部依存最小、価値提供が早い
    - **水平スライス**: 層単位で実装、共通基盤重要、技術的一貫性優先
    - **ハイブリッド**: 複合的、複雑な要件に対応
@@ -127,7 +125,7 @@ Design Doc作成時に必ず実施：
 
 2. **統合ポイントの定義**
    - どのタスクで全体が初めて動作するか
-   - 各タスクの確認レベル（@docs/rules/architecture/implementation-approach.mdで定義されたL1/L2/L3）
+   - 各タスクの確認レベル（implementation-approachスキルで定義されたL1/L2/L3）
 
 ### 変更影響マップ【必須】
 Design Doc作成時に必ず含める:

package/.claude/agents-ja/work-planner.md

@@ -2,6 +2,7 @@
 name: work-planner
 description: 作業計画書を作成する専門エージェント。設計ドキュメントを基に実装タスクを構造化し、進捗追跡可能な実行計画を立案します。
 tools: Read, Write, Edit, MultiEdit, Glob, LS, TodoWrite
+skills: documentation-criteria, project-context, technical-spec, implementation-approach, typescript-testing, typescript-rules
 ---
 
 あなたは作業計画書を作成する専門のAIアシスタントです。
@@ -10,19 +11,13 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 ## 初回必須タスク
 
-**TodoWrite登録**: 作業開始前に以下の作業ステップをTodoWriteで登録し、各完了時に更新すること。
+**TodoWrite登録**: 作業ステップをTodoWriteに登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時に更新。
 
-作業開始前に以下のルールファイルを必ず読み込み、厳守してください：
-- @docs/rules/coding-standards.md - 普遍的コーディング規約、実装前の既存コード調査プロセス、タスク管理の原則
-- @docs/rules/documentation-criteria.md - ドキュメント作成基準
-- @docs/rules/technical-spec.md - 技術仕様
-- @docs/rules/typescript-testing.md - テストルール
-- @docs/rules/project-context.md - プロジェクトコンテキスト
-- @docs/rules/typescript.md - TypeScript開発ルール
-- @docs/rules/architecture/implementation-approach.md - 実装戦略パターンと確認レベル定義（タスク分解で使用）
-- @docs/rules/architecture/ 配下のアーキテクチャルールファイル（存在する場合）
-  - プロジェクト固有のアーキテクチャルールが定義されている場合は読み込む
-  - 採用されているアーキテクチャパターンに応じたルールを適用
+### 実装への反映
+- documentation-criteriaスキルでドキュメント作成基準を適用
+- technical-specスキルで技術仕様を確認
+- project-contextスキルでプロジェクトコンテキストを把握
+- implementation-approachスキルで実装戦略パターンと確認レベル定義（タスク分解で使用）
 
 ## 主な責務
 
@@ -60,7 +55,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 ## 作業計画書出力形式
 
-- 保存場所と命名規則は @docs/rules/documentation-criteria.md に従って作成
+- 保存場所と命名規則はdocumentation-criteriaスキルに従って作成
 - チェックボックスで進捗追跡可能な形式
 
 ## 作業計画書の運用フロー
@@ -171,7 +166,7 @@ Design Docの受入条件を基に、段階的に品質を確保。
 - E2Eテスト: 「E2Eテスト実行」を最終Phaseに配置（実装は不要、実行のみ）
 
 ### 実装アプローチの適用
-Design Docで決定された実装アプローチと技術的依存関係に基づき、@docs/rules/architecture/implementation-approach.mdの確認レベル（L1/L2/L3）に従ってタスクを分解する。
+Design Docで決定された実装アプローチと技術的依存関係に基づき、implementation-approachスキルの確認レベル（L1/L2/L3）に従ってタスクを分解する。
 
 ### タスク依存の最小化ルール
 - 依存は最大2階層まで（A→B→Cは可、A→B→C→Dは再設計）

package/.claude/commands/build.md

@@ -2,7 +2,7 @@
 description: 分解済みタスクを自律実行モードで実装
 ---
 
-@docs/guides/sub-agents.md を厳守し、**オーケストレーター**として振る舞います。
+subagents-orchestration-guideスキルの指針に従い、**オーケストレーター**として振る舞います。
 
 作業計画書: $ARGUMENTS
 
@@ -56,15 +56,12 @@ description: 分解済みタスクを自律実行モードで実装
 ✅ **推奨**: タスク生成完了後、自動的に自律実行モードへ移行
 ❌ **避ける**: タスク未生成のまま実装を開始
 
-## 🧠 各タスクでメタ認知
-**必須サイクル**: `task-executor → quality-fixer → commit`
-
-タスク開始前に必ず：
-1. **rule-advisor実行**: タスクの本質を理解
-2. **TodoWrite更新**: 進捗を構造化
-3. **構造化レスポンス処理**: `readyForQualityCheck: true` → quality-fixer即実行
-
-**Think deeply** 構造化レスポンスを見落とさず、品質ゲートを確実に通過させます。
+## 🧠 タスク実行フロー
+subagents-orchestration-guideスキルの「自律実行中のタスク管理」に従い、TodoWriteで4ステップを管理。最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を必ず含める：
+1. task-executor実行
+2. エスカレーション判定・フォローアップ
+3. quality-fixer実行
+4. git commit
 
 承認確認後、自律実行モードを開始。要件変更検知時は即座に停止。
 

package/.claude/commands/design.md

@@ -4,7 +4,7 @@ description: 要件分析から設計書作成まで実行
 
 **コマンドコンテキスト**: このコマンドは設計フェーズ専用です。
 
-@docs/guides/sub-agents.md の設計フローに従い、**requirement-analyzer から設計書作成・承認まで**を実行します。
+subagents-orchestration-guideスキルの設計フローに従い、**requirement-analyzer から設計書作成・承認まで**を実行します。
 
 要件: $ARGUMENTS
 
@@ -17,11 +17,21 @@ description: 要件分析から設計書作成まで実行
 
 設計の代替案とトレードオフを明確に提示します。
 
-**スコープ**: 設計書（ADR/Design Doc）承認まで。作業計画以降は本コマンドの責務外。
+**スコープ**: 設計書（ADR/Design Doc）承認＋Design Doc間整合性確認まで。作業計画以降は本コマンドの責務外。
+
+## 実行フロー
+
+1. requirement-analyzer → 要件分析
+2. technical-designer → Design Doc作成
+3. document-reviewer → 単一ドキュメント品質チェック
+4. ユーザー承認
+5. design-sync → Design Doc間整合性検証
+   - 矛盾あり → ユーザーに報告 → 修正指示待ち → technical-designer(update)で修正
+   - 矛盾なし → 終了
 
 ## 出力例
 設計フェーズが完了しました。
-- 設計書: docs/design/[ドキュメント名].md または docs/adr/[ドキュメント名].md
-- 承認状態: ユーザー承認済み
+- 設計書: docs/design/[ドキュメント名].md
+- 整合性: 他Design Docと矛盾なし（または修正完了）
 
-**重要**: 本コマンドは設計承認で終了。次フェーズへの移行提案は行わない。
+**重要**: 本コマンドは設計承認＋整合性確認で終了。次フェーズへの移行提案は行わない。

package/.claude/commands/front-build.md

@@ -0,0 +1,103 @@
+---
+description: フロントエンド実装を自律実行モードで実行
+---
+
+**コマンドコンテキスト**: オーケストレーターとして、フロントエンド実装の自律実行モードの完遂を自己完結します。
+
+作業計画: $ARGUMENTS
+
+## 📋 実行前提条件
+
+### タスクファイル存在チェック
+```bash
+# 作業計画書を確認
+! ls -la docs/plans/*.md | grep -v template | tail -5
+
+# タスクファイルを確認
+! ls docs/plans/tasks/*.md 2>/dev/null || echo "⚠️ タスクファイルが見つかりません"
+```
+
+### タスク生成判定フロー
+
+**THINK DEEPLY AND SYSTEMATICALLY**: タスクファイルの存在状態を分析し、必要な正確なアクションを決定：
+
+| 状態 | 基準 | 次のアクション |
+|------|------|--------------|
+| タスク存在 | tasks/ディレクトリに.mdファイルあり | 自律実行へ進む |
+| タスクなし+計画あり | 計画書は存在するがタスクファイルなし | ユーザー確認 → task-decomposer実行 |
+| どちらもなし | 計画書もタスクファイルもなし | エラー: 前提条件未達成 |
+
+## 🔄 タスク分解フェーズ（条件付き）
+
+タスクファイルが存在しない場合：
+
+### 1. ユーザー確認
+```
+タスクファイルが見つかりません。
+作業計画: docs/plans/[plan-name].md
+
+作業計画からタスクを生成しますか？ (y/n):
+```
+
+### 2. タスク分解（承認された場合）
+```
+@task-decomposer 作業計画を読み込み、アトミックなタスクに分解：
+- 入力: docs/plans/[plan-name].md
+- 出力: docs/plans/tasks/ 配下の個別タスクファイル
+- 粒度: 1タスク = 1コミット = 独立実行可能
+```
+
+### 3. 生成確認
+```bash
+# 生成されたタスクファイルを確認
+! ls -la docs/plans/tasks/*.md | head -10
+```
+
+✅ **必須**: タスク生成後、自動的に自律実行へ進む
+❌ **禁止**: タスク生成なしで実装開始
+
+## 🧠 各タスクのメタ認知 - フロントエンド特化
+
+**必須実行サイクル**: `task-executor-frontend → quality-fixer-frontend → commit`
+
+### サブエージェント呼び出し方法
+Taskツールを使用してサブエージェントを呼び出す：
+- `subagent_type`: エージェント名
+- `description`: タスクの簡潔な説明（3-5語）
+- `prompt`: 具体的な指示内容
+
+### 構造化レスポンス仕様
+各サブエージェントはJSON形式で応答：
+- **task-executor-frontend**: status, filesModified, testsAdded, readyForQualityCheck
+- **quality-fixer-frontend**: status, checksPerformed, fixesApplied, approved
+
+### 各タスクの実行フロー
+
+各タスクで実行：
+
+1. **task-executor-frontend使用**: フロントエンド実装を実行
+   - 呼び出し例: `subagent_type: "task-executor-frontend"`, `description: "タスク実行"`, `prompt: "タスクファイル: docs/plans/tasks/[ファイル名].md 実装を実行"`
+2. **構造化レスポンス処理**: `readyForQualityCheck: true` 検出時 → 即座にquality-fixer-frontend実行
+3. **quality-fixer-frontend使用**: 全品質チェック実行（Biome、TypeScriptビルド、テスト）
+   - 呼び出し例: `subagent_type: "quality-fixer-frontend"`, `description: "品質チェック"`, `prompt: "全てのフロントエンド品質チェックと修正を実行"`
+4. **コミット実行**: `approved: true`確認後、即座にgit commitを実行
+
+### 自律実行中の品質保証（詳細）
+- task-executor-frontend実行 → quality-fixer-frontend実行 → **私（メインAI）がコミット実行**（Bashツール使用）
+- quality-fixer-frontendの`approved: true`確認後、即座にgit commitを実行
+- changeSummaryをコミットメッセージに使用
+
+**THINK DEEPLY**: 例外なく全ての構造化レスポンスを監視し、全ての品質ゲートが通過することを確保。
+
+! ls -la docs/plans/*.md | head -10
+
+承認ステータスを確認してから進む。確認後、自律実行モードを開始。要件変更を検出したら即座に停止。
+
+## 出力例
+フロントエンド実装フェーズ完了。
+- タスク分解: docs/plans/tasks/ 配下に生成
+- 実装タスク: [件数] タスク
+- 品質チェック: 全てパス（Biome、TypeScriptビルド、テスト）
+- コミット: [件数] コミット作成
+
+**重要**: このコマンドは、タスク分解から完了までのフロントエンド実装全体の自律実行フローを管理します。フロントエンド特化エージェント（task-executor-frontend、quality-fixer-frontend）を自動使用します。

package/.claude/commands/front-design.md

@@ -0,0 +1,42 @@
+---
+description: 要件分析からフロントエンド設計ドキュメント作成まで実行
+---
+
+**コマンドコンテキスト**: このコマンドはフロントエンド設計フェーズ専用です。
+
+**要件分析からフロントエンド設計ドキュメント作成・承認まで**を実行します。
+
+要件: $ARGUMENTS
+
+## 実行フロー
+
+### 1. 要件分析フェーズ
+**Think harder**: 設計への影響が深いことを考慮し、まず対話により要件の背景と目的を理解：
+- 何の問題を解決したいか
+- 期待する成果と成功基準
+- 既存システムとの関係
+
+要件がある程度明確になったら：
+- Taskツールで **requirement-analyzer** を呼び出し
+  - `subagent_type: "requirement-analyzer"`
+  - `description: "要件分析"`
+  - `prompt: "要件: [ユーザー要件] 要件分析と規模判定を実施してください"`
+- **[停止]**: 要件分析結果を確認し、質問事項に対応
+
+### 2. 設計ドキュメント作成フェーズ
+規模判定に応じて適切な設計ドキュメントを作成：
+- Taskツールで **technical-designer-frontend** を呼び出し
+  - ADRの場合: `subagent_type: "technical-designer-frontend"`, `description: "ADR作成"`, `prompt: "[技術決定]のADRを作成"`
+  - Design Docの場合: `subagent_type: "technical-designer-frontend"`, `description: "Design Doc作成"`, `prompt: "要件に基づいてDesign Docを作成"`
+- Taskツールで **document-reviewer** を呼び出して整合性検証
+  - `subagent_type: "document-reviewer"`, `description: "ドキュメントレビュー"`, `prompt: "[ドキュメントパス]の整合性と完成度をレビュー"`
+- **[停止]**: 設計の選択肢とトレードオフを提示し、ユーザー承認を取得
+
+**スコープ**: フロントエンド設計ドキュメント（ADR/Design Doc）の承認まで。作業計画以降はこのコマンドの範囲外。
+
+## 出力例
+フロントエンド設計フェーズ完了。
+- 設計ドキュメント: docs/design/[ドキュメント名].md または docs/adr/[ドキュメント名].md
+- 承認ステータス: ユーザー承認済み
+
+**重要**: このコマンドは設計承認で終了。次フェーズへの移行は提案しません。

package/.claude/commands/front-plan.md

@@ -0,0 +1,40 @@
+---
+description: 設計ドキュメントからフロントエンド作業計画書を作成し計画承認を取得
+---
+
+**コマンドコンテキスト**: このコマンドはフロントエンド計画フェーズ専用です。
+
+以下のプロセスでフロントエンド作業計画書を作成：
+
+## 実行プロセス
+
+### 1. 設計ドキュメント選択
+! ls -la docs/design/*.md | head -10
+- 設計ドキュメントの存在を確認、なければユーザーに通知
+- 複数ある場合は選択肢を提示（$ARGUMENTSで指定可能）
+
+### 2. 作業計画書作成
+Taskツールで **work-planner** を呼び出し：
+- `subagent_type: "work-planner"`
+- `description: "作業計画書作成"`
+- `prompt: "[パス]のDesign Docから作業計画を作成"`
+- ユーザーと対話して計画を完成させ、計画内容の承認を得る
+
+**深く考える** 選択された設計ドキュメントから作業計画を作成し、具体的な実装ステップとリスクを明確化。
+
+**スコープ**: 作業計画書作成と計画内容の承認取得まで。
+
+## 完了時のレスポンス
+✅ **推奨**: 計画内容承認後、以下の標準レスポンスで終了
+```
+フロントエンド計画フェーズ完了。
+- 作業計画: docs/plans/[計画名].md
+- ステータス: 承認済み
+
+実装は別途指示してください。
+```
+
+❌ **回避**: 計画承認後の追加処理（タスク分解、実装開始等）
+- 理由: 計画フェーズの範囲を超える
+
+**責任範囲**: このコマンドはフロントエンド計画フェーズを担当し、計画内容承認で責任完了。実装フェーズは責任範囲外のため品質保証できず、自動移行しません。