specify-behavior

承認済みのフレーム変更の結果から、docs/specs/<YYYY-MM-DD>-<feature>/requirements.md を作成します。要件は、意図を永続的に記録する情報源です。この会話が終わった後も残り、すべてのタスク、テスト、コミットで要件 ID を参照します。

2 つのモード — 渡された内容に応じて選択

Tier-1 ミニ仕様 — すでに承認済みの機能に対する修正とガードです（amend-feature または root-cause によるもの）。新しい requirements.md は作成しません。対象機能の requirements.md（または機能に属していない場合は docs/specs/fixes.md）に、修正要件（EARS 基準を 1 つ、Step 2 の形式）と、その**SHALL CONTINUE TO ガード**（Step 3、修正によって壊してはならない動作）を追記します。

この 2 つの基準だけをセルフレビューします。曖昧さとテスト可能性の確認に加え、基準がシステムの現在の動作を主張している場合に限り、コード主張の確認（Step 5）も行います。通常、ガードはこれに該当します。両方を承認用に提示し、機能の Status はそのままにして、test-first に進みます。Step 1 と Step 4、およびファイル全体のレビューは省略します。これらは新機能用であり、2 行のミニ仕様には適用されません。

新機能 — tier 2、またはまだ仕様が作成されていないものです。templates/requirements.md を起点とし、パックシードを次の順序で解決します。最初に存在するパスを使用します。SKILL.md と同じ階層の templates/、設定されている場合は ${CLAUDE_PLUGIN_ROOT}/templates、それ以外の場合は SKILL.md からの相対パス ../../../templates です。このテンプレートのすべての見出しは必須項目です。各項目を記入するか、None と記載します。項目を削除してはいけません。その後、以下の全手順を 1 ステップにつき 1 つの todo として実行します。

Step 1: 機能コードを登録する

短く一意なプレフィックスを選びます（2～12 文字、A～Z または 0～9 で構成し、先頭は英字。例：SHELL、SYNC2）。カタログは共有されています。docs/specs/INDEX.md がドメインルーターで、機能カードは docs/specs/catalog/<domain>.md にあります。要件を書く前に、対象のシャードにカードの行を追加します（そのドメインのルーター行が存在することも確認してください）。INDEX 自体には Code の行を追加してはいけません。廃止済みのコードを再利用してはいけません。INDEX がフラットな場合は、作業を中断し、/map-features のドメイン境界への移行を明示します。

ロードマップ項目を紐付ける。 docs/roadmap/INDEX.md が存在する場合は、このファイルと同じ階層にある roadmap-bind.md を読み、その指示に厳密に従います。シャードの行にある Roadmap item 列だけを、計画と仕様の紐付けに使用します。ロードマップが存在しない場合、または作業がロードマップ項目ではなかった場合は、— と記載します。

一時ファイルを昇格する。 この作業に .skills/_pending-<slug>/ ディレクトリを使用した場合は、.skills/<CODE>/ に移動します（CODE ディレクトリが存在しない場合は mv を使用）。以降の書き込みでは Feature ルートを使用してください。詳しくは templates/skills-ephemera-paths.md を参照してください。 完了条件： コードが対象のシャードに Draft カードとして登録され、Roadmap item のセルに ROAD-N または — が記載され、その ROAD が別の CODE にすでに紐付けられていないこと。

ステップ 2：ストーリーと EARS 基準を記述する

ユーザーストーリーごとに ## N. <title> セクションを 1 つ設け、階層 ID **CODE-N.M** を付けた EARS 形式の受け入れ基準を記述します。N はストーリー番号です（## N 見出しと同じ N）。この対応関係は重要です。後続のスキルは、これをもとにレビュー単位を導き出します。

各行動ストーリーには **Story:** 行を含めます。形式は As a <actor>, I want <capability>, so that <benefit>. です。この行では、ストーリーが実現した後に人が実行または実証できるデモ可能な行為を 1 つ示す必要があります。技術レイヤー（「ストレージレイヤーを書き換える」など）を記述してはいけません。

