authoring-technical-design

authoring-technical-design — SKILL.md

バリアント： 標準 · 使用するタイミング： 1 つの機能／コンポーネントの構築方法を技術設計書にまとめる場合（または承認済みの設計書を修正する場合）。エンジニアが設計を再検討せずに実装できる水準を目指します。

概要

このスキルは、優れた技術設計書（TDD）、つまり既存システム内の1 つの機能またはコンポーネントの詳細な実装設計を書くための方法です。PRD がプロダクトの「何を」を示し、機能仕様書が各機能の「どのように動作するか」を示すのに対し、TDD はその機能を「どのように構築するか」を示します。選択したアプローチ、コンポーネントとその責務、制御フローとデータフロー、主要なインターフェース、重要なロジック、障害モード、横断的な考慮事項（セキュリティ／プライバシー／可観測性）、検討した代替案、テスト、リリース計画を記述します。このスキルが定めるのは、作成者の判断基準、すなわち設計調査の手法と実装可能性の基準であり、セクション一覧ではありません。セクションの構成を提供する技術設計テンプレートツールと、設計の根拠となるエビデンスを集める詳細調査機能という、2 つの協力者を想定しています。作成者には承認済みの PRD と機能仕様書（存在する場合は、アーキテクチャ文書、API 仕様書、データモデルも）が渡され、汎用的な骨組みを出力するのではなく、その機能の構築方法を具体化しなければなりません。満たすべき基準は、エンジニアが設計を再検討せずに文書から機能を実装できること、そして選択したアプローチが少なくとも 1 つの実際的な代替案と比較して正当化されていることです。このスキルの基準は、レビュアーゲートである reviewing-technical-design と一元化されています。作成者はゲートが求める内容を正確に満たすため、両者の間にずれが生じません。

使用するタイミング

• 既存システム内での構築方法を設計するため、機能仕様書に記載された 1 つの機能／コンポーネントの TDD を作成する場合。
• 実装アプローチを決定して文書化する場合：コンポーネントの分割、制御フロー／データフロー、インターフェース、詳細なロジック、障害モード、可観測性、テスト、リリース計画。
• 承認済みの TDD をバージョン管理された差分として修正する場合（選択したアプローチが実装中に機能しないと判明した場合、機能仕様書の動作が訂正された場合、新たな障害モードが見つかった場合など）。ステップ 6 を参照してください。
• 機能の要件にひも付けて調査した、意思決定が完了した内容を技術設計テンプレートに記入する場合。

次の場合は有効化しないでください：

• システム全体の構造、サービスのトポロジー、または長期的な技術選定を設計する場合 → それはより高い抽象度のアーキテクチャ文書の対象です。TDD はそのアーキテクチャ内の 1 つの機能を設計し、アーキテクチャを参照します。
• API 契約（通信／エンドポイントのインターフェース）またはデータモデル（永続化されるスキーマ）そのものを作成する場合 → これらはそれぞれ独立した文書であり、TDD では参照するだけで、重複して記述しません。
• PRD または機能仕様書を作成する場合 → これらはこのスキルの上流入力です。
• 完成した TDD をレビューまたは評価する場合 → reviewing-technical-design を使用してください。

入力

計画から渡されたすべての文書、つまり depends_on の一式（上流文書のうち、調査によってこの文書に関連すると判断されたもの）を読み、この文書の内容をそれらにひも付けてください。一般的な上流文書は承認済みの PRD と機能仕様書（存在する場合は、アーキテクチャ文書、API 仕様書、データモデルも）ですが、これらは手法上の指針であり、受け取る文書の上限ではありません。自己完結型にし、実際に受け取ったコンテキストに基づいて文書を作成してください。関連文書が想定されていても存在しない場合は、手元にある情報で作業を進め、その不足を明示的な前提条件として示し、決して穴埋めのために捏造しないでください。また、利用可能な場合は調査機能（詳細調査）を使い、テンプレートを埋めるだけでなく、包括的かつ網羅的な文書を作成してください。

ワークフロー

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

