ui-verificationlisted

# UI Verification 本SkillはUI検証の正本である。設計・実装まで含む一貫したUI作業では `$ui-quality` を 使い、その検証段階として本Skillの規定（起動経路、検証matrix、証跡）を適用する。 ## 使用条件 - layout、component、style、interaction、navigation、loading/error/empty stateを変更する - screenshot、reference image、design token、visual consistencyが要求される - responsive、keyboard、focus、accessibility、scroll、async updateが関係する ## 1. 実装前brief 短く固定する。 ```markdown ## UI brief - 対象surface: Web / macOS / iOS / CLI TUI / その他 - 主な利用者とtask: - 主要action: - 視覚階層: - 対象size / theme / input method: - 必須state: normal / long / loading / success / error / empty / disabled - 既存token・component・reference: - 実画面の起動・検証経路: ``` 各screenまたはvisual regionの主要actionは原則1つにする。既存design systemを唯一の基準として再利用し、並行する体系を増やさない。 ## 2. 実装 - 既存component、token、spacing、typography、interaction patternに合わせる。 - 1回限りのvalueで既存tokenを上書きしない。 - stateごとにlayoutへ影響してよい範囲を明確にする。 - async updateで本文、page、scroll、selection、focusが意図せず変わらないようにする。 - dynamic layoutは表示mode、page reset、layout calculation、state transitionをtestする。 - 並列作業ではUI sourceのimplementation ownerを1人に限定し、他agentはread-only reviewを基本とする。 ## 3. 実画面を起動する - Webでは、project付属のUI/E2E command、project dependency、local/global Playwright、installed browser、browser/DevTools系toolの順に、安全に使える実行経路を確認する。共有browserが利用できないことだけを理由に打ち切らない。 - Playwrightと対応browserが利用可能なら、必ず実行する。ただし `UI_BROWSER_VERIFICATION=screenshots` のときは自動検証を省略してよく、���わりに検証matrixの主要な組合せのスクショを `_ai/tasks/<開始日-slug>/screenshots/` へ保存し、保存先を報告してユーザー目視へ委ねる。`off` のときは実画面確認を全面免除し、最終報告へ未検証と明記する。自動install、package追加、browser