authoring-feature-spec

authoring-feature-spec — SKILL.md

バリアント： standard · 使用するタイミング： PRDで挙げられた機能を、後続のビルドを計画・検証できる水準まで、包括的でテスト可能な機能仕様に具体化するとき。新規開発、または承認済み仕様のバージョン管理された改訂に使用します。

概要

このスキルは、優れた機能仕様を書くための 方法、つまりPRDの下位に位置するレイヤーです。PRDでは製品が何をするか、そしてなぜそうするかを説明し、機能を列挙します。機能仕様では、列挙された各機能がどのように動作するかを、実装とテストに十分な詳細で記述します。このスキルが扱うのは、作成者の判断力、すなわち調査方法と品質基準であり、セクション一覧ではありません。ここでは、セクションの構成を提供する機能仕様テンプレートツールと、各機能を根拠に基づいて記述するための詳細調査機能という、2つの協力者を前提とします。作成者に渡されるのは、承認済みのPRD（および上流の関連情報）であり、その機能を分解して具体化しなければなりません。汎用的な定型文を出力してはいけません。満たすべき基準は、各機能が実装可能かつテスト可能であることです。つまり、エンジニアは作成者に確認せずに実装でき、テスターは作成者に確認せずに検証でき、計画担当者はその仕様からタスクを切り出せる必要があります。

手法の骨子は、優れた機能仕様と変わりません。このバージョンでは、曖昧さのない動作の記述方法（EARS、ユースケースフロー、要件の問題点カタログ）をさらに掘り下げ、状態遷移表と判断表を明示し、機能ごとの非機能要件に関する規律とアーキタイプ別の補足（機能の性質によって重点が変わります）を加え、確率的／ML機能にも対応します（「動作する」ではなく、しきい値による基準を定めます）。さらに、承認済み仕様を変更する一般的なケースに対応する改訂方法も追加します。

使用を開始するタイミング

• 一連の機能が定義された承認済みPRDから、機能仕様を作成するとき。
• 1つの機能（または明確に範囲を限定した複数の機能）を、テスト可能な動作、入出力、状態、エッジケース、受け入れ基準に具体化するとき。
• 承認済みの機能仕様を改訂するとき（差分：機能、動作、AC、または状態が変更・追加される場合）。既存の仕様と変更依頼が渡されます。
• 調査済みで、各機能について必要な判断がすべて済んだ内容を、機能仕様テンプレートに記入するとき。

次の場合は使用しないでください：

• PRDそのもの（課題、ユーザー、指標、MVPの範囲）を作成するとき → PRD作成スキルを使用してください。ここではPRDは上流からの入力です。
• 完成済みの機能仕様をレビューまたは評価するとき → 機能仕様レビュー用スキルを使用してください。
• エンジニアリング設計書（ADR、RFC、アーキテクチャ）を作成するとき。これはこのレイヤーの下流にある、コードでどのように実装するかのレイヤーです。

入力

渡されたすべてのドキュメント、つまり depends_on セット（上流ドキュメントのうち、ディスカバリーによってこのドキュメントに関係すると判断されたもの）を読み、このドキュメントの内容がそれらに基づいていることを確認してください。通常、上流ドキュメントは承認済み PRDです。UI機能の場合は、ユーザーフロー／ワイヤーフレーム／デザインシステムも渡されることがあります。データ／ML機能の場合は、データ仕様が渡されることがあります。これらは手法のガイダンスであり、固定された上限ではありません。自己完結型にしてください。実際に受け取ったコンテキストをもとに作成し、想定される関連ドキュメントがない場合は、手元にある情報で進め、穴埋めのために内容を捏造するのではなく、その不足を明示的な前提として示してください。また、利用可能な場合はリサーチ機能（deep-research）を使い、テンプレートを埋めるだけでなく、包括的なドキュメントを作成してください。改訂の場合は、既存の仕様書と変更リクエストも追加で渡されます（波及範囲の確認が必要な場合は、関連する下流ドキュメントも渡されます）。

