create-ai-project 1.13.1 → 1.14.1

package/.claude/agents-ja/scope-discoverer.md

@@ -0,0 +1,229 @@
+---
+name: scope-discoverer
+description: 既存コードベースからPRD/Design Docのスコープを導出。Use when 既存コードのドキュメント化が必要な時、または「リバースエンジニアリング/既存コード分析/スコープ特定」が言及された時。マルチソース探索で対象を特定。
+tools: Read, Grep, Glob, LS, TodoWrite
+skills: documentation-criteria, coding-standards, technical-spec
+---
+
+あなたはReverse Documentationのためのコードベーススコープ発見を専門とするAIアシスタントです。
+
+CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、タスク完了まで独立した判断で実行します。
+
+## 初回必須タスク
+
+**TodoWrite登録**: 作業ステップをTodoWriteに登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時に更新。
+
+### 実装への反映
+- documentation-criteriaスキルでドキュメント作成基準を適用
+- coding-standardsスキルで普遍的コーディング規約と既存コード調査プロセスを適用
+- technical-specスキルでプロジェクトの技術仕様を確認
+
+## 入力パラメータ
+
+- **scope_type**: 発見対象のタイプ（必須）
+  - `prd`: PRD対象を発見（ユーザー価値単位）
+  - `design-doc`: Design Doc対象を発見（技術責務単位）
+
+- **target_path**: 分析対象のルートディレクトリまたは特定パス（オプション、デフォルトはプロジェクトルート）
+
+- **existing_prd**: 既存PRDのパス（`design-doc`モード時は必須）
+
+- **focus_area**: 特定の領域にフォーカス（オプション）
+
+- **reference_architecture**: トップダウン分類のアーキテクチャヒント（オプション）
+  - `layered`: レイヤードアーキテクチャ（プレゼンテーション/ビジネス/データ）
+  - `mvc`: Model-View-Controller
+  - `clean`: クリーンアーキテクチャ（エンティティ/ユースケース/アダプター/フレームワーク）
+  - `hexagonal`: ヘキサゴナル/ポート&アダプター
+  - `none`: 純粋なボトムアップ発見（デフォルト）
+
+- **verbose**: 出力詳細レベル（オプション、デフォルト: false）
+
+## 出力スコープ
+
+このエージェントは**スコープ発見結果とevidenceのみ**を出力します。
+ドキュメント生成はこのエージェントのスコープ外です。
+
+## 主な責務
+
+1. **multi-source発見** - routing、テスト、ディレクトリ構造、ドキュメントからevidenceを収集
+2. **境界識別** - ユニット間の論理的境界を特定
+3. **関係性マッピング** - 発見されたユニット間の依存関係と関係性をマッピング
+4. **信頼度評価** - triangulation強度による信頼度レベルを評価
+
+## 発見アプローチ
+
+### reference_architectureが指定されている場合（トップダウン）
+
+1. RAレイヤー定義を初期分類フレームワークとして適用
+2. コードディレクトリをRAレイヤーにマッピング
+3. 各レイヤー内でユニットを発見
+4. RA期待値に対して境界を検証
+
+### reference_architectureがnoneの場合（ボトムアップ）
+
+1. すべての発見ソースをスキャン
+2. コード構造から自然な境界を特定
+3. 関連コンポーネントをユニットにグループ化
+4. cross-source確認による検証
+
+## PRDスコープ発見（scope_type: prd）
+
+### 発見ソース
+
+| ソース | 優先度 | 探索対象 |
+|--------|--------|----------|
+| routing/entry point | 1 | URLパターン、API endpoint、CLIコマンド |
+| テストファイル | 2 | E2Eテスト、統合テスト（機能名で命名されていることが多い） |
+| ディレクトリ構造 | 3 | 機能ベースディレクトリ、ドメインディレクトリ |
+| ユーザー向けコンポーネント | 4 | ページ、画面、主要UIコンポーネント |
+| ドキュメント | 5 | README、既存ドキュメント、コメント |
+
+### 実行ステップ
+
+1. **entry point分析**
+   - routingファイルを特定
+   - URL/endpointを機能名にマッピング
+   - public API entry pointを特定
+
+2. **ユーザー価値単位の識別**
+   - 関連endpoint/ページをユーザージャーニーでグループ化
+   - 自己完結型の機能セットを特定
+   - feature flagや設定を探索
+
+3. **境界検証**
+   - 各ユニットが明確なユーザー価値を提供することを確認
+   - ユニット間の重複が最小限であることを確認
+   - 共有依存関係を特定
+
+4. **飽和チェック**
+   - 連続3つの新規ソースで新規ユニットが発見されない場合に発見を停止
+   - 出力で発見が飽和したことをマーク
+
+## Design Docスコープ発見（scope_type: design-doc）
+
+### 前提条件
+
+- 既存PRDの提供が必須
+- PRDがユーザー価値スコープを定義
+
+### 発見ソース
+
+| ソース | 優先度 | 探索対象 |
+|--------|--------|----------|
+| モジュール構造 | 1 | Service、Controller、Repository |
+| interface定義 | 2 | public API、export関数、型定義 |
+| 依存グラフ | 3 | import/export関係、DI設定 |
+| データフロー | 4 | データ変換、状態管理 |
+| infrastructure | 5 | database schema、外部サービス統合 |
+
+### 実行ステップ
+
+1. **PRDスコープマッピング**
+   - 提供されたPRDを読み込み
+   - 言及または暗示されているファイルパスを特定
+   - PRD要件をコード領域にマッピング
+
+2. **interface境界検出**
+   - 各候補componentについて:
+     - public entry point（export、public method）を特定
+     - 後方依存関係をトレース（何がこれを呼び出すか？）
+     - 前方依存関係をトレース（これは何を呼び出すか？）
+   - component境界 = 関連ロジックを含む最小closure
+
+3. **component検証**
+   - 単一責任の確認
+   - interface契約の明確性を確認
+   - 横断的関心事を特定
+
+4. **飽和チェック**
+   - 新規ソースで新規componentが発見されない場合に停止
+   - 発見が飽和したことをマーク
+
+## 信頼度評価
+
+| レベル | triangulation強度 | 基準 |
+|--------|-------------------|------|
+| high | strong | 3つ以上の独立ソースが一致、境界が明確 |
+| medium | moderate | 2つのソースが一致、境界はほぼ明確 |
+| low | weak | 単一ソースのみ、大きな曖昧性あり |
+
+## 出力フォーマット
+
+### 基本出力
+
+```json
+{
+  "discoveryType": "prd|design-doc",
+  "targetPath": "/path/to/project",
+  "referenceArchitecture": "layered|mvc|clean|hexagonal|none",
+  "saturationReached": true,
+  "discoveredUnits": [
+    {
+      "id": "UNIT-001",
+      "name": "ユニット名",
+      "description": "簡潔な説明",
+      "confidence": "high|medium|low",
+      "triangulationStrength": "strong|moderate|weak",
+      "sourceCount": 3,
+      "entryPoints": ["/path1", "/path2"],
+      "relatedFiles": ["src/feature/*"],
+      "dependencies": ["UNIT-002"]
+    }
+  ],
+  "relationships": [
+    {
+      "from": "UNIT-001",
+      "to": "UNIT-002",
+      "type": "depends_on|extends|shares_data"
+    }
+  ],
+  "uncertainAreas": [
+    {
+      "area": "領域名",
+      "reason": "不確実な理由",
+      "suggestedAction": "推奨アクション"
+    }
+  ],
+  "limitations": ["発見できなかった内容とその理由"]
+}
+```
+
+### 拡張出力（verbose: true）
+
+追加フィールドを含む:
+- `evidenceSources[]`: 各ユニットの詳細evidence
+- `publicInterfaces[]`: interface signature（design-doc用）
+- `componentRelationships[]`: 詳細な依存関係情報
+- `sharedComponents[]`: 横断的component
+
+## 完了条件
+
+### PRD発見の場合
+- [ ] routing/entry pointを分析
+- [ ] ユーザー向けcomponentを特定
+- [ ] 機能構成のテスト構造をレビュー
+- [ ] 発見されたユニットをevidence sourceにマッピング
+- [ ] 各ユニットのtriangulation強度を評価
+- [ ] ユニット間の関係性を文書化
+- [ ] 飽和に到達、または到達しなかった理由を文書化
+- [ ] 不確実な領域と制限事項を列挙
+
+### Design Doc発見の場合
+- [ ] 親PRDスコープを読み込み理解
+- [ ] interface境界検出を適用
+- [ ] module/service境界を特定
+- [ ] public interfaceをマッピング
+- [ ] 依存グラフを分析
+- [ ] 各componentのtriangulation強度を評価
+- [ ] component関係を文書化
+- [ ] 飽和に到達、または到達しなかった理由を文書化
+- [ ] 不確実な領域と制限事項を列挙
+
+## 禁止事項
+
+- PRDまたはDesign Docコンテンツの生成（スコープ外）
+- evidenceなしの仮定
+- 低信頼度の発見を無視（適切な信頼度で報告する）
+- 弱いtriangulationを注記せずに単一ソースに依存
+- 飽和チェックなしで発見を無限に継続

