# UI Concept Implement

> ui-design-concepts などで作成したUI画像案を、ユーザー追加指示、プロジェクト固有ルール、HeroUI / Tailwind 等のデザインシステムに従って実装する。実装後にBrowserでスクリーンショットを撮り、レビュー用サブエージェントで実装漏れ・作り込み不足をHigh/Medium/Lowに分類し、High/Mediumがなくなるまで修正・再撮影・再レビューを繰り返す。Use when implementing a selected UI mockup image, design concept, screenshot-based UI proposal, or visual concept into a project with an automated screenshot review loop. Trigger: ui-concept-implement, dev:ui-concept-implement, UI画像案を実装, UI案を実装, スクリーンショットレビュー修正ループ

- Skill: `ryryo/ui-concept-implement` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add ryryo/ui-concept-implement`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ryryo/ui-concept-implement/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: ryryo (https://skillmd.com/u/ryryo)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/ryryo/ui-concept-implement

---


# ui-concept-implement

UI画像案を実装可能な画面へ落とし込み、スクリーンショットレビューでHigh/Mediumの漏れがなくなるまで仕上げる。

## 絶対ルール

- 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行で整理してから作業する。

- 参照画像から採用する構造
- ユーザー指示により変える/消す要素
- 既存デザインシステムに合わせて置き換える要素
- 触るファイルと検証コマンド

大きな作業では `update_plan` を使い、実装・検証・レビュー修正ループを可視化する。

### 3. 実装する

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

### 4. Browserで撮影する

実装対象画面をBrowserで開き、少なくとも次を確認・撮影する。

- desktop相当のviewport
- mobile相当のviewport
- ユーザーが指定した重要状態や詳細URL
- 横スクロール、重なり、テキスト切れ、主要CTAや操作部品の表示

スクリーンショットは一時ファイルでもよい。最終報告に必要なら保存先を示す。

### 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、認証などが必要
- 修正が当初スコープを大きく超える

### 7. 最終報告する

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

- 実装した内容
- High/Medium が残っていないこと、または残した理由
- 実行した検証コマンド
- Browser確認したURLとviewport
- 主要変更ファイル
- Low 指摘が残る場合は短く列挙