design

design skill の概要

design skill は、あいまいな UI の要望を、明確な設計意図のある本番品質のビジュアルに変えるための skill です。特に、「新しいロジックを追加したい」よりも「このページ／コンポーネントをもっとよく見せたい」という課題に強く、UI Design、スクリーンショット起点の仕上げ、タイポグラフィの整理、そして「ダサい」「統一感がない」「分かりにくい」「ちぐはぐ」といった見た目の不満を直す用途に向いています。

design skill が最も向いている場面

design は、バックエンドの挙動ではなくフロントエンドの見せ方を扱うときに使います。たとえば、ページ、コンポーネント、ダッシュボード、マーケティングセクション、空状態、見た目の刷新などです。スクリーンショット、ざっくりした画面説明、または「なんとなく違和感がある」というフィードバックがある場合に相性がいい skill です。

何が違うのか

この design skill は、単なるスタイル指定のプロンプトではありません。より強い美的判断を促し、レイアウトや token の一貫性を求め、ありがちな無難すぎる UI を避けるように作られています。repo には、CSS 系が混在している状態、面の階層が弱い状態、使い古された見た目のパターンといった落とし穴を避けるための実用的なガードレールも含まれています。

design skill を使わないほうがよい場面

データフローのバグ、state 管理、API の問題、バックエンドだけの作業を解決する主役として design を使わないでください。根本原因がロジック、ルーティング、スキーマにあるなら、見た目は改善できても本質的な問題は解決できません。

design skill の使い方

インストール方法と読む順番

npx skills add tw93/Waza --skill design でインストールします。まず SKILL.md を読み、その後は次の順番で参考ファイルを読み進めてください: references/design-traps.md、references/design-reference.md、references/design-aesthetic-quality.md、references/design-tokens.md、そして画面がダッシュボード寄りなら references/design-data-viz.md。この順番にすると、ビジュアルを生成する前に制約を把握しやすくなります。

skill に必要な入力

design をうまく使うには、具体的な入力が欠かせません。画面の種類、想定ユーザー、今の問題点、ブランドの方向性、そして絶対に外せない制約を渡してください。たとえば、「この pricing page を企業向けに再設計して、既存コピーは維持し、落ち着いたプレミアム感を出し、ダークテーマは避けてほしい」のように、条件がはっきりした入力が強いです。「もっとよくして」だけでは弱すぎます。

よりよい出力を引き出すプロンプトの作り方

UI Design のための design では、何を固定し、何を変えてよいかをはっきり伝えてください。コンテンツ、対象デバイス、既存の design system、そして不満の具体的な内容を含めます。スクリーンショットがあるなら、問題が階層なのか、余白なのか、密度なのか、色なのか、タイポグラフィなのか、コンポーネントの一貫性なのかも明示すると精度が上がります。

実践的なワークフロー

まず方向性を固定します。安全にまとめるのか、ブランドに沿わせるのか、それとも探索的に攻めるのかを決めてください。次に、ひとつの明確な UI 方向で出力させ、最初の案を制約条件に照らして確認し、弱い部分だけを絞って改善します。結果が凡庸に見えるなら、見た目の要素を増やすのではなく、より強い設計意図を求めてください。

design skill の FAQ

design は普通のプロンプトと同じですか？

いいえ。普通のプロンプトでもスタイルは説明できますが、design skill には再利用できるガイダンス、アンチパターンのチェック、UI 作業に必要な出力の дисципline が加わっています。その結果、「デフォルトっぽいプロンプト」の出力を減らし、モデルが難しい美的判断をしやすくなります。

design skill は初心者向けですか？

はい、画面と問題点を説明できるなら使えます。深いデザイン用語は必要ありませんが、コンテキストは明確に伝える必要があります。初心者ほど、スクリーンショット、プロダクトの目的、何が違和感なのかの例を添えるとよい結果になりやすいです。

ダッシュボードやチャートにも使えますか？

はい。ただし、インターフェースが数値中心、またはチャート中心のときだけ dashboard 向けの reference を使ってください。アプリの shell や card のような UI Design では、ダッシュボード向けのルールは制約が強すぎて、レイアウトに過剰適合することがあります。

どんなときに design を使わないべきですか？

主に backend ロジック、データ変換、インフラが課題のときは外してください。また、ちょっとした見た目の微調整だけで、より意図的な設計判断までは要らない場合も、使わないほうが早いです。

design skill をもっと良くする方法

design の制約をより具体的にする

品質が大きく上がるのは、形容詞を増やすことではなく、制約をよくすることです。インターフェースの用途、使う人、残すべきもの、変えるべきものを伝えてください。「高級感を出して」より、「金融ユーザー向けに、落ち着きがあり、信頼感があり、効率的に感じるように」のほうが強いです。

より強いビジュアルフィードバックを返す

最初の結果がずれていたら、どこが外れているかを具体的に言ってください。たとえば、階層が平坦すぎる、余白が広すぎる、タイポグラフィが軽すぎる、面がごちゃついている、などです。design skill は、全面的な描き直しを求めるより、1つずつ直したほうが速く良くなります。

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

ありがちな失敗は、テンプレートっぽいレイアウト、飾りすぎたセクション、不揃いな corner radius、ありきたりなアクセントの使い方です。repo の reference が役立つのは、こうしたパターンが出力に現れる前に注意できるからです。

スクリーンショットと参考例で反復する

design の出力は、スクリーンショットや良い参考例と比べながら、狙いを絞って修正を依頼してください。より高い UI Design 品質が必要なら、階層を詰める、type scale を変える、より特徴的な surface system にするなど、1回に1点ずつ変えるのが効果的です。