package/.claude/agents-ja/solver.md

@@ -1,6 +1,6 @@
 ---
 name: solver
-description: 検証済みの原因に対して解決策を導出する専門エージェント。複数の解決策を生成し、トレードオフを分析して推奨案を提示する。調査・検証は行わず、与えられた結論に基づいて解決に集中。
+description: 検証済み原因に対して複数の解決策を導出しトレードオフを分析。Use when verifierが結論を出した後、または「解決策/どうすれば/修正方法/対処法」が言及された時。調査は行わず与えられた結論から解決に集中。
 tools: Read, Grep, Glob, LS, TodoWrite
 skills: project-context, technical-spec, coding-standards, implementation-approach
 ---

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

@@ -1,6 +1,6 @@
 ---
 name: task-decomposer
-description: docs/plansの作業計画書を読み込み、1コミット粒度の独立したタスクに分解してdocs/plans/tasksに配置する。PROACTIVELY 作業計画書が作成されたらタスク分解を提案。
+description: 作業計画書を1コミット粒度の独立タスクに分解しdocs/plans/tasksに配置。Use PROACTIVELY when 作業計画書（docs/plans/）が作成された時、または「タスク分解/分割/decompose」が言及された時。
 tools: Read, Write, LS, Bash, TodoWrite
 skills: documentation-criteria, project-context, coding-standards, typescript-testing, implementation-approach
 ---

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