EARS 形式：

• WHEN <event> THE SYSTEM SHALL <behavior> — イベント駆動
• WHILE <state> THE SYSTEM SHALL <behavior> — 状態駆動
• IF <unwanted condition> THEN THE SYSTEM SHALL <behavior> — エラー処理
• WHERE <feature enabled> THE SYSTEM SHALL <behavior> — オプション機能
• THE SYSTEM SHALL <behavior> — 常に成立する不変条件

基準ごとに、観測可能な動作を 1 つ記述します。文に「and」が必要な場合は、通常、基準を 2 つに分けます。1 つのルールが複数の入力（フィールドリストやデフォルト値のセットなど）に適用される場合、入力ごとに 1 つの基準を設けるのではなく、対象をすべて列挙した 1 つの基準にします。入力ごとの ID は、後続工程で入力ごとのテストになります。基準数の上限はありません。規模は EARS 行を数えるのではなく、計画／実行の事前確認時にタスクファイルのパスから後で把握できます。 完了条件： すべてのストーリーに 1 つ以上の基準があり、各基準に WHEN／WHILE／IF／WHERE／ユビキタス形式のいずれかがちょうど 1 つ含まれ、各 **Story:** にデモ可能な行為が 1 つ記述されていること。

ステップ 2b：非機能要件（品質属性）

行動基準（ステップ 2）はシステムが「何を」するかを示し、非機能要件（NFR）はシステムが「どの程度うまく」それを行うべきかを示します。明記されていない品質属性が、機能の失敗につながることも少なくありません。行動基準の後に、テンプレートの NFR セクション（templates/requirements.md にあらかじめ記載）を埋めてください。

## <N>. Quality attributes
**Section-kind:** nfr

SECTION-KIND IRON LAW
- NFR section MUST carry **Section-kind:** nfr (pre-printed in the template —
  do not delete it).
- absent = story  (unmarked section is a behavioral review unit)
- Fail visible: unmarked NFR → extra unit in preflight.
- Fail silent (forbidden): marking a real story nfr → boundary disappears.

次の 4 つの品質属性を確認します。

• パフォーマンス — レイテンシ、スループット、リソース上限。
• セキュリティ — 認証／認可、データ保護、越える信頼境界。
• 信頼性 — 可用性、エラーバジェット、復旧、耐久性。
• アクセシビリティ — 適合目標（例：WCAG 2.1 AA）、キーボード／スクリーンリーダーのサポート。

NFR の根拠となるシステムドキュメント（簡易参照）

この機能において属性が重要な場合（None とする予定ではない場合）は、このファイルと同じ場所にある nfr-grounding.md を読み、記載内容に厳密に従ってください。属性ごとに参照するシステムドキュメント、その内容より優先される厳格な制約、参照後の記述ルールを確認します。Approved ドキュメントに太字の定義がない限り、TB／THR／CMP／SLO（またはプロダクト指標）の ID を創作してはいけません。

適用されない属性も、黙って省略してはいけません。短い理由を添えて None と記録します（例：「アクセシビリティ：None — ヘッドレス CLI」）。これにより、見落としではなく、意図的に除外した判断であることが明確になります。None は重要でない属性に対して使うものであり、属性が重要な場合に参照を省略するための近道ではありません。

この分類は追加的なものであり、新たなゲートではありません。品質属性に関する懸念がない機能は、4 つすべてに None を記録します。tier-1 モードでは、修正自体が品質属性の変更である場合に限り、NFR を記録します。

完了条件： NFR セクションに **Section-kind:** nfr が含まれ、4 つの品質属性それぞれについて、ID 付きの NFR 基準、または理由を添えた明示的な None が記載されていること。また、重要な属性すべてについて、記述前に参照結果（使用した Approved ドキュメント、または Absent／非権威的なため対応不要）を記録していること。