技術設計テンプレートツール（包括版）からセクション構成を取得してください。セクション一覧をここで言い換えたり、再構成したりしないでください。このスキルが提供するのは、各セクションを適切に埋めるための方法です。テンプレートがない場合は、包括的な技術設計の構成を入手（依頼／作成）してから進めてください。この文書形式で中核となるセクション — コンテキスト／課題、要件トレース、採用するアプローチとコンポーネント分解、制御フローとデータフロー、インターフェース／契約、詳細設計、エラー処理、横断的な関心事（セキュリティ／プライバシーと可観測性）、代替案、テスト、ロールアウト／移行、バージョン管理／変更履歴 — はテンプレートに含まれています。あなたの役割は、それらを満たす内容の質を高めることです。作成した文書には、テンプレートの template: technical-design フロントマターを必ず付けてください。これは reviewing-technical-design が参照する有効化シグナルです。

ステップ 2：上流のドキュメントを読み、要件を起点に設計する

承認済みの PRD と機能仕様書を読みます。これらは入力資料であり、白紙ではありません。該当する場合は、アーキテクチャドキュメント（機能を組み込む対象のシステム）、API 仕様、データモデルも読みます。機能仕様書の要件と受け入れ基準を、網羅性のチェックリストとして使ってください。トレースは双方向です。すべての要件に設計を対応させ（網羅漏れをなくし）、すべての設計判断を要件に結び付けてください（根拠のない設計やスコープの拡大を避けます）。上流資料の記述が不十分な場合は、黙って既定値を設けず、未解決の質問または明示した前提として示してください。提示された情報から信頼性のある設計を行えない機能は、独自に作り上げず、ブロッカーとして明らかにしてください。

ステップ 3：設計の根拠となる情報を調査する

詳細な調査を行い、次の 2 点を設計の根拠にしてください。（a）確立されたエンジニアリング設計の実務 — この種の課題を設計ドキュメント／RFC の形式でどのように扱うか（独自に考案せず、実証済みのパターンを使う）。（b）プロジェクト固有の実際の制約 — 機能を組み込む既存のアーキテクチャ、技術スタック、コード。既存の構造に沿って設計してください。調査機能が利用できない場合は、アプローチ、制限、インターフェースを捏造しないでください。構築前に検証すべき、明確に注記した前提として示してください。

ステップ 4：各セクションに設計手法を適用する

テンプレートの各セクションを、この手法に沿って埋めます。小規模な機能に不要なセクションは省略してください（並行処理がなければ並行処理についての説明は不要、永続化される変更がなければ移行は不要、単純な内部ヘルパーなら軽い可観測性で十分です）。各観点の詳細は references/design-method.md と references/failure-test-rollout-amend.md に記載されています。

• コンテキストと要件のトレース — 機能のスコープで、機能と解決する問題を示し、詳細な資料は埋め込まずにリンクします。設計が満たすべき要件を列挙し、それぞれを PRD の目標／機能仕様の基準／制約と双方向にトレースします。裏付けとなる要件のない設計上の決定はスコープクリープであり、設計のない要件はカバレッジの不足です。目標と非目標、つまり目標になってもおかしくないものの、意図的に除外した項目を区別します。レビュー担当者が意図的な選択だとわかるよう、項目を明記してください。
• 採用するアプローチとコンポーネント分解 — まず短い概要を示し、その後、コンポーネント／モジュールをそれぞれ単一の責務と連携先に分けて説明します。既存システムとの位置づけを示す際は、周辺構造を描き直さず、アーキテクチャ文書を参照します。機能／コンポーネントの粒度にとどめてください。
• 制御フローとデータフロー — 主な実行時フローを図で示し、手順を追って文章でも説明します。図と文章の内容は一致させてください。ここでは成功時のフローを扱い、失敗はエラー処理に記載します。
• 主要なインターフェースと契約 — この機能が新たに導入または変更するシグネチャ／メッセージ形式／イベントを、実装ではなく契約として示します。API 仕様またはデータモデルですでに定義されているものは、それを参照して差分だけを記載します。エンドポイントを再列挙したり、スキーマを再定義したりしないでください（重複すると内容が乖離します）。
• 詳細設計 — 自明ではなく、設計の要となるロジックだけを記載します。中核となるアルゴリズム、保持する状態とその遷移、並行処理／順序付け／冪等性に関する懸念が対象です。単純な CRUD に説明は不要です。
• エラー処理と障害モード — 不正な入力、依存先の障害／タイムアウト、部分的な失敗など、各障害について、検出方法、処理／復旧方法、ユーザーに見える影響を列挙し、リトライ／タイムアウト／冪等性への対応方針も示します。正常系だけにとどめないでください。
• 横断的な懸念事項 — セキュリティとプライバシー： 機能に関わる認証／認可／シークレット（格納先を参照し、シークレットをインラインで記載しない）、信頼できない入力の範囲、扱う PII／保持期間／分類を示します。スケールと制限： 10 倍／1000 倍の負荷に対する機能の動作（項目単位かコレクション全体かの操作、上限のない増加、ホットパス）を示し、設計の要となる部分には対応方針を記載します。可観測性（後付けではなく、第一級の要件）： 出力・監視する健全性／障害のシグナルを明記します。成功／エラーのメトリクス、重要なログ／トレース、主要な障害モードに対するアラートを挙げてください。これらはロールバックのトリガーとなる同じシグナルです。懸念事項が該当しない場合は N/A と記載します。
• 検討した代替案 — 有能なエンジニアが実際に選びうる、藁人形論法ではない現実的な代替案を少なくとも1 つ挙げ、そのトレードオフと、採否を決めた判断基準を示します。形式的に承認されただけの選択肢しかないのは要注意です。
• テスト方針 — 単体／統合／エンドツーエンドのカバレッジ、上記の障害ケース、および機能が公開する契約の適合性テストを示します。受け入れ基準を繰り返し記載せず、機能仕様の受け入れ基準を参照してください。
• ロールアウト、移行とリスク — 提供方法（段階的な展開／機能フラグ／カナリア）、移行と後方互換性の方針、測定可能なトリガーに基づくロールバック計画（「問題がありそうならロールバック」ではなく、可観測性シグナルに結びつける）、残存リスクと未解決の疑問を示します。

