cursor-sdd 1.0.11 → 1.0.14

package/new/commands/init.md

@@ -0,0 +1,65 @@
+<meta>
+description: 詳細なプロジェクト説明で新しい仕様を初期化
+argument-hint: <project-description>
+</meta>
+
+# Spec 初期化
+
+<background_information>
+- **ミッション**: 新しい仕様のディレクトリ構造とメタデータを作成し、spec駆動開発の最初のフェーズを初期化
+- **成功基準**:
+  - ワークスペースのルートフォルダ名をプロジェクト名として使用
+  - `.cursor/[ルートフォルダ名]/` にspec構造を作成
+  - 次のフェーズ（要件生成）への明確なパスを提供
+</background_information>
+
+<instructions>
+## コアタスク
+ワークスペースのルートフォルダ名をプロジェクト名として使用し、仕様構造を初期化する。
+
+## 実行ステップ
+1. **プロジェクト名の取得**: ワークスペースのルートフォルダ名をプロジェクト名として使用
+2. **ディレクトリ作成**: `.cursor/[ルートフォルダ名]/`
+3. **テンプレートを使用してファイルを初期化**:
+   - `.cursor/templates/specs/init.json` を読み込み
+   - `.cursor/templates/specs/requirements-init.md` を読み込み
+   - プレースホルダーを置換:
+     - `{{FEATURE_NAME}}` → ルートフォルダ名（プロジェクト名）
+     - `{{TIMESTAMP}}` → 現在の ISO 8601 タイムスタンプ
+     - `{{PROJECT_DESCRIPTION}}` → $ARGUMENTS
+   - `spec.json` と `requirements.md` を `.cursor/[ルートフォルダ名]/` に書き込み
+
+## 重要な制約
+- この段階で requirements/design/tasks を生成しない
+- ステージごとの開発原則に従う
+- 厳格なフェーズ分離を維持
+- このフェーズでは初期化のみを実行
+</instructions>
+
+## ツールガイダンス
+- **Glob** を使用して `.cursor/[ルートフォルダ名]/` が既に存在するか確認
+- **Read** を使用してテンプレートを取得: `init.json` と `requirements-init.md`
+- **Write** を使用してプレースホルダー置換後に spec.json と requirements.md を作成
+- ファイル書き込み操作前に検証を実行
+
+## 出力説明
+`spec.json` で指定された言語で以下の構造で出力:
+
+1. **プロジェクト名**: ルートフォルダ名から取得したプロジェクト名
+2. **プロジェクトサマリー**: 簡潔なサマリー（1文）
+3. **作成されたファイル**: フルパス付きの箇条書きリスト
+4. **次のステップ**: `/requirements` を示すコマンドブロック
+5. **注記**: 初期化のみが実行された理由の説明（フェーズ分離について2-3文）
+
+**フォーマット要件**:
+- Markdown見出しを使用（##、###）
+- コマンドはコードブロックで囲む
+- 総出力は簡潔に（250語以内）
+- `spec.json.language` に従った明確でプロフェッショナルな言語を使用
+
+## 安全性とフォールバック
+- **テンプレートが見つからない**: `.cursor/templates/specs/` にテンプレートファイルが存在しない場合、具体的な不足ファイルパスでエラーを報告し、リポジトリセットアップの確認を提案
+- **ディレクトリ既存**: `.cursor/[ルートフォルダ名]/` が既に存在する場合、上書きするか確認をユーザーに求める
+- **書き込み失敗**: 具体的なパスでエラーを報告し、権限またはディスク容量の確認を提案
+
+</output>

package/new/commands/requirements.md