機能コンテキスト（提供される場合）： 呼び出し元から capability_record（capability-map.yaml product_capabilities のレコード）が渡された場合は、Step 1 の前にそれを読んでください。ここではスコープの境界が定義されています。owns は対象とするエンティティ、refs は所有せず参照するエンティティ、publishes／consumes は公開するイベント、entry_points／exit_points はユーザーの開始地点と終了地点、has_ui／has_api／has_persistence は該当するサーフェスを示します。提供されている場合は、これを厳格な制約として扱い、定義された境界から逸脱しないでください。

ワークフロー

Step 1: テンプレートツールから構成を取得する — アウトラインを独自に作らない

機能仕様書のテンプレートツール（包括版）からセクション構成を取得してください。ここでセクション一覧を再掲したり、再構成したりしないでください。このスキルが提供するのは、それらのセクションを適切に埋めるための手法です。包括版テンプレートには、機能ごとのブロックが繰り返し含まれ、バージョンヘッダー、動作（判定テーブルを含む）、I/O とデータ契約、状態遷移テーブル、エッジケース、エラー処理、受け入れ基準、非機能要件のセクション、依存関係、未解決の質問、バージョン管理／変更履歴のセクションがあります。テンプレートが利用できない場合は、包括的な機能仕様書の構成を入手（依頼して作成するか、標準的な機能ごとの構成を使用）してから進めてください。**適切な分量：**テンプレートは包括的ですが、記入内容は機能に応じた分量にしてください。簡素な機能であれば、状態テーブル、判定テーブル、NFR、変更履歴が空欄でも問題ありません。

capability_record がある場合、仕様書では scope の記述全体、すべての owns エンティティ、すべての publishes／consumes イベントを必ず扱ってください。refs エンティティや、depends_on にある機能に属する内容は扱わないでください（それぞれ別の機能仕様書で扱います）。

Step 2: PRD を読み、機能一覧に基づいて網羅性を確保し、各機能のアーキタイプを特定する

承認済み PRD と、そこから参照される上流ドキュメントを読みます。これらは入力情報であり、白紙から始めるわけではありません。PRD に記載されたすべての機能を列挙してください。この一覧が網羅性を確認するチェックリストになります。PRD を機能ごとの仕様書に分解し、各機能にそれぞれ専用のブロックを設けてください。各機能のアーキタイプ（UI・REST/API・データ ML・バッチ／非同期ジョブ・インテグレーション／Webhook・CLI。複数に該当する場合もあります）を明示してください。アーキタイプによって、どのセクションを重視するかが変わります（Step 4）。機能のドラフトを作成する前に、その機能固有の動作に関する知識の不足を補ってください。PRD の記述が不十分な場合は、情報不足を明示的な未解決の質問または明記した前提として示し、曖昧なまま一般化しないでください。PRD にある機能について、信頼できる形で詳細を説明できない場合は、動作を捏造せず、ブロッカーとして示してください。

Step 3: 各機能の根拠となるリサーチを行う

リサーチを行い、この製品固有の領域における根拠に基づいて、各機能の動作、ドメインルール、エッジケースを確認してください。「機能仕様書全般」について調べるのではありません。リサーチ機能を利用できない場合は、動作、制限、エラーコードを捏造しないでください。ビルド前に検証する必要がある前提として、明示的に示してください。

Step 4: 機能ごとの手法を適用する

テンプレートの機能ごとのセクションに、この方法で内容を記入します。機能ごとに繰り返し、簡素な機能では不要なセクションを折りたたみます（状態がない場合は、状態テーブルは不要です）。各観点の詳しい内容は references/ にあります。セクションで詳細な説明が必要になったら、読み込んでください。

