/aor-req — 要件作成（Requirements Authoring）

EARS-12 パターン、INCOSE C1-C9 品質属性、および標準的な相互参照構文に従って、UN、PR、SR をドラフトします。出力はマークダウンです。

スキルとエージェントに関する注意 AOR バンドルには、.claude/skills/aor-*/SKILL.md にあるスキル（このように直接呼び出し可能）と、.claude/agents/aor-sme-*.md にあるSME エージェント（aor-review / aor-review-adhoc によってのみ起動されるサブエージェントシステムプロンプト）が含まれています。エージェントをスキルとして呼び出さないでください — 「スキルが見つかりません」というエラーになります。

運用規律（Operating discipline）

全体にわたって適用します。起動時にそれぞれをユーザーに表示します。

モード（起動時に宣言）： これが探索セッション（単一要件、会話形式、ファイル書き込みなし）か、文書セッション（完全な仕様作成、ファイル書き込みあり）かを尋ねます。スコープがファイルパスなしでインラインテキストとして届いた場合は探索、それ以外の場合は文書がデフォルトです。モードはステップ 5～7 がディスクに書き込むかどうかを制御します。
呼び出し確認： スキルの最初の応答で「aor-req を <モード> モードで実行中です。特に指定がない限り、ファイルは <出力パス> に書き込まれます。」と述べます。「スキルは実際に実行されたのか？」というあいまいさを排除します。
質疑応答（Q&A）規律： 一度に 1 つの明確化質問をします。ユーザーの回答を待ってから次の質問をします。質問を積み重ねないでください。複数の選択肢を提示する単一の AskUserQuestion 呼び出し（例：複数選択メニュー）は1 つの質問です。1 回の呼び出しで 2 つの無関係な決定を提示することは積み重ねに当たります。
失敗開示： 規定されたステップを完了できない場合（ファイル書き込みブロック、サブエージェント呼び出し失敗、参照ファイル利用不可、部分完了、タイムアウト、アクセス許可拒否）、チャットでその旨を述べます。開示後、停止し、再試行するか、開示された手動エミュレーションにフォールバックするか、中止するかを尋ねます — 黙って続行しないでください。必須の開示の前に、明らかに一時的な失敗（例：ネットワークタイムアウト）に対しては 1 回の再試行が許可されます。

ワークフロー（Workflow）

ステップ 1: スコープの確立（Establish scope）

ユーザーがスコープテキストまたはファイルパスを渡した場合はそれを使用します。それ以外の場合は、AskUserQuestion を介して「どの機能または変更を指定すべきですか？」と尋ねます。

スコープテキストとファイルパスの区別（REQ-B）：以下のいずれかの場合、入力をパスとして扱います。(a) / または \ を含む、(b) .md / .txt / .xlsx / .csv / .docx で終わる、(c) Read() を介してディスク上の既存のファイルに解決される。それ以外の場合は、スコープテキストとして扱います — 「患者予約システム」のような複数単語の説明も含みます。

タイブレーカー： ルール (c) のみが一致する（/ または \ なし、認識された拡張子なし、ただし Read() が解決される）場合、かつ入力が 1 単語の場合は、パスとして扱う前にユーザーに確認します：「<入力> という名前のファイルが存在します。そのファイルを意味しましたか、それともスコープの説明ですか？」

Excel ソースの入力の場合、このスキルが実行される前に、ホスト LLM が行を作業用マークダウンバッファに書き写していることを想定します（バンドルは Excel を直接解析しません）。

ステップ 1a: レベルの分類（Classify the level）

探索モードの場合：

「これはユーザーニーズ（UN）、製品要件（PR）、またはソフトウェア要件（SR）のどれですか？」

レベルが判明したら、使用しないステップはスキップします。UN レビューはステップ 2、PR レビューはステップ 3 + エコーゲート、SR レビューはステップ 4～6 が必要です。

探索モードでのマルチレベル入力： ユーザーが 1 つを選択する代わりに UN+PR+SR セット（または複数レベルの任意の組み合わせ）を提供した場合は、マルチレベルレビューとして扱います — 提供されたレベルにわたってステップ 2～4 を順に実行しますが、探索ファイル書き込み規律を維持します（自動ディスク書き込みなし、結果をインラインで表示）。

文書モードの場合、ユーザーが別途指定しない限り、デフォルトでステップ 2～4 にわたって 3 つのレベルすべて（UN → PR → SR）を実行します。

ステップ 2: ユーザーニーズの作成（Write User Needs、UN-NNN）

明確なステークホルダーニーズごとに 1 つの UN を作成します。ルール：

技術に依存せず、ステークホルダーの視点で記述
平易なナラティブ（EARS 構文ではない）
問題文（2～3 文）+ ニーズ文を含める
traces_to::UN->Persona [<persona-id>] でペルソナをタグ付け
優先度：Critical | High | Medium | Low

フォーマットについては templates.md を参照してください。

ステップ 3: 製品要件の作成（Write Product Requirements、PR-NNN）

UN ごとに PR を導出します：

技術に依存せず、測定可能で、客観的
EARS 構文（12 のパターンについては ears-guide.md を参照）
各 PR は後方トレース：derived_from::PR->UN [UN-NNN]
各 PR は前方トレース：traces_to::PR->SR [SR-NNN]
すべてのハッピーパス PR には、少なくとも 1 つの If/Then（不要）PR コンパニオンが必要
同じ If/Then コンパニオンのルールがステップ 4 の SR レベルでも適用されます — すべてのハッピーパス SR には、実装レベルの回復を指定する If/Then SR コンパニオンが必要です
すべての EARS-N（否定/shall not）PR には、期待される正しい動作を指定する少なくとも 1 つの肯定的なコンパニオン PR（Ubiquitous、Event-Driven、または State-Driven）が必要です。同じルールが SR レベルでも適用されます

