specification

仕様：会話こそが成果物

仕様は文書ではありません。仕様とは、関係者同士の会話を通じて共通理解を築くことであり、書き上げられたものは、せいぜい本当に必要なものについての有識者による推測にすぎず、現実が最終判断を下すまで磨き続けられます（Gorman）。価値があるのは計画そのものではなく、計画を立てることです。会話を省いてエージェントに「仕様を書いて」と頼んでも、要点をすべて見落としてしまいます。このスキルは、まずあなたと、次に答えを知る人間同士で、会話を必ず行わせるためにあります。

位置づけ：story-splittingより前、planningより前、受け入れテストが作られるより前です。このスキルの出力は、そのすべてに引き継がれます。

リソース	次の場合に読み込みます…
spec-review-template.html	責任を持つ人間によるレビューに向けて、完成したマップを提示するとき
references.md	ここで教えるプラクティスの情報源を確認するとき

---

約束事

1. まずストーリーの置き場所を確認します。 このストーリーがどこにあるかを尋ねます。イシュー、docs/stories/配下のファイル、チケットなど、チームがすでに管理に使っている場所でかまいません。このスキルで作成するものはすべて、その成果物に書き戻します。まだ置き場所がなければ、どこに置くべきかを尋ねます。別のルールを黙って勝手に作ってはいけません。
2. 質問は一度に一つだけにします。 質問票にはしません。判断の重要性を伝え、「保留にする」という選択肢も認めます。保留にした質問には担当者と日付を設定し、放置してはいけません。リポジトリ内の根拠や、把握しているトレードオフに基づいて答えを推奨できる場合に限り、推奨します。それ以外は中立的に尋ね、暫定的な仮説があればその旨を明記し、決定権を持つ人の判断を誘導しないようにします。
3. 重要な前提はすべて質問にします。 人間から示されていない結果を自分で決めていると気づいたら、その時点で立ち止まって質問します。答えによってマップが変わらない質問は、真の決定事項ではありません。
4. マップはデータであり、文章ではありません。 作業しながらマップを作成し、見える状態にしておきます。

story:     <one line, in the words the human used>
rules:     # business policies / acceptance criteria
  - rule: <policy in domain language>
    examples:
      - <concrete: real values, real outcome — never a restatement of the rule>
    questions: # open assumptions attached to THIS rule (optional); parked items include owner and decision/review date
questions: # cross-cutting open assumptions; parked items include owner and decision/review date
acceptance criteria: # distilled from rules once examples stabilise
candidate terms:     # vocabulary the conversation coined or contested

5. マップをそのまま信頼せず、検証します。 各ルールについて、反例を問う質問（「この例の結果が異なるとしたら、何が真である必要があるか？」）、ゼロ・一・複数、境界、失敗時の動作を確認します。例が一つしかないルールは推測です。例がすべて一致するルールは仮説です。
6. マップの形を診断材料として読み取ります。 質問が多い場合は、構築に着手する準備ができていません。話し合いを続けるか、担当者を決めて保留し、作業を止めます。ルールが多い場合（およそ6つを超える場合）は、大きすぎます。マップをstory-splittingに渡します。具体例が各ルールに含まれていてバランスが取れていれば、準備完了です。

推奨する進め方：下書きの作成と責任者によるレビュー

上記のエージェントが進行する会話によって、共有された理解の初稿が作成されます。この内容は、成果に責任を持つ人々がレビューして初めて利用可能になります。作業に応じてレビューグループを選びます。リスクの低いローカルな変更なら単独の担当者で十分な場合がありますが、共有される動作、規制対象の動作、取り消せない動作、または複数分野にまたがる動作には、影響を受けるビジネス、開発、テスト、セキュリティ、運用、デザインの視点が必要です。意図的に含めなかった重要な視点と、その理由を記録してください。

推奨する複数ラウンドの進め方：

