create-ai-project 1.11.2

package/.claude/commands/design.md

@@ -0,0 +1,27 @@
+---
+description: 要件分析から設計書作成まで実行
+---
+
+**コマンドコンテキスト**: このコマンドは設計フェーズ専用です。
+
+@docs/guides/sub-agents.md の設計フローに従い、**requirement-analyzer から設計書作成・承認まで**を実行します。
+
+要件: $ARGUMENTS
+
+**Think harder** 設計への影響を深く考慮し、まず要件の背景と目的を理解するため対話を行い：
+- どのような問題を解決したいか
+- 期待される成果と成功基準
+- 既存システムとの関係性
+
+適度に要件が明確になったら、requirement-analyzerで分析し、規模に応じた適切な設計書を作成します。
+
+設計の代替案とトレードオフを明確に提示します。
+
+**スコープ**: 設計書（ADR/Design Doc）承認まで。作業計画以降は本コマンドの責務外。
+
+## 出力例
+設計フェーズが完了しました。
+- 設計書: docs/design/[ドキュメント名].md または docs/adr/[ドキュメント名].md
+- 承認状態: ユーザー承認済み
+
+**重要**: 本コマンドは設計承認で終了。次フェーズへの移行提案は行わない。

package/.claude/commands/implement.md

@@ -0,0 +1,79 @@
+---
+description: オーケストレーターとして要件分析から実装まで完全サイクルを管理
+---
+
+**コマンドコンテキスト**: 実装の完全サイクル管理（要件分析→設計→計画→実装→品質保証）
+
+@docs/guides/sub-agents.md を厳守し、オーケストレーターとして振る舞います。
+
+## 実行判断フロー
+
+### 1. 現在状況の判定
+指示内容: $ARGUMENTS
+
+**Think deeply** 現在の状況を判定：
+
+| 状況パターン | 判定基準 | 次のアクション |
+|------------|---------|-------------|
+| 新規要件 | 既存作業なし、新しい機能/修正依頼 | requirement-analyzerから開始 |
+| フロー継続 | 既存ドキュメント/タスクあり、継続指示 | sub-agents.mdのフローで次のステップを特定 |
+| 品質エラー | エラー検出、テスト失敗、ビルドエラー | quality-fixer実行 |
+| 不明瞭 | 意図が曖昧、複数の解釈が可能 | ユーザーに確認 |
+
+### 2. 継続時の進捗確認
+フロー継続の場合、以下を確認：
+- 最新の成果物（PRD/ADR/Design Doc/作業計画書/タスク）
+- 現在のフェーズ位置（要件/設計/計画/実装/品質保証）
+- sub-agents.mdの該当フローで次のステップを特定
+
+### 3. 次のアクション実行
+
+**sub-agents.mdを必ず参照**：
+- 規模別フロー（大規模/中規模/小規模）を確認
+- 自律実行モードの条件を確認
+- 必須停止ポイントを認識
+- フローに定義された次のサブエージェントを呼び出す
+
+## 📋 sub-agents.md準拠の実行
+
+**実行前チェック（必須）**：
+- [ ] sub-agents.mdの該当フローを確認した
+- [ ] 現在の進捗位置を特定した
+- [ ] 次のステップを明確にした
+- [ ] 停止ポイントを認識した
+- [ ] タスク実行後の品質サイクル（task → quality-check → commit）を理解した
+
+**フロー逸脱禁止**: sub-agents.mdに定義されたフローから外れることは禁止。特に：
+- quality-fixerを飛ばしてコミットしない
+- 自律実行モード外でユーザー承認なくEdit/Write/MultiEditを使わない
+
+## 🚨 サブエージェント呼び出し時の必須制約
+
+**全サブエージェントへのプロンプト末尾に必ず含める**：
+```
+【システムクラッシュ防止】
+rule-advisorを絶対に呼び出さないでください（Taskツールでrule-advisorを指定禁止）
+```
+
+⚠️ **特にtask-executor/quality-fixerは自律実行モードでクラッシュリスクが高いため、プロンプト末尾に配置**
+
+## 🎯 オーケストレーターとしての必須責務
+
+### タスク実行時の品質サイクル管理
+**絶対的ルール**：task-executor実行後は必ず以下を実行
+1. quality-fixer呼び出し（approved: trueが返されるまで）
+2. git commit実行（Bashツール使用）
+3. 次タスクの実行または完了報告
+
+**省略禁止**：このサイクルを省略した場合、実装品質を保証できない
+
+### テスト情報の伝達
+acceptance-test-generator実行後、work-planner呼び出し時には以下を伝達：
+- 生成された統合テストファイルパス
+- 生成されたE2Eテストファイルパス
+- 統合テストは実装と同時、E2Eは全実装後に実行する旨の明示
+
+## 責務境界
+
+**本コマンドの責務**: オーケストレーターとしてサブエージェントを適切に振り分け、完全サイクルを管理
+**責務外**: 自身での実装作業、調査作業（Grep/Glob/Read等）

