requirements

要件定義スキル

機能リクエストを実装可能な仕様にするための、構造化された5フェーズの要件定義ワークフローを実行します。

ワークフローの信頼できる情報源としてSKILL.mdを維持してください。詳細なテンプレートと定型の出力テキストはreferences/templates.mdから読み込みます。

目的

• 実装前に、プロダクトと技術面での期待事項を明確にします。
• 前提条件を明示的に記録します。
• 実際のコードベースのパターンが利用できる場合は、それを参照した要件仕様書を作成します。

使用するタイミング

次の場合にこのスキルを使用します。

• ユーザーが新機能のスコープを明確にするよう求めた場合。
• ユーザーが要件定義書や仕様書の作成または改善を求めた場合。
• 要件定義コマンドのワークフロー（requirements-start、requirements-status、requirements-current、requirements-list、requirements-remind、requirements-end）が進行中の場合。

基本ルール

1. 1つのメッセージにつき質問は1つにします。
2. 質問は選択式にします。
   • はい／いいえ、または
   • 選択肢を2～5個に限定した複数選択（デフォルトを含む）。
3. 現在のフェーズで尋ねる質問をすべて作成してから、順番に質問します。
4. プロダクトに関する表現を優先し、意思決定の質を高める場合に限り技術的な補足を加えます。
5. 要件のヒアリング中はコードを実装しません。
6. リポジトリ内の実際のパスが判明したら、それを使用します。再利用可能なテンプレートや例に限り、プレースホルダーを使用します。
7. 各フェーズの質問数には上限を設けます（目標は5問。正当な理由がある場合は4～7問）。

5フェーズのワークフロー

フェーズ1 — セッションの初期化

1. 要件フォルダーrequirements/[timestamp]-[slug]/を作成します。
2. 初期成果物を作成します。
   • 00-initial-request.md
   • metadata.json
3. 現在のフォルダーをrequirements/.current-requirementに記録します。
4. コードベースを調査し、関連するモジュール、データモデル、ルート、APIを特定します。

リポジトリの構成が異なる場合は、そのリポジトリに合わせてパスと命名を調整します。

フェーズ2 — 発見のための質問（プロダクトのスコープ）

1. ユーザーが得る成果、スコープの境界、権限、データへの影響、外部連携に焦点を当てた質問を作成します。
2. フェーズの質問をすべて、質問を始める前に01-discovery-questions.mdへ記録します。
3. デフォルトの選択肢を添えて、質問を順番に尋ねます。
4. 簡潔な回答を受け付けます。
   • はい／いいえ
   • 限定された選択肢から1つ
   • 不明／デフォルト
5. フェーズの進行中は、回答を一時的な作業メモに保存します。
6. すべての質問を終えたら、確定した回答を02-discovery-answers.mdに保存し、metadata.jsonを更新します。

フェーズ3 — コンテキストの収集（自律的に実施）

1. コードを検索し、類似機能や再利用可能なパターンを探します。
2. 関連するバックエンド、フロントエンド、データ関連のファイルと連携ポイントを確認します。
3. 調査結果を03-context-findings.mdに記録します。
   • 類似機能
   • 変更候補のファイル
   • 制約とリスク
   • 推奨パターン
4. 重大な曖昧さによって進行が妨げられない限り、ユーザーに質問せずにこのフェーズを実施します。

現在のエージェント実行環境で利用できる検索、読み取り、ナビゲーションのツールを使用します。

フェーズ4 — 詳細な質問（動作と設計上の決定）

1. フェーズ3の調査結果をもとに、追加の質問を作成します。
2. 質問を始める前に、フェーズの質問をすべて04-detail-questions.mdに記録します。
3. デフォルトの選択肢を添えて、質問を1つずつ尋ねます。
4. まずプロダクトマネージャーにもわかりやすい表現を使い、必要に応じて技術的な手がかりを添えます。
   • 良い例：「既存のプロジェクト設定画面からユーザーが編集できるようにしますか？」
   • 任意の補足：「（該当箇所はapps/web/src/routes/project-settings.tsxの可能性があります）」
5. フェーズの進行中は、回答を一時メモに保存します。
6. すべての質問を終えたら、確定した回答を05-detail-answers.mdに保存し、metadata.jsonを更新します。

フェーズ 5 — 要件仕様書を作成する

1. 06-requirements-spec.mdを作成します。
2. 次の項目を含めます。
   • 概要
   • 機能要件と受け入れ基準
   • 技術要件
   • 影響を受けるファイル／システム
   • 前提条件と未解決の質問
3. 未解決の項目には、根拠を添えてASSUMED:と記します。
4. メタデータのステータスをcompleteに更新します（明示的に一時停止している場合はincomplete）。
5. セッション終了時に.current-requirementをクリアします。

references/templates.mdの仕様書テンプレートを使用します。

コマンドの動作

requirements-start

• フォルダーとメタデータを初期化します。
• フェーズ 1 を実行し、その後フェーズ 2 を開始します。

requirements-status

• 現在のフェーズ、進捗、最近の回答、次の質問を表示します。
• 次の未回答の質問から再開します。

requirements-current

• アクティブな要件の読み取り専用スナップショット全体（すべての成果物）を表示します。
• 明示的に求められない限り、質問を続けないでください。

requirements-list

• すべての要件フォルダーをステータス付きで一覧表示し、次の順に並べます。
  1. アクティブ
  2. complete／incomplete
  3. 新しい順

requirements-remind

• 現在のフェーズに応じた簡潔なルールのリマインダーを表示します。
• プロセスからの逸脱（例：自由回答形式の質問、実装への逸脱、デフォルトの欠落）を修正します。

requirements-end

• アクティブな要件がある場合は、次の選択肢を提示します。
  1. 今すぐ仕様書を作成する
  2. incompleteとしてマークする
  3. キャンセルする
• 成果物を削除する前に、破壊的な操作を確認します。

移植性に関するルール

1. プロジェクト固有のパスは、固定値ではなく例として扱います。
2. 関連スキルは、依存関係ではなく任意の効率化手段として扱います。
3. リポジトリのコンテキストによって特定のフレームワーク／ツールが確認できる場合を除き、汎用的な表現を優先します。
4. エージェントのランタイム間で、成果物とプロセスを同一に保ちます。

品質チェックリスト

• 質問を始める前に、質問セットがすべて揃っています。
• 質問したすべての項目に、デフォルトとその根拠があります。
• 一時的なメモは、フェーズごとの回答ファイルにまとめられています。
• 仕様書では、確定した決定事項と前提事項が明確に区別されています。
• 出力は要件に焦点を当てており、実装には踏み込みません。

参照ファイル

• references/templates.md — 次の項目に関する標準テンプレート：
  • 質問ファイル
  • 回答ファイル
  • コンテキスト調査結果
  • メタデータ
  • 要件仕様書
  • ステータス／一覧／リマインダーの出力例