• 目的とPRDへのトレース — この機能が担う1つの役割を示し、特定のPRD要件／目標／指標に結び付けます（前方・後方のトレーサビリティ）。対応するPRD項目がない機能はスコープクリープであり、対応する機能がないPRD項目はカバレッジギャップです。該当するPRD項目を正確に引用／参照します。
• 動作とインタラクション — システムの応答を、観察可能で、実装方法に依存しない形（「どのように」ではなく「何を」）で説明します。主な成功シナリオを約3～11ステップで記述します（各ステップは「アクターがXを行う → システムがYを返す」）。次に、代替フロー（別の経路でも目標が達成される場合）と、例外フロー（目標が達成されない経路。各フローで処理方法を明記）を記述します。各動作の記述には、できるだけEARS形式を使います（「<trigger>の場合、システムは<response>する」「<state>の間は……」「<unwanted condition>の場合は、……する」）。動作を最小単位に分け、受け入れ基準と1対1で対応付けやすくなります。各ステップをたどり、「ここで何が失敗／変化しうるか」と考えて、エッジケースを洗い出します。references/requirement-and-behavior.mdを参照してください。
• 決定表（組み合わせルール） — 応答が複数条件の組み合わせに依存する場合、条件 × ルール → アクションの表で指定し、すべての組み合わせに対するアクションを定義します。これにより、ルールの欠落や矛盾が明らかになります。（補助的な手法です。動作に組み合わせが関係しない場合は省略します。）
• 入力／出力とデータ — すべての入力（ソース、型、検証ルール、必須／任意）と出力（応答形式、副作用、エラーコード）を列挙し、呼び出し側が検証するための契約として記述します。各入力について「有効な値、無効な値、境界は何か」を確認し、各出力について「呼び出し側／UIから何が見えるか」を確認します。読み取り／書き込みを行うエンティティと、永続化されるデータと一時データを明記します。
• 状態と遷移 — 状態を持つ場合は、状態遷移表を指定します。現在の状態 × イベント → 次の状態を示し、不正な遷移にはダッシュを記載します。初期状態と終端状態を明記します。表形式にすることで、不正な遷移を検証できます。
• エッジケースとエラー処理 — 境界／失敗時の経路を列挙します（境界値：各上限の直下／上限値／直上、null／空、重複／冪等性、並行処理／競合、権限／可視性、制限／オーバーフロー）。すべてのエッジケースとエラーについて、期待する処理（応答／メッセージ／復旧方法）を明記します。発生することだけを記述してはいけません。（エッジケース＝有効だが通常と異なる状況、エラー＝失敗です。両方を明記します。）
• 受け入れ基準 — 各動作と主要なエッジケース／エラーに、テスターが合否判定できる基準を付けます。Given／When／Then（シナリオ形式）またはルールベースのチェックリストを使います。機能あたり1～3件とします。通常、4件以上ある場合は、1つの機能に2つの機能が隠れているため、分割します。確率的／ML機能では、出力に対して決定的なG／W／Tは適しません。名前を付けたデータセットに対する指標のしきい値基準（「<eval-set>での適合率 ≥ 0.85」など）に加えて、信頼度が低い場合／フォールバックの動作と、データ要件（ソース／範囲／バランス）を記述します。「モデルの精度が高い」は基準になりません。references/io-states-archetype-amend.mdを参照してください。
• 非機能要件 — この機能に該当するNFRカテゴリを列挙し、それぞれに数値で検証可能な目標値を設定します（パフォーマンスのp95、信頼性／冪等性、セキュリティ／認可、プライバシー、UIのアクセシビリティWCAG 2.2 AA、制限／クォータ、互換性）。機能に応じた適切な範囲にします。単純な機能では不要です。「高速であること」「安全であること」はNFRではありません。
• アーキタイプごとの重点項目 — 機能の性質に応じた観点を適用します（UI → 状態ごとの動作＋アクセシビリティ＋マイクロコピー、API → リクエスト／レスポンスのスキーマ＋ステータス／エラーモデル＋冪等性＋レート制限［ワイヤー契約をapi-specに渡す］、データ／ML → データ要件＋しきい値に基づくAC＋ドリフト／フォールバック、バッチ → スケジュール＋冪等性＋部分的な失敗／再試行、統合 → 配信セマンティクス＋ペイロード契約、CLI → 引数／フラグ＋終了コード）。この観点は、記載すべき内容を確認するための補助として、適切な範囲で適用します。references/io-states-archetype-amend.mdを参照してください。
• 横断的な観点（機能横断で適用するものであり、個別のセクションではありません） — 1つの記述には1つの考えだけを含め（単一の内容にする）、用語を統一し、矛盾がないようにします。各要件／ACを要件の問題表現カタログ（主観的な表現、曖昧な副詞、検証不能／弱い表現、参照先のない比較表現、抜け道、範囲が不明確な「など」）に照らし、重要な箇所に該当する表現があれば、定量的／観察可能な記述に書き換えます。