@@ -0,0 +1,91 @@
+<meta>
+description: 仕様の包括的な要件を生成
+argument-hint: <feature-name:$1>
+</meta>
+
+# 要件生成
+
+<background_information>
+- **ミッション**: spec初期化からのプロジェクト説明に基づいて、EARSフォーマットで包括的でテスト可能な要件を生成
+- **成功基準**:
+  - 完全な要件ドキュメントを作成
+  - すべての受け入れ基準にプロジェクトのEARSパターンと制約を適用
+  - 実装詳細なしでコア機能にフォーカス
+  - メタデータを更新して生成状況を追跡
+</background_information>
+
+<instructions>
+## コアタスク
+requirements.md のプロジェクト説明に基づいて、機能 **$1** の完全な要件を生成する。
+
+## 実行ステップ
+
+1. **コンテキストの読み込み**:
+   - `.cursor/$1/spec.json` から言語とメタデータを読み込み
+   - `.cursor/$1/requirements.md` からプロジェクト説明を読み込み
+
+2. **ガイドラインの読み込み**:
+   - `.cursor/rules/ears-format.md` から EARS 構文ルールを読み込み
+   - `.cursor/templates/specs/requirements.md` からドキュメント構造を読み込み
+
+3. **要件の生成**:
+   - プロジェクト説明に基づいて初期要件を作成
+   - 関連機能を論理的な要件領域にグループ化
+   - すべての受け入れ基準に EARS フォーマットを適用
+   - spec.json で指定された言語を使用
+
+4. **メタデータの更新**:
+   - `phase: "requirements-generated"` を設定
+   - `approvals.requirements.generated: true` を設定
+   - `updated_at` タイムスタンプを更新
+
+## 重要な制約
+- 何を（WHAT）にフォーカスし、どのように（HOW）は含めない（実装詳細なし）
+- 要件はテスト可能で検証可能でなければならない
+- EARS文の適切な主語を選択（ソフトウェアにはシステム/サービス名）
+- 最初に初期バージョンを生成し、その後ユーザーフィードバックで反復（事前の連続質問なし）
+- requirements.md の要件見出しには先頭に数値IDのみを含めること（例: "Requirement 1"、"1."、"2 Feature ..."）、"Requirement A" のようなアルファベットIDは使用しない
+</instructions>
+
+## ツールガイダンス
+- **最初に読み込み**: 生成前にすべてのコンテキスト（spec、rules、templates）を読み込み
+- **最後に書き込み**: 完全な生成後にのみ requirements.md を更新
+- 外部ドメイン知識が必要な場合のみ **WebSearch/WebFetch** を使用
+
+## 出力説明
+spec.json で指定された言語で以下を出力:
+
+1. **生成された要件サマリー**: 主要な要件領域の簡潔な概要（3-5項目）
+2. **ドキュメントステータス**: requirements.md の更新と spec.json メタデータの更新を確認
+3. **次のステップ**: 進め方をガイド（承認して続行、または修正）
+
+**フォーマット要件**:
+- 明確さのためMarkdown見出しを使用
+- ファイルパスはコードブロックに含める
+- サマリーは簡潔に（300語以内）
+
+## 安全性とフォールバック
+
+### エラーシナリオ
+- **プロジェクト説明が見つからない**: requirements.md にプロジェクト説明がない場合、ユーザーに機能詳細を確認
+- **曖昧な要件**: 多くの事前質問ではなく、初期バージョンを提案してユーザーと反復
+- **テンプレートが見つからない**: テンプレートファイルが存在しない場合、警告付きでインラインフォールバック構造を使用
+- **言語が未定義**: spec.json で言語が指定されていない場合、日本語（`ja`）をデフォルトに
+- **不完全な要件**: 生成後、要件が期待されるすべての機能をカバーしているか明示的にユーザーに確認
+- **非数値の要件見出し**: 既存の見出しに先頭の数値IDがない場合（例: "Requirement A"）、数値IDに正規化し、マッピングの一貫性を維持（数値とアルファベットのラベルを混在させない）
+
+### 次のフェーズ: 設計生成
+
+**要件が承認された場合**:
+- `.cursor/$1/requirements.md` で生成された要件をレビュー
+- **オプションのギャップ分析**（既存コードベース用）:
+  - `/validate-gap $1` を実行して現在のコードとの実装ギャップを分析
+  - 既存コンポーネント、統合ポイント、実装戦略を特定
+  - ブラウンフィールドプロジェクトには推奨、グリーンフィールドにはスキップ
+- その後 `/design $1 -y` で設計フェーズに進む
+
+**修正が必要な場合**:
+- フィードバックを提供し `/requirements $1` を再実行
+
+**注記**: 設計フェーズに進む前に承認が必須。
+</output>

package/new/commands/status.md

