adversarial-ddd

Adversarial DDD Gate

あらゆるコードベースに適用できる、ドメイン駆動設計とユビキタス言語のゲートです。合否を判定するゲートとして、単一のブラインドレビュー用サブエージェントが敵対的な使命のもと、このゲートのルールに照らして作業を判定します。すべてのルールが PASS または N/A の場合に限り、作業は合格となります。このスキルは判定を下すだけで、作業を修正することはありません。

このゲートの要となるのは用語集のライフサイクルです。対象にドメイン概念が含まれる場合、記録されたユビキタス言語（用語集）が存在しなければなりません。用語集がない場合は FAIL となり、修正リストには作成すべき正確なファイルと、定義が必要な用語が記載されます。どのようなプロジェクトでもゲートを実行でき、最初の判定によって用語が必ず明文化されます。その後の実行では、コード、テスト、ドキュメント、顧客向けの文面が用語集に準拠しているかを確認し、適切な規模に保ちます。これにより、DDD の定めるとおり、ひとつのスキルで複数のプロジェクトに共通する、理解しやすい語彙を整備できます。

適用する場合

• ドメインコードのマージを控えており、助言的なフィードバックではなく、ユビキタス言語とドメインモデルの品質について客観的な PASS／FAIL 判定が必要な場合。
• プロジェクトを開始または導入するにあたり、共通の語彙を必ず明文化したい場合。最初の実行で作成される修正リストが、用語集の初期内容となります。
• エージェント（Claude、Codex）がコードを作成し、その既知のデフォルトである *Manager／*Helper 型、setStatus() による状態遷移、貧血エンティティ、ベンダー型のモデルへの取り込みについて、独立した確認を行いたい場合。
• DSL、フルーエントビルダー、または宣言型仕様の形式を導入しており、その表面がドメイン語彙の成果物として適切か判定したい場合。
• 定期監査として、コードベース、ドキュメント、ステークホルダー向けの領域にずれが生じており、その相違点を場所とともに明示したい場合。

ドメイン概念のない対象（純粋なインフラストラクチャ、ビルドツール、汎用ライブラリなど）には適用しないでください。レビュープロンプトの前提条件により、「GATE NOT APPLICABLE」として中止されます。ユーザーが判定ではなく、説明やリファクタリングを求めている場合にも適用しないでください。前提となる構造が存在しないルール（識別可能なコンテキストがない、DSL がない、準拠ルールに対する用語集がまだない）は FAIL ではなく N/A になります。ただし、存在しないこと自体が FAIL となる 2 つの不在ルール（gloss-language-recorded、dsl-deterministic-validator-exists）は例外です。

レビュープロトコル

以下の手順に厳密に従ってください。ゲートの価値は、すべてのレビューを同じ方法で実施することにあります。

1. 対象を特定します。 レビュー対象（差分、モジュール／境界づけられたコンテキスト、DSL の表面など）を正確に特定し、レビュー対象が曖昧さのない固定されたものになるよう、参照先とパスを記録します。必ずリポジトリのルートを含めてください。gloss-* ルールはリポジトリ内を検索して用語集と用語の使用状況を確認し、ctx-* ルールでは差分の外にある関連コンテキストを参照する必要があります。ドキュメントやユーザー向けの文言がある場合は、その場所も記録します。
2. ルールを読み込みます。 references/_sections.md と、references/ 内のすべてのルールファイル（gloss-*.md、lang-*.md、model-*.md、ctx-*.md、dsl-*.md の各ファイル）を読みます。
3. レビュアー用プロンプトを作成します。 ルールと対象を references/reviewer-prompt.md に反映します。作成したプロンプトは完全に自己完結していなければなりません。レビュアーには会話履歴が見えないため、プロンプト外のコンテキストを参照してはなりません。
4. ブラインドレビューを 1 件だけ依頼します。 作成したプロンプト全体だけを入力として、単一の Task サブエージェントを起動します。会話のコンテキストや、プロンプトに添えるコメントは一切含めません。
5. フェイルクローズで判定します。 レビュアーの構造化出力が判定結果です。すべてのルールが PASS または N/A の場合に限り、全体の判定を PASS とします。1 つでも FAIL があれば、ゲート全体が FAIL です。平均したり、重要度を比較したり、ルール適用を免除したりしてはなりません。「軽微な」FAIL も FAIL です。レビュアーが「GATE NOT APPLICABLE」（対象にドメイン概念がない）を返した場合は、判定結果を出さず、その旨を報告して終了します。
6. 判定結果を出力します。 assets/templates/verdict.md に結果を記入します。FAIL の場合は、レビュアーの「PASS に必要な修正」提案を修正リストにまとめ、カテゴリの重要度順に並べます。まず用語集の編集を記載してください。記録された言語を作成または修正することで、残りのルールを検証できるようになるためです。FAIL となったルールはすべて修正リストに記載し、記載どおりに適用できる具体的な変更を示します。レビュアーの提案が違反内容の言い換えにとどまる場合は、出力前にそのルールの Correct 例をもとに修正内容を導き出してください。