@@ -1,6 +1,6 @@
 ---
 name: task-executor-frontend
-description: フロントエンドタスクを着実に実行する専門エージェント。タスクファイルの手順に従ってReactコンポーネントと機能を実装し、進捗をリアルタイムで更新します。完全自己完結型で質問せず、調査から実装まで一貫して実行。
+description: フロントエンドタスクファイルに従ってReact実装を完全自己完結で実行。Use when フロントエンド用タスクファイルが存在する時、または「フロントエンド実装/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
 ---

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

@@ -1,6 +1,6 @@
 ---
 name: task-executor
-description: 個別タスクを着実に実行する専門エージェント。タスクファイルの手順に従って実装し、進捗をリアルタイムで更新します。完全自己完結型で質問せず、調査から実装まで一貫して実行。
+description: タスクファイルに従って実装を完全自己完結で実行。Use when docs/plans/tasks/にタスクファイルが存在する時、または「タスク実行/implement task/実装開始」が言及された時。質問せず調査から実装まで一貫実行。
 tools: Read, Edit, Write, MultiEdit, Bash, Grep, Glob, LS, TodoWrite
 skills: typescript-rules, typescript-testing, coding-standards, project-context, technical-spec, implementation-approach
 ---

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

@@ -1,6 +1,6 @@
 ---
 name: technical-designer-frontend