ステップ 5：引き継ぎ前に実装可能性の基準を満たしているか自己確認する

すべて満たしていることを確認します。これが reviewing-technical-design が定める基準です（作成者とゲートで同じ基準を使い、ずれが生じないようにします。ゲートの 11 条件は、以下の条件と 1 対 1 で対応しています）。

1. 要件の追跡が完全で双方向 — すべての要件が記載され、情報源まで追跡できます。すべての決定が要件まで追跡でき、孤立した決定も、カバーされていない要件もありません。
2. 1 つの機能にスコープを絞り、適切な詳細度にする — アーキテクチャ内の 1 つの機能／コンポーネントを設計します。システム全体の構造は参照するにとどめ、再設計しません。
3. アプローチと分解が実装可能 — コンポーネントとその責務が、構築に十分な具体性を備えています。制御フローとデータフローが図で示され、かつ文章でも説明されており、両者に矛盾がありません。
4. 重複ではなく参照する — API 仕様／データモデル／アーキテクチャ文書がすでに所有するインターフェースとデータの接点は、変更点のみを示して参照します。内容をインラインで複製しません。
5. 判断基準を伴う、実質的な代替案が少なくとも 1 つある — 見せかけではない選択肢をトレードオフとともに比較し、選択を決定づけた基準を明記します。
6. 障害モードに対処している — 重大な障害を列挙し、それぞれの検出方法と、設計された処理／復旧方法を示します。該当する場合は、並行性／冪等性に加え、セキュリティ／スケール／プライバシーの考慮事項にも対処します。
7. 可観測性に対処している — ヘルスシグナルと障害シグナルを明記し、ロールバックのトリガーとして機能させます。
8. テストに対処している — 障害ケースや契約への準拠も含め、検証アプローチをテスト可能な形で示します。
9. ロールアウト／移行／ロールバックに対処している — リリース方法、移行と後方互換性、および測定可能なトリガーを伴うロールバックを示します。
10. 前提が明示され、根拠がある — 未確定事項はすべて、暗黙に既定値を設定せず、前提／未解決の質問として明らかにします。この機能固有の詳細と実際の周辺システムを設計に反映し、事実を捏造しません。
11. 改訂に対応している（改訂時） — 承認済み TDD への差分をスコープ内に収め、バージョンと変更履歴を更新し、置き換えられた内容を明示して、その波及を分析します（ステップ 6）。

入力不足のゲート： 提供された情報や、信頼できる前提から機能を設計できない場合は、根拠のないアプローチで取り繕わず、ブロッカー（「設計の仕様が不十分です — アーキテクチャまたはプロダクトに関する判断が必要です」）として明示します。

ステップ 6：承認済み TDD の改訂（差分による改訂）

