adversarial-ios-design

アドバーサリアル iOS デザインゲート

iOS のデザインと UX を審査するゲートです。合否は、単独のブラインド審査サブエージェントが敵対的な立場でこのゲートのルールに照らして作業を評価し、すべてのルールが PASS または N/A の場合にのみ合格となります。このスキルは判定を下すものであり、作業を修正することはありません。

このゲートが審査するのは、ソーステキストではなく、レンダリングされたユーザーインターフェースです。証拠の収集（シミュレーターのスクリーンショットと、フィルムストリップに並べた操作録画）は必須のプロトコル手順です。審査者はピクセルから逆算して作業します。キャプチャを観察し、違反の可能性を疑い、その後でコードを開いて該当箇所を特定します。コードだけの審査は、このゲートで記録されている失敗パターンです。見たことのないアニメーションを指示するリンターへとゲートを変えてしまうためです。

ルールは、Apple のデザイン審査で指摘される内容のうち、判定可能な部分を対象にしています。各ルールには、判定に用いる証拠が明記されており、Human Interface Guidelines、WWDC のデザインセッション、Apple 自身が測定したアプリの慣例に基づいています。このゲートでは、エージェントや、経験はあるものの熟練者ではない開発者が実際に出荷してしまう失敗パターンを審査します。タブバーを置くべき場所にハンバーガードロワーを置く、スワイプで閉じると入力内容が失われるプッシュ表示のフォーム、「はい」「いいえ」と表示するアラート、空白の空状態、画面全体を覆うスピナー、状態変化の瞬間移動、コンテンツに描画されたガラス表現、アクセシビリティサイズでクリップするテキストなどです。

適用するタイミング

• ユーザー向けの SwiftUI 画面、機能、または PR のマージを控えており、助言的なフィードバックではなく、デザインと UX の品質について客観的な PASS／FAIL 判定が必要な場合。
• エージェント（Claude、Codex）が UI を作成し、それが Web／Android の慣例を Swift に置き換えたものではなく、プラットフォームの作法（モーダル表示、ナビゲーション構造、アラートの適切な使用、フィードバック状態）に従っているか、独立した確認を求める場合。
• 画面は「動く」もののネイティブらしく感じられず、好みを表す形容詞ではなく、判定可能な原因とその箇所を列挙したい場合。
• デザインの仕上げで Apple レベルの品質を目指したと主張しており、コードから推測される内容ではなく、画面が実際にレンダリングするもの（スクリーンショットとフィルムストリップ）に照らして、その主張を検証したい場合。
• 以前の「仕上げ」やゲート主導の修正で UI が煩雑になり、アニメーション、触覚フィードバック、装飾が追加された場合に、抑制の方針を徹底したい場合。過剰な動きは不合格となり、すべての修正は最小限の変更でなければならず、追加より削除が優先されます。
• 差分でジェスチャーや操作の振る舞い（認識器、ドラッグ／長押し／サイズ変更、カスタムの ButtonStyle／PrimitiveButtonStyle 実装）が変更されている場合。このゲートとそのキャプチャプロトコルは、関連するアーキテクチャゲートより先に実行してください。認識器の競合はコードだけの審査では見えず、問題のない試行が一度あっただけでは証拠になりません（references/_evidence-capture.md の反復試行要件を参照）。このゲートを最後に回すと、審査済みに見える操作のリグレッションを出荷することになります。

SwiftUI のユーザーインターフェースを持たないターゲット（サーバー側 Swift、CLI ツール、UI のないパッケージ）には適用しないでください。審査者プロンプトの前提条件により、「GATE NOT APPLICABLE」で中止されます。SwiftUI のアーキテクチャと更新の仕組み（Observation、ビューの同一性、タスクのライフサイクル、リスト構築）は関連する adversarial-swift-ui ゲートの担当であり、Swift 言語としての品質は adversarial-swift の担当です。このゲートでは判定できない好みの判断（ヒーローのスケール、感情的な意図、構図）は ios-taste の対象です。対象外の項目は gotchas.md に記載されています。修正にプロジェクトより新しいデプロイメントターゲットが必要なルールは FAIL ではなく N/A です。審査者プロンプトにはバージョンゲートの表が含まれています。