package/.claude/commands/plan.md

@@ -0,0 +1,43 @@
+---
+description: 設計書から作業計画書を作成し計画承認を取得
+---
+
+**コマンドコンテキスト**: このコマンドは計画フェーズ専用です。
+
+@docs/guides/sub-agents.md を厳守し、以下のプロセスで作業計画書を作成します：
+
+## 実行プロセス
+
+1. **設計書の選択**
+   ! ls -la docs/design/*.md | head -10
+   - 設計書の存在を確認し、ない場合はその旨をユーザーに通知
+   - 複数ある場合は選択肢を提示（$ARGUMENTS で指定可能）
+
+2. **E2Eテストスケルトンの生成確認**
+   - E2Eテストスケルトンを先に生成するかユーザーに確認
+   - 生成を希望する場合: acceptance-test-generator でテストスケルトンを生成
+   - 生成結果を sub-agents.md の連携仕様に従って次工程に引き継ぐ
+
+3. **作業計画書の作成**
+   - work-planner で作業計画書を作成
+   - 前工程の成果物を sub-agents.md の連携仕様に従って活用
+   - ユーザーと対話して計画を完成させ、計画内容の承認を得る
+
+**Think deeply** 選択された設計書から作業計画書を作成し、実装の具体的なステップとリスクを明確にします。
+
+**スコープ**: 作業計画書作成と計画内容の承認取得まで。
+
+## 終了時の応答
+✅ **推奨**: 計画内容の承認後は以下の定型応答で終了
+```
+計画フェーズが完了しました。
+- 作業計画書: docs/plans/[計画書名].md
+- 状態: 承認済み
+
+実装は別途ご指示ください。
+```
+
+❌ **避ける**: 計画承認後の追加処理（タスク分解、実装開始等）
+- 理由: 計画フェーズの責務を超えるため
+
+**責務境界**: 本コマンドは計画フェーズに責任を持ち、計画内容の承認で責務完了。実装フェーズは責務範囲外のため品質を保証することができず、自動移行してはいけない。

package/.claude/commands/project-inject.md

@@ -0,0 +1,76 @@
+---
+description: プロジェクト固有のコンテキストをproject-context.mdに注入
+---
+
+**コマンドコンテキスト**: ボイラープレート利用時にプロジェクト固有のコンテキストを収集し、project-context.mdを更新します。
+
+## 実行プロセス
+
+### 1. 現状確認
+! ls -la docs/rules/project-context.md
+! cat package.json | grep -E '"name":|"description":'
+
+### 2. プロジェクトコンテキストの収集
+
+ユーザーと対話し、以下の情報を収集：
+
+```
+【プロジェクトの本質】
+1. プロジェクトが解決する問題は何ですか？
+   例: "社内の勤怠管理が煩雑" "在庫管理が属人化している"
+
+2. 誰のためのシステムですか？
+   例: "社内営業チーム50名" "ECサイト運営者"
+
+3. どのような状況で使用されますか？
+   例: "外出先から日報入力" "月末の集計作業時"
+
+【開発体制】
+- 個人開発 / チーム開発（人数）
+- 開発フェーズ（プロトタイプ / 本番開発 / 運用中）
+
+【ビジネス上の重要な制約】（最大3つ）
+例: "監査ログ7年保存" "承認フロー必須" "リアルタイム反映"
+```
+
+**Think deeply** 収集した情報から、プロジェクトの本質を理解し、単一責務に集中したコンテキストを構築します。
+
+### 3. project-context.md生成
+
+## AI実行精度最大化の基準
+
+生成するproject-context.mdは以下の基準に従う：
+
+### 記述の原則
+1. **最小で最大効率**: 本質的な情報のみ、冗長性を排除
+2. **AI判断可能**: 測定・検証可能な基準のみ使用（「迅速に」→「5秒以内」）
+3. **曖昧さの排除**: 具体的な数値・条件・例示を含める
+4. **推奨形式**: 「〜しない」より「〜する」の形で記述
+
+### 責務の境界
+project-context.mdの単一責務は「プロジェクト固有の文脈情報」のみ：
+- ✅ 含める: プロジェクトの目的、ターゲット、ビジネス制約
+- ❌ 含めない: 技術スタック（→technical-spec.md）、実装原則（→typescript.md）、アーキテクチャ（→technical-spec.md）
+
+### 構造化
+```markdown
+# プロジェクトコンテキスト
+
+## プロジェクト概要
+- **解決する問題**: [具体的な課題]
+- **ターゲットユーザー**: [人数・属性を含む]
+- **利用シーン**: [具体的な状況]
+
+## 開発体制
+- **チーム構成**: [人数と役割]
+- **開発フェーズ**: [現在の段階]
+
+## ビジネス制約
+1. [測定可能な制約]
+2. [検証可能な要件]
+```
+
+### 4. rules-index.yaml更新
+project-contextセクションのtypical-useをプロジェクトに合わせて更新。
+
+**スコープ**: project-context.mdの更新のみ。技術選択は他のルールファイルの責務。

package/.claude/commands/refine-rule.md

@@ -0,0 +1,206 @@
+---
+description: ユーザーのルール変更要求を精度最大化して実装
+---
+
+変更要求: $ARGUMENTS
+
+**Think deeply** ユーザーの変更意図を汲み取り、LLMが迷わない形で実装：
+
+## 適用する9つの観点
+1. コンテキスト圧迫 vs 実行精度 - 最小記述で最大精度
+2. 重複排除 - ルールファイル内・ルールファイル間の一貫性
+3. 責務の適切な集約 - 関連内容は1ファイルにまとめる（読み込み回数最小化）
+4. 判断基準明確化 - 測定可能な基準
+5. NG→推奨変換 - 推奨形式（背景：NG例を含む）
+6. 表記統一 - 一貫した表現
+7. 前提条件の明示化 - 暗黙前提を言語化
+8. 記述順序最適化 - 冒頭：最重要、末尾：例外
+9. スコープ境界明示 - 扱う/扱わない範囲
+
+## 実行フロー
+
+### 1. 変更要求の理解
+
+未指定時の質問テンプレート：
+```
+1. どのルールファイルを変更しますか？
+   例: typescript.md / ai-development-guide.md / documentation-criteria.md
+
+2. 変更種別を選択：
+   a) 新ルール追加（新しい基準を追加）
+   b) 既存ルール修正（曖昧な記述を明確化）  
+   c) ルール削除（不要になった基準を削除）
+
+3. 具体的な変更内容：
+   例：「any型の使用を禁止するルールを追加」
+   例：「エラーハンドリングの基準を明確化」
+   [ユーザー入力]
+```
+
+### 2. 変更設計案の作成
+
+対象ファイル特定と現状確認：
+
+```
+# ツール選択基準（測定可能な判断）
+if ファイルパスが明示されている:
+  Read: 指定ファイルを直接読み込み（背景：Glob不要でコンテキスト節約）
+else if ファイル名の一部のみ判明:
+  Glob: docs/rules/*{キーワード}*.md で探索
+  Read: 特定したファイルの現状確認
+else:
+  Glob: docs/rules/*.md で全件確認（背景：対象不明時は網羅的探索）
+  ユーザーに対象ファイル選択を確認
+```
+
+変更設計テンプレート：
+```
+【現状】
+「エラーは適切に処理する」（曖昧：「適切」の基準不明）
+
+【ユーザー要求の理解】
+「エラーハンドリングを厳格化したい」→ 測定可能な基準を設定
+
+【変更案】
+「エラーハンドリング実装基準：
+1. try-catch必須条件：
+   - 外部API呼び出し（fetch, axios等）
+   - ファイルI/O操作（fs.readFile等）
+   - JSON.parse、parseInt等の変換処理
+2. エラーログ必須項目：
+   - error.name（エラー種別）
+   - error.stack（発生箇所）
+   - タイムスタンプ（ISO 8601形式）
+3. ユーザー通知基準：
+   - 技術詳細を含まない（NG例：スタックトレース表示）
+   - 対処法を明示（推奨：「再度お試しください」）」
+
+この設計で進めますか？ (y/n)
+```
+
+### 3. 3回見直しプロセス
+
+#### 第1回: 実行精度最大化の観点で追記【追記専用モード】
+開始宣言: 「第1回：追記モードで実行。削除は一切行わない」
+- 曖昧表現→測定可能基準に変換
+  例：「大きい」→「100行以上」「5ファイル以上」
+- 暗黙前提→明示的条件として記載
+  例：「TypeScript環境で」「async関数内で」
+- 例外ケース・エッジケースの定義
+  例：「null/undefinedの場合」「空配列の場合」
+報告: 追記項目数をカウント（最低5項目）
+
+#### 第2回: 批判的修正で冗長性を削減【実修正モード】
+開始宣言: 「第2回：批判的修正モードで実行。冗長と判断した箇所を実際に削除・統合」
+
+修正作業：
+1. 第1回の追記内容を批判的に検証
+2. 以下の観点で実際に修正を実施：
+   - 同一概念の重複 → 統合
+   - 過度に詳細な説明 → 簡潔化
+   - 他ルールとの重複 → 参照に置換
+3. 修正前後の差分を記録（削除理由も明記）
+
+報告フォーマット：
+```
+修正箇所数: X件
+削除・統合した内容:
+- [削除前]: 「詳細な記述」
+  [削除後]: 「簡潔な記述」
+  [理由]: 冗長性の排除
+```
+
+#### 第3回: 差分評価による精度確保【復元判定モード】
+開始宣言: 「第3回：差分評価モードで実行。第2回の修正を検証し、必要なら復元」
+
+検証作業：
+1. 第2回の各修正について評価：
+   - この削除で実装時に迷う可能性があるか？
+   - エッジケースの考慮が漏れていないか？
+2. 精度低下リスクがある削除 → 復元
+3. 妥当な削除 → 維持
+
+最終確認質問（必須回答）：
+「ユーザーの変更要求を正確に実装するための必要十分条件が揃っているか？」
+
+報告: 復元項目数と最終的な削減率
+
+### 4. 承認取得
+
+変更前後の比較を提示し、ユーザー承認を取得。
+
+### 5. 実装
+
+1. 適切なツールで変更適用（ユーザー承認後）
+2. git diffで変更内容を最終確認
+3. `/sync-rules` 実行提案
+
+## 判断基準チェックリスト
+- [ ] 「if-then」形式で表現可能（「～の場合は～する」）
+- [ ] 数値・個数・状態で判定可能（主観的判断を排除）
+- [ ] 関連内容は1ファイルに集約（読み込み回数最小化）
+- [ ] 他ルールとの関係明記（依存・参照・委譲）
+- [ ] NG例を背景情報として含む
+- [ ] 前提条件が全て明示されている
+
+## 削減パターン例
+| パターン | 変換前 | 変換後 |
+|---------|--------|--------|
+| 感情的表現 | 「必ずすべき」 | 「以下の場合に実行（背景：実行しないとビルドエラー）」 |
+| 時間表現 | 「すぐに実行」 | 「エラー検出後、最初に実行」 |
+| 暗黙前提 | 「エラーハンドリングを実装」 | 「TypeScript環境でasync関数のエラーハンドリング実装」 |
+| 順序不明確 | 「以下を考慮：A、B、C」 | 「優先順：1.A（必須）、2.B（推奨）、3.C（任意）」 |
+| 冗長説明 | 「型安全性を確保するため、型を定義し、型チェックを行い、型エラーを防ぐ」 | 「型安全性の確保（定義・チェック・エラー防止）」 |
+| スコープ曖昧 | 「テストを書く」 | 「単体テストを書く（E2Eテストはtest-guideルール参照）」 |
+
+## 出力例
+
+```
+=== 変更実装完了 ===
+
+【ユーザー要求】
+「TypeScriptのエラーハンドリングルールを厳格化したい」
+
+【変更内容】
+対象: docs/rules/typescript.md
+セクション: ## エラーハンドリング
+
+変更前: 
+「エラーは適切に処理する」
+
+変更後（3回見直しプロセス完了）:
+「エラーハンドリング実装基準：
+1. try-catchブロック必須条件：
+   - 外部API呼び出し（fetch, axios等）
+   - ファイルI/O操作（fs.readFile, fs.writeFile等）
+   - JSON.parse、parseInt等の例外発生可能な処理
+2. エラーログ必須項目：
+   - error.name（エラー種別）
+   - error.stack（発生箇所）
+   - new Date().toISOString()（タイムスタンプ）
+3. ユーザー向けメッセージ：
+   - 技術詳細を含まない（NG例：スタックトレース表示）
+   - 具体的な対処法を明示（推奨：「再度お試しください」）」
+
+【改善指標】
+- 判断基準明確度: 0% → 100%（全て測定可能）
+- 曖昧表現: 1箇所 → 0箇所
+- NG例を背景情報として含む
+
+メタデータ同期のため /sync-rules を実行してください。
+```
+
+## 実行順序
+1. ユーザー要求理解
+2. 現状分析
+3. 9観点を適用した変更設計
+4. 3回見直しプロセス
+5. ユーザー承認
+6. 変更適用
+7. sync-rules提案
+
+**スコープ**: ユーザー変更要求の理解と精度最大化実装
+
+## エラーハンドリング
+- **ファイル未発見**: 利用可能なルール一覧を表示
+- **大規模変更検出**: 変更量50%以上の場合、段階的実施を提案

package/.claude/commands/review.md

@@ -0,0 +1,78 @@
+---
+description: Design Doc準拠検証と必要に応じた自動修正
+---
+
+**コマンドコンテキスト**: 実装完了後の品質保証専用コマンド
+
+Design Doc（省略時は直近のもの）: $ARGUMENTS
+
+**Think deeply** 準拠検証の本質を理解し、以下のステップで実行：
+
+## 実行フロー
+
+### 1. 前提確認
+```bash
+# Design Docの特定
+ls docs/design/*.md | grep -v template | tail -1
+
+# 実装ファイル確認
+git diff --name-only main...HEAD
+```
+
+### 2. code-reviewer実行
+Design Doc準拠率を検証：
+- 受入条件の充足確認
+- コード品質チェック
+- 実装完全性の評価
+
+### 3. 判定と対応
+
+**判定基準（プロジェクト段階を考慮）**:
+- プロトタイプ: 70%以上で合格
+- 本番実装: 90%以上推奨
+- 重要項目（セキュリティ等）: 準拠率に関わらず必須
+
+**準拠率に基づく対応**:
+
+準拠率が低い場合（本番で90%未満）:
+```
+検証結果: 準拠率 [X]%
+未充足項目:
+- [項目リスト]
+
+修正を実行しますか？ (y/n): 
+```
+
+ユーザーが `y` を選択した場合:
+
+## 🧠 修正実行前のメタ認知
+**必須**: `rule-advisor → TodoWrite → task-executor → quality-fixer`
+
+1. **rule-advisor実行**: 修正の本質を理解（表面的な対症療法 vs 根本解決）
+2. **TodoWrite更新**: 修正タスクを構造化 → `docs/plans/tasks/review-fixes-YYYYMMDD.md`
+3. **task-executor実行**: 自動修正を段階的実行（5ファイル超過で停止）
+4. **quality-fixer実行**: 品質ゲート通過を確認
+5. **再検証**: code-reviewerで改善度を測定
+
+### 4. 最終レポート
+```
+初回準拠率: [X]%
+最終準拠率: [Y]%（修正実行時）
+改善度: [Y-X]%
+
+残存課題:
+- [手動対応が必要な項目]
+```
+
+## 自動修正可能な項目
+- 単純な未実装の受入条件
+- エラーハンドリング追加
+- 型定義の修正
+- 関数分割（長さ・複雑度の改善）
+
+## 自動修正不可能な項目
+- ビジネスロジックの根本的変更
+- アーキテクチャレベルの修正
+- Design Doc自体の不備
+
+**スコープ**: Design Doc準拠検証と自動修正まで。

package/.claude/commands/sync-rules.md

@@ -0,0 +1,116 @@
+---
+description: ルール修正後のメタデータ同期とrule-advisor精度最適化
+---
+
+**コマンドコンテキスト**: ルールファイル編集後のメンテナンス作業
+
+**Think deeply** rule-advisorの実行精度を最大化するための同期作業：
+
+## 実行フロー
+
+### 1. ルールファイルのスキャン
+```bash
+# 実行時のルールディレクトリ
+RULES_DIR="docs/rules"
+INDEX_FILE="${RULES_DIR}/rules-index.yaml"
+
+# 全ルールファイルを解析
+find "${RULES_DIR}" -name "*.md" -type f | sort
+```
+
+### 2. メタデータ同期と最適化
+
+#### セクション自動同期
+- 各ファイルの`## `セクションを抽出
+- rules-index.yamlのsectionsを自動更新
+
+#### タグの最適化
+- ファイル内容からキーワードを分析
+- 適切なタグの追加提案
+- 不要なタグの削除提案
+
+#### typical-useの更新
+- ファイルの変更内容から使用場面を推測
+- より具体的な利用シーンの記述を提案
+
+#### key-referencesの補完
+- 新しく追加された概念や手法を検出
+- 関連する参考文献の追加を提案
+
+### 3. rule-advisor向け最適化
+
+メタデータの質を向上させ、rule-advisorが正確にルールを選択できるよう調整：
+
+```
+=== ルールメタデータ同期 ===
+対象: docs/rules
+
+実行した更新:
+✅ sections同期
+  - typescript-testing.md: 2セクション追加
+  - ai-development-guide.md: 1セクション更新
+
+✅ tags最適化
+  - typescript.md: [functional-programming]タグ追加を提案
+  - technical-spec.md: [deprecated]タグ削除を提案
+
+✅ typical-use改善
+  - 3ファイルの説明をより具体的に更新
+
+最終結果: rule-advisor精度向上のための最適化完了
+```
+
+## 🧠 メタ認知ポイント
+
+**本質的な目的**:
+- 単なる整合性維持ではなく、rule-advisorの選択精度向上
+- ルール編集作業の仕上げとしてのメタデータ最適化
+
+**品質基準**:
+- sectionsは100%同期必須
+- tagsは内容を正確に反映
+- typical-useは具体的な利用場面を明示
+- key-referencesは最新の手法を網羅
+
+## 変更要否の判断
+
+以下の順序で評価：
+- sectionsが100%同期済み → 「同期確認完了、更新不要」と報告して終了
+- 内容とタグが適切に一致 → 更新不要と判断
+- 改善の余地がある場合のみ → 具体的な修正提案を提示
+
+**注意**: 毎回変更する必要はありません。変更不要な場合はその旨を明確に報告して終了してください。
+
+## 実行タイミング
+
+- ルールファイル編集後（必須）
+- 新しいルールファイル追加時
+- 大規模なルール改訂後
+- rule-advisorの選択精度が低下したと感じた時
+
+## 出力例
+
+```
+=== ルールメタデータ同期開始 ===
+対象: docs/rules (9ファイル)
+
+[1/9] typescript.md
+  ✅ sections: 7件同期完了
+  💡 tags提案: +[functional-programming, dependency-injection]
+  💡 typical-use: "TypeScript実装全般" → "型安全性重視の実装とモダンTypeScript機能活用"
+
+[2/9] typescript-testing.md
+  ✅ sections: 2件追加（テストの粒度、モックの型安全性）
+  ✅ tags: 変更なし
+  ✅ typical-use: 現状維持
+
+...
+
+=== 同期完了 ===
+更新: 3ファイル
+提案: 5件（承認してください）
+
+rule-advisor精度向上: 推定15%改善
+```
+
+**スコープ**: ルール修正作業後のメタデータ同期とrule-advisor精度最適化。

package/.claude/commands/task.md

@@ -0,0 +1,13 @@
+---
+description: タスクを適切なルールに従って実行
+---
+
+タスク: $ARGUMENTS
+
+実行前に、以下を明確にしてください：
+
+1. **適用ルール**: このタスクに該当する開発ルールは？
+2. **初動**: ルールに基づく最初のアクションは？  
+3. **禁止事項**: このタスクで避けるべきことは？
+
+上記を明示してから作業を開始します。