shape

shape skill の概要

shape ができること

shape skill は、コードを書く前に機能要件を定義するための、プランニング先行の UX/UI ワークフローです。いきなりレイアウトやコンポーネント作成に進むのではなく、構造化されたディスカバリー・インタビューを行い、その回答をデザインブリーフに落とし込みます。チームとして「何を作るか」は大まかに見えていても、ユーザー目標、制約、状態、エッジケース、実装の方向性がまだ整理できていない段階で特に役立ちます。

shape skill を導入すべき人

shape skill が最も向いているのは、プロダクト志向の開発者、デザイナー、フロントエンドエンジニア、そしてプロトタイピング前に判断の質を上げたい AI 活用チームです。特に shape for UI Design は、機能の輪郭がまだ曖昧なときに有効です。新しいフロー、ダッシュボード、フォーム、オンボーディング、設定画面など、「とりあえず UI を生成する」だけではユーザーが本当に達成したい仕事を捉え損ねやすい場面に向いています。

なぜ汎用プロンプトではなく shape が選ばれるのか

通常のプロンプトは、その場でモックアップやコンポーネント案をすぐ返しがちです。一方 shape は、あえてその流れを遅くします。最大の違いは、まず文脈を集め、そのうえで後続の実装スキルに引き渡せるデザインブリーフを作る点です。リポジトリでも役割は明確で、これはコーディングではなく設計計画のためのスキルです。この線引きがあることで、表面的な UI 提案を減らし、説明可能で妥当性のあるプロダクト判断につなげやすくなります。

shape skill の使い方

インストール時の前提と必須条件

スキルは pbakaus/impeccable リポジトリから、通常の skills ワークフローでインストールします。例:
npx skills add pbakaus/impeccable --skill shape

導入時に最も重要なのは、SKILL.md にある前提条件です。shape requires /impeccable first と明記されています。つまり、まず /impeccable を呼び出し、その Context Gathering Protocol に従い、まだ設計コンテキストが存在しない場合は shape skill を使う前に /impeccable teach を実行する必要があります。この手順を飛ばすと、スキルが想定するワークフローから外れます。

shape がうまく機能する入力

引数のヒントは [feature to shape] ですが、機能名を 1 行だけ渡す形では通常不十分です。より良い shape usage の出発点として、少なくとも次を含めるのが理想です。

• 機能の目的
• 対象ユーザーまたはロール
• 現在の業務フローやペインポイント
• 成功条件
• プラットフォーム、権限、コンプライアンス、既存デザインシステムなどの厳しい制約
• 既知のエッジケースや非目標

弱い入力例:
Shape a notifications page.

強い入力例:
Shape a notifications center for account admins who miss urgent billing and security events. It must work on desktop first, reuse our existing table and filter patterns, and avoid adding real-time infrastructure in v1.

実務での進め方と最初に読むべきファイル

まず SKILL.md を読み、運用上の契約書として扱ってください。このリポジトリのスナップショットではそのファイルしか公開されていないため、価値の大半はそこに書かれた順序を正しく守ることにあります。

1. /impeccable を通じて設計コンテキストを集める。
2. shape は実装ではなく計画フェーズで使う。
3. ディスカバリー・インタビューを実施させる。
4. そのインタビュー結果をデザインブリーフに変換する。
5. できあがったブリーフを /impeccable craft、/impeccable、または別の実装ワークフローに渡す。

この順序が重要なのは、このスキルが UI 作業に入る前の推測を減らすよう最適化されており、一発で完成度の高い画面を出すことを目的にしていないためです。

shape skill で出力品質を上げるプロンプトパターン

shape skill を効果的に使うには、インタビューの実施と最終成果物を明示して依頼するのが有効です。構成例:

• shape したい機能
• 主なユーザーは誰か
• いま起きている問題
• 絶対に外せない制約
• ブリーフの中で確定したい判断事項