審査プロトコル

以下の手順を正確に実行してください。すべての審査を同じ方法で実施することが、このゲートの価値です。

手順 1 の前に、2 つの前提条件があります。どちらも、このゲートファミリーで記録されている現場の失敗パターンを受けて設けられたものです（2026 年 7 月：変化し続ける対象をクリーンアップの対象としてゲートを実行した結果、差分が 33 ファイルに増えるまで判定が一つも出ませんでした）。

• 固定されたターゲット。 ターゲットマニフェストに記録された固定の参照先、つまりコミット SHA、stash、または保存済みの差分に対してのみディスパッチします。レビュー対象のコードがまだ変更中の場合（ワークツリーに編集が追加され続けている、ほかのエージェントが作業中など）は、ディスパッチしないでください。レビュアーの作業中にターゲットが変わった場合、その実行は無効です。判定の代わりに GATE VOID — target changed と報告し、新たに固定した状態に対して再ディスパッチしてください。ディスパッチされたゲートは、必ずレンダリングされた判定、GATE NOT APPLICABLE、または記録された無効化のいずれかで終了させてください。「レビュー済み」と区別できない無応答のままにしてはいけません。
• クリーンアップではなく判定。 このゲートは、完成した作業に対する最終チェックです。「ゲートを実行して、すべてを徹底的に修正する」という考え方は、この契約を逆転させるものであり、スコープの肥大化につながると明示されている手順です。まず実装し、固定してから、ゲートを実行してください。FAIL の後、呼び出し元は元のターゲットの範囲内でのみ修正を適用します。その後のゲートでは、同じターゲットマニフェストに対して新たなブラインドレビュアーをディスパッチします。ラウンド間で対象範囲が広がることはありません。新しいコードには、それぞれ独自のマニフェストを持つ新たなゲート呼び出しが必要です。

レビュー中にほかのエージェントがワークスペースを変更する可能性がある場合、レビュアーはライブのチェックアウトではなく、不変のスナップショット（例：git archive <ref> <skill-dir> | tar -x -C "$TMPDIR"）からルールを読み込みます。また、スキルディレクトリは読み取り専用のインフラストラクチャであり、あらゆるクリーンアップや修正の対象範囲から除外してください。

