dxe

dxe

インターフェースをレビューする際は、次の優先順位に従います。

1. 装飾より意図を優先します。
2. 見た目の都合より、正しいセマンティクスとアクセシビリティを優先します。
3. 実装手法より操作感を優先します。意図した操作感を保てる範囲で、最もネイティブな実装を使用します。
4. プロトタイプの巧妙さより、本番環境での信頼性を優先します。

開始前に references/dxe-core.md を読んでください。これはすべてのモードで共通の評価基準です。既定では、他のスキルをすべて読み込まないでください。

モード

リクエストからモードを推測します。指定がない場合は review を使用します。

dxe の後にパスが指定されている場合は、そのパスを対象にして各モードを適用します。「すべてのスキルを適用して」という指示は、dxe exhaustive として扱います。

モード	対象範囲	変更
dxe quick	代表的な画面を1つ対象に共通の評価基準を適用します。不可欠な場合を除き、他のスキルは読み込みません	なし
dxe / dxe review	エビデンスマトリクス全体とリポジトリ内の代表的なサンプルを確認し、必要に応じて関連する他のスキルを段階的に読み込みます	なし
dxe fix	レビュー後、範囲を限定した確度の高い修正を実装し、検証します	あり（リクエストされた範囲内）
dxe exhaustive	確認可能なすべての画面を調査し、関連する他のスキル一式を読み込みます	ユーザーから修正も依頼された場合を除き、なし

レビュー・モードでは、いかなる変更も行いません。ファイルの編集、依存関係のインストール、外部への変更の開始、本番システムの変更は禁止です。読み取り専用の調査とローカルでの検証は可能です。修正モードでは、無関係な作業と既存のデザインシステムの成果物を維持してください。

対象範囲とサンプリング

リポジトリまたはパス、主要なユーザータスク、技術スタック、トークン、プリミティブ、インタラクション／ランタイムライブラリを特定します。独自の代替を考案するより、既存の資材を優先してください。

リポジトリをレビューする場合、すべての画面を同じ程度に確認したかのように示すのではなく、代表的な画面を選んでください。

• 主要なランディングページまたはタスクページ
• 該当する場合は、コンテンツ／詳細ページと一覧／インデックスページ
• 1つのフォームまたは変更フロー
• 1つのオーバーレイ、ダイアログ、またはメニュー
• 利用可能な読み込み状態、空の状態、またはエラー状態
• 主要なフォームファクターと対照的なフォームファクター、関連する入力方法、動きを減らす設定のバリエーション

レポートには、確認対象から除外したものを明記してください。網羅的モードでは、調査を始める前に、確認可能なすべての画面と状態を列挙してください。

エビデンスの方針

短い仮説と対象外事項を記し、その後、モードに応じて必要最小限のエビデンスを収集します。通常のレビュー／修正では、次の内容を記録します。

エビデンス	最低限の内容
資料	スタック、トークン、プリミティブ、モーション／ランタイムライブラリ
ソース	代表的なルートと共有コンポーネント
検証	安全に実施でき、利用可能な場合は、既存の型チェック／テストと本番ビルド
フォームファクター	描画された主要レイアウトと対照的なレイアウト、クリッピング／オーバーフロー、タスクの階層
インタラクション	最初の意味のある入力シーケンス、オーバーレイ／メニュー／シートの状態、関連する場合は戻る操作とタッチ／ポインター／キーボードの一貫性
アクセシビリティ	プラットフォーム名、ロール／特性／セマンティクス、状態、フォーカス／復帰、動きを減らす設定
本番環境	読み込み／エラー／空の状態での動作、プラットフォームメタデータ、プラットフォーム固有のランタイムログ
確信度	confirmed-rendered、confirmed-source、likely、unverified、environment-only

ソースの調査だけで、描画上の不具合があると断定しないでください。描画やチェックが利用できない場合は、推測せず、その制約を明記してください。

観察事項は、次のように分類してください。

1. 確認済みのプロダクトの不具合；
2. ソースレベルのリスク；
3. 環境またはツールの問題；
4. 未検証の疑い。

