write-requirements

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

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

Tier-1 ミニ仕様 — すでに承認済みの機能に対する修正と、その修正を保護するガードです（amend または debug から来た場合）。新しい requirements.md は作成しません。対象機能の requirements.md（機能がない場合は docs/specs/fixes.md）に追記します。

• 修正要件 — 修正後の動作を示す、Step 2 の形式による EARS 基準を 1 つ。
• SHALL CONTINUE TO ガード — 修正によって壊してはならない動作を示す、Step 3 のガード。

追記したこの 2 つの基準のみを自己レビューします。曖昧さとテスト可能性を確認し、基準がシステムの現在の動作をどう実現しているかを主張する場合に限り、コード主張の確認（Step 5）も行います。通常、ガードはこれに該当します。追記した 2 つの基準を承認に回し、機能の Status は維持して、tdd に進みます。Step 1 と Step 4、およびファイル全体のレビューは省略してください — 新しい機能コード、Out-of-Scope セクション、ファイル全体の自己レビューが必要なのは、新機能の場合であり、2 行のミニ仕様ではありません。

新機能 — tier 2、または仕様がまだ作成されていないものです。スキルセットの templates/requirements.md を使ってください。プラグインとしてインストールされている場合は templates/ を ${CLAUDE_PLUGIN_ROOT}/templates として解決し、それ以外の場合はこの SKILL.md からの相対パス ../../../templates として解決します。テンプレート内のすべての見出しは必須の項目です。各項目を埋めるか、その下に None と記入してください。削除してはいけません。その後、以下の手順をすべて実行します。各手順の ToDo を作成してください。

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

短く一意なプレフィックスを選びます（2～12 文字、A～Z0～9、先頭は英字。例：SHELL、SYNC2）。docs/specs/INDEX.md を確認し、要件を書く前に行を追加します。廃止済みのコードは再利用しないでください。

ロードマップ項目を紐付ける。 docs/roadmap/INDEX.md が存在し、この作業がその項目のいずれかを実装する場合は、その項目の ROAD-N を行の Roadmap item 列に記録します。ロードマップがない場合、または作業がロードマップの項目として計画されていなかった場合は、— と記入し、それ以外は変更せずに機能を登録します。この列は計画と仕様を結び付ける唯一のリンクで、この手順でのみ記入します。ROAD-N をここで新たに作成してはならず、既存のものを参照するだけです。 完了条件： INDEX.md にコードの行があり、ステータスが Draft で、Roadmap item のセルに ROAD-N または — が記入されていること。

Step 2: ストーリーと EARS 基準を書く

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

各動作ストーリーには、次の内容を含めます。

**Story:** As a <actor>, I want <capability>, so that <benefit>.

**Story:** の行には、ストーリーの実装後に人が実行または確認できるデモ可能な行為を 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 つに分けます。基準数に上限はありません — 規模は後で、EARS 行の数ではなく、plan/execute の事前確認時にタスクファイルのパスから把握できます。 完了条件： すべてのストーリーに基準が 1 つ以上あり、各基準が WHEN／WHILE／IF／WHERE／常時成立の形式をちょうど 1 つ含み、各 **Story:** がデモ可能な行為を 1 つ示していること。

Step 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）、キーボードおよびスクリーンリーダーのサポート。

該当するものはそれぞれ、測定または確認が可能な目標と、その検証方法の両方を明記した EARS 基準（ステップ 2 の形式）として記述し、振る舞いの基準と同じようにタスクやテストまで追跡できる階層的な **CODE-N.M** ID を付けてください。例：

• **CODE-3.1** WHEN the notes list renders 1,000 items THE SYSTEM SHALL paint the first screen within 200 ms at p95 — verified by a CI performance trace.

該当しない品質特性を黙って省略してはいけません。短い理由を添えて None と記録してください（例：「アクセシビリティ：None — ヘッドレス CLI」）。こうすることで、見落としではなく、意図的な判断であることが明確になります。

