adversarial-zod

Adversarial Zod Gate

TypeScript アプリの Zod スキーマコードに対する通貨性と正確性のゲートです。合否を判定するゲートで、1 人のブラインドレビュアーサブエージェントが、敵対的な指示に基づいてこのゲートのルールに照らして作業を評価します。すべてのルールが PASS または N/A の場合にのみ、作業は合格となります。このスキルは判定結果を出すだけで、作業を修正することはありません。

ルールは zod 4.4.x（[email protected] 以降のパッケージルート、2025 年 7 月）と、start- カテゴリーについては TanStack Start v1 RC（.validator() が現行、.inputValidator() は非推奨）に固定されています。

適用するタイミング

• Zod スキーマを定義または編集する差分や機能をマージする前に、助言的なフィードバックではなく、Zod 4 の通貨性に関する客観的な PASS／FAIL 判定が必要な場合。
• エージェント（Claude、Codex）がスキーマコードを作成しており、Zod 3 の学習データに由来するパターン（非推奨のメソッド形式、削除されたパラメーター、z.interface() という幻覚）を再現していないか、独立したチェックが必要な場合。
• Zod 3 → 4 の移行が完了したとされており、見落とされがちなセマンティクスの変更（.default() のショートサーキット、列挙型キーのレコードにおける網羅性、文字列フラグに対する z.coerce.boolean()）の監査が必要な場合。
• TanStack Start アプリがサーバー関数の入力または検索パラメーターを Zod で検証しており、アダプター不要の Standard Schema パターンを使うべき場合。

Zod 3 のコードベースには適用しないでください（レビュアープロンプトの前提条件により、「GATE NOT APPLICABLE」で中止されます）。また、判定ではなく説明やリファクタリングをユーザーが求めている場合も適用しないでください。それは、厳選された zod 蒸留スキルの役割です。2 つの start- ルールは TanStack アプリ以外では N/A となります。それ以外のゲートは、Zod 4 を使うあらゆる TypeScript プロジェクトで機能します。

レビュープロトコル

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

1. 対象を特定する。 レビュー対象（差分、ファイル一式、PR）を正確に特定し、曖昧さのない固定された対象に対してレビューできるよう、ref／パスを記録します。対象パスには必ず package.json を含めてください。Zod 4 の前提条件と pkg-、compose-native-json-schema、start- アダプタールールは、差分で package.json に触れていない場合でも、依存関係の指定によって判断されるためです。
2. ルールを読み込む。 references/_sections.md と、references/ 内のすべてのルールファイル（すべての sem-*.md、gone-*.md、err-*.md、dep-*.md、compose-*.md、start-*.md、pkg-*.md ファイル）を読みます。
3. レビュアープロンプトを構成する。 ルールと対象を references/reviewer-prompt.md に記入します。構成したプロンプトは完全に自己完結していなければなりません。レビュアーには会話履歴が見えないため、プロンプト外のコンテキストを参照してはなりません。
4. ブラインドレビュアーを 1 人起動する。 構成したプロンプト全体を唯一の入力とする Task サブエージェントを 1 つ起動します。会話コンテキストや、それに添えるコメントを含めてはなりません。
5. 不合格側に倒して判定する。 レビュアーの構造化出力を判定結果とし、統合ステップはありません。すべてのルールが PASS または N/A の場合にのみ、全体の判定は PASS となります。1 つでも FAIL があれば、ゲートは不合格です。重大度の平均化、重み付け、ルールの免除はしないでください。「軽微な」FAIL も FAIL です。レビュアーが「GATE NOT APPLICABLE」（Zod 3 または Zod なし）を返した場合は、判定結果ではなく、その旨を報告して終了します。
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	暗黙的なセマンティクスの破損	sem-	パースされたデフォルト値に対する .prefault()、疎な列挙型キーに対する z.partialRecord()、文字列フラグに対する z.stringbool()
2	削除された API	gone-	.ip()/.cidr()、単一引数の z.record()、エラーパラメーターの 3 点セット、.errors ゲッター、関数ファクトリー、存在しない z.interface()
3	エラーのカスタマイズとフォーマット	err-	message に代わる統一された error パラメーター、トップレベルの z.treeifyError/z.flattenError/z.prettifyError
4	非推奨のメソッド形式	dep-	トップレベルの文字列フォーマット、z.strictObject/z.looseObject、.merge より .extend、z.nativeEnum より z.enum、z.int()、z.promise() は使用しない
5	合成、再帰、コーデック	compose-	ゲッターによる再帰、双方向のワイヤー変換に対する z.codec()、ネイティブの z.toJSONSchema()
6	TanStack Start との統合	start-	.validator() に渡すスキーマ単体、アダプター不要の validateSearch
7	パッケージングとインポート	pkg-	ルートの "zod" インポートパス、ハードなバンドル制約がある場合に限り zod/mini を使用

関連スキル

• zod（厳選版）— Zod の使い方を教えるスタイルでまとめた資料です。判定ではなく説明やリファクタリングが目的の場合に使用します。
• adversarial-tanstack — TanStack Start アプリ向けのフレームワークレベルのゲートです。Start の差分を十分に網羅するには、両方を実行してください（このスキルの serverfn-validate-input はバリデーターの存在を確認し、このゲートの start- ルールはバリデーターが最新の Zod 4 のパターンを使っているか確認します）。

参照ファイル

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