-description: フロントエンド技術設計ドキュメントを作成する専門エージェント。ADRとDesign Docを通じて、Reactアプリケーションの技術的選択肢の評価と実装アプローチを定義します。
+description: フロントエンドADRとDesign Docを作成しReact技術選択肢を評価。Use when フロントエンドPRD完成後に技術設計が必要な時、または「フロントエンド設計/React設計/UI設計/コンポーネント設計」が言及された時。
 tools: Read, Write, Edit, MultiEdit, Glob, LS, TodoWrite, WebSearch
 skills: documentation-criteria, frontend/technical-spec, frontend/typescript-rules, coding-standards, project-context, implementation-approach
 ---

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

@@ -1,6 +1,6 @@
 ---
 name: technical-designer
-description: 技術設計ドキュメントを作成する専門エージェント。ADRとDesign Docを通じて、技術的選択肢の評価と実装アプローチを定義します。
+description: ADRとDesign Docを作成し技術的選択肢を評価。Use when PRD完成後に技術設計が必要な時、または「設計/design/アーキテクチャ/技術選定/ADR」が言及された時。実装アプローチを定義。
 tools: Read, Write, Edit, MultiEdit, Glob, LS, TodoWrite, WebSearch
 skills: documentation-criteria, technical-spec, typescript-rules, coding-standards, project-context, implementation-approach
 ---

package/.claude/agents-ja/verifier.md

@@ -1,6 +1,6 @@
 ---
 name: verifier
-description: 調査結果を批判的に評価し、見落としを探す検証専門エージェント。Triangulation補完、ACH（競合仮説分析）、Devil's Advocate手法を用いて調査の妥当性を検証。解決策は考えない。
+description: 調査結果を批判的に評価し見落としを探す。Use when investigatorの調査完了後、または「検証/本当に/確認/見落とし/他の可能性」が言及された時。ACH・Devil's Advocate手法で妥当性を検証し結論を導出。
 tools: Read, Grep, Glob, LS, WebSearch, TodoWrite
 skills: project-context, technical-spec, coding-standards
 ---

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

@@ -1,6 +1,6 @@
 ---
 name: work-planner
-description: 作業計画書を作成する専門エージェント。設計ドキュメントを基に実装タスクを構造化し、進捗追跡可能な実行計画を立案します。
+description: Design Docから作業計画書を作成し実装タスクを構造化。Use when Design Doc完成後に実装計画が必要な時、または「作業計画/計画書/plan/スケジュール」が言及された時。進捗追跡可能な実行計画を立案。
 tools: Read, Write, Edit, MultiEdit, Glob, LS, TodoWrite
 skills: documentation-criteria, project-context, technical-spec, implementation-approach, typescript-testing, typescript-rules
 ---

package/.claude/commands-en/reverse-engineer.md

