mcpField
S
shape

shape

github.com/shipshitdevデザイン・UI3886 回インストール今日更新
リポジトリ

shape について

shape は、実装前に機能の UX と UI を計画するデザインスキルです。実装担当へ方針を引き継ぐチーム向けに、既存のプロジェクト情報を調べ、発見インタビューを経て構造化されたデザインブリーフを作成します。

主な機能

  1. 01プロジェクトとデザイン背景の確認
  2. 02インタビューによる要件の整理
  3. 03操作、状態、コンテンツ要件の明確化
  4. 04構造化されたデザインブリーフの作成
  5. 05実装前にブリーフを確認

活用シーン

  1. 01開発開始前の機能設計
  2. 02複雑な画面の主要状態の定義
  3. 03確認済みの設計内容を実装担当へ引き継ぐ

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/shipshitdev/skills --skill shape

インストール後、Claude Code で/shapeを入力して読み込まれたか確認します。

同梱ファイルplugin.jsonREADME.md

詳細

コードを書く前に、機能の UX と UI を設計します。このスキルではデザインブリーフを作成します。これは、推測ではなく調査に基づいて実装を導くための、構造化された成果物です。

対象範囲:設計計画のみです。このスキルではコードを書きません。優れたコードを生み出すための考え方をまとめます。

出力:任意の実装スキルに引き継げるデザインブリーフです。

委任先:フェーズ 1 では grill-me に委任します。ブリーフの確認後、実装スキルを推奨してください。ユーザーが呼び出した別のスキルは実行しないでください。

コンテキストの収集

インタビューの前に、プロジェクトの現状を把握し、既存の内容を反映したブリーフを作成できるようにします。

  • デザインのコンテキスト — リポジトリに PRODUCT.md、DESIGN.md、.impeccable.md のいずれか、または .github/copilot-instructions.md の ## Design Context ブロックがある場合は、それを読みます。いずれも存在しない場合は、何も言わずにスキップします。
  • 既存のシステム — 確立されたデザインシステム(CSS/トークン/テーマと、代表的なコンポーネントまたはページを 1 つ)を読み、既存の規約を把握します。既存のものを活用し、UX が向上する場合に限って別の方向性を検討します。
  • 位置づけ — デザインそのものがプロダクトなのか(マーケティング、ランディングページ、ポートフォリオ → アイデンティティと大胆さを重視)、それともデザインがプロダクトを支えるのか(アプリ、ダッシュボード、ツール → 明快さと抑制を重視)を判断します。この判断が、以下のあらゆる方向性の選択の基準になります。

フェーズ 1:発見のためのインタビュー

このフェーズではコードを書かず、デザイン上の決定もしません。後で優れたデザイン上の決定を下せるよう、機能を深く理解します。

grill-me スキルを実行します。以下の分岐を使ってデザインツリーを作成し、検討範囲を網羅します。

  • 目的とコンテキスト — 何のためのものか、具体的に誰が使うのか、成功の定義、ユーザーの心理状態
  • コンテンツとデータ — 表示または収集するもの、現実的な範囲、空の状態/エラー時/初回利用時/パワーユーザー向けのケース、動的に変化するもの
  • デザイン目標 — 最も重要なユーザー操作、望ましい使い心地、既存のプロダクトパターン、参考例
  • 対象範囲 — 詳細度、網羅性、インタラクティブ性、対象として明示されたものと変更しないもの
  • 制約 — 技術、コンテンツ、モバイル、WCAG AA を超えるアクセシビリティ
  • 避けるべきこと — 誤った方向性と、これを誤った場合の最大のリスク

リポジトリからすでに分かる事実は、検討範囲に含めません。grill-me は残りの点について、推奨回答を示しながら段階的に質問します。

フェーズ 2:デザインブリーフ

インタビューの後、内容を構造化されたデザインブリーフにまとめます。このスキルを完了とする前に、ユーザーに提示して確認を得ます。

要件が固まっている場合は 3〜5 個の箇条書きを使用し、曖昧な場合や複数画面にまたがる場合は完全な構成を使用します。対象範囲、現実的な範囲、必要なメディアの役割、実装者が独自に決めてはならない事項を含めます。重要な未決事項は引き継ぎ前に解決し、実装に持ち越さないでください。

ブリーフの構成

1. 機能の概要(2〜3文) これは何か、誰を対象としているか、何を実現する必要があるかを説明します。

2. 主なユーザーアクション ユーザーがここで行う、または理解するべき最も重要なことを1つ示します。

3. デザインの方向性 どのような印象にするか、どのような美的アプローチが適しているかを示します。.impeccable.md または .github/copilot-instructions.md(存在する場合)にあるプロジェクトのデザインコンテキストを参照し、この機能でどのように表現するかを説明します。

4. レイアウト戦略 大まかな空間構成を説明します。何を強調し、何を補足情報とし、情報をどのような流れで見せるかを示します。具体的な CSS ではなく、視覚的な階層とリズムを説明します。

5. 主要な状態 この機能に必要なすべての状態を列挙します。標準、空、読み込み中、エラー、成功、エッジケースを含めます。それぞれについて、ユーザーに何を見せ、どのように感じてもらう必要があるかを記します。

6. インタラクションモデル ユーザーがこの機能をどのように操作するかを説明します。クリック、ホバー、スクロール時の動作、ユーザーへのフィードバック、開始から完了までの流れを示します。

7. コンテンツ要件 必要なコピー、ラベル、空の状態のメッセージ、エラーメッセージ、マイクロコピーを示します。動的コンテンツがある場合は、その内容と現実的な範囲を記します。

8. 推奨リファレンス ブリーフに基づき、実装時に特に役立つリファレンスファイルやドキュメントを列挙します(例:複雑なレイアウトには空間デザインのガイダンス、アニメーション機能にはモーションデザイン、フォームが中心の機能にはインタラクションデザイン)。

9. 未解決の質問 引き継ぎを妨げる未解決事項を記します。実装前にユーザーと確認し、デザイン上の判断を確認済みのブリーフに暗黙のうちに委ねないでください。


推測できないことはユーザーに直接尋ねて明確にしてください。完了する前に、ブリーフについて明示的な確認を得てください。ユーザーがいずれかの内容に同意しない場合は、関連するヒアリングの質問に戻ってください。

確認が済むと、ブリーフは完成です。ユーザーはこれを、任意の実装スキルやアプローチに引き継げるようになります。

コメント