ツールのノイズをプロダクト上の問題として報告する前に、ユーザーに見える不具合を再現してください。ブラウザーエラー、サーバーエラー、想定内のローカルサービスの失敗、フレームワーク／ツールの警告を区別してください。

状態変化を起こすチェックでは、状態を記録する前に、観察可能な安定状態になるまで待ってください。任意の待ち時間よりも、対象プラットフォームのアクセシビリティ／セマンティクスの値、フォーカスの移動先、遷移の完了、またはアニメーションの収束を優先してください。描画やアニメーションがまだ進行中の場合、アクション直後のサンプルを最終的なエビデンスとして報告しないでください。

提供対象のプラットフォームに合った検証レーンを選択してください。

プラットフォーム	必須のランタイムエビデンス
Web	ブラウザーのconsole.error、未捕捉のpageerror、サーバーログ、レスポンシブ時のオーバーフロー、キーボード操作のシーケンス
Apple native	利用可能な場合はXcodeのビルド／テスト、シミュレーター／デバイスの診断、アクセシビリティの検査、Dynamic Type、対象フォームファクター
Android native	利用可能な場合はGradleのビルド／テスト、Logcatのエラー／致命的エラー、セマンティクス／TalkBackのチェック、フォントスケール、対象ウィンドウサイズ

コンパクトなフェーズ横断チェック

すべてのフェーズを検討しますが、各フェーズで無理に問題を見つける必要はありません。

意図

• インターフェースがユーザーのどのような目的達成を支援するのかを明記します。
• 重複するアクション、説明のない装飾、生成による残留物を削除対象として示します。
• 目的が明確で役立つ要素は維持します。

プラットフォーム

• divとARIAによる再構成より、ネイティブ要素と状態の契約を優先します。
• ナビゲーション／フォーカス順序、名前、ロール、状態、無効時の動作、フォームへの参加を確認します。
• 動作を損なわずに表現できる場合は、ネイティブのCSS／HTMLを優先します。

使用感

• キーボード、タッチ、精密ポインターで入力方法を見つけやすいか確認します。
• モーションは応答性が高く、必要に応じて中断でき、動きを減らす設定に対応する経路が必要です。
• 喜びをもたらす工夫は、期待感、信頼性、配慮を高めるものであるべきです。目的のない新奇さを加えるべきではありません。

橋渡し

• デザイン構造が、コード、トークン、プリミティブ、描画、アクセシビリティに意図的に対応しているか確認します。
• 既存のシステムと相容れない個別の値や抽象化があれば指摘します。

リリース

• 関連する読み込み、空の状態、エラー、認証、検証、フォーカス、メタデータ、繰り返し利用の各経路を試します。
• プロトタイプ上の簡略化と、確認済みのリリースリスクを区別します。
• 網羅的なテストを求めるのではなく、重要な契約を対象とするテストを確認します。

段階的な兄弟スキルのルーティング

資料マップ、初期の根拠、または要求された深さによって必要になった場合にのみ、兄弟の SKILL.md を読み込みます。コレクション内の兄弟スキルはこのスキルの隣にインストールされるため、レンズを利用できないと判断する前に、まず ../<skill-name>/SKILL.md を解決してください。兄弟スキルが存在し、読み取り可能であれば、このセッションの検出レジストリに登録されていなくても、その内容を使用してください。レジストリの更新が必要なのは、個別に呼び出せるスキルとして公開する場合だけであり、現在のパスを続行するためではありません。検出結果にも隣接パスにも読み取り可能なスキルがない場合は、共有ルーブリックに沿って続行し、欠けているレンズを明記したうえで、その詳細なガイダンスを創作しないでください。