ステップ 5：承認済み仕様を修正する（変更依頼を受けた場合）

入力が既存の承認済み仕様と変更依頼である場合、仕様全体を再生成せず、その場で修正してください。

1. 変更範囲を定める — この差分がどの機能／動作／AC／状態／I/O フィールドに影響するかと、意図的に変更しない箇所を明記します。
2. 該当箇所を直接編集する — 影響を受けるブロックのみを変更します。
3. 機能内の一貫性を再構築する — 動作を変更した後、AC、状態テーブル、I/O、エッジケースを更新し、機能内の一貫性を保ちます。
4. 双方向の波及影響を分析する — 上流（引き続き PRD の記述にたどれるか？ トレースされていない機能が追加される場合は、「先に PRD を修正する必要があります」と明記）、内部（古くなった AC／状態／I/O／エッジケースはどれか — ステップ 3 で修正）、下流（古くなった技術設計上の判断／テストケース／api-spec の項目はどれか — 影響を受ける項目として列挙）。
5. バージョンと変更履歴 — 文書自体のバージョンヘッダーを更新し、変更履歴の項目（誰が／いつ／何を／なぜ）を追加します。
6. 置き換えられた内容を明示する — 古くなった動作／基準／状態には、理由を添えて置き換え済みであることを明記します。黙って削除しないでください。references/io-states-archetype-amend.md を参照してください。

ステップ 6：引き渡し前に実装可能性の基準に照らして自己チェックする

以下のすべてを満たしていることを確認します（これがレビュー担当者の判断基準です。作成者とレビュー担当者が同じ基準を共有することで、認識のずれを防ぎます）。

1. PRD にトレースされている — すべての機能が特定の PRD 要件／指標に対応している。孤立した機能がなく、カバーされていない PRD の記述もない。
2. 動作が曖昧でない — 各動作の解釈が一通りに定まり、実装方法に依存せず、観測可能である。フローは分類済み（メイン／代替／例外）であり、重要要件にありがちな曖昧さがない。
3. I/O と状態が網羅されている — 入力（検証を含む）と出力（形式／副作用を含む）を列挙する。状態を持つ機能には状態遷移テーブル（有効なセル＋無効を示すマーカー）を用意する。組み合わせに関するルールには完全な決定表を用意する。
4. エッジケースとその処理が網羅されている — null／空、重複／冪等性、並行処理、権限、制限をそれぞれ挙げ、期待されるエラー／処理も明記する。
5. 受け入れ基準がテスト可能である — 各動作／エッジケースに、独立してテストできる合否基準（G/W/T またはルールベース。確率的な機能には指標のしきい値）を設ける。
6. 一貫性があり、要件が分割されている — 1 つの要件につき 1 つのアイデアとし、用語を統一し、内部矛盾をなくす。
7. 実現可能で、計画を立てられる — 明示された制約内で構築できる。I/O と基準が、タスク／マイルストーンに分割できる程度に具体的である。
8. 未解決の疑問が明示されている — 実際の不明点や未解決の判断を率直に示し、確定した事実であるかのように取り繕わない。設計上の前提を明示し、推測を黙って採用しない。
9. 必要な箇所に非機能目標が設定されている — その機能の実現を左右する NFR カテゴリに、妥当な数値目標を設定する。
10. （修正時のみ）差分の範囲が明確で、波及影響が整理され、バージョン管理されている — 変更が対象範囲内であり、引き続き PRD にトレースされている（または上流の PRD 修正が必要だと明示されている）。内部の一貫性が保たれ、下流への波及影響が明らかにされ、バージョンと変更履歴が更新され、置き換えられた内容が明示されている。

