requirements

name	requirements
description	機能開発・バグ修正の着手前に使用。メインセッションで人間パートナーと対話し、要件を構造化する。コード調査は Explore エージェントに委譲。

Requirements（要件理解）

概要

実装の前に、何を作るか・なぜ作るかを構造化する。 人間パートナーとの対話を通じて曖昧さを除去し、全員（人間・AI）が参照できる要件ドキュメントを作る。

入力: 人間パートナーからのタスク指示 出力: requirements/REQ-*/requirements.md + context.md（+ 必要に応じて decisions.md）

原則: 曖昧な要件から始めた実装は、曖昧な結果を生む。

Iron Law

構造化された要件なしに設計を始めるな

要件が頭の中にある？ それはまだ要件ではない。書け。

• 「自明だから要件定義は不要」→ 自明に見える要件に限って解釈が割れる
• 「口頭で合意した」→ 口頭の合意は1時間で蒸発する
• 「要件は実装しながら固める」→ 固まらない。スコープが膨張する

タスクサイズによらず要件定義を行う。タスクが小さければ書く量が少なくなるだけで、プロセスは同じ。

いつ使うか

常に:

• 新機能の開発
• 複数ファイルにまたがるバグ修正
• 仕様変更・機能拡張

例外（人間パートナーに確認すること）:

• typo 修正
• 自動生成コードの更新

プロセス

digraph requirements {
    rankdir=TB;
    input [label="タスク受領", shape=ellipse];
    explore [label="調査\nExplore エージェント\n(コード/ドキュメント)", shape=box, style=filled, fillcolor="#cce5ff"];
    shaping [label="深掘り対話\n「何がしたいか」「なぜか」\nAskUserQuestion", shape=box, style=filled, fillcolor="#ccffcc"];
    gap [label="差分分析\n既知/未知/曖昧を整理", shape=box, style=filled, fillcolor="#cce5ff"];
    dialog [label="差分ヒアリング\nAskUserQuestion\n（不足部分だけ）", shape=box, style=filled, fillcolor="#ccffcc"];
    structure [label="要件ドキュメント\n構造化・作成", shape=box, style=filled, fillcolor="#ccccff"];
    review [label="人間パートナーの\n承認", shape=diamond];
    done [label="要件確定\n→ 次のステップへ", shape=ellipse];

    input -> explore;
    explore -> shaping;
    shaping -> gap;
    gap -> dialog;
    dialog -> structure;
    structure -> review;
    review -> done [label="承認"];
    review -> dialog [label="修正\n要求"];
}

1. 調査（Explore エージェント）