@@ -0,0 +1,86 @@
+<meta>
+description: 仕様のステータスと進捗を表示
+argument-hint: <feature-name:$1>
+</meta>
+
+# 仕様ステータス
+
+<background_information>
+- **ミッション**: 仕様の包括的なステータスと進捗を表示
+- **成功基準**:
+  - 現在のフェーズと完了状況を表示
+  - 次のアクションとブロッカーを特定
+  - 進捗の明確な可視性を提供
+</background_information>
+
+<instructions>
+## コアタスク
+機能 **$1** のステータスレポートを生成し、すべてのフェーズの進捗を表示する。
+
+## 実行ステップ
+
+### ステップ1: Specコンテキストの読み込み
+- `.cursor/$1/spec.json` からメタデータとフェーズステータスを読み込み
+- 既存ファイルを読み込み: `requirements.md`、`design.md`、`tasks.md`（存在する場合）
+- `.cursor/$1/` ディレクトリで利用可能なファイルを確認
+
+### ステップ2: ステータスの分析
+
+**各フェーズを解析**:
+- **Requirements**: 要件と受け入れ基準の数をカウント
+- **Design**: アーキテクチャ、コンポーネント、ダイアグラムを確認
+- **Tasks**: 完了タスク vs 全タスクをカウント（`- [x]` vs `- [ ]` を解析）
+- **Approvals**: spec.json で承認状況を確認
+
+### ステップ3: レポートの生成
+
+spec.json で指定された言語でレポートを作成し、以下をカバー:
+1. **現在のフェーズと進捗**: ワークフローにおけるspecの位置
+2. **完了状況**: 各フェーズの完了率
+3. **タスク内訳**: タスクが存在する場合、完了/残りの数を表示
+4. **次のアクション**: 次に何をすべきか
+5. **ブロッカー**: 進捗を妨げる問題
+
+## 重要な制約
+- spec.json の言語を使用
+- 正確な完了率を計算
+- 具体的な次のアクションコマンドを特定
+</instructions>
+
+## ツールガイダンス
+- **Read**: 最初に spec.json を読み込み、次に必要に応じて他のspecファイルを読み込み
+- **慎重に解析**: tasks.md のチェックボックスから完了データを抽出
+- **Glob** を使用してどのspecファイルが存在するか確認
+
+## 出力説明
+
+spec.json で指定された言語でステータスレポートを提供:
+
+**レポート構造**:
+1. **機能概要**: 名前、フェーズ、最終更新
+2. **フェーズステータス**: Requirements、Design、Tasks と完了率
+3. **タスク進捗**: タスクが存在する場合、X/Y 完了を表示
+4. **次のアクション**: 次に実行する具体的なコマンド
+5. **問題**: ブロッカーや不足要素
+
+**フォーマット**: ステータス用の絵文字（✅/⏳/❌）で明確でスキャンしやすいフォーマット
+
+## 安全性とフォールバック
+
+### エラーシナリオ
+
+**Specが見つからない**:
+- **メッセージ**: "`$1` のspecが見つかりません。`.cursor/` で利用可能なspecを確認してください"
+- **アクション**: `.cursor/` 内の利用可能な機能ディレクトリをリスト
+
+**不完全なSpec**:
+- **警告**: どのファイルが不足しているか特定
+- **提案アクション**: 次のフェーズコマンドを指示
+
+### すべてのSpecをリスト
+
+すべての利用可能なspecを見るには:
+- 引数なしで実行またはワイルドカードを使用
+- `.cursor/` 内のすべてのspecをステータスとともに表示
+
+</output>

package/new/commands/tasks.md