1. ラウンド 1（エージェントが進行）：アイデアを持ち込んだ人とともに、上記の進め方で契約を実行します。マップをストーリーの成果物に書き戻します。そこからレビュー用ページ（下記）を生成します。
2. ラウンド 2（責任を持つ人々）：レビュー用ページを担当者と、リスクに関連する視点を持つ人々に渡します。共有されるプロダクトの動作には、三者（ビジネス、開発、テスト）での会話が有効な既定の方法ですが、あらゆる小さなタスクで形式的に実施するものではありません。レビュー担当者はページに注釈を付けます。意見の相違は黙って編集するのではなく、新たな質問として扱います。
3. ラウンド 3 以降（調整）：フィードバックを回答と新たな赤カードとしてエージェントのラウンドに戻します。マップと成果物を更新し、ページを再生成します。新しいルールも、変更された例も、新しい質問も出なくなるまで繰り返します。
4. その後、分割：安定したマップを story-splitting に渡します。各子ストーリーはルールと例を引き継ぎます。ルールごとの質問は、後続のマッピングで想定される単一の質問リストにまとめます。また、受け入れテストの外側ループが導入されている場合は、それらの例が各スライスのマッピングの出発点になります。

最終的な判断を下すのは、依然として現実です。ここに記述した受け入れ基準は、リリースしたスライスで確認されるまでは仮説にすぎません。現実と食い違った場合は、会話を再開します。これは仕様の失敗ではなく、この手法の特長です。

レビューページ

ラウンド 2 では、resources/spec-review-template.html から自己完結型のページを 1 つ生成します。JSON データ欄に値を入力し、二重アンダースコアの REVIEW_DATA トークンが現れる箇所をすべて置き換えます（文字列値に含まれる < はすべて \u003c にエスケープします）。一時ディレクトリに保存し、ローカルで開き、生成したページは決してコミットしないでください。データは、1 つのカードエンジンを共有するセクションとして構成します。ルールセクションでは、ルールごとに 1 枚のカードを作成します。ルールをカード名に、具体例をプレーンテキストに、関連する質問をハイライト行にし、マップの該当箇所をそのまま折りたたみ可能な領域に表示します。保留中の質問セクションでは、質問を名前に、担当者、判断日／レビュー日、背景情報をプレーンテキストにします。候補用語セクションでは、用語を名前に、1 行の説明をプレーンテキストにします。どのカードにもコメントを付けられます。フィードバックのコピー機能は、すべての注釈を 1 つの Markdown ブロックにまとめ、次のラウンドに戻します。このページは会話の成果物であり、承認記録ではありません。各ラウンドで自由に再生成してください。

用語の記録

仕様についての会話では、絶えず新しい用語が生まれます。それこそが会話の価値の半分です。会話の中で生み出された用語、異論が出た用語、または異なる 2 つの意味で使われた用語はすべて、1 行の説明を添えて candidate terms に記録します。ubiquitous-language スキルが導入されている場合は、候補を 1 つずつ 5 段階の言語プロトコルにかけます（抽出では候補を集め、採用するのはプロトコルのみです）。導入されていない場合も、命名についての会話がどこかで行われるよう、候補リストをストーリーとともに引き継ぎます。

境界

状況	スキル
あいまいな決定木、成果物はまだなく、選択肢を絞り込んでいる	インストールされていれば grill-me、そうでなければこのスキルの一問プロトコル
穴を突く必要がある既存のストーリー・計画・仕様	find-gaps
合意したマップが大きすぎる。子ストーリーへの分割	story-splitting
子ストーリーを PR サイズの計画に変換する	planning
振る舞いと制約が安定した後に、ライブラリ、ツール、アプリケーション、サービス、プラットフォームプリミティブ、またはオーダーメイド実装を比較する	evaluate-existing-solutions
スライスごとの実行可能な仕様（インストールされている場合）	acceptance-testing
会話から浮かび上がった語彙に名前を付ける（インストールされている場合）	ubiquitous-language

検証チェックリスト

• ストーリー成果物の置き場所は仮定せず確認した。すべての出力はそこに書き戻された
• 質問は一度に一つずつ行った。推奨は、証拠または既知のトレードオフがそれを正当化する場合にのみ示された
• すべてのルールに少なくとも一つの具体的な例がある（実際の値、実際の結果）
• 各ルールは反例の挑戦に耐えた
• 保留にした質問には担当者と決定・レビューの日付がある
• 候補となる用語を記録した（インストールされている場合は言語プロトコルにルーティングした）
• 説明責任を持つ担当者がページをレビューした。リスクに関連する観点が参加した、またはその不在が記録された
• フィードバックは回答・質問として返され、無言の編集として返されることはなかった
• マップの形を確認した。質問偏重でもルール偏重でもなく、例は具体的である