design-review

design-review の概要

design-review でできること

design-review は、実際のコードベース内で見た目の不整合、余白の問題、階層の崩れ、AIっぽい雑なパターン、操作のもたつきといった UI の粗を見つけ、検証しながら段階的に修正していくためのデザイン QA skill です。
「なんとなく違和感がある」状態から、具体的なソース変更と before/after の検証まで進めたいチームに向いています。

こんな人に向いている

ライブな UI を UX 観点で監査したい、既存実装を磨き込みたい、あるいはすでにコード上にある画面をレビューしたいときに、design-review skill を使ってください。
特に、まったく新しいレイアウト案を生成するよりも、見た目の一貫性が重要なアプリで働くプロダクトデザイナー、フロントエンドエンジニア、エージェントに適しています。

何が違うのか

一般的な UX Audit 用プロンプトと違い、この design-review ガイドはワークフローを前提に作られています。問題を見つけ、原子的な修正を加え、結果を再確認する流れに沿って動きます。
また、plan-mode の分離にも対応しているため、すぐに編集するのではなく、まずレビューしてから実装したい場面でも使いやすいです。

design-review skill の使い方

インストールしてタスクを振り分ける

まずは skills manager から design-review のインストールコマンドを実行し、レビューしたい UI を含むリポジトリをエージェントに指定します。
plan mode で作業するなら /plan-design-review に振り分けます。コード変更まで行いたい場合は、skill 内で説明されている active review の経路を使ってください。

適切な入力を与える

良い design-review の依頼文には、対象画面、ユーザーフロー、そして気にしている失敗ポイントを入れます。
たとえば、「checkout modal の余白、階層、モバイルでのボタンの分かりやすさをレビューして、最も問題の大きい箇所を修正してほしい」は良い例です。「これをもっと良くして」は弱い依頼です。前者は skill に対して、対象・制約・成功条件をはっきり示しています。

先に読むファイル

fit をきちんと見極めたい design-review ガイドなら、まず SKILL.md を読みます。必要であれば、存在する場合は SKILL.md.tmpl のような生成テンプレートも確認してください。
さらに、prompt-routing や helper の慣習がないかリポジトリツリーも見ておくとよいです。このリポジトリは補助スクリプトや docs よりも skill 本体を中心に構成されているためです。

レビューのループとして回す

この skill は、確認、修正、検証、反復という短いサイクルで使うのが基本です。何を変えたのか、その理由は何かを示すように依頼し、タイポグラフィ、余白、インタラクションの遅さのように、1 回のパスで扱う問題は 1 種類に絞るのが効果的です。
そうするとレビューの焦点がぶれず、回帰の発見もしやすくなります。

design-review skill の FAQ

design-review は仕上げの微調整だけ向けですか？

いいえ。design-review skill は、公開中サイトの仕上げ、コードベースの整理、そして見た目の品質がすでにあるが詰めが必要な UX Audit 系のチェックにも使えます。
一方で、初期コンセプトの発想段階よりは、実装済み UI を直して検証する用途のほうが向いています。

デザイナーでなくても使えますか？

はい。ただし、画面と問題点を明確に説明する必要があります。
デザイナーでない人ほど、「何が変だと感じるのか」「誰向けの画面なのか」「どうなれば成功なのか」を具体的に伝えたほうが、曖昧な redesign を頼むより良い結果につながります。

通常のプロンプトと何が違いますか？

通常のプロンプトは提案を返すだけで終わることがありますが、design-review はコード内の問題を見つけ、それを変更し、結果を確認するところまでを前提にしています。
助言だけ欲しいなら、この skill はオーバースペックかもしれません。測定可能な UI 修正をしたいなら、こちらのほうが適しています。

design-review を使わないほうがよいのはいつですか？

純粋に戦略レベルの判断、ブランド方針の検討、あるいは画面を見ないコンテンツ修正だけのタスクでは使わないでください。
また、コードベースにアクセスできない場合や、変更後に screenshot で検証できない場合も相性は弱いです。skill の価値は反復的な検証にあるためです。

design-review skill を改善するには

まずはレビュー対象を絞る

design-review の成果が最も出やすいのは、1 ページ、1 コンポーネント、1 つのユーザーフローのように対象を狭くしたときです。
viewport、デバイス条件、主な関心事を渡してください。たとえば「desktop の settings page。alignment と scanability を重視」や「mobile の pricing card。tap の分かりやすさを重視」といった指定が有効です。

何を最適化したいかを伝える

一貫性、アクセシビリティ、CV の分かりやすさ、操作速度のどれを最優先にしたいのかを最初に伝えましょう。
そうすると、design-review skill は競合する修正案の間で適切に判断しやすくなります。ある変更が 1 つの面を良くして、別の面を弱めることはよくあるからです。

よくある失敗パターンに注意する

弱い入力の典型は、「もっときれいにして」「デザインを良くして」「全部監査して」です。こうした依頼は、広くてシグナルの薄い出力を招きがちです。
より強い入力は、欠陥の種類、コンポーネント、変更許容範囲を明示します。そのほうが不要な編集を減らせて、design-review の使い方としても精度が上がります。

証拠を見ながら反復する

最初のパスのあとには、残っている上位の問題、実際に変更されたファイル、そして screenshot ベースでまだ見える回帰があるかを確認してください。
結果がかなり良いがまだ不十分、という場合は、より鋭い制約を加えて依頼を絞り込みます。たとえば「レイアウトは変えない」「配色は変更しない」「階層と余白だけ直す」といった指定が有効です。