画像モックを承認してから「文章の仕様」と一緒にIssueへ固定し、エージェントに並列で実装させる

どんな問題を解決するか / いつ使うか

「AIにUIを作らせるのは難しい」と感じるとき、たいていは見た目の合意がないまま実装が始まっている。SWC作者の kdy1 さんは、$design-ui（モック作成と承認）→ $add-issue（承認済みモックとプロンプトをIssueに添付）→ $slop-fix-batch（Issueを並列実装）の3つのスキルで、見た目の合意と実装を分けている。画面ごとのアニメーション追加のように、同じ種類の変更を多くの画面にまとめて入れたいときに向く。考え方は コードより先に画像生成でデザインモックを作る。最初にスタイル案を4つ出させて選ぶ の延長で、違いは「承認したものをIssueに固定する」点。

やり方

1. 計画モードで提案だけ作る（design-ui スキルの中身の要点）
   • まずリポジトリの指示書、デザインシステム、トークン、今の画面（スクショ）を読み取り専用で確認する。
   • 対象の画面、利用者、目的、ビューポート、状態、「変えてはいけない挙動」を確定する。
   • 画像生成（ui-mockup 用途）でプレビューを作る。UIの言語が決まっていれば、画像内の文字の言語をプロンプトで明示する。
   • 今の画面のスクショがあれば、編集対象や参照として渡す。広い範囲のスクショは参考にとどめ、プレビューには変更する部分だけを写させる。離れた場所を何か所も変えるなら、場所ごとに1枚ずつ作る。
   • 最終プロンプトをプレビューと一緒に見せ、1回のフィードバックでは1か所だけ直す。
2. 承認と記録
   • 人が特定のプレビューと文章の仕様をはっきり承認するまで進めない。修正依頼が来たら承認は取り消し、プレビュー作りに戻る。
   • 文章の仕様は、画像がなくても実装できる内容にする：情報の優先順位、レイアウト、部品と文言、トークンの意図、操作とナビゲーション、読み込み中／空／エラー／権限なしの状態、レスポンシブ、キーボード・フォーカス・アクセシビリティ、守る挙動、受け入れ条件、テスト項目、対象外の作業。
   • 正本は文章の仕様、画像は補助として扱う。
3. Issue化して並列実装
   • 承認済みのプレビュー（保存パス・説明・最終プロンプト）と仕様をIssueに添付する。
   • 実装用のスキルでIssueをまとめて並列に処理させる。実装後はチェックを回し、受け入れ条件・ビューポート・状態どおりかを表示で確かめさせる。
4. 頼み方の例（韓国語からの英訳を要約）：「各画面に適切なアニメーションを足したい。画面ごとに $add-issue して」。

注意点

• 計画モード中はリポジトリのファイルを変更させない、とスキルに明記されている。提案と実装を混ぜないための線引き。
• 承認済みの画像が見つからないときは、勝手に作り直させない。文章の仕様から進め、画像がないことを報告させる。
• kdy1 さん本人は「main へ別途レビューなしでマージしている」と書いている。チームで使うなら、PRでのレビューは残した方が安全。
• スキルは Codex の $ 呼び出しと計画モード前提。Claude Code などでも考え方はそのまま使える。

出典

• 紹介: @kgsi · 2026-10-13
• 元記事: kdy1「How I Build UIs with AI」kdy1.dev/2026-10-12-ai-ui
• スキル: github.com/kdy1/kdy1-scripts（skills/design-ui/SKILL.md）
• 収集日: 2026-10-14（JST）