1. 対象を特定します。 レビュー対象（差分、ファイル一式、PR、1 画面、または一連の画面遷移）を正確に定め、レビュー対象が曖昧さのない固定されたものとなるよう、ref とパスを記録します。Swift ツールチェーンと最小デプロイターゲットも記録してください。いくつかのルールはこれらのバージョンによって適用条件が変わります。リポジトリのルートも含めてください。nav-stack-per-tab、flow-onboarding-optional、state-launch-screen-replica では、差分の範囲外にある App のエントリポイント、Info.plist、アセットカタログも確認する必要が生じる場合があります。
2. レンダリング済みの証拠を取得します。 references/_evidence-capture.md に従います。まず、キャプチャが可能か事前確認します（シミュレーターを起動し、使い捨てのスクリーンショットを 1 枚撮影します。失敗した場合は、レビュー開始から数時間後ではなく、その時点で具体的なブロッカーを記録します）。次に、対象をシミュレーターでビルドして実行し、影響を受けるすべての画面についてライトモード、ダークモード、アクセシビリティサイズのスクリーンショットを撮影します。また、構造を変化させる操作はすべて 10 fps のフィルムストリップに記録し、主要な画面ごとに短いアイドル録画も撮影します。ジェスチャーを伴う操作は、同じアプリセッション内で 3 回以上連続して記録する必要があります。認識器の調停を判断する根拠として、1 回だけの成功した実行では不十分です。この手順は必須です。名前を明記したブロッカーがある場合に限り省略できます（プロジェクトがビルドできない、利用できるシミュレーターランタイムがない、認証情報がないと画面に到達できないなど）。ブロッカーは判定ヘッダーに記録してください。キャプチャがない場合、スクリーンショット依存の項目は N/A となり、モーションルールは候補の報告しかできません。FAIL にも PASS にもしてはいけません。
3. ルールを読み込みます。 references/_sections.md と、references/ 内のすべてのルールファイル（すべての nav-*.md、flow-*.md、layout-*.md、color-*.md、type-*.md、glass-*.md、state-*.md、motion-*.md、haptic-*.md、craft-*.md ファイル）を読みます。
4. レビュープロンプトを作成します。 ルール、対象、ツールチェーン／デプロイに関する情報、絶対パスで指定したスクリーンショット、録画、フィルムストリップの各パス（または名前を明記したキャプチャのブロッカー）を含め、references/reviewer-prompt.md を埋めます。作成したプロンプトだけで完全に内容が把握できるようにしてください。レビュー担当者には会話履歴が見えないため、プロンプト外のコンテキストを参照してはいけません。
5. ブラインドレビュー担当者を 1 人起動します。 入力全体が作成したプロンプトのみとなる Task サブエージェントを 1 つ起動します。会話のコンテキストや、プロンプトと一緒に渡すコメントは含めません。
6. フェイルクローズで判定します。 レビュー担当者の構造化出力を判定とし、結果を統合する手順はありません。すべてのルールが PASS または N/A の場合に限り、総合判定は PASS です。FAIL が 1 つでもあればゲートは失敗です。平均を取ったり、重大度を考慮したり、ルールの適用を免除したりしてはいけません。「軽微な」FAIL も FAIL です。レビュー担当者が「GATE NOT APPLICABLE」（SwiftUI の UI サーフェスがない）を返した場合は、判定を出さずに終了し、その結果を報告してください。
7. 判定を出力します。 assets/templates/verdict.md を埋めます。FAIL の場合は、レビュー担当者の「PASS に必要な不足事項」に関する提案を、カテゴリの重要度順に並べ、それぞれの場所を示した修正リストにまとめます。最終結果が FAIL のルールはすべて修正リストに含め、記載どおりに適用できる具体的な変更を示してください。レビュー担当者の提案が違反内容を言い換えただけの場合は、出力前にルールの Correct 例を基に修正内容を導き出します。出力前にすべての修正について最小性のテストを実施してください。そのルールを PASS にする最小の変更を選び、追加より削除を優先し、ルールで指定された対応を超えるものは何も追加してはいけません。たとえば、アニメーション、触覚フィードバック、ビュー、状態、抽象化などを追加しません。修正リストは作業キューではなく、各 FAIL が判断可能で、変更によって解消できることを示す検証資料です。修正は宣言した対象の範囲内にとどめます。対象マニフェストの範囲外でレビュー担当者が見つけた違反は、判定の対象外の所見に記載し、次回のゲート実行に向けて報告してください。今回のゲートでは修正せず、判定にも含めません。 同一のルールが、変更されていない対象の再レビューごとに判定を変える場合や、人が証拠を確認して判定を覆す場合、そのルールには決定可能性のバグがあります。gotchas.md に記録し、ルールを明確化してください。ゲートの判定を覆してはいけません。

判定形式

レビュー担当者は、ルールごとに PASS | FAIL | N/A、証拠（file:line、引用、または名前付きのスクリーンショット領域。PASS と FAIL の両方で必須）、そして FAIL ごとに、適用後にルールが PASS に変わる修正（違反内容を言い換えるのではなく、変更内容とその場所を明記）を返します。最終レポートは assets/templates/verdict.md に従います。

ルールのカテゴリー