例:
Use shape to plan a bulk-edit inventory feature for operations managers. Interview me first. Focus on user intent, error prevention, empty/loading/failure states, permissions, and what the v1 interaction model should be. Output a design brief I can hand to implementation.

これは “design a UI for X” とだけ頼むよりも効果的です。方向性を固定する前に、必要な確認質問をスキル側ができる余地を残せるからです。

shape skill の FAQ

shape skill はコーディング向けですか、それとも計画向けですか？

shape skill は計画向けです。リポジトリでも、コードは書かないとはっきり示されています。成果物は後続の実装を導くデザインブリーフです。すぐにコードが欲しいなら出発点としては不向きですが、先にプロダクト判断や UI 判断の質を上げたいなら適しています。

shape はどんなときに通常のプロンプトより有利ですか？

shape は、機能定義が甘いとき、リスクが高いとき、ユーザー接点が強いとき、あるいは状態やトレードオフが複雑になりそうなときに使うべきです。使い捨てのモックアップなら汎用プロンプトのほうが速い場合もあります。ですが、ワークフロー、ユーザーニーズ、制約、引き継ぎ品質まで含めて考えたいなら shape のほうが適しています。

shape skill は初心者にも向いていますか？

はい。ただし 1 点だけ注意があります。初心者であっても、ディスカバリー・インタビューに答えられるだけのプロダクト文脈は必要です。スキルは整理の枠組みを与えてくれますが、ユーザー像、制約、成功指標をゼロから発明してくれるわけではありません。UX 計画に不慣れでも、インタビュー駆動の進め方によって本来先に答えておくべき問いが可視化されるため、むしろ助けになる場面は多いです。

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

問題がすでに完全に定義済みである場合、必要なのがごく小さな見た目の調整だけである場合、あるいはタスクが純粋に技術的でユーザー操作を扱わない場合は、shape for UI Design は使わないほうがよいでしょう。また、前提となるコンテキスト収集のステップを受け入れない場合も不向きです。このスキルはその土台に依存しています。

shape skill を改善する方法

shape により良い計画入力を渡す

品質に最も効くのは入力の質です。shape における良い入力とは、単なる機能名以上のものです。ユーザーの種類、タスク頻度、失敗コスト、既存パターン、業務ルール、そして何をスコープ外に置くのかまで含めてください。スキルはその後もインタビューを行いますが、出発時点の文脈が豊富なほど、ブリーフは鋭くなり、ありがちな一般論に流れにくくなります。

最大の失敗パターンを避ける: 解決策の早出し

このリポジトリで最も強く警告されているのは、設計判断を早く固めすぎないことです。shape skill のありがちな誤用は、ユーザー課題を明確にする前に画面、カード、タブ、レイアウトを求めてしまうことです。会話があまりに早くインターフェース・パターンへ飛んでいると感じたら、方向を戻してください。まず確認すべきなのは、満たされていないユーザーニーズ、タスクフロー、状態、トレードオフ、制約です。

プロンプトだけでなく design brief を磨く

最初の出力のあとに改善すべきなのは、プロンプトだけではなくブリーフ自体です。不明瞭な判断に対して、次のような観点で問い直してください。

• どのユーザー目標が最優先か？
• 抜けている状態はないか？
• 検証が必要な前提は何か？
• v1 から意図的に外しているものは何か？
• 実装時に曖昧さを生みそうな点はどこか？

この種の反復のほうが、単に「もっと良い UI を」と繰り返し頼むより、shape usage の改善につながります。

shape を後続の実行フローと組み合わせる

shape install の価値を高める実践的な方法は、これを一連の流れの最初の段階として扱うことです。まず shape でブリーフを作り、そのブリーフを /impeccable craft や別の実装スキルに渡します。引き継ぎ用の成果物が良いほど、その後のコード生成やデザイン生成も、もっともらしいだけの弱い UI に流れず、ユーザーニーズに沿ったまま進みやすくなります。