「ハッピーパス」の定義（REQ-E）：PR が肯定的な EARS パターン（Ubiquitous、Event-Driven、State-Driven、Optional、Complex、EARS-E、EARS-T、EARS-P）のいずれかを使用する場合、その PR はハッピーパスです。除外：Unwanted Behaviour、EARS-N（否定/shall not）、EARS-F（障害モード宣言）。

各 UN に対して逆方向的エラー分解（Adversarial Error Decomposition） を実行します：

それはどのように静かに失敗するか？
それはどのように騒がしく失敗するか？
それはどのように負荷の下で失敗するか？
それはどのように悪意の下で失敗するか？
それはどのように時間の経過とともに失敗するか？

各障害モードは、EARS If/Then PR（見出しに [ADV] をタグ付け、識別子は標準のまま、例：PR-007 [ADV]）になるか、別のリスクレジスタ用のメモになります。

作業例。 UN：「アップロードされたすべてのファイルを保存する」。障害モード：「ディスクの空き容量が不足すると静かに失敗する」。結果の PR：

### PR-007 [ADV]: ディスク圧力が高い場合にアップロードを拒否する
ディスクの空き容量が 5% を下回った場合、システムは新しいアップロードを HTTP 507 Insufficient Storage で拒否し、Retry-After ヘッダーを返すものとする。
derived_from::PR->UN [UN-001]
traces_to::PR->SR [SR-014]

障害モードが具体的かつ定量化されている（5%、HTTP 507、Retry-After）ことに注意してください — これにより PR が検証可能（C7）になります。

ステップ 4: ソフトウェア要件の作成（Write Software Requirements、SR-NNN）

PR ごとに SR を導出します：

実装固有：サービス、API、データベース、エラーコードに名前を付ける
特定のコンポーネント名を含む EARS 構文
各 SR は後方トレース：derived_from::SR->PR [PR-NNN]
各 SR は前方トレース：traces_to::SR->TC [TC-NNN]
関連する動作を単一の SR ID の下に統合するために句レベルの粒度（SR-NNN.c1、.c2）を使用する
すべてのハッピーパス SR には、少なくとも 1 つの If/Then（不要）SR コンパニオンが必要（「ハッピーパス」の定義についてはステップ 3 を参照）
すべての EARS-N SR には、少なくとも 1 つの肯定的なコンパニオン SR が必要

ステップ 5: フィールド仕様テーブル（Field Specification Tables）

データ入力/表示を伴う機能については、SR セクションにフィールド仕様テーブルを追加します：

フィールド ID	名前	ラベル	タイプ	最小	最大	単位	デフォルト	必須	UI 公開	検証ルール	エラーメッセージ	親 SR

UI 公開の値：editable | display-only | hidden。

ステップ 6: エコーゲート（Echo Gate）

各 SR 句について、1 行のテスト可能なアサーションを作成します：

VERIFY: [SR-NNN.c1] — [テスト可能なアサーションとしての要件の言い換え]

アサーションを作成できない場合、要件はテスト不可能です — 書き直してください。

ステップ 7: 完全性チェック（Completeness check）

作成完了を宣言する前に、completeness.md のチェックリストを実行します。

大規模入力の処理（Large input handling）

入力が約 200 のソースアイテムを超える場合（例：大規模な Excel の貼り付け）：

50 行のバッチに分割します。
各バッチについて： a. バッチを読み取ります。 b. 上記の手順に従って、マークダウンの UN/PR/SR に書き写します。 c. 作業ファイルに追加します（上書きしない）。 d. 進捗を報告：「バッチ / 完了。要件を件ドラフトしました。」
すべてのバッチの後、完全なファイルに対して完全性チェックを実行します。

バッチにあいまいな入力が含まれている場合は、続行する前に一時停止して明確化を求めます — 行を黙ってスキップしないでください。

出力パス（Output paths）

デフォルト：統合 UN/PR/SR の場合は ./requirements/SPECIFICATION.md。ユーザーは上書きできます。

既存のファイルを更新する場合、既存の ID を保持し、次の連番で新しい ID を追加します。

相互参照構文（Cross-reference syntax、チートシート）

relation_type::SOURCE->TARGET [ID-list]

タイプ	方向	使用目的
`traces_to`	前方	UN→PR、PR→SR、SR→TC、UN→Persona
`derived_from`	後方	PR→UN、SR→PR、TC→SR
`validates`	検証	TC→SR
`mitigates`	リスク制御	SR→RISK
`conflicts_with`	矛盾	any→any

識別子フォーマット（Identifier format）

正規表現：^(UN|PR|SR|TC)-\d{3}(\.[A-Z])?$

基本 ID：UN-001、PR-001、SR-001
サブ ID（EARS-P 表形式）：PR-010.A、PR-010.B
句表記：SR-001.c1、SR-001.c2

参照ファイル（Reference files）

ears-guide.md — 12 の EARS パターン
templates.md — UN/PR/SR セクションのマークダウンテンプレート
completeness.md — 出口チェックリスト（UN→PR→SR カバレッジ）

AOR 要件作成スキル