cursor-sdd 1.0.11 → 1.0.12

package/new/commands/check-design.md

@@ -0,0 +1,87 @@
+<meta>
+description: インタラクティブな技術設計品質レビューと検証
+argument-hint: <feature-name:$1>
+</meta>
+
+# 技術設計検証
+
+<background_information>
+- **ミッション**: 技術設計のインタラクティブな品質レビューを実施し、実装準備の確認
+- **成功基準**:
+  - 重大な問題の特定（最も重要な懸念事項を最大3つ）
+  - 強みを認識したバランスの取れた評価
+  - 根拠を伴う明確な GO/NO-GO 判定
+  - 必要に応じた改善のための実行可能なフィードバック
+</background_information>
+
+<instructions>
+## コアタスク
+承認済み要件と設計ドキュメントに基づいて、機能 **$1** のインタラクティブな設計品質レビューを実施する。
+
+## 実行ステップ
+
+1. **コンテキストの読み込み**:
+   - `.cursor/$1/spec.json` から言語とメタデータを読み込み
+   - `.cursor/$1/requirements.md` から要件を読み込み
+   - `.cursor/$1/design.md` から設計ドキュメントを読み込み
+
+2. **レビューガイドラインの読み込み**:
+   - `.cursor/rules/design-review.md` からレビュー基準とプロセスを読み込み
+
+3. **設計レビューの実行**:
+   - design-review.md のプロセスに従う: 分析 → 重大な問題 → 強み → GO/NO-GO
+   - 最も重要な懸念事項を最大3つに限定
+   - ユーザーとインタラクティブにやり取り
+   - spec.json で指定された言語で出力
+
+4. **判定と次のステップの提供**:
+   - 根拠を伴う明確な GO/NO-GO 判定
+   - 判定に基づいた進め方のガイド
+
+## 重要な制約
+- **品質保証であり完璧追求ではない**: 許容可能なリスクを受け入れる
+- **重大問題のみフォーカス**: 最大3問題、成功に著しく影響するもののみ
+- **インタラクティブアプローチ**: 一方的な評価ではなく対話
+- **バランスの取れた評価**: 強みと弱みの両方を認識
+- **実行可能なフィードバック**: すべての提案は実装可能でなければならない
+</instructions>
+
+## ツールガイダンス
+- **最初に読み込み**: レビュー前にすべてのコンテキスト（spec、rules）を読み込み
+- **必要に応じてGrep**: パターン検証や統合チェックのためコードベースを検索
+- **インタラクティブ**: レビュープロセス全体を通じてユーザーとやり取り
+
+## 出力説明
+spec.json で指定された言語で以下を出力:
+
+1. **レビューサマリー**: 設計品質と準備状況の簡潔な概要（2-3文）
+2. **重大な問題**: 最大3つ、design-review.md フォーマットに従う
+3. **設計の強み**: 1-2つのポジティブな側面
+4. **最終評価**: 根拠と次のステップを伴う GO/NO-GO 判定
+
+**フォーマット要件**:
+- 明確さのためMarkdown見出しを使用
+- design-review.md 出力フォーマットに従う
+- サマリーは簡潔に
+
+## 安全性とフォールバック
+
+### エラーシナリオ
+- **設計が見つからない**: design.md が存在しない場合、メッセージで停止: "先に `/design $1` を実行して設計ドキュメントを生成してください"
+- **設計が未生成**: spec.json で設計フェーズが生成済みとしてマークされていない場合、警告を出すがレビューを続行
+- **言語が未定義**: spec.json で言語が指定されていない場合、英語（`en`）をデフォルトに
+
+### 次のフェーズ: タスク生成
+
+**設計が検証に合格した場合（GO判定）**:
+- フィードバックをレビューし、必要に応じて変更を適用
+- `/tasks $1` を実行して実装タスクを生成
+- または `/tasks $1 -y` で自動承認して直接進行
+
+**設計の修正が必要な場合（NO-GO判定）**:
+- 特定された重大な問題に対処
+- `/design $1` を改善とともに再実行
+- `/check-design $1` で再検証
+
+**注記**: 設計検証は推奨ですがオプション。品質レビューにより問題を早期発見可能。
+</output>