承認済み TDD と変更依頼を受け取った場合（空の機能定義ではない場合）は、文書全体を再生成せず、バージョン管理された差分としてその場で改訂します。詳細な手順は references/failure-test-rollout-amend.md に記載されています。方法は次のとおりです。

• 変更の対象を、影響を受ける設計上の決定（コンポーネントの責務／インターフェース契約の差分／障害モードと処理／ロールアウトの手順／代替案と判断基準）に絞ります。それらを編集し、残りはそのままにします。
• 変更した部分の内部のつながりを再確認します。変更した決定は、引き続き要件まで追跡できるか。その障害モード／可観測性／テスト／ロールアウトは引き続き妥当か。代替案の判断基準は、引き続きその選択を決定づけるものか。
• 双方向の波及と SSOT への波及を分析します。上流 — 変更された要件が起点の場合は、PRD／機能仕様を先に改訂します（下流文書より先に上流文書を更新します）。内部 — 上記の内部のつながりを再確認します。下流と SSOT — 変更が契約に影響する場合、その契約を所有する api-spec／data-model にも独自の改訂が必要です（TDD には差分のみを記載します）。TDD をもとに作成された実装／テスト計画／リリース手順書は、参照先を更新します。
• バージョンと変更履歴 — 作成した文書自体のバージョンを上げ、変更履歴の項目（誰が／いつ／何を／なぜ）を追加します。
• 置き換えられた決定には、（superseded-by と相互参照の注記を付けて）置き換え済みであることを明示します。黙って削除してはいけません。

ルール

厳守ルール（決して違反しないでください）：

• すべての決定を要件に結び付け、逆方向も確認してください。 PRD／機能仕様に根拠のない設計判断を行わず、設計されていない要件を残さないでください。
• 重複させず、参照してください。 API 仕様／データモデル／アーキテクチャ文書が管理するインターフェース、スキーマ、システム構造は、差分のみを示して参照してください。内容をそのまま記載すると、TDD と信頼できる情報源の間にずれが生じます。
• 実際の代替案を少なくとも1つ示してください。 真正な代替案をトレードオフと明示した判断基準とともに比較してください。藁人形論法や、比較検討のない単一案では、このセクションの要件を満たしません。
• 失敗モードには対処方法を示してください。 失敗を列挙するだけでは不十分です。検出方法と復旧方法を明記してください。
• 観測可能かつロールバック可能にしてください。 本番環境に関わる機能では、ヘルス／障害のシグナルと、測定可能なトリガーを伴うロールバック方法を示してください。「後でログを追加する」「問題がありそうならロールバックする」では不十分です。
• 設計を捏造しないでください。 完全に見せるために、アプローチ、制限、インターフェースをでっち上げないでください。根拠となる情報がない場合は、ビルド前に検証すべき明示的に注記した仮定として記載してください。
• アウトラインを重複させず、組み合わせてください。 セクション構成はテンプレートツールから取得し、このスキルはその構成を埋めるための方法として使ってください。競合するアウトラインを貼り付けないでください。
• システムではなく、1つの機能を設計してください。 機能／コンポーネントの粒度にとどめ、システム全体に関する内容はすべてアーキテクチャを参照してください。
• 書き直すのではなく、改訂してください。 承認済みの TDD は、範囲を限定し、バージョン管理し、影響を分析した差分として変更してください。再生成してはいけません。
• 実装可能でなければ、完成とは見なせません。 エンジニアが実装のために設計を再導出しなければならない状態で引き渡さないでください。

推奨事項（変更可能）：

• 「包括的」は出力の目指す水準を定めますが、適切な分量を保ってください。重要な判断を漏れなく含めることが目的であり、語数を増やすことではありません。設計文書は短くまとめる傾向にあり、小規模な機能では不要なセクションを統合します。
• メッセージ交換にはシーケンス図、判断／データフローにはフローチャートを優先し、図には必ず番号付きの説明を添えてください。
• 詳細なロジックは、最終実装ではなく、契約やアルゴリズムの形を示すフェンス付き疑似コードで表現してください。

注意点