入力不足のゲート： PRD 内の機能について、動作を調査できず、信頼できる前提を置くこともできない場合、推測した動作で取り繕うのではなく、ブロッカー（「機能の定義が不十分 — プロダクト上の判断が必要」）として提示します。

ルール

厳守事項（決して違反しないこと）：

• すべての機能をPRDにひも付けてください。 PRDにひも付かない機能も、カバーされていないPRDの機能もあってはなりません。カバレッジはPRDの機能リストに基づきます。
• 動作は観察可能で、実装方法には立ち入りません。 機能が「何をするか」を指定し、「どのようにコード化するか」は指定しないでください。後者は下流の設計レイヤーで扱います。
• エッジケースやエラーには、その処理方法も記載してください。 ケースを挙げるだけで、期待される応答を明記しないのは不十分です。
• 受け入れ基準はテスト可能でなければなりません。 G/W/T、ルールベース、または確率的な機能の場合はメトリクスのしきい値を使ってください。合否を判定できない基準では、動作がまだ仕様化されていません。
• 曖昧な表現は避けてください。 主観的な語（「高速」「堅牢」「使いやすい」）や、問題のある用語集の語を、定量化または観察可能な記述（「p95 < 200 ms」「重複キーの場合は409を返す」）に置き換えてください。「モデルの精度が高い」は基準になりません。
• 動作を決して捏造しないでください。 完全に見せるために、制限、エラーコード、ルールを作り出さないでください。根拠がない場合は、構築前に検証すべき明示的にフラグ付けした前提として記載してください。
• 重複させず、組み立ててください。 セクション構成はテンプレートツールから採用し、このスキルはその構成を埋める手法です。
• PRDを詳しく展開し、書き直さないでください。 PRDの問題、ユーザー、メトリクスを繰り返したり、どの機能を含めるかを再決定したりしないでください。
• 再生成せず、該当箇所を修正してください。 変更依頼では、影響を受けるブロックを編集し、バージョンと変更履歴を更新し、置き換え済みであることを示して、双方向の波及影響を分析してください。仕様全体を黙って出し直してはいけません。
• 実装可能かつテスト可能でなければ、完成とはみなしません。
• 能力の境界（capability_record が指定されている場合）。 文書の出力範囲を、そのレコードの境界内に限定してください。境界外の内容を生成する（refs エンティティを自分の担当範囲であるかのように扱う、exit_point を越えたフローを設計するなど）ことはスコープ違反であり、仕様にない内容を捏造するのと同じです。

推奨事項（上書き可能）：

• 「包括的」という指定は、出力の目指す範囲を示します。比例性を保ち、語数ではなく、意思決定の網羅性を重視してください。機能が小規模であれば、不要なセクション（NFR、状態テーブル、決定テーブル、初稿での変更履歴）を省いてください。
• 動作の記述にはEARS、シナリオにはGiven/When/Thenを優先してください。不変条件や検証テーブルにはルールベースのチェックリストを、確率的な出力にはメトリクスのしきい値を使用してください。
• 受け入れ基準は機能ごとに1～3件にしてください。4件以上ある場合は、分割を検討してください（INVESTの「Small」「Testable」）。

注意点

