By name: define-reqs description: >- 曖昧な機能要求から具体的な要件を抽出する時に使用する。 ユーザーと対話しながら、目的・対象ユーザー・必須機能・非機能要件・制約・未決事項を明確化する。 メインエージェントが使用し、design-spec / plan-tasks の前に実行する。 user-invocable: false allowed-tools: [Read, Glob, Grep, AskUserQuestion]
要件定義ワークフロー
曖昧な機能要求を具体的で構造化された要件へ変換する対話プロセスを定義する。 メインエージェントがユーザーと対話しながら要件を明確化するために使用する。
準備
対象のフィーチャー名を確認する。未指定の場合は、作業を進める前にユーザーへ確認する。
「要件を定義したいフィーチャー名は？」
フェーズ 1: 現状の把握
- ワークスペース全体のディレクトリ構造を確認し、何が既に存在するかを把握する。
Grep/Globで関連コンポーネント・設定・依存関係・既存の成果物を特定する。- 関連するソースコードや設定が見つかった場合は
Readで確認する。 .artifacts/features/<feature>/requirements.mdが既に存在する場合は読み込み、更新が必要な箇所を特定する。.artifacts/project_architecture.mdが存在する場合は読み込み、既存構造を踏まえる。
フェーズ 2: 要件の明確化
以下の観点で不足している情報をユーザーへ確認する。一度に聞きすぎず、最も重要な質問を優先する。
ツール使用: 情報収集には
AskUserQuestionを使う。テキストで質問を並べるのではなく、 構造的に回答できる形にする。
- 目的 / 背景: なぜ作るのか。どんな問題を解決するのか。
- 対象ユーザー: 誰が使うのか。
- 必須機能: 最低限必要な機能は何か。
- 非機能要件: パフォーマンス・セキュリティ・保守性に求めるレベル。
- 制約: 技術スタック、既存システムへの依存、使用禁止のアプローチ。
- 未決事項 / リスク: まだ決まっていないこと、懸念点。
フェーズ 3: 完了の扱い
要件が固まった時点で本スキルの責務は完了とする。成果物ファイルへの書き出し・ユーザーへの報告・ 次フェーズへの案内は本スキルでは行わない。これらは呼び出し元（コマンドまたはエージェント定義）が担う。
要件の明確化中、各観点について以下の順でステップごとに思考を展開すること。 最終出力には含めず、内部推論として用いる。
- 観点の選定: いま埋めるべき観点は何か（目的・対象ユーザー・必須機能・非機能要件・制約・未決事項のうち）。
- 既知情報の整理: ユーザーからすでに得ている情報と、既存の成果物に書かれている情報を区別する。
- 不足情報の特定: 設計に進むために、いま埋めるべき不足は何か。
- 質問の設計: 構造的に回答できる形（候補選択・スコア・自由記述の選択）を選ぶ。
- 測定可能性の確認: 回答が「速い」「使いやすい」のような定性表現になっていないか、測定可能な基準に 変換できているかを確認する。
- 曖昧さを測定可能な基準へ変換する: 「できるだけ速く」「使いやすい」などの定性表現は、 測定可能な数値や条件へ落とす。
- WHY を先に確定する: 機能（WHAT）の前に目的（WHY）を明確にする。目的がぶれると設計全体がぶれる。
- スコープを明示する: 過剰な設計を防ぐため、スコープ外を明確に定義する。
- 完了基準を定義する: 「完了」の定義を曖昧なままにせず、検証可能な条件で記述する。
- 未決事項は未決として保持する: まだ決まっていないことは、仮定で埋めずに未決として明示する。