description: 仕様の包括的な要件を生成 argument-hint: [requirements-context:$2] # 要件生成 > 将来的に既存要件取り込みモード（`--import`）への統合を検討するが、 > 現時点では `/requirements-import` と併存運用する。 - **ミッション**: spec を自動初期化しつつ、プロジェクト説明に基づいて EARSフォーマットで包括的でテスト可能な要件を生成 - **成功基準**: - `/requirements` 単体で開始できる - 完全な要件ドキュメントを作成 - すべての受け入れ基準にプロジェクトのEARSパターンと制約を適用 - 実装詳細なしでコア機能にフォーカス - メタデータを更新して生成状況を追跡 ## コアタスク requirements.md のプロジェクト説明に基づいて、機能 **$1** の完全な要件を生成する。 ## 実行ステップ ### ステップ1: コンテキストの読み込み - `.cursor/$1/spec.json` と `.cursor/$1/requirements.md` の存在を確認 - **未初期化の場合（spec.json がない場合）**: - `.cursor/templates/specs/init.json` と `.cursor/templates/specs/requirements-init.md` を読み込み、`.cursor/$1/` を初期化する - `{{PROJECT_NAME}}` はワークスペースルート名、`{{FEATURE_KEY}}` と `{{FEATURE_NAME}}` は `$1` 末尾セグメント、`{{FEATURE_PATH}}` は `$1` を使用 - `{{PROJECT_DESCRIPTION}}` には `$2`（requirements-context）があれば使用し、なければユーザーに説明入力を求める - `{{INIT_MODE}}` は feature 扱いとし、`{{TIMESTAMP}}` を現在日付で埋める - その後 `.cursor/$1/spec.json` から言語とメタデータを読み込み - `.cursor/$1/requirements.md` からプロジェクト説明を読み込み ### ステップ2: ガイドラインの読み込み - `.cursor/rules/ears-format.md` から EARS 構文ルールを読み込み - `.cursor/templates/specs/requirements.md` からドキュメント構造を読み込み - `.cursor/rules/spec-state-management.md` と `.cursor/rules/gate-invalidation-policy.md` を読み込み ### ステップ3: 要件の生成 - プロジェクト説明に基づいて初期要件を作成 - 関連機能を論理的な要件領域にグループ化 - すべての受け入れ基準に EARS フォーマットを適用 - spec.json で指定された言語を使用 ### ステップ4: メタデータの更新 `spec.json` 更新時は、共通ルール `.cursor/rules/spec-state-management.md` と `.cursor/rules/gate-invalidation-policy.md` に従う。 - `phase: "requirements-generated"` を設定 - `approvals.requirements.generated: true` を設定 - `approvals.requirements.approved: false` を維持または設定 - `approvals.requirements.source: "generated"` を設定 - 要件再生成により下流成果物が古くなる可能性があるため、必要に応じて以下をリセット: - `approvals.design.approved: false` - `quality_gates.review.status` / `quality_gates.final_check.status` / `traceability.status` は ポリシーに従って `not_run` または `stale` を設定 ## 重要な制約 - 何を（WHAT）にフォーカスし、どのように（HOW）は含めない（実装詳細なし） - 要件はテスト可能で検証可能でなければならない - EARS文の適切な主語を選択（ソフトウェアにはシステム/サービス名） - 最初に初期バージョンを生成し、その後ユーザーフィードバックで反復（事前の連続質問なし） - requirements.md の要件見出しには先頭に数値IDのみを含めること（例: "Requirement 1"、"1."、"2 Feature ..."）、"Requirement A" のようなアルファベットIDは使用しない - 事前初期化を前提にしない（`/requirements` 単体で開始可能） ## 成果物（artifacts）の自動作成 `/requirements` 実行時に、`.cursor/rules/artifacts-generation.md` を読み込み、 `.cursor/$1/artifacts/feature-list.md` を（無ければ）テンプレから作成する（**上書き禁止**）。 - テンプレ: `.cursor/templates/artifacts/create-feature-list.md` ### 出力への追記 - 作成/スキップした成果物ファイルの一覧を、requirements 出力サマリーに含める。 ## ツールガイダンス - **最初に読み込み**: 生成前にすべてのコンテキスト（spec、rules、templates）を読み込み - **最後に書き込み**: 完全な生成後にのみ requirements.md を更新 - 外部ドメイン知識が必要な場合のみ **WebSearch/WebFetch** を使用 ## 出力説明 spec.json で指定された言語で以下を出力: 1. **生成された要件サマリー**: 主要な要件領域の簡潔な概要（3-5項目） 2. **ドキュメントステータス**: requirements.md の更新と spec.json メタデータの更新を確認 3. **状態更新**: 現在フェーズ、承認待ち、無効化された下流ゲートがあれば明記 4. **次のステップ**: 進め方をガイド（承認して続行、または修正） **フォーマット要件**: - 明確さのためMarkdown見出しを使用 - ファイルパスはコードブロックに含める - サマリーは簡潔に（300語以内） ## 安全性とフォールバック ### エラーシナリオ - **初期化情報が不足**: 未初期化かつ `$2` が空でプロジェクト説明がない場合、要件生成を停止して説明入力を求める - **プロジェクト説明が見つからない**: requirements.md にプロジェクト説明がない場合、ユーザーに機能詳細を確認 - **曖昧な要件**: 多くの事前質問ではなく、初期バージョンを提案してユーザーと反復 - **テンプレートが見つからない**: テンプレートファイルが存在しない場合、警告付きでインラインフォールバック構造を使用 - **言語が未定義**: spec.json で言語が指定されていない場合、日本語（`ja`）をデフォルトに - **不完全な要件**: 生成後、要件が期待されるすべての機能をカバーしているか明示的にユーザーに確認 - **非数値の要件見出し**: 既存の見出しに先頭の数値IDがない場合（例: "Requirement A"）、数値IDに正規化し、マッピングの一貫性を維持（数値とアルファベットのラベルを混在させない） ### 次のフェーズ: 設計生成 **要件が承認された場合**: - `.cursor/$1/requirements.md` で生成された要件をレビュー - **オプションのギャップ分析**（既存コードベース用）: - `/difference-check $1` を実行して現在のコードとの実装ギャップを分析 - 既存コンポーネント、統合ポイント、実装戦略を特定 - ブラウンフィールドプロジェクトには推奨、グリーンフィールドにはスキップ - その後 `/design $1 -y` で設計フェーズに進む **修正が必要な場合**: - フィードバックを提供し `/requirements $1` を再実行 **注記**: 設計フェーズに進む前に承認が必須。