• PRD を書き直す仕様。 問題、ユーザー、指標を言い換えたり、機能セットを再決定したりするのは PRD の仕事です。分解して詳細化し、スコープを再議論しないでください。
• 実装が漏れ出す振る舞い。 「トークンを Redis に 1h の TTL で保存する」は 実装方法 であり、後続工程の内容です。観測可能な契約（「セッションは 1h 有効で、その後は再認証が必要」）を指定してください。
• 列挙されているが対処されていないエッジケース。 解決策を示さずに「エッジケース：同時編集」と書くのは、仕様ではなく質問です。
• テストできない受け入れ基準。 「機能が正しく動作する」「エラーを適切に処理する」「モデルの精度が高い」は、合否を判定できません。
• 確率的な機能に対する決定論的な基準。 モデル／ランカーには、固定出力を前提とする Given/When/Then ではなく、名前付きデータセットに対する指標のしきい値とフォールバックが必要です。
• 表がないまま状態を列挙する。 状態を列挙しても、遷移（特に許可されない遷移）を推測に委ねるのは仕様不足です。許可されないセルにはダッシュを記載した states×events 表を使ってください。
• 基準の増殖＝隠れた第 2 の機能。 受け入れ基準が 4 つ以上ある場合、通常は 2 つの振る舞いがまとまっています。分割してください。
• アーキタイプ／NFR をセクションの有無で確認すること。 オーバーレイと NFR は 規模に応じた補助 です。小規模な機能では省略して問題ありません。完成度を高く見せるために水増ししないでください。
• 再生成による変更。 小さな変更のたびに仕様全体を出し直すと、来歴が失われ、気付かないずれが生じるおそれがあります。該当箇所を直接修正し、変更履歴を記録し、波及箇所も更新してください。

対比例 — 曖昧（表面上は要件を満たしている）と実装可能（自己チェックに使用してください）：

項目	曖昧／構築不可能（却下）	実装可能（リリース）
PRD との対応	「この機能は請求書に関するものです。」	「PRD §4.2 自動リマインダー を実装し、指標『支払いまでの中央値を 21→14 日に短縮』を改善します。」
振る舞い	「システムがリマインダーを送信します。」	「請求書の支払期限を 3 日過ぎており、かつ未払いの場合、システムはリマインダーテンプレートをクライアントにメールで送信し、reminder_sent イベントを記録します。」
エッジケース	「請求書が支払い済みの場合に対応します。」	「3 日の期限を迎える前に請求書が支払い済みになった場合、リマインダーは送信しません。キューに入っているリマインダーがあればキャンセルします。」
エラー処理	「メールのエラーを処理します。」	「メールプロバイダーが 5xx を返した場合、バックオフを伴って 3 回再試行します。その後、reminder_failed としてマークし、ダッシュボードに表示します。」
受け入れ（決定論的）	「リマインダーが動作します。」	「3 日間期限を過ぎた未払いの請求書がある状態で、日次ジョブが実行されたとき、リマインダーメールが 1 通だけ送信され、reminder_sent イベントが記録されます。」
受け入れ（確率的）	「関連性モデルの精度が高いです。」	「2026-Q2-holdout セットで、precision@10 ≥ 0.80 かつ recall@10 ≥ 0.65 を満たします。confidence < 0.4 の場合、結果は新しさ順のソートにフォールバックします。」

記述した内容が左列のようであれば（どの機能にも当てはまり、トリガーも観測可能な結果も対処方法もない）、未完成です。

アンチパターン