@@ -0,0 +1,155 @@
+<meta>
+description: 仕様の実装タスクを生成
+argument-hint: <feature-name:$1> [-y:$2] [--sequential:$3]
+</meta>
+
+# 実装タスクジェネレーター
+
+<background_information>
+- **ミッション**: 技術設計を実行可能な作業項目に変換する、詳細で実行可能な実装タスクを生成
+- **成功基準**:
+  - すべての要件が特定のタスクにマッピング
+  - タスクが適切なサイズ（各1-3時間）
+  - 適切な階層で明確なタスク進行
+  - 機能に焦点を当てた自然言語の説明
+</background_information>
+
+<instructions>
+## コアタスク
+承認済み要件と設計に基づいて、機能 **$1** の実装タスクを生成する。
+
+## 実行ステップ
+
+### ステップ1: コンテキストの読み込み
+
+**必要なすべてのコンテキストを読み込み**:
+- `.cursor/$1/spec.json`、`requirements.md`、`design.md`
+- `.cursor/$1/tasks.md`（存在する場合、マージモード用）
+- `.cursor/rules/frontend.md`（フロントエンド実装制約）
+
+**承認の検証**:
+- `-y` フラグが提供された場合（$2 == "-y"）: spec.json で要件と設計を自動承認
+- それ以外: 両方が承認されていることを確認（されていない場合は停止、安全性とフォールバック参照）
+- シーケンシャルモードの判定: `sequential = ($3 == "--sequential")`
+
+機能: $1
+機能ディレクトリ: .cursor/$1/
+自動承認: {$2 == "-y" なら true、それ以外 false}
+シーケンシャルモード: {sequential なら true、それ以外 false}
+
+読み込むファイルパターン:
+- .cursor/$1/*.{json,md}
+- .cursor/rules/tasks-generation.md
+- .cursor/rules/tasks-parallel-analysis.md（シーケンシャルモードが false の場合のみ含める）
+- .cursor/templates/specs/tasks.md
+
+モード: {tasks.md の存在に基づいて generate または merge}
+命令ハイライト:
+- すべての要件をタスクにマップし、要件IDのみをリスト（カンマ区切り）、追加の説明なし
+- 単一の実行可能なサブタスクはメジャータスクに昇格させ、コンテナのサマリーは簡潔に
+- 並列基準を満たす場合のみ `(P)` マーカーを適用（シーケンシャルモードでは省略）
+- 延期可能なMVP後の受け入れ基準フォーカスのテストカバレッジサブタスクには `- [ ]*` でマーク
+
+### ステップ2: 実装タスクの生成
+
+**生成ルールとテンプレートの読み込み**:
+- `.cursor/rules/tasks-generation.md` から原則を読み込み
+- `sequential == false` の場合: `.cursor/rules/tasks-parallel-analysis.md` から並列判定基準を読み込み
+- `.cursor/templates/specs/tasks.md` からフォーマットを読み込み（`(P)` マーカーをサポート）
+
+**すべてのルールに従ってタスクリストを生成**:
+- spec.json で指定された言語を使用
+- すべての要件をタスクにマップ
+- 要件カバレッジを文書化する際は、数値の要件IDのみをリスト（カンマ区切り）、説明的な接尾辞、括弧、翻訳、自由形式のラベルなし
+- すべての設計コンポーネントが含まれていることを確認
+- タスク進行が論理的で段階的であることを検証
+- 単一サブタスク構造はメジャータスクに昇格させて折りたたみ、コンテナのみのメジャータスクで詳細を重複させない（テンプレートパターンに従う）
+- 並列基準を満たすタスクに `(P)` マーカーを適用（`sequential == true` の場合はマーカーをスキップ）
+- 延期可能なMVP後の受け入れ基準フォーカスのテストカバレッジサブタスクには `- [ ]*` でマーク
+- 既存の tasks.md が見つかった場合、新しいコンテンツとマージ
+
+### ステップ3: 最終化
+
+**書き込みと更新**:
+- `.cursor/$1/tasks.md` を作成/更新
+- spec.json メタデータを更新:
+  - `phase: "tasks-generated"` を設定
+  - `approvals.tasks.generated: true, approved: false` を設定
+  - `approvals.requirements.approved: true` を設定
+  - `approvals.design.approved: true` を設定
+  - `updated_at` タイムスタンプを更新
+
+## 重要な制約
+- **ルールを厳密に遵守**: tasks-generation.md のすべての原則は必須
+- **自然言語**: コード構造の詳細ではなく、何をするかを説明
+- **完全なカバレッジ**: すべての要件がタスクにマップされなければならない
+- **最大2レベル**: メジャータスクとサブタスクのみ（より深いネストなし）
+- **連番**: メジャータスクは増分（1, 2, 3...）、重複なし
+- **タスク統合**: すべてのタスクがシステムに接続（孤立した作業なし）
+</instructions>
+
+## ツールガイダンス
+- **最初に読み込み**: 生成前にすべてのコンテキスト、ルール、テンプレートを読み込み
+- **最後に書き込み**: 完全な分析と検証後にのみ tasks.md を生成
+
+## 出力説明
+
+spec.json で指定された言語で簡潔なサマリーを提供:
+
+1. **ステータス**: `.cursor/$1/tasks.md` にタスク生成完了を確認
+2. **タスクサマリー**: 
+   - 合計: メジャータスク X 個、サブタスク Y 個
+   - Z 個のすべての要件をカバー
+   - 平均タスクサイズ: サブタスクあたり1-3時間
+3. **品質検証**:
+   - ✅ すべての要件がタスクにマップ
+   - ✅ タスク依存関係を検証済み
+   - ✅ テストタスクを含む
+4. **次のアクション**: タスクをレビューし、準備ができたら進行
+
+**フォーマット**: 簡潔（200語以内）
+
+## 安全性とフォールバック
+
+### エラーシナリオ
+
+**要件または設計が未承認**:
+- **実行停止**: 承認済みの要件と設計なしでは続行不可
+- **ユーザーメッセージ**: "タスク生成前に要件と設計の承認が必要です"
+- **提案アクション**: "`/spec-tasks $1 -y` を実行して両方を自動承認して進行"
+
+**要件または設計が見つからない**:
+- **実行停止**: 両方のドキュメントが存在しなければならない
+- **ユーザーメッセージ**: "`.cursor/$1/` に requirements.md または design.md がありません"
+- **提案アクション**: "要件と設計フェーズを先に完了してください"
+
+**不完全な要件カバレッジ**:
+- **警告**: "すべての要件がタスクにマップされていません。カバレッジを確認してください。"
+- **ユーザーアクション必要**: 意図的なギャップを確認するか、タスクを再生成
+
+**テンプレート/ルールが見つからない**:
+- **ユーザーメッセージ**: "`.cursor/rules/` または `.cursor/templates/` にテンプレートまたはルールファイルがありません"
+- **フォールバック**: 警告付きでインライン基本構造を使用
+- **提案アクション**: "リポジトリのセットアップを確認するか、テンプレートファイルを復元"
+- **数値要件IDが見つからない**:
+  - **実行停止**: requirements.md のすべての要件には数値IDが必要。いずれかの要件に数値IDがない場合、停止してタスク生成前に requirements.md の修正を要求。
+
+### 次のフェーズ: 実装
+
+**実装開始前**:
+- **重要**: `/spec-impl` 実行前に会話履歴をクリアしてコンテキストを解放
+- これは最初のタスク開始時またはタスク切り替え時に適用
+- 新鮮なコンテキストでクリーンな状態と適切なタスクフォーカスを確保
+
+**タスク承認後**:
+- 特定のタスクを実行: `/spec-impl $1 1.1`（推奨: 各タスク間でコンテキストをクリア）
+- 複数タスクを実行: `/spec-impl $1 1.1,1.2`（注意して使用、タスク間でコンテキストをクリア）
+- 引数なし: `/spec-impl $1`（すべての保留タスクを実行 - コンテキスト膨張のため非推奨）
+
+**修正が必要な場合**:
+- フィードバックを提供し `/spec-tasks $1` を再実行
+- 既存タスクは参照として使用（マージモード）
+
+**注記**: 実装フェーズでは、適切なコンテキストと検証でタスク実行をガイド。
+
+</output>

package/new/rules/design-discovery-full.md

@@ -0,0 +1,93 @@
+# 技術設計向けフルディスカバリープロセス
+
+## 目的
+技術設計が完全で正確かつ最新の情報に基づいていることを確保するため、包括的な調査と分析を実施する。
+
+## ディスカバリーステップ
+
+### 1. 要件分析
+**要件を技術的ニーズにマッピング**
+- EARSフォーマットからすべての機能要件を抽出
+- 非機能要件を特定（パフォーマンス、セキュリティ、スケーラビリティ）
+- 技術的制約と依存関係を決定
+- コア技術課題をリスト
+
+### 2. 既存実装分析
+**現在のシステムを理解**（修正/拡張する場合）:
+- コードベース構造とアーキテクチャパターンを分析
+- 再利用可能なコンポーネント、サービス、ユーティリティをマッピング
+- ドメイン境界とデータフローを特定
+- 統合ポイントと依存関係を文書化
+- アプローチを決定: 拡張 vs リファクタ vs ラップ
+
+### 3. 技術調査
+**ベストプラクティスとソリューションを調査**:
+- **WebSearchを使用**して以下を検索:
+  - 類似問題に対する最新のアーキテクチャパターン
+  - 技術スタックに対する業界のベストプラクティス
+  - 関連技術の最近の更新や変更
+  - よくある落とし穴と解決策
+
+- **WebFetchを使用**して以下を分析:
+  - フレームワーク/ライブラリの公式ドキュメント
+  - APIリファレンスと使用例
+  - 移行ガイドと破壊的変更
+  - パフォーマンスベンチマークと比較
+
+### 4. 外部依存関係調査
+**各外部サービス/ライブラリについて**:
+- 公式ドキュメントとGitHubリポジトリを検索
+- APIシグネチャと認証方法を検証
+- 既存スタックとのバージョン互換性を確認
+- レート制限と使用制限を調査
+- コミュニティリソースと既知の問題を検索
+- セキュリティの考慮事項を文書化
+- 実装調査が必要なギャップを記録
+
+### 5. アーキテクチャパターンと境界分析
+**アーキテクチャオプションを評価**:
+- 関連パターンを比較（MVC、Clean、Hexagonal、Event-driven）
+- 既存アーキテクチャとステアリング原則との適合性を評価
+- チーム間の競合を回避するために必要なドメイン境界と所有権の継ぎ目を特定
+- スケーラビリティへの影響と運用上の懸念を考慮
+- 保守性とチームの専門知識を評価
+- 推奨パターンと却下した代替案を `research.md` に文書化
+
+### 6. リスク評価
+**技術的リスクを特定**:
+- パフォーマンスボトルネックとスケーリング限界
+- セキュリティ脆弱性と攻撃ベクトル
+- 統合の複雑さと結合
+- 技術的負債の生成 vs 解消
+- 知識ギャップとトレーニングニーズ
+
+## 調査ガイドライン
+
+### 検索するタイミング
+**常に検索するもの**:
+- 外部APIドキュメントと更新
+- 認証/認可のセキュリティベストプラクティス
+- 特定されたボトルネックに対するパフォーマンス最適化テクニック
+- 依存関係の最新バージョンと移行パス
+
+**不確かな場合に検索するもの**:
+- 特定のユースケースに対するアーキテクチャパターン
+- データフォーマット/プロトコルの業界標準
+- コンプライアンス要件（GDPR、HIPAAなど）
+- 予想負荷に対するスケーラビリティアプローチ
+
+### 検索戦略
+1. 公式ソース（ドキュメント、GitHub）から開始
+2. 最近のブログ記事や記事をチェック（過去6ヶ月）
+3. 一般的な問題についてStack Overflowを確認
+4. 類似のオープンソース実装を調査
+
+## 出力要件
+設計決定に影響するすべての発見を共有テンプレートを使用して `research.md` にキャプチャ:
+- アーキテクチャ、技術整合、コントラクトに影響する主要なインサイト
+- 調査中に発見された制約
+- 推奨アプローチと選択したアーキテクチャパターン（根拠付き）
+- 却下した代替案とトレードオフ（設計決定セクションに文書化）
+- コンポーネント & インターフェースコントラクトに情報を提供する更新されたドメイン境界
+- リスクと軽減戦略
+- 実装中にさらなる調査が必要なギャップ

package/new/rules/design-discovery-light.md

@@ -0,0 +1,49 @@
+# 拡張向け軽量ディスカバリープロセス
+
+## 目的
+機能拡張のための既存システムと統合要件を迅速に分析する。
+
+## 焦点を絞ったディスカバリーステップ
+
+### 1. 拡張ポイント分析
+**統合アプローチを特定**:
+- 既存の拡張ポイントまたはインターフェースを特定
+- 変更スコープを決定（ファイル、コンポーネント）
+- 従うべき既存パターンを確認
+- 後方互換性の要件を特定
+
+### 2. 依存関係チェック
+**互換性を検証**:
+- 新しい依存関係のバージョン互換性を確認
+- APIコントラクトが変更されていないことを検証
+- パイプラインに破壊的変更がないことを確認
+
+### 3. クイック技術検証
+**新しいライブラリの場合のみ**:
+- WebSearchで公式ドキュメントを使用
+- 基本的な使用パターンを検証
+- 既知の互換性問題を確認
+- ライセンス互換性を確認
+- 主要な発見を `research.md` に記録（技術整合セクション）
+
+### 4. 統合リスク評価
+**クイックリスクチェック**:
+- 既存機能への影響
+- パフォーマンスへの影響
+- セキュリティの考慮事項
+- テスト要件
+
+## フルディスカバリーにエスカレーションするタイミング
+以下を発見した場合、フルディスカバリーに切り替える:
+- 重大なアーキテクチャ変更が必要
+- 複雑な外部サービス統合
+- セキュリティ上センシティブな実装
+- パフォーマンスクリティカルなコンポーネント
+- 未知またはドキュメントが不十分な依存関係
+
+## 出力要件
+- 明確な統合アプローチ（境界への影響を `research.md` に記録）
+- 変更するファイル/コンポーネントのリスト
+- バージョン付きの新しい依存関係
+- 統合リスクと軽減策
+- テストの焦点領域