Communitygithub.com

haina-x/design-team-skills

ライブWebサイトとFigmaデザインを比較し、視覚的なUI検収を実施します。ページと状態のマッピングを発見し、レンダリングの差分を検査し、証拠に基づいた課題レポートを作成します。デザインUAT、UI UAT、ビジュアルアクセプタンス、実装の忠実度確認に使用します。デザインの実装や広範なビジネスフローのテストには使用しません。

design-team-skills とは?

このスキルは、Webサイトの視覚的実装をFigmaデザイン参照と比較し、UIの検収(UAT)を支援します。開発者は、提供されたWebサイトURLとFigmaリンクを基に、デザインと実際のページの対応関係を自動的に発見し、視覚的な差分をキャプチャして証拠に基づいた課題レポートを生成できます。このスキルは、Figmaコネクタとブラウザ制御ツールを活用してデザイン構造とライブUIを取得し、`scripts/report_rendering.py`を使用して自己完結型のHTMLレポート、課題一覧CSV、および合格基準がある場合は受入チェックリストを出力します。主な機能は、デザインツーページマッピングの探索、比較可能な証拠のキャプチャ、アクション可能な発見事項の分類、デザインレビューの組み込み、そして構造化されたレポートの納品です。このスキルはプロジェクト間で再利用可能であり、プロジェクト固有のデータは作業スペースに保持され、証拠はレポートの中心的な要素として扱われます。

対応~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/haina-x/design-team-skills/tree/HEAD/design-uat

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

デザインUAT

Webサイトの視覚的実装を、そのデザイン参照と比較します。デフォルトでは英語で課題優先のHTMLレポートを出力しますが、要求された言語やレポート形式があればそれに従います。このスキルはプロジェクト間で再利用可能です。プロジェクトURL、フレームマッピング、許容される差異、認証情報、実行証跡はこのスキルフォルダには含めないでください。

ユーザーのスコープから開始する

提供されたWebサイトとFigmaリンクを初期スコープとして使用します。適切なプロジェクトプロファイルが存在すればそれを再利用し、そうでなければ準備されたルートリストや設定を要求せずに発見を開始します。Figmaのページがバージョン引き継ぎを表す場合、そのページ全体を棚卸しし、各モジュールのテストパスを個別に発見します。提供されたWebサイトURLはエントリポイントであり、ルートの制限ではありません。明示的にページ全体のスコープが指定された場合はそれに従い、サンプルで代用せずに除外やブロックされた状態を記録します。広範なスコープが指定されていない場合は、有用なレビューの境界を明示します。1画面をサンプリングしただけではモジュール全体を受け入れたことにはなりません。

プロジェクトデータは現在のプロジェクトの書き込み可能なワークスペースに保持し、リポジトリの指示に従います。有用なデフォルトは design-uat/<project>/project.json と runs/<run-id>/ ですが、既存の場所が確立されている場合はそれを維持します。マッピングを作成するとき、レポート入力を構築するとき、または再実行を記録するときは、project-data.md を参照してください。

実際に利用可能なツールを発見します。デザイン構造と測定にはFigmaコネクタを、ライブUIの制御にはブラウザ制御を推奨します。必要な場合は関連するツールの指示と前提スキルを使用します。このスキルはそれらのツールを提供しません。可能な場合は既存の承認済みログインを再利用します。アクセスがブロックされている場合は、有用な独立した作業を続行し、レビューできなかった状態を正確に報告します。

デザインからページへのマッピングを発見する

画像を比較する前に、デザイン階層とライブナビゲーションを調査します。キャンバスには、モジュールコンテナ、スクリーンフレーム、ローカル状態の例、メモ、注釈、代替案が含まれる場合があります。ドキュメンテーションボード全体をスクリーンとしてエクスポートするのではなく、その構造内の視覚的ターゲットを特定します。

関連するメモやローカル状態の例を読み取ります。これらは、メインフレームに表示されないレスポンシブ動作、入力寸法、切り詰め、コンポーネントの詳細を指定する場合があります。可視/有効なノードコンテンツを使用します。非表示のコンポーネントヘルパー/エラーテキストは、単にツリー内に存在するという理由だけでアクティブな要件ではありません。

