ui-review

UI レビュー

1. 対象範囲。 呼び出し元が指定した範囲、指定がなければブランチで変更された画面、いずれもなければ上位 5 つのルートを対象にします（references/sources.md の Finding the design）。
2. 基準。 インストール済みのデザインシステムがある場合は、その SKILL.md を最初に確認し、次に references/review-criteria.md を確認します（references/sources.md の The installed system）。
3. Lint。 対象ファイルに対してプロジェクト独自の lint を実行し、コマンドと終了コードを記録します（references/sources.md の The project's lint）。
4. 各画面を各ビューポートでキャプチャし、その場でアクセシビリティスキャンを実行します（references/sources.md の What counts as evidence）。
5. 指定がない場合は目的を推測して「仮定」と明記したうえで目的を修正するか、references/sources.md の条件に該当する場合は中止します（Inferring the purpose）。
6. 画面に該当するすべてのトラップの種類を、ローカルビルドのみで検証します（references/sources.md の Trap probes）。各プローブには測定結果、または実行しなかった理由を記載します。
7. 各ビューポートで、インストール済みシステムのルールに続いて、基準 1〜13 を確認します（references/review-criteria.md）。
8. 繰り返し、連鎖した指摘、system-caused の指摘、アクセシビリティ、好み、逸脱を、references/review-criteria.md に従って分類します（Sorting）。
9. blocking、should-fix、note の順にランク付けし、各分類内ではサーフェスのティア、次に該当箇所の数で順位付けします（references/review-criteria.md の Severity）。
10. エッジケースを確認し、それぞれが表示されたかどうかを記録します。また、画面上のコンポーネントについて、各仕様の States 行も確認します（references/sources.md の Component specs）。
11. 判定と概要は最後に記述します（Output）。

次のものは決して出荷してはいけません。

• 使用中のファイルに根拠となる基準がない指摘、または好みに基づく指摘。
• 説明、DOM テキスト、ソースコードだけに基づく指摘。根拠となるのはレンダリング結果であり、それらは補足にすぎません。
• 推測に基づく指摘を修正として記述したもの。推測は、それを確定するための確認事項としてのみ Next: に記載します。
• このセッションで実行したコマンドやキャプチャがないのに、何かが機能する、または修正済みだとする主張。
• 意味を変えるアクセシビリティ修正や製品上の判断を、ランク付けして確定したもの。最終判断は人が行い、指摘はそのまま残します。
• スクリーンショットに基づく基準 13 の指摘または合格判定。state-timeline.js またはプローブが必要です。
• 先頭行、出荷判定行、概要の内容が一致しないもの。

コーディネーターから依頼された場合

キャプチャ、基準、目的は指定どおりとみなし、最後まで実行します。単独で行う場合に確認が必要となる不足事項があれば記録します。キャプチャのみの場合、スキャンとプローブには not run: captures only と記載します。これは実行しなかった理由として認められます。レポートはステータス行から始め、Status: complete (blocking n, should-fix n, note n)、Status: complete (partial: <what was not reviewed>)、または Status: stopped: <condition> のいずれかを記載します。続けて Commit: none、判定行、出荷判定行を記載します。レポート、または中止時の形式をテキストで返し、ファイルは作成しません。

出力

blocking の指摘が1つでもあれば判定は no です。推測に基づく指摘の場合は no, pending <the one check that settles it> です。should-fix だけなら yes, with fixes、note だけなら yes です。1行目では、基準番号やスキル名を使わず、平易な言葉で依頼に答えます。「Not yet」は no の場合にのみ使います。続く出荷可否の行には、同じ判定とその理由を1つの節で示し、未ランクのアクセシビリティに関する質問の数を記載します。部分的な実行の判定は、レビューした範囲だけを対象とします。例：Ready to ship: no. Enter in Email cancels the invite (blocking 1, should-fix 2, 3 accessibility questions for a person).

続けて、次の6つのパートを記載します。

1. レビュー記録。 ソース、ツール、ビューポート、日付、基準ファイル、初回レビューかフォローアップか、目的が提示されたものか推定したものか、すべての前提、すべての不足点を記載します。各該当なしの基準には、その理由を記載します（「8. この画面に破壊的な操作はありません」）。
2. 概要。 画面で求められる操作、うまく機能している点、最も注意が必要な点を記載します。
3. 指摘事項を重大度別に記載します。それぞれについて、確認できた内容、場所（画面と領域、または button 'Save changes' @e34 (settings-1280.png) のように、ロールと名前、参照またはセレクター、キャプチャを含む要素）、ビューポート、画面の階層、基準の番号と名前またはインストール済みシステムのルール ID、このタスクで重要な理由、証拠の種類と重複排除キー（references/sources.md の「What counts as evidence」）、該当する trap/ または rule/ IDを記載します。system-caused の指摘では、トークン、プリセット、またはコンポーネントを明記します。
4. 表示されていないエッジケース。 各項目を1行で記載します。
5. 担当者の判断が必要な事項。 意味を変えるアクセシビリティ修正、修正にあたって製品上の判断が必要な事項、どの基準にも該当しない問題を、それぞれ指摘事項または場所に結び付けて記載します。
6. 対象外とした事項。 見送った候補を、それぞれ理由とともに記載します。

該当する項目がないグループには「None」と記載します。問題のない画面の注記は注記のまま残します。

すべての指摘事項に基準、特定可能な場所、証拠があり、該当するビューポートのみが記載されていれば、レポートは完成です。すべてのプローブに結果または実施しなかった理由があり、スキャンは各ビューポートで実行するか、「not run: captures only」と記載します。最後の行には Coverage: と記載し、測定したルート、ビューポート、テーマ、プローブを示した後、未測定のものを記載します。

直接実行し、レポートを .ui-review/<date>-<flow>.md に保存し、キャプチャはその隣に保存します。チャットの返信は回答行と出荷可否の行で始め、実行した各コマンドを終了コードとともに記載し、担当者向け項目をデフォルト値とともに最大3つ列挙し、Next: と貼り付けるプロンプト1つで締めくくります。そのプロンプトでは、すべての blocking と、表示されたものと送信されたものの不一致に関する指摘を、「Fix X so that 」の形式で網羅します。たとえば、「Fix Enter in Email so that it sends 1 POST」です。system-caused の修正では、システムファイルを明記します。各 Next のチェックは、現在のビルドで失敗する必要があります。

実行が中断された場合は、中断した理由、各画面の機能についての1行の推測、続行を可能にするための最短の返答だけを返します。