mcpField
H
handoff

handoff

github.com/tranz007デザイン・UI4846 回インストール8 週間前に更新
リポジトリ

handoff について

Handoff は、デザイン意図を実装向けのエンジニアリング説明にまとめるスキルです。既存の根拠や製品規約、状態ごとの動作、未解決事項を整理し、チームが意図した体験を実装・検証できるようにします。

主な機能

  1. 01既存のデザインとプロジェクト文脈の確認
  2. 02既知・推測・未解決事項の区別
  3. 03状態、分岐、復帰動作の説明
  4. 04既存コンポーネントと規約の再利用
  5. 05チームのワークフローに合わせた整理

活用シーン

  1. 01承認済みフローの実装引き継ぎ
  2. 02エンジニアリングと QA 向けの動作仕様
  3. 03デザイン判断を実行可能な作業に変換

インストール

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

$npx skills add https://github.com/tranz007/ux-skills --skill handoff

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

詳細

引き継ぎ

見た目だけでなく、デザインの意図を引き継ぎます。

常に

  • コンテキスト — ユーザーに同じことを繰り返し尋ねる前に、すでにわかっていることを確認します。プロダクトの目的や成果によって回答が変わる場合は .ux/INTENT.md を参照し、タスクに必要な追加のプロジェクト情報だけを読み込みます。
  • ユーザー — 影響を受ける人々、その目標、タスク、状況、利用可能な根拠を踏まえて作業します。ユーザーのニーズ、行動、ペルソナを作り上げてはいけません。
  • 根拠 — 既知の情報、推測、仮定、不明な情報、意見が食い違っている情報は、違いが重要な場合に区別して扱います。
  • システム — 新しいものを考案する前に、確立されたプロダクトの用語、コンポーネント、パターン、ルールを優先します。
  • 明確さ — 役立つ要点から始め、必要最小限の構成にし、一般的なAIの埋め草を取り除きます。
  • 信頼 — 根拠、要件、理由、実装状況、コンプライアンスについて、決して作り上げてはいけません。
  • 成果 — 複数の手順を含む大規模な作業では、意図を常に把握し、継続性が必要な場合に限って簡潔な .ux/STATE.md を使用します。仕上げよりも影響の大きい未解決の課題を優先し、完了を宣言する前に実際の体験が意図に沿っていることを確認します。

これらのルールが回答に実質的な影響を与えない限り、ユーザーに説明してはいけません。

ユーザーとタスクが明確な場合や、不足情報が作業内容を大きく左右しない場合は、調査の質問、ペルソナ、探索作業を持ち込んではいけません。

信頼できる情報源を集める

承認済みのデザイン、関連するフローや状態に関する判断、デザインシステムのコンポーネント、コンテンツ、アクセシビリティ要件、制約、意思決定記録、チームで既に採用されているエンジニアリングのワークフローを確認します。意図した体験を損なわないために必要なプロジェクト情報だけを読み込みます。

承認状況が明確でない提案中の動作を、承認済みとして説明してはいけません。

準備状況を確認する

成果物をまとめる前に、エンジニアリング側の推測を招く要素がないか確認します。

  • 状態や復旧方法の不足;
  • あいまいな遷移;
  • 新しいコンポーネントやパターンに根拠がない;
  • コンテンツや用語が未確定;
  • アクセシビリティの動作が未定義;
  • 体験を大きく左右するデータやサービスの条件;
  • 重要な判断が未解決のままになっている。

実装に影響しないドキュメントが不足していても、引き継ぎを止めてはいけません。

動作を説明する

エンジニアリングに必要な事項を優先します。

  • ユーザーの目標と成果;
  • 開始条件と主な動作;
  • 重要な分岐と復旧方法;
  • コンポーネントとパターンの使い方;
  • 状態とデータ条件;
  • 関連する場合のレスポンシブ動作;
  • コンテンツのルールと用語;
  • 確立されている場合の、フォーカス、通知、セマンティクス、キーボード操作などのアクセシビリティ動作;
  • 依存関係と制約;
  • 未解決の質問。

正確さが役立つ場合は、次のように動作を説明します。

When <condition>
→ the system <behavior>
→ the user <sees/hears/can do>
→ relevant state <persists/resets/changes>
→ recovery <behavior>

チームのワークフローに合わせる

チームが Jira、GitHub Issues、Linear、Azure DevOps、その他のチケット形式を必要としている場合は、意味のないUIの断片に分割せず、引き継ぎ内容を実装可能な作業に変換します。

ユーザーが引き継ぎだけを必要としている場合は、できるからといってチケット形式の出力を作成してはいけません。

出力

意図した体験を明確かつテスト可能にする、最小限のエンジニアリング向け成果物を作成します。権威あるデザインシステム、意思決定、調査、意図、デザインの情報源を示し、内容を重複させないようにします。

対比の例

悪い例:

Figmaに従って、更新後の認証画面を実装してください。読み込み状態とエラー状態を含め、アクセシビリティにも配慮してください。

良い例:

認証に失敗した場合は現在のステップにとどまり、入力済みのコードを保持し、インラインエラーを表示して、フォーカスをエラーの概要に移動します。既存の Alert パターンと認証入力パターンを再利用します。コードの有効期限が切れた場合の復旧方法は未解決のため、エンジニアリング側で動作を考案してはいけません。

理由:良い引き継ぎでは、画像とあいまいな指示を渡すのではなく、動作、システムの使い方、アクセシビリティの意図、未解決の判断を引き継いでいます。

例

  • 「これをエンジニアリングに引き渡せる状態にしてください。」
  • 「承認済みのフローを実装引き継ぎ用の資料にまとめてください。」
  • 「エンジニアリングとQAがテストできるよう、動作を記述してください。」
  • 「UXの意図を損なわずに、これを実装可能なチケットに分割してください。」

コメント