実際のページ仕様と、一般的なインタラクションの図解を区別します。一般的なドロワーの例は、既存のモジュールの矛盾を明らかにすることができますが、すべてのカテゴリの必須フィールドを確立するわけではありません。有用なクロスモジュールの発見は、実際のルート、ナビゲーションコンテキスト、ベースラインの制限とともに保持します。履歴が不明でない限り、疑わしいレガシーステータスは未確認としてラベル付けします。

モジュールコンテキスト、ルート、可視ページタイトル、フィールドラベル、UI構造、レンダリングされた外観の複合的な証拠を使用してマッチングします。フレームID、ページ/状態、比較領域、信頼度、マッピングステータスをプロジェクトデータに記録します。URLは多くの視覚的状態を持つ可能性があります。リスト、開いたドロワー、フォーカスされた入力、空の状態を混同しないでください。

人間による確認が得られていない場合でも、十分に裏付けられたマッチングは「推測」としてマークして処理を進めます。真に曖昧な選択肢はユーザーに一括してバッチ処理し、ブロックされていないケースは引き続き処理します。代替/バックアップデザインは、理由を付けて選択されたスコープ外として記録します。名前だけで許容されるバージョンが決まるわけではありません。再利用前に、以前に保存されたマッピングを現在のデザインとライブページに対して検証します。

大きなFigmaファイルの場合、生のメタデータをローカルに保持し、コンテキストにはコンパクトで浅いサマリーのみを返します。詳細なサブツリーやスクリーンショットを抽出する前に、既知の祖先で絞り込みます。ファイル全体を繰り返しロードしないようにします。

比較可能な証拠を取得する

最初のキャプチャの前、または比較の問題を診断するときに、evidence-workflow.md を読んでください。アートボードのオーバーフロー、状態マッチング、注釈の除外、動的コンテンツ、ローカルクロップ、スクリーンショットの受け入れ基準について説明しています。

ナビゲーション、フォーカス、可逆的な入力変更を通じて、必要な視覚的状態を露出させます。スクリーンショットを取得するためだけに、許可なくビジネス変更を送信しないでください。状態に利用できないデータや書き込みアクションが必要な場合は、それを偽装せずにその制限を記録します。

互換性のあるビューポート、スケール、テーマで、正確なデザイン領域とブラウザ状態をキャプチャします。フォント/コンテンツが読み込まれ、ターゲットが安定していることを確認します。ローディングがレビュー対象の状態でない限り、一時的なローディングキャプチャは拒否します。レポートで使用する前に、保存されたスクリーンショットを検査します。クロップ、オーバーレイ、注釈とともに、元のキャプチャを保存します。

差異は両方の画像に基づいて、必要に応じてFigmaのジオメトリとブラウザ要素の境界も考慮します。測定値はそのソースに帰属させます。Pillowが利用可能な場合は、scripts/compare_regions.py を使用してオプションのネイティブスケールのペアクロップとマークを取得します。レポートレンダラー自体はPythonの標準ライブラリのみを必要とします。

個々のディメンションだけでなく、コントロール行全体の関係も検査します。隣接するギャップ、配置、残りのアクションスペース、アクティブフィルターコントロールが表示されたときの変化などを確認します。根拠または明示的なレビューアフィードバックによって裏付けられている場合、共有レイアウトの修正とその視覚的結果を、1つの安定した課題としてグループ化します。そのグループ化をコードレベルの根本原因診断と区別します。

コンテキストと欠陥を区別します。サンプルデータ、アカウントID、展開されたナビゲーション、グローバルなアナウンス、後のコンポーネントバージョンはスクリーンショットを変更する可能性があります。これらを記録し、レイアウトへの影響を黙って無視しないでください。テキスト値はコピーマッチングから除外される場合がありますが、その折り返し、オーバーフロー、配置はレビュー可能なままです。差異を隠すためにスクリーンショットを引き伸ばしたり、全ページ類似度スコアを捏造したりしないでください。

実行可能な発見事項を作成する

各発見事項を、その証拠が裏付ける内容に基づいて分類します:

  • visual-defect:クリッピング、オーバーラップ、確認された実装違反など、再現可能な視覚的障害。条件と期待のソースを明記します。
  • baseline-mismatch:提供されたリファレンスとの実証された相違。現在受け入れられているデザイン/バージョンの確認が必要な場合があります。
  • design-clarification:受け入れを判断するためのデザインガイダンスが不十分または矛盾している観察された状態。