• 「PRD の機能を自分の言葉で言い換えます。」 それは詳細化ではありません。PRD に記載されていない振る舞い、入力／出力、状態、エッジケース、基準を追加してください。
• 「正確にするため、実装方法を説明します。」 実装は後続の設計レイヤーに属します。
• 「エッジケースを列挙すれば、対処方法は明らかです。」 そうではありません。それぞれに期待される対処方法を明記してください。明記しなければ未解決の質問です。
• 「『期待どおりに動作する』／『モデルの精度が高い』は、適切な受け入れ基準です。」 テストできないため、禁止です。観測可能にするか、データセットに対する指標のしきい値を指定してください。
• 「大きな機能ブロック 1 つにまとめておけばよいです。」 基準が 4 つ以上、または振る舞いが肥大化している場合は分割してください。
• 「十分に詳しく見せるため、UI／API／ML／NFR のセクションを追加します。」 アーキタイプと NFR は規模に応じたものです。機能上必要な場合にのみ追加してください。
• 「この変更に合わせて仕様を再生成します。」 該当箇所を直接修正してください。バージョン、変更履歴、波及箇所も更新してください。
• 「概要は自分で書きます。」 テンプレートツールと重複します。

出力

Step 6 の実装可能性基準を満たす包括的な機能仕様（または、対象範囲を限定し、バージョン管理されたその改訂版）。この基準には、すべての機能が PRD に追跡可能であること、分類されたフローによる曖昧さのない観察可能な動作、完全な I/O と状態遷移表、決定表にまとめた組み合わせルール、対処方法を含めてカバーされたエッジケース、テスト可能な受け入れ基準［G/W/T または指標のしきい値］、該当する NFR の目標値、単一かつ一貫していること、実現可能で計画可能であること、未解決の質問が明示されていることが含まれます。改訂版にはさらに、対象範囲の明確化、変更の波及が適切に処理されていること、バージョン管理が必要です。抽象的な利用者は、後続の計画フェーズ、実装を担うエンジニア、検証を行うテスター、および同じ基準を適用するレビュアーです。機能仕様は入力として PRD に依存します。その構成はテンプレートツールによって定まり、このスキルは内容の品質を担います。媒体：現在、成果物はテキスト形式の Markdown ドキュメントです。手法は媒体に依存せず、仕様が別の場所に保存される場合にも同様に適用できます。

関連項目

• 機能仕様テンプレートツール（例：コンテンツ／テンプレートゲートウェイ） — このスキルが内容を埋める、機能ごとのセクション構成を提供します。このツールと組み合わせて使用し、アウトラインを再掲しないでください。
• ディープリサーチ機能 — 各機能の動作、ドメインルール、エッジケースを根拠に基づいて記述します。
• PRD 作成スキル — このスキルが入力として必要とする、上流工程の PRD を作成します。追跡先のない機能を追加する改訂では、まず PRD を改訂します。
• 機能仕様レビューのスキル — 完成した仕様に対して、同じ実装可能性／テスト可能性の基準（差分に限定した改訂レビューを含む）を適用します。作成者とレビュアーが同じ基準を共有することで、基準のずれを防ぎます。
• 後続の利用者 — technical-design（実現方法）、test-plan（検証方法）、api-spec（通信契約）。この仕様はこれらに入力を提供し、改訂時の波及分析では変更の影響を受けるものを特定します。

段階的な開示

• references/requirement-and-behavior.md — ISO/IEC/IEEE 29148 の品質特性、EARS パターンのセット、要件の問題点カタログ、ユースケースのメイン／代替／例外フローの手法です。動作と受け入れ基準を作成または明確化するときに読み込みます。
• references/io-states-archetype-amend.md — I/O データ契約、状態遷移表と決定表の形式、機能レベルの NFR 分類と数値基準、6 つのアーキタイプ別の追加事項（確率的／ML を含む）、改訂時の波及手順です。機能に状態管理、組み合わせルール、アーキタイプ固有の要件がある場合、または改訂する場合に読み込みます。
• references/sources.md — 手法と品質基準の調査根拠です。ガイダンスの出典を監査するときにのみ読み込みます。

本文の分量

• description は 1,024 文字以下（agentskills.io の上限）です。
• 本文は約 500 行／5,000 トークンを目安とします（厳密な上限ではありません。品質を優先し、継続的に 700 行／7,000 トークンを超える場合はその旨を明示してください）。
• 詳細な内容は references/ に置き、必要に応じて読み込みます。