package/new/commands/design.md

@@ -0,0 +1,188 @@
+<meta>
+description: 仕様の包括的な技術設計を作成
+argument-hint: <feature-name:$1> [-y:$2]
+</meta>
+
+# 技術設計ジェネレーター
+
+<background_information>
+- **ミッション**: 要件（WHAT）をアーキテクチャ設計（HOW）に変換する包括的な技術設計ドキュメントを生成
+- **成功基準**:
+  - すべての要件が明確なインターフェースを持つ技術コンポーネントにマップ
+  - 適切なアーキテクチャ発見と調査の完了
+  - 設計が既存パターンに整合
+  - 複雑なアーキテクチャには視覚的ダイアグラムを含む
+</background_information>
+
+<instructions>
+## コアタスク
+承認済み要件に基づいて、機能 **$1** の技術設計ドキュメントを生成する。
+
+## 実行ステップ
+
+### ステップ1: コンテキストの読み込み
+
+**必要なすべてのコンテキストを読み込み**:
+- `.cursor/$1/spec.json`、`requirements.md`、`design.md`（存在する場合）
+- `.cursor/templates/specs/design.md` からドキュメント構造
+- `.cursor/rules/design-principles.md` から設計原則
+- `.cursor/templates/specs/research.md` から発見ログ構造
+- **`package.json`（プロジェクトルートに存在する場合）**: 既存の依存関係とバージョンを把握
+- `.cursor/rules/frontend.md`（存在する場合）からフロントエンド設計原則
+
+**要件承認の検証**:
+- `-y` フラグが提供された場合（$2 == "-y"）: spec.json で要件を自動承認
+- それ以外: 承認状況を確認（未承認の場合は停止、安全性とフォールバック参照）
+
+### ステップ2: 発見と分析
+
+**重要: このフェーズは設計が完全で正確な情報に基づくことを保証。**
+
+1. **機能タイプの分類**:
+   - **新機能**（グリーンフィールド）→ フル発見が必要
+   - **拡張**（既存システム）→ 統合重視の発見
+   - **シンプルな追加**（CRUD/UI）→ 最小限または発見なし
+   - **複雑な統合** → 包括的な分析が必要
+
+2. **既存パッケージの優先確認**（package.json が存在する場合）:
+   - **優先原則**: 既にインストール済みのパッケージで要件を満たせる場合は、新規追加より既存を活用
+   - dependencies / devDependencies を確認し、使用可能なライブラリをリストアップ
+   - 既存パッケージのバージョンと互換性を検証
+   - 不足している機能がある場合のみ、追加パッケージを検討
+
+3. **適切な発見プロセスの実行**:
+   
+   **複雑/新機能の場合**:
+   - `.cursor/rules/design-discovery-full.md` を読み込んで実行
+   - WebSearch/WebFetch を使用した徹底的な調査:
+     - 最新のアーキテクチャパターンとベストプラクティス
+     - 外部依存関係の検証（API、ライブラリ、バージョン、互換性）
+     - 公式ドキュメント、移行ガイド、既知の問題
+     - パフォーマンスベンチマークとセキュリティ考慮事項
+   
+   **拡張の場合**:
+   - `.cursor/rules/design-discovery-light.md` を読み込んで実行
+   - 統合ポイント、既存パターン、互換性にフォーカス
+   - Grep を使用して既存コードベースのパターンを分析
+   
+   **シンプルな追加の場合**:
+   - 正式な発見をスキップ、クイックパターンチェックのみ
+
+4. **発見結果をステップ3用に保持**:
+   - 外部APIの契約と制約
+   - 根拠を伴う技術的決定
+   - 従うまたは拡張する既存パターン
+   - 統合ポイントと依存関係
+   - 特定されたリスクと緩和戦略
+   - 潜在的なアーキテクチャパターンと境界オプション（詳細を `research.md` に記録）
+   - 将来のタスク用の並列化考慮事項（依存関係を `research.md` にキャプチャ）
+   - **パッケージ選定結果**:
+     - 既存パッケージの活用リスト（package.json から）
+     - 追加推奨パッケージ（理由・用途を明記）
+     - 不要または代替可能な既存パッケージ（あれば）
+
+5. **発見結果をリサーチログに永続化**:
+   - 共有テンプレートを使用して `.cursor/$1/research.md` を作成または更新
+   - 発見スコープと主要な発見をサマリーセクションに記録
+   - リサーチログトピックに調査、ソース、影響を記録
+   - テンプレートセクションを使用してアーキテクチャパターン評価、設計決定、リスクを文書化
+   - `research.md` の記述には spec.json で指定された言語を使用
+
+### ステップ3: 設計ドキュメントの生成
+
+1. **設計テンプレートとルールの読み込み**:
+   - `.cursor/templates/specs/design.md` から構造
+   - `.cursor/rules/design-principles.md` から原則
+
+2. **設計ドキュメントの生成**:
+   - **specs/design.md テンプレート構造と生成指示に厳密に従う**
+   - **すべての発見結果を統合**: 調査した情報（API、パターン、技術）をコンポーネント定義、アーキテクチャ決定、統合ポイント全体で使用
+   - ステップ1で既存の design.md が見つかった場合、参照コンテキストとして使用（マージモード）
+   - 設計ルールを適用: 型安全性、ビジュアルコミュニケーション、フォーマルトーン
+   - spec.json で指定された言語を使用
+   - セクションが更新された見出し（"アーキテクチャパターンと境界マップ"、"技術スタックと整合性"、"コンポーネントとインターフェース契約"）を反映し、`research.md` からのサポート詳細を参照することを確認
+
+3. **spec.json のメタデータを更新**:
+   - `phase: "design-generated"` を設定
+   - `approvals.design.generated: true, approved: false` を設定
+   - `approvals.requirements.approved: true` を設定
+   - `updated_at` タイムスタンプを更新
+
+## 重要な制約
+ - **型安全性**:
+   - プロジェクトの技術スタックに合わせた強い型付けを適用。
+   - 静的型付け言語では、明示的な型/インターフェースを定義し、安全でないキャストを避ける。
+   - TypeScriptでは、`any` を使用しない。正確な型とジェネリクスを優先。
+   - 動的型付け言語では、利用可能な型ヒント/アノテーション（例: Python型ヒント）を提供し、境界で入力を検証。
+   - 公開インターフェースと契約を明確に文書化し、コンポーネント間の型安全性を確保。
+- **最新情報**: 外部依存関係とベストプラクティスには WebSearch/WebFetch を使用
+- **テンプレート準拠**: specs/design.md テンプレート構造と生成指示に厳密に従う
+- **設計フォーカス**: アーキテクチャとインターフェースのみ、実装コードなし
+- **要件トレーサビリティID**: requirements.md で定義された通りの数値要件IDのみを使用（例: "1.1"、"1.2"、"3.1"、"3.3"）。新しいIDを発明したりアルファベットラベルを使用しない。
+
+### 言語リマインダー
+- spec.json が設計出力に別の言語を要求しても、Markdownプロンプトコンテンツは英語のままにする。生成される design.md と research.md は spec の言語を使用すべき。
+</instructions>
+
+## ツールガイダンス
+- **最初に読み込み**: アクション前にすべてのコンテキストを読み込み（specs、templates、rules）
+- **不確かな時は調査**: 外部依存関係、API、最新ベストプラクティスには WebSearch/WebFetch を使用
+- **既存コードを分析**: Grep を使用してコードベースのパターンと統合ポイントを検索
+- **最後に書き込み**: すべての調査と分析完了後にのみ design.md を生成
+
+## 出力説明
+
+**コマンド実行出力**（design.md コンテンツとは別）:
+
+spec.json で指定された言語で簡潔なサマリーを提供:
+
+1. **ステータス**: `.cursor/$1/design.md` に設計ドキュメント生成完了を確認
+2. **発見タイプ**: どの発見プロセスが実行されたか（full/light/minimal）
+3. **主要な発見**: 設計を形作った2-3の重要な洞察
+4. **パッケージ選定サマリー**:
+   - 既存パッケージで活用するもの
+   - 追加推奨パッケージ（あれば理由と共に）
+5. **次のアクション**: 承認ワークフローのガイダンス（安全性とフォールバック参照）
+
+**フォーマット**: 簡潔なMarkdown（200語以内）- これはコマンド出力であり、設計ドキュメント自体ではない
+
+**注記**: 実際の設計ドキュメントは `.cursor/templates/specs/design.md` 構造に従う。
+
+## 安全性とフォールバック
+
+### エラーシナリオ
+
+**要件が未承認**:
+- **実行停止**: 承認済み要件なしでは続行不可
+- **ユーザーメッセージ**: "要件がまだ承認されていません。設計生成前に承認が必要です。"
+- **提案アクション**: "`/design $1 -y` を実行して要件を自動承認して進行"
+
+**要件が見つからない**:
+- **実行停止**: 要件ドキュメントが存在しなければならない
+- **ユーザーメッセージ**: "`.cursor/$1/requirements.md` に requirements.md が見つかりません"
+- **提案アクション**: "先に `/requirements $1` を実行して要件を生成してください"
+
+**テンプレートが見つからない**:
+- **ユーザーメッセージ**: "`.cursor/templates/specs/design.md` にテンプレートファイルがありません"
+- **提案アクション**: "リポジトリセットアップを確認するか、テンプレートファイルを復元"
+- **フォールバック**: 警告付きでインライン基本構造を使用
+
+**発見の複雑さが不明確**:
+- **デフォルト**: フル発見プロセスを使用（`.cursor/rules/design-discovery-full.md`）
+- **根拠**: 重要なコンテキストを見逃すより過剰調査の方が良い
+- **無効な要件ID**:
+  - **実行停止**: requirements.md に数値IDがない、または非数値の見出し（例: "Requirement A"）がある場合、停止して続行前に requirements.md の修正を指示。
+
+### 次のフェーズ: タスク生成
+
+**設計が承認された場合**:
+- `.cursor/$1/design.md` で生成された設計をレビュー
+- **オプション**: `/validate-design $1` でインタラクティブな品質レビューを実行
+- その後 `/tasks $1 -y` で実装タスクを生成
+
+**修正が必要な場合**:
+- フィードバックを提供し `/design $1` を再実行
+- 既存の設計は参照として使用（マージモード）
+
+**注記**: タスク生成に進む前に設計の承認が必須。
+</output>

