handoff-to-claude-code

完成したデザインを実際のコードベースに実装するため、開発者またはコーディングエージェントに引き継ぐようユーザーから依頼されたときに読み込まれます。このスキルの出力は、自己完結型の引き継ぎフォルダーです。ZIP に圧縮し、ダウンロード用としてユーザーに提示します。

フォルダーの準備

• ./opendesign/handoffs/<feature-slug>/ にフォルダーを作成します。スラッグには機能を表す名前を付けます（例：onboarding-flow、settings-redesign）。プロジェクトのルートに handoff/、export/ などの汎用的な名前を付けてはいけません。
• 関連する HTML プロトタイプ、コンポーネントファイル、画像、フォント、参照先のアセットをすべてフォルダーにコピーします。開発者がメインプロジェクトのツリーをたどってパスを探す必要がないようにします。
• フォルダーのルートに README.md を作成します。開発者に必要な情報はすべて README に記載します。

README の構成

以下のセクションはすべて必須です。見出しは、次のとおりの文言と順序にしてください。

1. 概要。 機能の内容と目的を簡潔に説明する段落を 1 つ記載します。デザインの経緯は含めません。
2. デザインファイルについて。 最初に免責事項を明記します。趣旨は次の文と同じにします。バンドル内の HTML ファイルはデザインの参考資料であり、そのままコピーして本番コードに使用するものではありません。開発者は、対象コードベースで既に採用されているフレームワーク（React、Vue、SwiftUI、ネイティブなど）と既存のパターンやライブラリを使って、デザインを再現してください。コードベースがまだ存在しない場合は、プロジェクトに最も適したフレームワークを選んでください。
3. 忠実度。 デザインが高忠実度（ピクセル単位で正確に再現）か、低忠実度（ワイヤーフレーム。レイアウトとフローを参考にし、既存のデザインシステムを適用）かを明記します。この判断によって、README の残りの内容をどの程度基準とするかが変わります。
4. 画面／ビュー。 デザイン内のすべての画面について、以下を記載します。
   • 名前と目的。
   • レイアウト — グリッド構造、フレックスの方向、幅、高さ、マージン、パディング。具体的な数値を記載します。
   • コンポーネント。各コンポーネントについて、位置とサイズ、正確な色（16 進数）、タイポグラフィ（フォントファミリー、サイズ、太さ、行の高さ、文字間隔）、角丸、シャドウ、ボーダー、ホバー／アクティブ／フォーカス状態、正確な文言を記載します。
5. インタラクションと動作。 クリックハンドラー、ナビゲーションフロー、アニメーション（時間、イージング、アニメーション対象のプロパティ）、ホバー状態、読み込み状態、エラー状態、フォームの検証ルール、該当する場合はレスポンシブ動作を記載します。
6. 状態管理。 状態変数、状態遷移とそのトリガー、データ取得要件を記載します。
7. デザイントークン。 色（16 進数）、スペーシングのスケール、文字のスケール、角丸、シャドウを記載します。説明文ではなく、フラットなリストにします。
8. アセット。 デザインで使用する画像、アイコン、フォント、その他のアセットをすべて、それぞれのソースとともに記載します。
9. ファイル。 バンドルに含める HTML／CSS／JS ファイルを列挙し、それぞれがどの画面に対応するかを記載します。

絶対に守るルール

• サイズ、色、タイポグラフィを極めて正確に記載します。開発者は HTML を目で確認するのではなく、このドキュメントをもとに実装します。
• 最初に、HTML は参考資料であり、リリースする成果物ではないことを明記します。開発者にとって、これが最も重要です。明記しないと、プロトタイプをコードベースに貼り付けてそのままリリースしてしまう可能性があります。
• デザインでブランドアセットを使用している場合は、HTML に埋め込まれたコピーを使わず、コードベースに既存のブランドシステムから取得するよう開発者に伝えます。
• 作業を終える前に、デザインのスクリーンショットをバンドルに含めるかどうかをユーザーに尋ねます。デフォルトでは含めません。
• フォルダーを作成した後、ZIP に圧縮し、アーカイブをダウンロード用としてユーザーに提示します。ZIP の名前は <feature-slug>.zip にします。

README の文体

• デザインの話し合いに参加していない開発者向けに書きます。「話し合ったとおり」などの表現や、前提知識を求める記述は避けます。
• 命令形で具体的に記載します。「プライマリボタンには #246BFD を使用します」は、「プライマリボタンには青系の色を使用します」より適切です。
• 実装に必要でない限り、理由やデザイン上の正当化は記載しません。これは提案書ではなく、仕様書です。