このカテゴリは追加的なものであり、新たなゲートではありません。品質特性に関する懸念がない機能は、4 つすべてを None と記録します。その場合も、振る舞いの基準、構造、2 つの作成モードに変更はありません。NFR は品質に関する懸念を明らかにするものであり、それを満たすことを必須条件とするものではありません。ティア 1 のミニ仕様モードでは、修正自体が品質特性の変更にあたる場合に限り、NFR を記録します。このカテゴリによって、振る舞いに関するミニ仕様に NFR の義務が追加されることはありません。 完了条件： NFR セクションに **Section-kind:** nfr があり、4 つの品質特性それぞれについて、ID 付きの NFR 基準または明示的な None のいずれかが記載されていること。

Step 3：既存の振る舞いを保護する

変更が触れるファイルをすべて列挙し、そのリストに沿って作業します。既存の振る舞いが損なわれるリスクのないファイルには、明示的に no behavior to guard と記し、それ以外は何も追加しません。その他のファイルにある既存の振る舞いには、それぞれガードを追加します。 **CODE-N.M** (guard) WHEN <condition> THE SYSTEM SHALL CONTINUE TO <existing behavior> ガードは、誰も言及していないものの基盤となる振る舞いをエージェントが壊すのを防ぎます。ティア 1 のバグ修正では、このステップと修正要件 1 つが仕様となり、「2 つのモード」で指定された配置先に追記されます。 完了条件： 変更が触れるファイルがすべて列挙されていること。それらのファイルで見つかった既存の振る舞いそれぞれに、専用のガード要件があること。既存の振る舞いがないファイルには、明示的に no behavior to guard と記載されていること。リストを伴わない空のガード一覧は条件を満たしません。

Step 4：対象外

この機能が意図的に行わないことを列挙します。このセクションは、実装やレビュー中にスコープが拡大するのを防ぎます。

ステップ 5：自己レビューしてから承認ゲートへ

ユーザーに見せる前に自己レビューします。

• 曖昧さの確認： 基準を2通りに解釈できる可能性はありませんか？ 解釈を1つ選び、明記してください。
• テスト可能性の確認： 各基準を自動テストまたは具体的な手動チェックで検証できますか？ できないものは書き直してください。
• プレースホルダーの確認： 「TBD」「etc.」「handle errors appropriately」がないことを確認してください。
• コードに関する主張の確認（独立して実施）： 基準にシステムの現在の動作（データ形式、既存の挙動、制約など）についての主張が含まれている場合は、レビュー用サブエージェントを起動し、実際のコードに照らして各主張を検証してください（ファイルを grep/read し、file:line を引用し、当てはまらないものがあれば指摘します）。調査結果は .skills/<slug>-req-review.md に記載してください。ここでの誤った前提（たとえば「本文は ProseMirror-JSON である」が、実際には Markdown である場合）は、設計、計画、コードを台無しにします。ゲートに進む前に基準を修正してください。自分でコードを読んではいけません。（サブエージェントがいない場合は、自分でコードを確認してください。）

ストーリー品質ゲート（デモ可能な行為の確認）。 手順：

1. NFR 以外の ## N をすべて列挙し、それぞれの **Story:** の行を示します。
2. 各項目が1つのデモ可能な行為を示しているか、ユーザーに確認を求めます。
3. いずれかが不適合の場合は分割または書き直して、再提示します。すべて確認された場合はファイルの承認後に Status: Approved に設定できます。
4. 無言で承認してはいけません。各ストーリーについて個別に確認されていない「問題なさそうです」は、確認とはみなしません。

その後、レビュー用にファイルをユーザーに提示し、作業を停止します。会話上の合意だけを根拠に設計へ進んではいけません。承認されるのは、文書化された要件です。（ストーリー品質の確認を含めて）承認されたら、Status: Approved に設定してください。 完了条件： ユーザーが文書化されたファイルを承認し、行動を示す各ストーリーが1つのデモ可能な行為であることを確認していること。

ID の不変性

Status が Approved になった後は、ID の意味を変えたり、番号を振り直したりしてはいけません。 要件を廃止する場合は、取り消し線で示します（~~**CODE-1.2**~~ superseded by CODE-1.4）。trace チェックでは取り消し線付きの ID は未定義として扱われるため、それを参照するテストやタスクがすぐに明らかになります。

終了

必須サブスキル：write-design（tier 2）を使用するか、tier-1 の修正内容を新しい ID とともにそのまま tdd に渡してください。