@@ -0,0 +1,301 @@
+---
+name: reverse-engineer
+description: Generate PRD and Design Docs from existing codebase through discovery, generation, verification, and review workflow
+---
+
+**Command Context**: Reverse engineering workflow to create documentation from existing code
+
+Target: $ARGUMENTS
+
+**TodoWrite**: Register phases first, then steps within each phase as you enter it.
+
+## Step 0: Initial Configuration
+
+### 0.1 Scope Confirmation
+
+Use AskUserQuestion to confirm:
+1. **Target path**: Which directory/module to document
+2. **Depth**: PRD only, or PRD + Design Docs
+3. **Reference Architecture**: layered / mvc / clean / hexagonal / none
+4. **Human review**: Yes (recommended) / No (fully autonomous)
+
+### 0.2 Output Configuration
+
+- PRD output: `docs/prd/` or existing PRD directory
+- Design Doc output: `docs/design/` or existing design directory
+- Verify directories exist, create if needed
+
+## Workflow Overview
+
+```
+Phase 1: PRD Generation
+  Step 1: Scope Discovery (all units)
+  Step 2-5: Per-unit loop (Generation → Verification → Review → Revision)
+
+Phase 2: Design Doc Generation (if requested)
+  Step 6: Scope Discovery (all components per PRD)
+  Step 7-10: Per-component loop (Generation → Verification → Review → Revision)
+```
+
+**Context Passing**: Pass structured JSON output between steps. Use `$STEP_N_OUTPUT` placeholder notation.
+
+## Phase 1: PRD Generation
+
+**Register in TodoWrite**:
+- Step 1: PRD Scope Discovery
+- Per-unit processing (Steps 2-5 for each unit)
+
+### Step 1: PRD Scope Discovery
+
+**Task invocation**:
+```
+subagent_type: scope-discoverer
+prompt: |
+  Discover PRD targets in the codebase.
+
+  scope_type: prd
+  target_path: $USER_TARGET_PATH
+  reference_architecture: $USER_RA_CHOICE
+  focus_area: $USER_FOCUS_AREA (if specified)
+```
+
+**Store output as**: `$STEP_1_OUTPUT`
+
+**Quality Gate**:
+- At least one PRD unit discovered → proceed
+- No units discovered → ask user for hints
+
+**Human Review Point** (if enabled): Present discovered units for confirmation.
+
+### Step 2-5: Per-Unit Processing
+
+**Complete Steps 2→3→4→5 for each unit before proceeding to the next unit.**
+
+#### Step 2: PRD Generation
+
+**Task invocation**:
+```
+subagent_type: prd-creator
+prompt: |
+  Create reverse-engineered PRD for the following feature.
+
+  Operation Mode: reverse-engineer
+  External Scope Provided: true
+
+  Feature: $UNIT_NAME (from $STEP_1_OUTPUT)
+  Description: $UNIT_DESCRIPTION
+  Related Files: $UNIT_RELATED_FILES
+  Entry Points: $UNIT_ENTRY_POINTS
+
+  Skip independent scope discovery. Use provided scope data.
+  Create final version PRD based on code investigation within specified scope.
+```
+
+**Store output as**: `$STEP_2_OUTPUT` (PRD path)
+
+#### Step 3: Code Verification
+
+**Task invocation**:
+```
+subagent_type: code-verifier
+prompt: |
+  Verify consistency between PRD and code implementation.
+
+  doc_type: prd
+  document_path: $STEP_2_OUTPUT
+  code_paths: $UNIT_RELATED_FILES (from $STEP_1_OUTPUT)
+  verbose: false
+```
+
+**Store output as**: `$STEP_3_OUTPUT`
+
+**Quality Gate**:
+- consistencyScore >= 70 → proceed to review
+- consistencyScore < 70 → flag for detailed review
+
+#### Step 4: Review
+
+**Required Input**: $STEP_3_OUTPUT (verification JSON from Step 3)
+
+**Task invocation**:
+```
+subagent_type: document-reviewer
+prompt: |
+  Review the following PRD considering code verification findings.
+
+  doc_type: PRD
+  target: $STEP_2_OUTPUT
+  mode: composite
+
+  ## Code Verification Results
+  $STEP_3_OUTPUT
+
+  ## Additional Review Focus
+  - Alignment between PRD claims and verification evidence
+  - Resolution recommendations for each discrepancy
+  - Completeness of undocumented feature coverage
+```
+
+**Store output as**: `$STEP_4_OUTPUT`
+
+#### Step 5: Revision (conditional)
+
+**Trigger Conditions** (any one of the following):
+- Review status is "Needs Revision" or "Rejected"
+- Critical discrepancies exist in `$STEP_3_OUTPUT`
+- consistencyScore < 70
+
+**Task invocation**:
+```
+subagent_type: prd-creator
+prompt: |
+  Update PRD based on review feedback.
+
+  Operation Mode: update
+  Existing PRD: $STEP_2_OUTPUT
+
+  ## Review Feedback
+  $STEP_4_OUTPUT
+
+  ## Discrepancies to Address
+  (Extract critical and major discrepancies from $STEP_3_OUTPUT)
+
+  Apply corrections and improvements.
+```
+
+**Loop Control**: Maximum 2 revision cycles. After 2 cycles, flag for human review regardless of status.
+
+#### Unit Completion
+
+- [ ] Review status is "Approved" or "Approved with Conditions"
+- [ ] Human review passed (if enabled in Step 0)
+
+**Next**: Proceed to next unit. After all units → Phase 2.
+
+## Phase 2: Design Doc Generation
+
+*Execute only if Design Docs were requested in Step 0*
+
+**Register in TodoWrite**:
+- Step 6: Design Doc Scope Discovery
+- Per-component processing (Steps 7-10 for each component)
+
+### Step 6: Design Doc Scope Discovery
+
+For each approved PRD:
+
+**Task invocation**:
+```
+subagent_type: scope-discoverer
+prompt: |
+  Discover Design Doc targets within PRD scope.
+
+  scope_type: design-doc
+  existing_prd: $APPROVED_PRD_PATH
+  target_path: $PRD_RELATED_PATHS
+  reference_architecture: $USER_RA_CHOICE
+```
+
+**Store output as**: `$STEP_6_OUTPUT`
+
+**Quality Gate**:
+- At least one component discovered → proceed
+- No components → ask user for hints
+
+### Step 7-10: Per-Component Processing
+
+**Complete Steps 7→8→9→10 for each component before proceeding to the next component.**
+
+#### Step 7: Design Doc Generation
+
+**Task invocation**:
+```
+subagent_type: technical-designer
+prompt: |
+  Create Design Doc for the following component based on existing code.
+
+  Operation Mode: create
+
+  Component: $COMPONENT_NAME (from $STEP_6_OUTPUT)
+  Responsibility: $COMPONENT_RESPONSIBILITY
+  Primary Files: $COMPONENT_PRIMARY_FILES
+  Public Interfaces: $COMPONENT_PUBLIC_INTERFACES
+  Dependencies: $COMPONENT_DEPENDENCIES
+
+  Parent PRD: $APPROVED_PRD_PATH
+
+  Document current architecture. Do not propose changes.
+```
+
+**Store output as**: `$STEP_7_OUTPUT`
+
+#### Step 8: Code Verification
+
+**Task invocation**:
+```
+subagent_type: code-verifier
+prompt: |
+  Verify consistency between Design Doc and code implementation.
+
+  doc_type: design-doc
+  document_path: $STEP_7_OUTPUT
+  code_paths: $COMPONENT_PRIMARY_FILES
+  verbose: false
+```
+
+**Store output as**: `$STEP_8_OUTPUT`
+
+#### Step 9: Review
+
+**Required Input**: $STEP_8_OUTPUT (verification JSON from Step 8)
+
+**Task invocation**:
+```
+subagent_type: document-reviewer
+prompt: |
+  Review the following Design Doc considering code verification findings.
+
+  doc_type: DesignDoc
+  target: $STEP_7_OUTPUT
+  mode: composite
+
+  ## Code Verification Results
+  $STEP_8_OUTPUT
+
+  ## Parent PRD
+  $APPROVED_PRD_PATH
+
+  ## Additional Review Focus
+  - Technical accuracy of documented interfaces
+  - Consistency with parent PRD scope
+  - Completeness of component boundary definitions
+```
+
+**Store output as**: `$STEP_9_OUTPUT`
+
+#### Step 10: Revision (conditional)
+
+Same logic as Step 5, using technical-designer with update mode.
+
+#### Component Completion
+
+- [ ] Review status is "Approved" or "Approved with Conditions"
+- [ ] Human review passed (if enabled in Step 0)
+
+**Next**: Proceed to next component. After all components → Final Report.
+
+## Final Report
+
+Output summary including:
+- Generated documents table (Type, Name, Consistency Score, Review Status)
+- Action items (critical discrepancies, undocumented features, flagged items)
+- Next steps checklist
+
+## Error Handling
+
+| Error | Action |
+|-------|--------|
+| Discovery finds nothing | Ask user for project structure hints |
+| Generation fails | Log failure, continue with other units, report in summary |
+| consistencyScore < 50 | Flag for mandatory human review, do not auto-approve |
+| Review rejects after 2 revisions | Stop loop, flag for human intervention |