#	カテゴリー	プレフィックス	対象
1	ナビゲーションと情報アーキテクチャ	nav-	ドロワーやボタングリッドではなく TabView を使うこと、タブは操作ではなく画面遷移に使うこと、タブは 5 個以下にすること、タブバーを安定して表示すること、タブごとに NavigationStack を 1 つ設けること、システムの戻るボタンを使うこと、すべての画面にタイトルを付けること、システムの機能を使って検索すること
2	モダリティとフローの文法	flow-	自己完結型のタスクにはシートを使うこと、左側にキャンセル、右側に完了を配置すること、変更済みのシートを誤って閉じないようにすること、メディアや複数ステップのフロー以外には fullScreenCover を使わないこと、一度に表示するシートは 1 つだけにすること、実行可能な操作がある場合にのみアラートを表示し、動詞のボタンを使うこと、意図的に破壊的な操作には confirmationDialog を使うこと、取り消し可能な削除では確認を求めないこと、オンボーディングを任意とし、権限は適切な文脈で求めること、文脈に応じた設定は最小限にすること
3	レイアウトと視覚的階層	layout-	44×44 pt のタップ領域とその周囲の余白を確保すること、ボタンを画面の端から内側に配置すること、背景はセーフエリアまで広げ、コンテンツはセーフエリアを尊重すること、Dynamic Type のテキストを固定高さの領域に閉じ込めないこと、入れ子になった角丸の半径を同心円状にすること
4	色とコントラスト	color-	システムの背景色を使うこと、セマンティックなラベルの階層を使うこと、セマンティックな役割を維持すること、数値で定めたコントラストの下限を満たすこと、色だけで状態を示さないこと、カスタムカラーや画像にはダーク用のバリエーションを用意すること、テキストと画像の間に読みやすさを保つレイヤーを設けること
5	タイポグラフィ	type-	最小サイズを 11 pt とすること、UI のテキストに Ultralight／Thin／Light を使わないこと、セクション見出しにはタイトルスタイルを使うこと
6	マテリアルと Liquid Glass	glass-	Glass はフローティングレイヤーでのみ使用し、Glass 同士を重ねないこと、各バーの色付きアクションは 1 つにすること、バーの背後に塗りを置かず、スクロール端のスタイルを混在させないこと
7	フィードバック状態	state-	空の状態を設計すること、画面全体をスピナーで覆うのではなくスケルトンを使うこと、曖昧なラベルを使わず進捗を明示すること、エラー状態に原因と復旧方法を示すこと、起動画面のレプリカはクロームのみとすること
8	モーション	motion-	録画を主な証拠とすること：フィルムストリップで、瞬間移動、長すぎるフィードバック、クロームのオーバーシュート、ズームの代わりにスライドする動き、不要な装飾を判定します。イーズ曲線よりスプリングを優先し、Reduce Motion の経路はコードから判定可能にします。それ以外では、コードのみで候補を絞り込みます
9	ハプティクス	haptic-	重要な結果には成功／エラーのハプティクスを使うこと、過剰なトリガーを使わないこと、パターンの意味を文書化すること、標準コントロールで二重に発生させないこと
10	作り込み	craft-	固定幅の数字に数値テキストのトランジションを使うこと、SF Symbols のサイズ指定にはテキスト API を使い、ウェイト／バリエーションを一致させること、外観を固定しないこと

注意事項

レビュー担当者を割り当てる前に gotchas.md を読んでください。ルールの忠実性を守るためのガード（フォント／カラーのリテラルに関する兄弟ゲートの境界、削除確認の双方向ルール、単一のアクセントルールが存在しないこと）、しきい値の根拠（導出された 0.5 s のモーション上限）、スクリーンショットの証拠に関するプロトコル、およびこのゲートが意図的に除外している判断事項が事前に記録されています。

関連スキル

• adversarial-swift-ui — SwiftUI のアーキテクチャと更新の仕組み（監視、識別性、タスクのライフサイクル、リスト、アニメーションの適用範囲）を対象とする関連ゲートです。ユーザー向けの SwiftUI 作業では両方を実行してください。差分がジェスチャーや操作の挙動に関わる場合は、こちらのゲートを先に実行します。
• adversarial-swift — 複合的な作業における Swift 言語の懸念事項を対象とする関連ゲートです。
• ios-taste（厳選）— このゲートでは意図的に除外している、判断を要するデザインの指針です。画面のデザインにはこちらを使い、判断可能なレイヤーの検証にはこのゲートを使ってください。
• design-review（厳選）— このゲートの視点に相当する、助言を提供する Web UI 向けのツールです。

参照ファイル

ファイル	説明
references/_evidence-capture.md	必須のキャプチャ手順：シミュレーターのスクリーンショット、操作の録画、ffmpeg のフィルムストリップ、およびその確認方法
references/reviewer-prompt.md	ブラインドレビュー用の自己完結型プロンプトテンプレート。バージョンゲート、コードより先にピクセルを確認するレビュー順序、キャプチャ手順を含みます
assets/templates/verdict.md	判定レポートのテンプレート
references/_sections.md	カテゴリーの定義と順序
metadata.json	バージョンとソースの参照情報