package/new/commands/difference-check.md

@@ -0,0 +1,83 @@
+<meta>
+description: 要件と既存コードベース間の実装ギャップを分析
+argument-hint: <feature-name:$1>
+</meta>
+
+# 実装ギャップ検証
+
+<background_information>
+- **ミッション**: 要件と既存コードベースのギャップを分析し、実装戦略を策定
+- **成功基準**:
+  - 既存コードベースのパターンとコンポーネントの包括的な理解
+  - 不足している機能と統合課題の明確な特定
+  - 複数の実行可能な実装アプローチの評価
+  - 設計フェーズに必要な技術調査の特定
+</background_information>
+
+<instructions>
+## コアタスク
+承認済み要件と既存コードベースに基づいて、機能 **$1** の実装ギャップを分析する。
+
+## 実行ステップ
+
+1. **コンテキストの読み込み**:
+   - `.cursor/$1/spec.json` から言語とメタデータを読み込み
+   - `.cursor/$1/requirements.md` から要件を読み込み
+
+2. **分析ガイドラインの読み込み**:
+   - `.cursor/rules/gap-analysis.md` から包括的な分析フレームワークを読み込み
+
+3. **ギャップ分析の実行**:
+   - gap-analysis.md フレームワークに従って徹底的な調査を実施
+   - Grep と Read ツールを使用して既存コードベースを分析
+   - 必要に応じて WebSearch/WebFetch で外部依存関係を調査
+   - 複数の実装アプローチ（拡張/新規/ハイブリッド）を評価
+   - spec.json で指定された言語で出力
+
+4. **分析ドキュメントの生成**:
+   - gap-analysis.md の出力ガイドラインに従って包括的なギャップ分析を作成
+   - トレードオフを含む複数の実行可能なオプションを提示
+   - さらなる調査が必要な領域にフラグを立てる
+
+## 重要な制約
+- **決定より情報**: 最終的な実装選択ではなく、分析とオプションを提供
+- **複数オプション**: 適用可能な場合は代替案を提示
+- **徹底的な調査**: ツールを使用して既存コードベースを深く理解
+- **明示的なギャップ**: 調査や検討が必要な領域を明確にフラグ
+</instructions>
+
+## ツールガイダンス
+- **最初に読み込み**: 分析前にすべてのコンテキスト（spec、rules）を読み込み
+- **広範囲にGrep**: パターン、規約、統合ポイントをコードベースで検索
+- **WebSearch/WebFetch**: 必要に応じて外部依存関係とベストプラクティスを調査
+- **最後に書き込み**: 完全な調査後にのみ分析を生成
+
+## 出力説明
+spec.json で指定された言語で以下を出力:
+
+1. **分析サマリー**: スコープ、課題、推奨事項の簡潔な概要（3-5項目）
+2. **ドキュメントステータス**: 使用した分析アプローチの確認
+3. **次のステップ**: 設計フェーズへの進め方をガイド
+
+**フォーマット要件**:
+- 明確さのためMarkdown見出しを使用
+- サマリーは簡潔に（300語以内）
+- 詳細分析は gap-analysis.md 出力ガイドラインに従う
+
+## 安全性とフォールバック
+
+### エラーシナリオ
+- **要件が見つからない**: requirements.md が存在しない場合、メッセージで停止: "先に `/spec-requirements $1` を実行して要件を生成してください"
+- **要件が未承認**: 要件が承認されていない場合、警告を出すが続行（ギャップ分析は要件修正に役立つ）
+- **複雑な統合が不明確**: ブロックするのではなく、設計フェーズでの包括的調査のためにフラグ
+- **言語が未定義**: spec.json で言語が指定されていない場合、英語（`en`）をデフォルトに
+
+### 次のフェーズ: 設計生成
+
+**ギャップ分析完了時**:
+- ギャップ分析の洞察をレビュー
+- `/spec-design $1` を実行して技術設計ドキュメントを作成
+- または `/spec-design $1 -y` で要件を自動承認し直接進行
+
+**注記**: ギャップ分析はオプションですが、ブラウンフィールドプロジェクトでは設計決定の参考として推奨。
+</output>

