UI は「画像モック→承認→Issue→並列実装」の順で作らせる
いきなり UI コードを書かせず、画像生成でモックを作って人間が承認し、承認済みモックとプロンプトを Issue に添付してから実装を並列に回す。
AI に UI を直接書かせると、会話の途中で出てきたラベルが変な位置に置かれたり、意図と違う手戻りが起きやすい。完成像を先に1枚の画像で合意しておくと、その後の実装は「この画像に合わせる」だけになる。
どんな時に使う？
- 画面ごとのアニメーション追加や新画面など、見た目の合意が必要な UI 作業をまとめて頼むとき
- 名刺・スライド・LP など、一発で書かせると平凡か崩れた出来になりがちなとき
手順（kdy1 さんのワークフローを再構成）
- モック作成スキル（例
$design-ui）: エージェントが画像生成でモックを作り、「これで進めてよいか」と承認を求める - Issue 化スキル（例
$add-issue）: 承認されたモック画像と、そのとき使ったプロンプトを Issue に添付する - 並列実装スキル（例
$slop-fix-batch）: 溜まった Issue をまとめて並列に実装させる - 依頼文は「各画面に適切なアニメーションを付けたい。画面ごとに $add-issue して」のように、画面単位で Issue を切らせる
名刺の例（@gosrum）でも、先に画像生成で複数デザインを出して選び、アセットや文字だけ直させる方が、コードから作らせるより完成度が高かったという報告がある。
注意点
- 原著者は「別途レビューせず main にマージしている」運用。チームでは PR レビューを残す
- 画像モックの作り方そのもの（スタイル案を4つ出させる等）は design 分野の コードより先に画像生成でデザインモックを作る。最初にスタイル案を4つ出させて選ぶ を参照
- スキル本体は kdy1/kdy1-scripts リポジトリにある
出典
- @laiso 2026-10-12（紹介）: @laiso · 2026-10-12
- 元記事: kdy1.dev/2026-10-12-ai-ui
- @gosrum 2026-06-20（名刺は画像生成から選ぶ）: @gosrum · 2026-06-20