ui-concept-implement

採用済みのUI画像案・カンプを操作できる画面へ落とし込み、スクリーンショットレビューでHigh/Mediumの漏れがなくなるまで仕上げる。カンプの画像一枚を表示しただけのものを実装としない。

作業範囲と参照資料

• 納品範囲を素材のみ／組み合わせプレビューまで／アプリ実装までで定める。素材のみなら本体を変更せず、実装までの依頼なら素材納品で止めない。
• 素材の分解・生成・配信用整備が必要なら、作成前に 素材化と受け渡し を読む。素材のみの依頼では、その完了条件で納品する。
• UIの方向性を比較する画像そのものが必要なら ui-design-concepts を使う。採用済み案の実装だけのために、新たな比較案や再承認を挟まない。

絶対ルール

• main Codex が最終判断、実装統合、検証、commit / push / PR を担当する。
• レビュー用サブエージェントは評価担当に限定し、修正の採否は main Codex が決める。
• ユーザーが変更・削除を指示した箇所、プロジェクトのデザインシステム、既存UI制約により参照画像と差が出ることは正常差分として扱う。
• 参照画像をそのまま模写せず、ユーザー指示と実アプリの情報設計を優先する。
• High/Medium 指摘は原則すべて解消する。解消不能なものは理由を明示して停止する。
• Low 指摘は最終報告に残してよく、自動修正ループの必須対象にしない。
• 既存の未コミット変更やユーザー作業を戻さない。

Workflow

1. 入力と根拠を確定する

次を確認してから実装に入る。

• 実装対象のUI画像を実際に開く。例: docs/DESIGN/**/concept_03_*.png。複数案を組み合わせる場合は要素ごとに採用元を特定し、不採用案を根拠にしない。
• 同じフォルダに prompts.md があれば、画像生成時の意図、参照UI、制約を読む。ない場合は提供画像と依頼から判断し、ファイルの不在だけで止めない。
• ユーザーの追加指示。削除対象、文言変更、優先順位、実装範囲を明確にする。
• AGENTS.md、既存UI、package.json、使用中のUIライブラリ、テーマ、ルーティング、状態管理。
• 既存画面がある場合はBrowserで現在UIを確認する。

不足情報がローカル調査で解決できない場合だけ、ユーザーへ短く確認する。

2. 実装方針を短く固定する

実装前に、以下を2〜6行で整理してから作業する。

• 参照画像から採用する構造
• ユーザー指示により変える/消す要素
• 既存デザインシステムに合わせて置き換える要素
• 対象端末・代表幅・最小対応幅と、幅に応じた配置の組み替え
• 触るファイルと検証コマンド

大きな作業では利用可能な計画機能または既存PLANで、実装・検証・修正の進捗を管理する。

カンプの縦横比を画面全体へ固定せず、読む順序と主要操作を保って幅・余白・カラム・改行・スクロールを設計する。PCではスマホ画像の拡大や無条件の横並びで済ませず、スマホでも承認済みの2列を自動で1列にしない。必要な内容は自然にスクロールさせ、ファーストビューへ収めるために文字や操作部品を縮めない。別端末の参照画像がなくても通常のレスポンシブ判断で補い、主要操作や採用構図が変わる不明点だけを確認する。

3. 実装する

• 既存コンポーネント、状態管理、ルーティング、デザイントークンを優先する。
• HeroUI / HeroUI Pro を使うプロジェクトでは、そのプロジェクトの既存 import と compound component 作法に合わせる。
• Tailwind は既存の色・余白・角丸・タイポグラフィの傾向に合わせる。
• UI画像の装飾を盲目的に再現せず、実アプリで操作可能な状態、空状態、読み込み、レスポンシブを必要範囲で作る。
• ユーザーが削除指示したUIや文言は残さない。
• 装飾は操作や読み上げを妨げず、画像にはロード前からレイアウトを保てる寸法を与える。
• 実装後、対象に応じた smallest relevant checks を実行する。通常は typecheck / build / 既存テスト。

4. Browserで撮影する

接続URLはプロジェクトの環境設定から確認する。実装対象画面をBrowserで開き、画像読み込みとUIの準備完了後に、少なくとも次を確認・撮影する。初期disabled状態を完成画面と誤認しない。

• プロジェクトが対応するviewport。レスポンシブ画面ではdesktopとmobile、最小幅とブレークポイント前後、対象端末が限定される画面ではその範囲
• ユーザーが指定した重要状態や詳細URL。変更に関係する空・入力中・送信中・失敗・保存状態とキーボード操作
• 横スクロール、重なり、テキスト切れ、指定改行や短いラベルの途中改行、主要CTAや操作部品の表示

参照との見た目の比較はスクリーンショットで行い、寸法やDOMの数値だけで合格にしない。スクリーンショットは一時ファイルでもよい。最終報告に必要なら保存先を示す。

5. レビュー用サブエージェントを起動する

references/review-agent-prompt.md を読み、次を含むpromptでサブエージェントを起動する。

• 対象プロジェクトの絶対パス
• 参照UI画像の絶対パス
• 実装後スクリーンショットの絶対パス、またはBrowser確認結果
• ユーザー追加指示の要約
• プロジェクトルールの要約。例: AGENTS.md、HeroUI、Tailwind、既存UI制約
• 指摘は High / Medium / Low に分類すること
• ユーザー指示やデザインシステム適用により当然変わる差分は指摘しないこと
• 修正は依頼せず、レビュー結果だけ返すこと

レビューのためにサブエージェントを使える場合は使う。使えない場合は main Codex が同じ基準で自己レビューし、その旨を報告する。

6. High/Medium修正ループを回す

1. サブエージェントの指摘を main Codex が検収する。
2. 妥当な High/Medium を修正対象にする。
3. Low は原則メモに残し、必須修正にしない。
4. 修正で影響した検証を再実行する。
5. 影響した画面・状態をBrowserで再撮影する。
6. 指摘箇所と修正が影響する範囲を再レビューし、前提が変わらない確認結果は引き継ぐ。
7. High/Medium が0件になるまで繰り返す。

以下の場合はループを停止し、残存理由を明示する。

• ユーザー指示同士が矛盾している
• 参照画像と実アプリ要件の両立ができない
• 必須の外部データや認証を取得できず、または必要なAPI実装が許可範囲外で、受け入れ条件を確認できない
• 修正が当初スコープを大きく超える

許可範囲内のAPI実装、ローカル起動、表示不良の修正は続行する。合意済みの正常差分を再び欠陥へ戻さず、新しい根拠のない全面レビューを繰り返さない。

7. 最終報告する

最終報告には次だけを簡潔に含める。

• 実装した内容と完了範囲。素材を作成した場合は採用ファイルと配置説明も示す
• High/Medium が残っていないこと、または残した理由
• 実行した検証コマンド
• Browser確認したURLとviewport
• 主要変更ファイル
• Low 指摘が残る場合は短く列挙