package/new/commands/impl.md

@@ -0,0 +1,109 @@
+<meta>
+description: TDD手法を使用してspecタスクを実行
+argument-hint: <feature-name:$1> [task-numbers:$2]
+</meta>
+
+# 実装タスク実行
+
+<background_information>
+- **ミッション**: 承認済み仕様に基づいて、テスト駆動開発手法を使用して実装タスクを実行
+- **成功基準**:
+  - すべてのテストを実装コードより先に記述
+  - コードがすべてのテストに合格しリグレッションなし
+  - タスクが tasks.md で完了としてマーク
+  - 実装が設計と要件に整合
+</background_information>
+
+<instructions>
+## コアタスク
+テスト駆動開発を使用して、機能 **$1** の実装タスクを実行する。
+
+## 実行ステップ
+
+### ステップ1: コンテキストの読み込み
+
+**必要なすべてのコンテキストを読み込み**:
+- `.cursor/$1/spec.json`、`requirements.md`、`design.md`、`tasks.md`
+- `.cursor/rules/frontend.md`（存在する場合）からフロントエンド実装ルール
+
+**承認の検証**:
+- spec.json でタスクが承認されていることを確認（されていない場合は停止、安全性とフォールバック参照）
+
+### ステップ2: タスクの選択
+
+**実行するタスクを決定**:
+- `$2` が提供された場合: 指定されたタスク番号を実行（例: "1.1" または "1,2,3"）
+- それ以外: すべての保留タスクを実行（tasks.md で未チェック `- [ ]`）
+
+### ステップ3: TDDで実行
+
+選択された各タスクについて、Kent BeckのTDDサイクルに従う:
+
+1. **RED - 失敗するテストを書く**:
+   - 次の小さな機能のテストを書く
+   - テストは失敗するはず（コードがまだ存在しない）
+   - 説明的なテスト名を使用
+
+2. **GREEN - 最小限のコードを書く**:
+   - テストを通過させる最もシンプルなソリューションを実装
+   - このテストを通過させることだけにフォーカス
+   - オーバーエンジニアリングを避ける
+
+3. **REFACTOR - クリーンアップ**:
+   - コード構造と可読性を改善
+   - 重複を削除
+   - 適切な箇所にデザインパターンを適用
+   - リファクタリング後もすべてのテストが通過することを確認
+
+4. **VERIFY - 品質を検証**:
+   - すべてのテストが通過（新規と既存）
+   - 既存機能にリグレッションなし
+   - コードカバレッジを維持または改善
+
+5. **完了マーク**:
+   - tasks.md でチェックボックスを `- [ ]` から `- [x]` に更新
+
+## 重要な制約
+- **TDD必須**: テストは実装コードより先に書かなければならない
+- **タスクスコープ**: 特定のタスクが要求するものだけを実装
+- **テストカバレッジ**: すべての新しいコードにテストが必要
+- **リグレッションなし**: 既存のテストは引き続き通過しなければならない
+- **設計整合性**: 実装は design.md 仕様に従わなければならない
+</instructions>
+
+## ツールガイダンス
+- **最初に読み込み**: 実装前にすべてのコンテキストを読み込み
+- **テストファースト**: コードより先にテストを書く
+- 必要に応じてライブラリドキュメントのため **WebSearch/WebFetch** を使用
+
+## 出力説明
+
+spec.json で指定された言語で簡潔なサマリーを提供:
+
+1. **実行されたタスク**: タスク番号とテスト結果
+2. **ステータス**: 完了タスクが tasks.md でマーク、残りのタスク数
+
+**フォーマット**: 簡潔（150語以内）
+
+## 安全性とフォールバック
+
+### エラーシナリオ
+
+**タスクが未承認またはSpecファイルが見つからない**:
+- **実行停止**: すべてのspecファイルが存在し、タスクが承認されていなければならない
+- **提案アクション**: "前のフェーズを完了してください: `/requirements`、`/design`、`/tasks`"
+
+**テスト失敗**:
+- **実装停止**: 続行前に失敗したテストを修正
+- **アクション**: デバッグして修正、その後再実行
+
+### タスク実行
+
+**特定のタスクを実行**:
+- `/impl $1 1.1` - 単一タスク
+- `/impl $1 1,2,3` - 複数タスク
+
+**すべての保留タスクを実行**:
+- `/impl $1` - すべての未チェックタスク
+
+</output>

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>