ステップ 3：既存の動作を保護する

変更が触れるファイルをすべて列挙し、そのリストに沿って作業します。既存の動作が損なわれるリスクのないファイルには、明示的に no behavior to guard という行だけを記載します。それ以外のファイルにある既存の動作ごとに、保護要件を追加します。 **CODE-N.M** (guard) WHEN <condition> THE SYSTEM SHALL CONTINUE TO <existing behavior>。 保護要件は、誰も言及していないものの、変更すると基盤となる動作を壊してしまうような箇所を、エージェントが壊すのを防ぎます。tier-1 のバグ修正では、このステップと修正要件 1 つが仕様となり、「2 つのモード」に記載された出力先に追記されます。 完了条件： 変更が触れるすべてのファイルが列挙されていること。それらのファイルで確認された既存の動作ごとに、個別の保護要件があること。該当する動作がない各ファイルには、明示的に no behavior to guard という行が記載されていること。リストがない状態で保護要件が空でも、完了とはみなしません。

ステップ 4：対象外

この機能で意図的に実装しないことを列挙します。このセクションは、実装やレビュー中のスコープクリープを防ぐためのものです。

ステップ 5：セルフレビューを行い、承認ゲートに進む

ユーザーに提示する前に、セルフレビューを行います。

• 曖昧さの確認： 各基準が複数の解釈をされる可能性はありませんか？解釈を 1 つ選び、明記します。
• テスト可能性の確認： 各基準は、自動テストまたは具体的な手動チェックで検証できますか？できない基準は書き直します。
• プレースホルダーの確認： 裸の「TBD」、「etc.」、「エラーを適切に処理する」といった記述を残してはいけません。clarify-decisions の完了パッケージに Owned unknowns が記載されている場合、それらを topic — owner — date — forbid-guess（cấm đoán）の形式で「未解決の質問」に貼り付けます。これら 3 つのフィールドがない裸の TBD があると、Status: Approved にできません。未解決事項を隠すために「未解決の質問」を削除してはいけません。
• コードに関する主張の確認（独立）： 現在のシステムの動作について主張する基準がある場合は、このファイルの隣にある self-review-conditional.md を読み、その記載に厳密に従います。ゲートの前に、実際のコードに照らして主張を検証するレビュー用サブエージェントをディスパッチしてください。ここに誤った前提があると、設計、計画、コードが損なわれます。
• 完了パッケージの取り込み： clarify-decisions の完了パッケージがある場合は、このファイルの隣にある self-review-conditional.md を読み、その記載に厳密に従います。完了パッケージですでに確定した NFR を None とする理由にしてはいけません。

ストーリー品質ゲート（デモ可能なアクションの確認者）。 NFR ではない ## N をすべて列挙し、それぞれの **Story:** 行とともに、各ストーリーがデモ可能なアクションを 1 つだけ示していることをユーザーに確認してもらいます。満たさないものは分割または書き直して、再提示します。すべて確認され、ユーザーがファイルを承認した場合にのみ、Status: Approved に設定できます。暗黙の承認は決して行ってはいけません。ストーリーごとの明示的な「はい」を伴わない「問題なさそうです」は、確認とはみなしません。

その後、FILE をユーザーに提示してレビューを受け、停止します。会話上の合意を根拠に設計へ進んではいけません。承認の対象となるのは、文書化された要件です。 完了条件： ユーザーが文書化されたファイルを承認し、各動作ストーリーがデモ可能なアクション 1 つであることを確認していること。

ID の不変性

承認後は、ID の意味を変更したり、番号を振り直したりしてはいけません。廃止する場合は、取り消し線を付けます （~~**CODE-1.2**~~ superseded by CODE-1.4）。audit-trace は取り消し線付きの ID を未定義として扱うため、それを参照するテストやタスクはすぐに表面化します。

終了

必須のサブスキル：design-solution（tier 2）を使用するか、tier-1 の修正を新しい ID とともに test-first に直接引き渡します。