観察の信頼度、提案された優先度、フォローアップステータスは別々に保持します。高信頼度のスクリーンショットの差異を、差異が明白であるという理由だけで受け入れられた欠陥と呼んではいけません。プロジェクトの優先度スキームを使用します。決定が未解決の場合は、提案としてラベル付けし、優先度を未設定のままにします。所有者、ターゲットリリース、承認された逸脱、実装完了、再テスト成功を捏造してはいけません。

各発見事項には、安定したID、ページ/状態、簡潔なタイトル、実際の結果、期待される結果または明示的な不確実性、証拠の根拠、推奨されるアクション、再現手順が必要です。対象を絞った比較証拠と完全な現在状態のキャプチャを添付します。関連するFigma参照を含めます。視覚的証拠のない発見事項は、制限事項または質問であり、確認された視覚的欠陥ではありません。

チェックした項目とブロック/未レビューの状態は別々に記録します。再実行時には同じ課題IDを維持します。新しい証拠が一致した場合のみ課題をクローズまたは解決済みとしてマークし、以前の観察は保持し、変更された受け入れ基準を説明します。

デザインレビューを組み込む

デフォルトではレビュードラフトから始め、デザイナーの決定を組み込んでから開発者への引き継ぎを行います。フィードバックを受け取ったとき、デザインベースラインを修正するとき、または正式なレポートを準備するときは、review-workflow.md を読んでください。会話内で既に明示的なレビューと承認が与えられている場合はそれで十分であり、同じ確認を再度求めてはいけません。

保持、除外、受け入れ、マージ、延期、デザイン更新の決定を、そのソースとスコープとともにプロジェクトデータに記録します。デザイン参照の修正は実装修正ではありません。デザイン変更に関するレビューアのフィードバックは、それ自体ではFigmaの編集を許可しません。ドラフトと決定履歴を保持します。開発者への引き継ぎには、保持されたアクション項目のみを含めます。これには、明示的に保持された明確化や既存モジュールのフォローアップも含まれます。未割り当ての優先度、所有者、リリース、再テストフィールドを確認された値に変換してはいけません。

レポートを納品する

レポートを作成するときは、report-format.md を読んでください。実証済みの読みやすさの順序を維持します:スコープコンテキスト → 簡潔な課題一覧 → 選択された課題の実際/期待される視覚的証拠 → カバレッジとレビューノート。視覚的証拠をレポートの実質とし、切り離された付録にしてはいけません。すべての課題やすべてのパスチェックに対して大きなスクリーンショットを繰り返さないようにします。

project-data.md に記述されている構造化実行データを書き込み、その後レンダリングします:

python3 <skill-dir>/scripts/render_report.py <run-dir>/report.json

これにより、自己完結型の report.html、issue-register.csv、および基準が提供されている場合は acceptance-checklist.csv が生成されます。開発者への引き継ぎでは、保持された各項目に直接テストURL、ナビゲーション/コンテキスト、開発者アクション、観察可能な受け入れ基準が必要です。レンダラーはこれらのフィールドを直接サポートしています。生成されたHTMLにパッチを当てて追加しないでください。レンダラーにはPython 3.9以降が必要で、サードパーティパッケージは不要です。入力/証拠を検証しますが、レビュー決定を推測したり、外部システムにアクセスしたり、開発者にレポートを送信したりしません。

レンダリングされたレポート、その課題切り替え/フィルタリング、画像拡大、比較コントロールを検査します。利用可能なローカルプレビューツールを使用して結果を開き、そのブラウザルールに従います。必要に応じて、ループバックにバインドされた競合しないローカルプレビューを使用します。要求されない限り、外部システムに公開したり書き込んだりしないでください。一時的なブラウザビューポートオーバーライドとテスト入力を実用的な範囲で復元し、変更されたままの状態があれば報告します。

レポートリンク、簡潔なカバレッジ、主要な結果を会話の言語で提供します。重要な制限事項を説明します。要求されたレポートを生成するためだけに承認を求めてはいけません。アプローチについて議論するリクエストは、UAT実行を実行するリクエストではありません。

関連スキル