reference-design-contract について
reference-design-contractは、デザインの参考例や好みの手掛かりを、明確で再利用できるデザイン契約にまとめるスキルです。プロトタイプ、資料、リデザイン、画像の再構成に向けて、判断記録と実装ガイドも作成します。
主な機能
- 019セクション構成の`DESIGN.md`を作成
- 02根拠、判断、境界、リスクを記録
- 03実装引き継ぎ資料を作成
- 04簡易プレビュー`example.html`を作成可能
- 05チェックリストに基づいて出力を検証
活用シーン
- 01ビジュアル参考から再利用可能な方向性を作成
- 02コーディングエージェント向けの実装指示を準備
- 03リデザインで維持・変更する点を記録
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ nexu-io/ open-design --skill reference-design-contractインストール後、Claude Code で/reference-design-contractを入力して読み込まれたか確認します。
同梱ファイルexample.htmlreferences/checklist.md
詳細
リファレンスデザイン契約
ユーザーが好みの傾向や参考資料を示している場合、または「これみたいに」という大まかな要望があり、生成に先立って再利用可能なデザイン契約が必要な場合に、このスキルを使用します。目的は、プロンプトを長くすることではありません。その後のプロトタイプ、デッキ、リデザイン、画像リミックスの作業で推測が不要になるよう、デザイン上の判断を明確にすることです。
このスキルで作成するもの
次の3つのファイルを作成します。
DESIGN.md— OpenDesign の標準的な9セクション構成に沿った、再利用可能なビジュアルの方向性。design-contract.md— 使用した根拠、維持・変更の境界、判断理由、リスク、品質基準を記録したドキュメント。implementation-handoff.md— 次の成果物作成スキルまたはコーディングエージェント向けの簡潔な実装指示。
プレビューが役立つ場合は、小規模な手作業で作成する契約プレビューとして example.html も作成します。これを主な成果物にしないでください。
ワークフロー
- 依頼内容を確定する。 対象の成果物の種類、対象者、ブランドや製品の背景、参考資料、制約を特定します。回答が欠けていると方向性が変わる場合に限り、質問は最大2つまでにします。それ以外の場合は妥当な既定値を選び、推定であることを明記します。
- 根拠を確認する。 提供されたスクリーンショット、URL、既存の
DESIGN.md、ブランド資料、画像の成果物、ユーザーのメモを使用します。根拠が不足している場合はその旨を明記し、概要だけをもとに契約を作成します。ブランドに関する事実を捏造しないでください。 - 参考資料の意味を切り分ける。 各参考資料について、次の項目に分けます。
Keep:密度、構成、素材感、タイポグラフィのリズム、色温度、動きの印象など、維持する特性。Change:題材、コピー、ブランドマーク、具体的なレイアウト、保護対象のアセット、ユーザーが変更を希望する要素。Do not copy:スクリーンショットそのもの、ロゴ、主張、価格、独自の UI、例に含まれるプロンプトの正確な文言。
- 方向性を確定する。 一貫したビジュアルの方針を1つ選びます。互いに関連のないムードボードを5つ提示しないでください。実際に競合する方向性がある場合は、簡潔に名前を挙げ、推奨するものを選んで進めます。
DESIGN.mdを作成する。 次の9つの見出しをそのまま使用します。## 1. Visual Theme & Atmosphere## 2. Color## 3. Typography## 4. Spacing & Grid## 5. Layout & Composition## 6. Components## 7. Motion & Interaction## 8. Voice & Brand## 9. Anti-patterns
design-contract.mdを作成する。 次の項目を含めます。- 目標と対象の成果物
- 確信度(
observed、provided、inferred)を含む根拠の表 - keep/change/do-not-copy の表
- 最終的なデザイン方針をまとめた1段落
- リスクと明示的な不明点
- 品質基準チェックリスト
implementation-handoff.mdを作成する。 簡潔で実務的な内容にします。- 読むべきファイル
- トークン、パレット、書体、レイアウトの制約
- アセットのルール
- レスポンシブ対応の要件
- 受け入れ基準としての「最初の成果物で実証すべきこと」
- 検証する。
references/checklist.mdを読み、最終的な引き継ぎの前に、すべての P0 基準を満たします。
出力ルール
- すべての主張を、ユーザー入力、確認した参考資料の根拠、または明示した推定に結び付けてください。
- 形容詞より具体的な制約を優先します。「プレミアム」よりも「暖色系のアクセントを1色使用し、紫や青の発光効果は使わない」のように記述します。
- 「同じスタイルで」を「調整可能な特性を取り入れる」と解釈し、元の題材やプロンプトを模倣しないでください。
- ユーザーが UI の即時生成も求めている場合は、まずこれらの契約ファイルを完成させてから、次のステップで適切な成果物作成スキルに引き継ぎます。
コメント
Markdown 対応