• 機能ではなくシステムを設計してしまう。 サービスのトポロジーを描き直したり、データストアを再検討したりするのは、より高い視点でのアーキテクチャ作業です。それを参照し、その中で対象となる1つの機能を設計してください。
• APIやスキーマをそのまま埋め込む。 エンドポイント一覧やテーブルのDDLを貼り付けると、API仕様やデータモデルが重複し、どちらかが変更された時点で内容がずれてしまいます。管理元のドキュメントにリンクし、その機能に必要な差分だけを記載してください。
• 形だけの代替案。 「代替案：何もしない／すべて書き直す」は、実質的なトレードオフではありません。代替案は、有能なエンジニアが実際に選んだ可能性のある設計とし、それを退けた判断基準も示してください。
• 正常系だけの設計。 決して失敗しないフローは、設計されたとは言えません。失敗モードとその復旧方法を列挙してください。実装バグはそこに潜んでいます。
• 可観測性を後回しにする。 「メトリクスは後で追加します」では、運用も安全なロールバックもできない機能になってしまいます。シグナルも設計の一部として明記してください。
• 図と説明文の不一致。 説明文にない手順がシーケンス図に示されている（またはその逆）と、読者は推測するしかありません。両者の内容を一致させてください。
• テンプレートの構成を繰り返す。 コンテンツ内（またはこのスキル内）でセクション一覧を再構成すると、テンプレートツールと重複し、内容がずれていきます。代わりに、各セクションを判断に基づいて埋めてください。
• 修正時に書き直す。 1つの判断を変更するためにTDD全体を再生成すると、レビュー履歴と安定した判断IDが失われます。差分だけを編集し、バージョンと変更履歴を更新してください。

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

項目	曖昧／実装不能（却下）	実装可能（採用）
要件の追跡	「この文書はエクスポート機能を設計します。」	「feature-spec §3.1 CSV エクスポートを設計します。『1万行を5秒未満でエクスポートできる』という受け入れ基準を満たします。」
分解	「エクスポーターコンポーネントがエクスポートを処理します。」	「ExportJob（キューイングと状態追跡）が、行のストリーミング処理をRowSerializerに委譲します。既存のReportQueryポート経由で読み取ります。architecture-doc §Reportingを参照してください。」
インターフェース	「レポートAPIを呼び出します。」	「既存のGET /reports/{id}/rows（api-spec §Reports）を再利用します。この機能で追加するのはformat=csvクエリパラメーターのみです。差分はそちらに記載します。」
代替案	「最善の方法を選びました。」	「バッファリングではなくストリーミングを選びました。バッファリングのほうがシンプルですが、約5万行を超えるとOOMが発生します。判断基準は、1万行の目標に対してメモリ使用量を一定範囲に保てることです。」
失敗モード	「エラーは処理されます。」	「ストリーミング中にReportQueryがタイムアウトした場合、ジョブをfailedとしてマークし、部分ファイルを破棄して、ユーザーに再試行可能なエラーを表示します。」
可観測性	「監視します。」	「export_duration_secondsとexport_failures_total{reason}を出力します。5分間の失敗率が5%を超えた場合にアラートを発報します。同じシグナルがロールバックの判断にも使われます。」

記入内容が左列のようであれば——どの機能にも当てはまり、追跡可能性も、具体的なコンポーネントも、判断基準も、対処方法も、シグナルもないのであれば——まだ完成していません。

アンチパターン

• 「ドキュメントだけで完結するよう、アーキテクチャを改めて説明します。」 アーキテクチャ文書と内容が重複し、そこから逸脱していきます。アーキテクチャ文書を参照し、その枠組みの中で機能を設計してください。
• 「レビュー担当者が参照しなくて済むよう、API／スキーマを貼り付けます。」 API 仕様／データモデルが管理する契約をそのまま記載すると、確実に内容が乖離します。リンクを貼り、差分だけを記載してください。
• 「明らかに正しい選択肢があるので、代替案の検討は無駄です。」 代替案のセクションでは、トレードオフを検討します。現実的な代替案と判断基準を示すか、選択に根拠がないことになります。
• 「正常系が設計のすべてで、障害は実装の詳細です。」 設計の価値が問われるのは障害への対応です。障害モードを列挙し、それぞれの対処方法を示してください。
• 「オブザーバビリティやロールアウトは運用チームの課題です。」 本番環境に対応できる設計では、機能の監視方法とロールバック方法を明示します。これらは構築後の作業ではなく、構築の一部です。
• 「アウトラインは自分で書きます。」 テンプレートツールと重複します。構成はテンプレートツールから取得してください。
• 「調査は省略します。設計ドキュメントのことは分かっています。」 調査によって、このシステムの制約と、この問題に対して実証済みのパターンを把握できます。設計ドキュメントの一般論を調べるわけではありません。
• 「この変更のためにドキュメント全体を再生成します。」 承認済みの TDD は、範囲を限定したバージョン付きの差分として改訂します。書き直すと、履歴と安定した決定 ID が失われます。

