design-gate

Design Gate

「ここではどの設計レンズが適用されるか」を、小規模なエビデンスに基づくルーティング判断に変換し、選択したレンズだけを適用して、その結果を単一の判定にまとめます。このスキルがルーティングの判断元です。別のレビュー手法を新たに考案したり、評議会を招集したりはしません。

ワークフローの各ステージの境界と、このゲートの後に続く実践的なスキルについては、shared/references/workflow-stage-routing.mdを参照してください。

Workflow

1. 計画、Slice Contract、または変更範囲からステージと対象領域を特定します。タスクの計画中に、共有機能に関する判断を一度評価し、各タスクの適用可能性と残存リスクを分類します。複数のタスクで結論が確定している場合は、shared/references/planning-reuse.mdを使用します。実装前に継承された制約を使用し、エビデンスによって設計対象領域が変わった場合にのみ再ルーティングします。
2. 未解決の判断、または変化したリスクに対してのみレンズを選択します。対象範囲、権限、前提、情報源のリビジョンが一致する場合は、ID によって確定済みの判断を再利用します。対象範囲が一致するタスクでは、レンズを再度適用する必要はありません。残存リスクとセキュリティを個別に分類してください。中心的なリスクに対して、まず最大 3 つの限定されたレンズを適用します。別の重大なリスクを網羅する必要がある場合は、その対象範囲の理由を記録し、現在の役割でその限定されたレンズを適用します。現在の役割では提供できない専門知識や独立性がリスク対応に必要な場合にのみ、承認済みのルートに従って専門家を派遣します。それ以外の場合は、明示的なブロッカーとして残します。レンズの数だけを理由に派遣が必要になることも、網羅性が不要になることもありません。ローカルな変更に該当する行がない場合、ゲートは不要です。
3. 選択した各レンズを、現在のコーディネーターまたは実装者が読み取り専用の手順として適用します。独立した専門家が必要なのは、重大なリスクまたは未解決の問いがある場合です。派遣前にshared/references/model-preview.mdを使用して、承認済みルートの具体的なスナップショットを再利用するか、取得します。計画または設計上の問題、対象範囲内のファイルと境界、以下で定義する正規のゲート結果を伝えます。この応答は、レンズ単独のブリーフ、編集、または実装ルートに代わるものです。独立した最終コードレビューは、別個のワークフロー要件として維持されます。
4. 結果をまとめます。具体的で判断の根拠となる指摘がある場合、reviseが 1 件でもあれば、ゲートの判定はreviseになります。表面的または推測に基づく指摘は、参考意見として扱います。
5. reviseの場合、必要な計画変更を短い番号付きリストで示します。レンズによって実際に未解決のトレードオフが明らかになった場合は、verdict: reviseとdecision_requiredを設定して停止します。このスキルからmodels-consensusを呼び出してはいけません。さらに意見が必要な場合、ユーザーは別途これを呼び出せます。

ルーティング表

変更内容	観点スキル
システム全体のスタイルが未解決	macro-architecture
ビジネス用語、境界づけられたコンテキスト、またはドメインコンテキスト間の関係	domain-driven-design
サービスの分割、またはサービス／データの所有権	macro-architecture
ローカルモジュールの配置、凝集度、または依存関係の方向	architecture-lens
1つのコンテキスト内のビジネスロジック構造（集約、不変条件、イベント）	domain-driven-design
コード構造の選択、拡張性、肥大化した条件分岐	design-patterns
スコープの制約、または実質的なトレードオフを伴う競合するローカル構造	architecture-lens
モジュール／クラス／API のインターフェース設計（深さ、情報隠蔽、インターフェースの複雑さ）	software-design-philosophy
保存状態、データベース、キュー、キャッシュ、マイグレーション、リトライ、並行性、外部 API	data-systems-coding-lens
分散アプリケーションのコンテナー／プロセスのトポロジー（サイドカー、アンバサダー、アダプター、負荷分散されたレプリカ、シャーディング、散布／集約、FaaS への適合性、所有権の選出、作業キュー、バッチワークフロー）	distributed-systems-patterns
信頼できる情報源としてのイベントストリーム（イベント駆動型マイクロサービスの採用または移行、Kafka/Pulsar/Kinesis のトピック、イベントスキーマ、振り分けとオーケストレーションの比較、CDC／outbox によるデータ解放）	distributed-systems-patterns（イベント駆動型ルート）、data-systems-coding-lens
構築対象そのものがエージェントである（LLM のツール呼び出しループ、マルチエージェントパイプライン、永続状態、中断中の承認、またはリプレイが必要な長時間実行の自律処理）	agent-architecture-lens
React の状態配置、レンダリング、エフェクト、または非同期動作	advanced-react
新規または再設計されたユーザー向けフロー、情報階層、またはデザインシステム	ui-ux-pro-max
実質的なトレードオフを伴う、2つ以上の競合するアプローチ	architecture-lens

フォールバック行（上記に該当する行がない場合のみ）： 特定の観点に該当しないものの、変更がアーキテクチャ上重要である場合は、architecture-lens を 観点1のトレードオフ評価 として適用します（緊張関係にある2〜4個の特性、実際の選択肢、およびそれぞれのコストを明示します）。記録する前に all three or no ADR を適用し、正規の ADR テンプレート architecture-lens/references/adr-template.md を使用します。これは上記の行と組み合わせないでください。重要でありながらルーティング先がない変更に対する包括的な受け皿であり、他の観点と並列に適用するものではありません。

該当する行がなく、変更がアーキテクチャ上重要でない場合、変更はローカルなものです。「no design gate required」という注記を付けて proceed を返し、レビューを作り出さないでください。

出力仕様

shared/references/gate-result.md を読み、そこに定められた正規のゲート結果を返してください。結果の統合または再確認時には、ブロッキングおよび助言的な指摘の ID、ステータス、解決の根拠、レビューの重点を維持してください。タスクを承認する前に、ブロッキング指摘、必須の変更、重要な決定を解決してください。バージョン管理された記録を shared/scripts/gate_contract.py で検証してください。セキュリティ分類は security-gate とは別に扱います。実装エンジンにはこれらの制約が渡されます。すべての観点を再実行することはありません。

注意点

1. 重要な決定またはリスクごとに観点を選び、その範囲を限定してください。
2. 観点に変更を加えさせないでください。ゲートは読み取り専用です。
3. スタイルに関する意見を理由にブロックしないでください。境界、データ所有権、契約、または正確性に影響する指摘のみをブロッキング対象とします。
4. revise による修正後にゲート全体を再適用しないでください。ブロッキング指摘を挙げた観点のみ再適用してください。
5. 意見の相違を解消するために合意形成パネルを使用しないでください。ゲートは決定事項を特定できますが、ユーザーの選好を作り出すことはできません。

重要なリスクまたは未解決の問いについて、独立した専門家の判断が必要な場合は、最新の決定事項を範囲を限定してまとめた資料とソースの位置情報を、新しいコンテキストで渡してください。その役割のコンテキストを再利用するのは、その役割が挙げたブロッキング指摘の再確認に限ります。製品に関する議論全体を、狭い範囲のゲートのために分岐させないでください。すべての重要なリスクを対象に含め、ルート承認の境界を維持してください。