変更されていない対象を再レビューした際に同じルールの判定が変わる場合、または人間が根拠を確認したうえで判定を覆す場合、そのルールには判定可能性の不具合があります。gotchas.md に記録し、ルールを明確にしてください。ゲートの判定を覆してはなりません。

判定形式

レビュアーはルールごとに、PASS | FAIL | N/A、根拠（file:line、引用、または用語集の項目。PASS と FAIL のどちらにも必須）、そして FAIL の場合は、適用するとそのルールを PASS にできる修正（違反内容の言い換えではなく、変更内容とその場所）を返します。また、見つかった用語集、または用語集が存在せず、検索した場所も報告します。最終レポートは assets/templates/verdict.md に従います。

ルールのカテゴリ

#	カテゴリ	プレフィックス	対象
1	用語集のライフサイクル	gloss-	記録されたユビキタス言語が存在すること（不在は FAIL）、コードがそれに準拠すること、すべての項目が有効であり続けること、定義にビジネス上の意味があること
2	言語の一貫性	lang-	1 つの概念に 1 つの名称、1 つの名称に 1 つの意味、ドメインルールで意味のない名称を使わないこと、遷移を操作として命名すること、コード／テスト／ドキュメント／UI で語彙を統一すること
3	ドメインモデルの整合性	model-	ルールがモデルとともに存在すること、構築時に妥当であること、単なるプリミティブ型よりドメイン型を使うこと、ブール型フラグの寄せ集めより名前付きの状態を使うこと
4	境界とコンテキストの整合性	ctx-	コンテキスト間で公開されるインターフェース、ベンダーとの境界における腐敗防止、インフラストラクチャから独立したドメイン、保存モデルごとに書き込み元を 1 つにすること
5	セマンティックモデルと DSL の表面	dsl-	セマンティックモデルを構文の媒体から分離すること、不正な文を構築不能にするか即時に失敗させること、外部 DSL に対して決定論的なバリデーターを用意すること

関連スキル

• domain-architect（実験的） — ドメインモデリングに関する指導スタイルのガイダンスです。ゲートではなくモデルの設計が目的の場合に使用します。
• adversarial-ts-patterns（実験的） — TypeScript/React のパターン使用をチェックするゲートです。網羅的にチェックするには、TS を対象とする際にこのゲートと併用します（コードイディオムのレベルで、ステートマシンと過剰な抽象化に関するルールを担当します）。
• feature-arch-gate（実験的） — フォルダー／機能アーキテクチャをチェックするゲートです。プロジェクト構造のレベルで補完します。

参照ファイル

ファイル	説明
references/reviewer-prompt.md	各ブラインドレビュアー向けの自己完結型プロンプトテンプレート
assets/templates/verdict.md	判定レポートのテンプレート
references/_sections.md	カテゴリーの定義と順序
metadata.json	バージョンとソースの参照