トリガー	読み込むスキル
プロダクトの意図が不明確、または意思決定に根拠が必要	write-first-design
装飾的、冗長、または認知的負荷の高い UI	subtractive-design
デンマーク機能主義のデザインレンズが求められている	humane-functionalism
Web フォーム、メニュー、ダイアログ、カスタムコントロール、またはセマンティクス上の問題	semantic-html-first
Web のレスポンシブレイアウト、または CSS/HTML の実装に関する質問	modern-css-html
SwiftUI、UIKit、AppKit、Xcode、または Apple プラットフォームの UI	apple-native-ui
Kotlin、Android Gradle、Jetpack Compose、Android Views、または Compose Multiplatform	android-native-ui
ジェスチャー、スプリング、割り込み、または共有要素のモーション	fluid-design
発見しにくさ、ホバー時のみのアクション、または入力方法の不一致	interface-affordances
有用な仕上げを加える具体的な機会	product-delight
デザインやコードの構造、またはトークンの変換に問題が生じている	design-engineering
重大なインタラクションの挙動が未定義、または一貫していない	interaction-contracts
共有コンポーネントやトークンモデルに、互換性または移行の判断が必要	design-system-evolution
セットアップ、待機、または中断が繰り返され、反復作業のコストが高い	design-for-repetition
プレースホルダーや均一なコンテンツが、階層やレイアウトの判断を妨げている	real-content-design
テンプレート的、または AI 生成の残留物を評価する必要がある	ai-output-judgement
認証、検証、状態、レジリエンス、またはリリースに関する懸念	prototype-to-production

dxe exhaustive モードでのみ、ルーティング表にあるすべての兄弟スキルを読む必要があります。

重大度と確信度

• 重大: 主要なタスクを妨げる、データやセキュリティの損失を招く、深刻なアクセシビリティ上の問題が確認されている、または本番環境でのレンダリングを破損させるもの。
• 修正すべき: 理解、ナビゲーション、セマンティクス、レジリエンス、または信頼への悪影響が確認されており、修正範囲が限定されているもの。
• あれば望ましい: 磨き込み、一貫性、休眠中のプリミティブのリスク、またはブロッキングではないクリーンアップ。

すべての指摘に、確信度タグを1つ付けてください。unverified または environment-only の観察事項を「重大」に分類してはいけません。引用するのは必要最小限のソース断片にとどめ、パスまたはレンダリングされた画面を根拠として示してください。

レポート

# dxe pass — [scope]

## Hypothesis
## Evidence collected
## Verified strengths
- [skill or core] path/surface — what should be preserved

## Findings
### Critical
- [confidence] [skill or core] path/surface — issue — bounded fix
### Should fix
### Nice to have

## Cuts
## Proposed changes
## Verification status
## Limits and unresolved observations

検証済みの強みは、慰めではなく根拠です。機能しており、今後の変更後も維持すべきシステムとして記録してください。重大度セクションが空でも問題ありません。指摘の数を無理に増やしてはいけません。

検証手順

ツールとリポジトリのスクリプトで実行できる場合は、次の手順を行います。

1. 既存の型チェック、テスト、本番ビルドを実行します。
2. メインの対象環境と、対照となるビューポート、ウィンドウ、デバイス、またはフォームファクターでレンダリングします。
3. プラットフォームの要件に応じて、クリッピング／オーバーフロー、安全領域／インセット、主要タスクの階層を確認します。
4. キーボード、タッチ、ポインター、リモート、または支援技術を使った最初の有意な操作シーケンスを記録します。
5. メニュー、ダイアログ、シート、またはナビゲーションの遷移を1つ試します。状態が安定するまで待ってから、状態とフォーカス／復帰を確認します。
6. 動きを伴うタスクを、視差効果を減らす設定でもう一度実行します。アニメーションの状態や回数を記録する前に、処理が落ち着くまで待ちます。
7. プラットフォームのランタイムエラーを取得します。ブラウザーの console.error／pageerror、Apple シミュレーター／デバイスの診断情報、または Android Logcat のエラー／致命的エラーが該当します。これらをツールのノイズとは分けて分類します。
8. 修正モードでは、影響を受けるチェックを繰り返し、正確な結果を報告します。

レビューの一環として、本番環境や外部システムを変更してはいけません。

完了条件

• 対象範囲、仮説、対象外の事項、サンプリング、制限事項が明示されています。
• すべてのフェーズを検討し、条件に該当した関連スキルのみを読み込んでいます。
• 主張は、根拠、重大度、確信度、およびパスまたは画面に結び付けられています。
• 確認済みの製品の不具合と、ツールのノイズや疑いが区別されています。
• 該当する場合は、既存の強みと削除による変更を記録しています。
• 許可された修正は、影響範囲を限定し、リスクに応じて検証されています。