出力

ステップ 5 の実装可能性基準（すべての決定が要件と双方向に追跡可能であること、実装可能なアプローチと分解が示されていること、制御フロー／データフローが、同期された図と説明で示されていること、インターフェース／データがそれぞれを管理するドキュメントを参照していること、障害モードと横断的関心事［セキュリティ／プライバシー＋オブザーバビリティ］、テスト、ロールアウト／ロールバックに対応していること、現実的な代替案と判断基準が少なくとも 1 つあること、前提が明示されていること、単一の機能に範囲を限定していること。改訂時は、範囲を限定したバージョン付きの差分であること）を満たす、包括的な技術設計ドキュメントです。Markdown 形式のテキストとして、文章＋Mermaid のシーケンス図／フロー図＋コードフェンスで囲んだインターフェース／疑似コード＋トレードオフ表で表現します。方法と基準は、媒体に依存しません。想定する読者は、機能を実装するエンジニアと、同じ基準を検証する reviewing-technical-design ゲートです。TDD は、入力として PRD と feature-spec（および存在する場合は architecture-doc／API spec／data-model）に依存します。その構成はテンプレートツールから取得し、このスキルは内容の品質を担います。

関連項目

• 技術設計テンプレートツール（コンテンツ／テンプレートゲートウェイなど）— このスキルで内容を埋めるためのセクション構成を提供します。組み合わせて使用し、アウトラインを再記載しないでください。
• 詳細調査機能 — 確立された設計ドキュメントの実践と、プロジェクト固有の実際の制約を踏まえた設計に役立ちます。
• 上流の PRD と feature-spec — この設計で具体化する要件です（入力として使用し、ここで再作成しません）。
• architecture-doc／API spec／data-model（存在する場合）— TDD が参照するシステム、契約、スキーマです（必要な新しいものを提示する場合はあります）が、内容を重複させません。
• reviewing-technical-design — 完成した TDD に対して、同じ実装可能性基準（単一の情報源で管理される 11 条件のチェックリスト）を実行時に検証するゲートです。執筆者とレビュアーが同一の基準を共有し、乖離を防ぎます。（doc-library の technical-design アーティファクトには専用のレビュアーがあり、汎用の design-review がゲートするのは、RFC／ADR／仕様／計画などの兄弟にあたるエンジニアリング成果物であり、このアーティファクトではありません。）

段階的開示

• references/design-method.md — 要件トレーサビリティマトリクス（RTM）の仕組み、視点の高さ（C4）による枠組み、分解と同期フローの手法、参照して重複を避ける／SSOT の原則、詳細設計／疑似コードの形式を説明します。セクション 1～6 を記入するときに読み込んでください。
• references/failure-test-rollout-amend.md — 故障モード影響解析（FMEA）の手法、オブザーバビリティ信号の分類、テストピラミッドとコントラクト適合性の詳細、ロールアウト／フラグ／測定可能なロールバックのパターン、改訂の波及手順を説明します。セクション 7～12 を記入するとき、または改訂するときに読み込んでください。
• references/sources.md — 手法と実装可能性の基準の調査根拠を示します。ガイダンスの出典を確認するときのみ読み込んでください。

本文の上限

• description は 1,024 文字以下（agentskills.io の上限）。Claude は、スキル一覧で description と when_to_use の合計が 1,536 文字を超えると切り捨てます。
• 本文は約 500 行／5,000 トークン以下。
• 詳細な内容は references/ に置き、必要に応じて読み込みます。

変更履歴

• 1.2.0（2026-06-14）— 本番運用レベルへの再構成：改訂／差分の手法（ステップ 6）を追加し、オブザーバビリティを横断的な最優先事項として位置付け、テストとロールアウトを強化（測定可能なロールバックのトリガー）、新しい reviewing-technical-design ゲートと一元化した 11 項目のステップ 5 セルフチェックを拡張し、詳細な内容を 2 つの新しい references/ ファイルに移しました。手法の骨子と、参照して重複を避ける／実際の代替案／視点の高さに関するルールは変更ありません。
• 1.1.0（2026-06-04）— 初回レビュー済みリリース。