w-ui

ユーザー向けの画面を構築または再設計します。UI 作業を伴わない機能計画は /w-plan で行います。プリミティブのインストールは /w-shadcn で行います。PRODUCT.md や DESIGN.md を勝手に作成しないでください。既存のトークンと、ルートに DESIGN.md がある場合はそれに従ってください。アニメーションライブラリやデザイン検出用フックをインストールしないでください。

ビジュアルの方向性には frontend-design、再利用可能な API には composition-patterns、UI コードのチェックリストには web-design-guidelines を読み込みます。継続的に参照する情報は、該当する MDX／README／DESIGN.md に記載します。

1. 作業内容、対象となる人、画面のモードを明確にします。モードは、操作（アプリ／タスク）、訴求（マーケティング）、閲覧（ドキュメント）のいずれかです。
2. ブリーフ、既存の画面、または明示された美的方針を利用します。リポジトリにトークンと共有コンポーネントがある場合は、まずそれらを確認します。
3. 共有プリミティブを優先します。2 つ目の呼び出し箇所で合成します。単発のルートのために複合 API を切り出さないでください。サーバーデータをクライアントプロバイダーに移さないでください。
4. モバイルファーストのレイアウト、視認できるフォーカス、キーボード操作の経路、prefers-reduced-motion に対応します。新しいモーションライブラリは追加しないでください。
5. 該当する場合は、読み込み中、空の状態、エラー、成功、オーバーフローに対応します。
6. 作業を完了するために必要な、最小限の範囲を実装します。
7. デスクトップとモバイルを合わせて確認します。主要な操作とキーボード操作を試します。スクリーンショットを批評します。根拠のある問題を一度のまとめ作業で修正します。確認は追加でもう 1 回まで行い、その後は終了します。ブラウザーツールがない場合は、その旨を伝えます。型チェックはビジュアル QA の代わりにはなりません。
8. 任意：既存の a11y ドキュメントとテストに照らして /w-a11y を実行します（WCAG レベルを勝手に設定しないでください）。既存の spec で対象の経路がカバーされている場合に限り、Playwright E2E を実行します。
9. ドキュメント：動作やコマンドを変更した場合は /w-docs を実行します。