adversarial-ts-patterns

Adversarial TS Patterns Gate

TypeScript と React のアプリケーションコードにおけるデザインパターンの使用を判定するゲートです。合否を判定するゲートとして、単一のブラインドレビュアーサブエージェントが、敵対的な指示のもと、このゲートのルールに照らして成果物を評価します。すべてのルールが PASS または N/A の場合にのみ、成果物は合格となります。このスキルは判定を示すものであり、成果物を修正することはありません。

このゲートでは、両方向から評価します。過剰な抽象化 — イディオマティックな TypeScript なら関数、モジュール、またはタグ付きユニオンを選ぶ場面で、Java/C# から持ち込まれた Gang of Four パターンやエンタープライズ向けの仕組みを使うことです。モデル化の不足 — コンパイルできてしまう不可能な状態を含む、暗黙的なステートマシンです。たとえば、ブール値フラグによるライフサイクル、エフェクトチェーン、手動で同期する派生状態、何も通知しない default 分岐などです。

適用するタイミング

• TypeScript/React の差分や機能をマージする前に、パターンの使用について助言ではなく、客観的な PASS/FAIL 判定が必要な場合。
• エージェント（Claude、Codex）がコードを作成し、Java/C# の学習データに由来するイディオム（Singleton クラス、ファクトリー階層、リポジトリーラッパー、JavaBean アクセサー）を再現していないか、独立したチェックを行いたい場合。
• 別のスタック（Java、C#、Angular 風の DI）からの移行が完了したとされ、移植されたアーキテクチャのうち、TypeScript では根拠を失ったレイヤーを監査する必要がある場合。
• コンポーネントやストアの状態が場当たり的に増え、暗黙的なステートマシンの失敗パターン（矛盾するブール値、エフェクトチェーン、網羅性のないマッチ）がリリース前に見つかるようにしたい場合。

TypeScript 以外のコードベースには適用しないでください（レビュアープロンプトの前提条件により、「GATE NOT APPLICABLE」で中止します）。また、判定ではなく説明やリファクタリングを求めている場合も適用しないでください。それは厳選された implementation-design-patterns および implementation-functional-patterns スキルの役割です。React 固有のルールは、React を使用しない TypeScript プロジェクトでは N/A となります。それ以外のゲートは、どの TypeScript アプリケーションでも機能します。

レビュープロトコル

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

1. 対象を特定します。 レビュー対象（差分、ファイル一式、PR）を正確に特定し、曖昧さのない固定された対象に対してレビューを実施できるよう、ref／パスを記録します。対象の説明にはリポジトリのルートを含めてください。layer-no-single-impl-interface と layer-no-di-container-in-app のルールでは、2つ目の実装や登録を見つけるため、差分の範囲を超えて検索する必要があります。
2. ルールを読み込みます。 references/_sections.md と、references/ 内のすべてのルールファイル（すべての state-*.md、create-*.md、behave-*.md、layer-*.md、react-*.md、oo-*.md ファイル）を読みます。
3. レビュアー向けプロンプトを作成します。 ルールと対象を references/reviewer-prompt.md に記入します。作成したプロンプトは完全に自己完結している必要があります。レビュアーには会話履歴が表示されないため、プロンプト外のコンテキストを参照してはなりません。
4. ブラインドレビュアーを1人起動します。 入力全体が作成済みのプロンプトのみである Task サブエージェントを1つ起動します。会話コンテキストや、プロンプトに添えるコメントは含めません。
5. フェイルクローズで判定します。 レビュアーの構造化された出力が判定結果であり、統合ステップはありません。すべてのルールが PASS または N/A の場合に限り、全体の判定は PASS です。1つでも FAIL があればゲートは失敗です。重大度を平均したり、比較衡量したり、ルールの適用を免除したりしてはなりません。「軽微な」FAIL も FAIL です。レビュアーが「GATE NOT APPLICABLE」（TypeScript の対象ではない場合）を返した場合は、判定の報告に進まず、代わりにその旨を報告してください。
6. 判定結果を出力します。 assets/templates/verdict.md に記入します。FAIL の場合は、レビュアーの「missing for PASS」の提案を修正リストにまとめ、各項目に該当箇所を記載し、カテゴリの重要度順に並べます。最終結果が FAIL のルールはすべて修正リストに含め、記載どおりに適用できる具体的な変更を示す必要があります。レビュアーの提案が違反の言い換えにすぎない場合は、出力前にそのルールの Correct の例から修正内容を導き出してください。

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

判定形式

レビュアーはルールごとに、PASS | FAIL | N/A、証拠（file:line または引用。PASS と FAIL の両方で必須）、およびすべての FAIL について、適用後にルールが PASS に変わる修正内容（違反の言い換えではなく、変更内容とその場所）を返します。最終レポートは assets/templates/verdict.md に従います。

ルールのカテゴリ

#	カテゴリ	プレフィックス	対象
1	状態モデリングと状態マシン	state-	真偽値フラグより判別可能なユニオンを優先する、エフェクトチェーンを使わない、派生状態を保存しない、never を使った網羅的なマッチ
2	生成パターンのポート	create-	getInstance() シングルトンを使わない、ファクトリークラス階層を作らない、オプションの入れ物にビルダーを使わない
3	振る舞いのポート	behave-	単一メソッドのクラスより関数を優先する、State／Visitor 階層よりユニオンを優先する、React ツリー内でイベントバスを使わない
4	エンタープライズレイヤー	layer-	パススルーリポジトリを作らない、単一実装の DI コンテナーを使わない、単一実装のインターフェースを作らない
5	React のコンポジション	react-	コンポーネントの継承を使わない、ロジックのみの HOC よりフックを優先する、命令型ハンドルより props を優先する
6	OO の儀礼的コード	oo-	静的メンバーのみのコンテナークラスを作らない、単純なアクセサーの組を作らない

関連するスキル

• implementation-design-patterns（厳選）— GoF のクラス形式を採用すべき場合を説明するためのリファレンスです。判定ではなく、ガイダンスやリファクタリングが目的の場合に使用します。
• implementation-functional-patterns（厳選）— このゲートの create-／behave- ルールがレビュー可能なサブセットとして適用する、GoF から関数型への対応表です。
• adversarial-tanstack ／ adversarial-zod — TanStack Start アプリ向けのフレームワークおよびライブラリレベルのゲートです。Start の差分を網羅的に確認するには、このゲートと併せて実行してください。

リファレンスファイル

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