shape

shape skill の概要

shape skill でできること

shape は、UI/UX Design 向けの「設計前の整理」を重視した planning-first スキルです。コードを書く前に、構造化された discovery process を進めることで、粗い機能アイデアを design brief に落とし込めます。目的は、ピクセル単位の見た目や実装の細部を決めることではありません。ユーザー課題、制約、プロダクトの方向性を明確にし、その後の設計・実装をより速く、推測頼みになりにくい状態にすることです。

どんな人・チームに向いているか

shape skill は、プロダクト視点のある設計の出発点が欲しいときに向いています。新機能、UX 改善、リデザイン、あるいは要件がまだ曖昧なインターフェース案件に特に有効です。レイアウト、フロー、コンポーネント選定をいきなり提案させる前に、AI アシスタントにより良い問いを立ててほしいチームにも相性があります。

shape skill が選ばれる理由

shape skill の価値は、最終的な「意思決定の質」にあります。単なる汎用的な UI コンセプトではなく、文脈整理、スコープの見極め、設計意図を踏まえた brief が得られるためです。リスクが「遅く作ること」ではなく「間違ったものを作ること」にある場面では、一発回答の prompt より shape skill のほうが適しています。

shape skill の使い方

shape のインストールとセットアップ

npx skills add pbakaus/impeccable --skill shape でインストールします。導入後はまず SKILL.md を開いてください。この skill は、より広い $impeccable のガイダンスに依存しており、設計判断に入る前にその Context Gathering Protocol に従う前提になっています。環境内に十分な design context がまだない場合は、先に $impeccable teach を実行するのが安全です。

最初の入力は「課題がわかる形」で渡す

shape skill は、「UI をよくして」のような曖昧な依頼ではなく、機能ゴールを渡したときに最も力を発揮します。良い入力には、ユーザーの目的、対象のプロダクト領域、既知の制約、成功の定義が含まれます。たとえば「配送方法選択でゲストユーザーの離脱が起きている mobile commerce app の checkout flow を shape してほしい」のような依頼です。こうした具体性があると、skill 側も掘り下げるべき論点を明確にできます。

shape skill のおすすめ運用フロー

shape skill は planning phase で使うのが基本です。まず機能を説明し、discovery questions に答え、そのうえで design brief を生成させます。その brief は、$impeccable craft のような implementation skill へ渡す handoff artifact として扱うと効果的です。すでに解決策が固まっているなら、shape は早すぎる可能性があります。逆に、問題設定自体がまだ曖昧なら、まさに最初に使うべきスキルです。

先に確認したいファイル

最初に読むべきなのは SKILL.md です。その後、親 repo のうち、principles、context gathering、handoff behavior を定義している箇所を確認してください。この repo snapshot では、見えているファイルは SKILL.md のみです。そのため、導入判断は補助スクリプトやサンプルではなく、SKILL.md に書かれた workflow rules をどう評価するかにかかっています。言い換えると、実運用ではプロジェクト側の context を自分たちで多めに渡す前提で考える必要があります。

shape skill の FAQ

shape skill は UI/UX Design 専用ですか？

はい。shape skill は UI/UX Design の planning に特化しています。コード生成用の skill ではなく、単体で最終的な visual spec を仕上げる用途にも向いていません。役割はあくまで設計課題を明確にし、後続の実装で手戻りを減らすことです。

普通の prompt と shape skill は何が違いますか？

通常の prompt は、すぐに解決案へ飛びがちです。一方、shape skill は discovery-first の進め方を強制します。そのため、もっともらしいモックアップが欲しいだけではなく、プロダクトとして筋の通った判断が必要な場面に向いています。画面案を即座に出力する prompt を求めているなら、shape は最適解ではありません。

初心者でも使えますか？ 事前のデザイン経験は必要ですか？

いいえ、必須ではありません。ただし、初心者ほど機能の説明を明確にできると shape skill の恩恵を受けやすくなります。skill 自体が会話をリードしてくれますが、それでも必要なのは使える context です。想定ユーザー、目的、edge cases、制約が曖昧だと、最初の出力は不完全になりやすいと考えてください。

shape skill を使わないほうがよいのはどんなときですか？

小さな見た目調整、要件が完全に固まっている作業、あるいは実装終盤の execution には向きません。デザインの方向性がすでに確定していて、残る作業が実行だけなら、build-focused skill のほうが通常は適しています。shape が最も強いのは、不確実性そのものが問題になっている局面です。

shape skill を改善するには

最初に渡す context をより鋭くする

shape skill の結果を良くする最短ルートは、ユーザー、タスク、制約面を 1 段落で明確に伝えることです。platform、audience、business goal、そして変えてはいけない条件を含めてください。弱い prompt は「ダッシュボードを設計して」ですが、強い prompt は「1 分以内にエラーを見つけたい ops manager 向けの B2B dashboard を設計したい。laptop と tablet の両方で使え、新しい nav item は追加できない」のようなものです。

discovery phase には具体で答える

この skill は context gathering を中核にしているため、回答が曖昧だと brief の質はすぐ落ちます。ゴールやフローを聞かれたら、好みではなく実際の行動で答えてください。たとえば、ユーザーが今どう操作しているか、どこで離脱するか、どんな入力データが存在するかを伝えます。そうすることで、shape skill は汎用的なアイデア出しではなく、使える product direction を返せるようになります。

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

最も多い失敗は、ヒアリング工程を飛ばして早い段階でデザインを求めてしまうことです。もうひとつは、出力制約だけを渡して、その理由を説明しないことです。これでは提案が硬直的になりやすくなります。最初の brief が広すぎると感じたら、問題文を絞り、主要ユーザーを明確にし、成功指標を言い直してから再度回してください。

brief から handoff まで磨き込む

最初の出力のあとに、edge cases、優先順位、途中で見えてきた technical constraints や brand constraints を追加して brief を改善していきます。そのうえで、完成度を上げた brief を implementation skill や既存の design workflow に渡してください。shape がもっとも価値を発揮するのはこの段階です。作業コストが高くなる前に曖昧さを減らせます。