review-design

review-design — ユーザーに見える成果物を評価する

対象者が、成果物の目的主導のビジュアル表現も含め、意図されたとおりに理解し、関わり、利用できるかを判断します。レビューのみを行います。問題を見つけて説明するのはあなたの役割であり、決定して編集するのは作者です。成果物を修正してはいけません。報告後の修正適用は、呼び出し元のワークフローに対する別の依頼です。ゲートとして呼び出された場合は、実際の判断根拠を記録してください。このスキルによって、実行時の検証方法が変わることはありません。自分が作成した成果物を単独でレビューする場合は、可能であれば新しいコンテキストを使用してください。そうでない場合は自己レビューであることを明示し、同じ証拠基準を適用してください。

入力

$ARGUMENTS にはレビュー対象（ファイルパス、ディレクトリ、URL、またはアクセス方法を含む実行中のアプリ）が渡されます。ジャンルを明示的に指定して (genre=dashboard、genre=deck など)、検出結果を上書きすることもできます。マニフェストゲートの Evidence は、実行で選択された評価者のもとでこのスキルを有効にします。ゲートでは、ジャンルのほか、作者が定義時に固定したモック、例、基準などの参照資料を指定でき、評価ではそれらとの照合を行います。

引数がない場合は、作業ツリー内で直近に更新されたユーザーに見える成果物をレビューし、どれを選んだかを伝えてください。対象が曖昧な場合は、推測せず、レビュー対象を確認してください。ただし、質問できるユーザーがいない状態でゲート評価者として実行されている場合は、曖昧さを示して BLOCKED を返してください。

レンダリングされた証拠、または BLOCKED

ソースの確認だけに基づく判定は、完全なデザイン評価ではありません。成果物を想定されたブラウザー、ネイティブホスト、プレーヤー、またはデバイスで確認し、関連する挙動を実際に試してください。レスポンシブなウェブのビューポートは出発点ですが、すべてのファイルをウェブサイトにする必要はありません。音声、コマンド、会話では、再生または操作の証拠を使用してください。視覚以外の特性については、スクリーンショットは必須ではありません。対応テーマ、入力、アクセス方法、関連する状態を確認してください。必要な特性を利用可能な機能で確認できない場合は、その範囲を BLOCKED とし、検証を可能にする条件を明記してください。代理となるプレビューで問題を解消してはいけません。ソースの確認は、原因の特定や、セマンティック構造などの特性の立証には利用できます。

基準

対象者を中心としたアートディレクションには ../design/SKILL.md を使用してください。これはブリーフや確立されたデザインシステムに従属するガイダンスであり、スタイル準拠のゲートではありません。ここに示す公開済み基準はすべて、特定の意見に基づく既定値です。ユーザーがセッション内またはコンテキストファイルで示したルール、あるいはプロジェクト独自の文書化されたデザインシステムが異なる場合は、そのルールが優先されます。それに従った成果物については指摘事項を挙げず、レポートでは適用したルールを明記してください。唯一の例外は、手順に記載された重大な失敗のルールです。その場合は、指摘を生じさせたルールを明記してください。付随するスキルがない場合は、既定値を独自に作り出さず、提示されたブリーフと参照資料に照らして判断してください。

この評価者は、以下の条件付き基準を担当します。成果物の媒体と対象分野に応じて、該当するものを読み込んでください。

レビュー時の条件	読むもの
ウェブへのアクセスとインタラクション	references/floors.md — 要件、例外、動作チェック
構造化情報、定量情報、情報グラフィック	references/figures.md — 正確な符号化と同等のアクセス
状態を持つ作業や共有作業、複数ページにわたる導線、プレゼンテーション、ウェブ以外の媒体または馴染みのない媒体	references/experience.md — 継続性、結果、実際の媒体による証拠

手順

1. 判断の対象となるジャンルと使用状況を、指摘事項を述べる前に1行で明示します。 想定する用途が間違っている指摘はノイズであり、作者は無視すべきです。明示的な genre= 引数があればそれを優先します。なければ成果物の役割から判定し、判定が本当に拮抗する場合はその旨を伝えて確認を求めます。確認できるユーザーがいない場合は、より近い使用状況を基準に評価し、その判断をレポートに明記します。
2. 評価する前に、提示された概要、根拠、要件から、意図された成果と作業を把握します。 対象者、その人に関係する手順または一連の作業、必要な情報をひとまとめにして明示します。意図がわからない場合は、評価できる内容と、目的への適合性が未検証である内容を区別します。成果物からその見かけ上の動作は読み取れますが、それだけでは意図された成果に役立つとは確認できません。目標をでっち上げて、それを基準に問題視してはいけません。
3. 該当するチェックを実行します。 確立されたプロジェクト用ツールを使い、HTML の場合はこのスキルのディレクトリから node scripts/design-check.mjs <artifact.html> を実行します。終了コードがゼロでも、チェックが完了したことを示すだけで、問題がないとは限りません。測定された候補と NOTE 項目は、評価する前に実際の成果物と該当する例外に照らして検証します。SKIPPED のプロパティは未検証のままです。セレクターが存在することも、ヒューリスティックな数値も、要件への違反や適合を立証するものではありません。
4. 上のセクションに従ってレンダリングし、実際に操作します。 ステップ 2 の一連の作業を自分で2回行い、それぞれの試行にかかる手間を確認します。観察対象は、意図された成果を基準に選びます。読み込んだ標準にあるデリバリーの検証手順は、最初の例として利用できます。
5. 改善案は、条件をそろえて既存版と比較します。 内容、状態、出力サイズ、有用な忠実度を一致させます。実際の作業と視覚表現における利点と損失を明らかにし、うまく機能している個性と動作は維持します。元の成果物が入手できない場合は、その制約を述べ、優れていると断言してはいけません。
6. 読み込んだ標準に照らしてレンダリングを評価し、次の順で行います。 タスクへの適合性――配置によって一連の作業を実行できるか、作業に必要な情報が同時に見えるか、繰り返す操作に探し回らずたどり着けるか、手順の順序が読み進める順序と一致しているか、また references/figures.md のエンコーディングに関するガイダンスに照らして、選んだ表現が情報や体験に適しているか。使用状況への適合性。機能上の最低条件（状態、エラー経路、復旧）。構成と階層――主要なレンダリングをぼかすか縮小し、視線が最初に向かう場所とそこからたどる経路が、その瞬間に必要なものに合っているか、二次的な要素が競合していないかを確認します。他の視覚的な検証方法は、判断の補助として使います。仕上がりの一貫性（グループ化、配置、色の役割、タイポグラフィ）。コピー。視覚的なインパクトとクリエイティブディレクション――構成、タイポグラフィ、色、画像、素材感、インタラクション、モーションが、目的と主題に役立つかたちで成果物を魅力的にしているか。ユーザーの要件と既存のデザインシステムの範囲内で、すべてのジャンルにこれを適用します。機械的な正確さだけでは、デザインが完成したとはいえません。各要素だけでなく、体験全体も評価します。関係性が明確になる箇所、強調が競合する箇所、説明が意味を加えるだけなのか、単に繰り返しているのかを確認します。最もよく見えるフレームだけでなく、使用中、終了時、再訪時も含めて確認します。該当する場合は、モーションを静止時や動きを抑えた代替表示と比較します。デザイン上の判断と、測定された対象者の理解、記憶、好みは区別します。

タスクへの適合性を最初に評価するのは、成果物の構成を作り変える唯一の評価軸だからです。これより下位の指摘事項は、維持されない可能性のある配置を前提に評価されます。一連の作業を支障なく進められる見慣れないレイアウトは、指摘事項ではありません。 成果物の目的と選択された方向性に照らして評価してください。自分なら選んだであろう配置やスタイルを基準にしてはいけません。数値やスタイルの標準から外れているだけでは、指摘事項にはなりません。該当する要件、または確認されたタスク上の影響を明示してください。標準のレベルと例外は維持してください。明記されたルールも好みも、重大な機能上の問題やアクセシビリティ上の問題を打ち消すものではありません。

ビジュアル面の意欲に関する指摘では、レンダリング結果で何が未解決のままなのかを示してください。たとえば、対象を視覚的に表現できていないありふれた構成や、互いに競合する効果によって中心的なアイデアが見えにくくなっている処理などです。そして、ブリーフの範囲内で具体的な改善策を説明してください。よくあるパターン、控えめなスタイリング、必須のデザインシステムのコンポーネントは欠陥ではありません。

評価

• CRITICAL — 成果物がそのジャンルの目的を果たせていません。エラー時にフォームの入力内容が失われる、スライドの主張を言い換えられない、コンテンツにアクセスできない、または読み取れない、繰り返しのループをまったく完了できない、といった場合です。
• HIGH — 通常の使用で対象者が遭遇する最低基準への違反です。空の状態やエラー状態の欠落、本文テキストのコントラスト不足、狭いビューポートでレイアウトが崩れること、または操作対象や頭の中で保持する値から離れるスクロールが毎回必要になるほど、ループ内で要素を同時に見られない配置などが該当します。また、タスクに必要な情報を実質的に見えにくくする、誤解を招く、または不適切な表現も該当します。
• MEDIUM — レンダリングされた結果に基づき、慎重なレビュアーならリリース前に修正を求める、明確なプロダクト上または品質上の不足です。未解決のクリエイティブな方向性や、対象者のタスクを実質的に難しくするグルーピングなどが該当します。誤解を招くコントロール、誤った動作、明示的な約束の不履行は、High または Critical です。
• LOW — スタイル、命名、構造など、あらゆる種類の仕上げや細かな指摘です。明示的な要件には引き続き拘束力があります。正確性や安全性の問題、または拘束力のある約束の不履行を Low と評価した場合は、呼び出し元のポリシーを適用する前に、証拠に基づいて再評価してください。

呼び出し元は、合格判定の主張と、意図的に指定した重大度またはカテゴリのポリシーを提示します。主張に基づくゲートでは、レンダリング結果が対象者の利用、選択された方向性、または適用される要件にどう反しているかを示してください。評価や別の美的選択肢を示すだけでは、主張への反証になりません。指定されたしきい値は維持してください。判定ゲートの指定がない場合は、結論を示さずに分類を報告してください。復元可能な主張やポリシーがない状態で結論を求められた場合は、確認を求めるか、BLOCKED と報告してください。必要なレンダリング結果や操作に関する証拠が不足している場合は、BLOCKED のままにしてください。

報告

各指摘には、次の内容を含めてください。

• 重大度とルールの領域
• 該当箇所 — 要素、画面、状態、およびそれを示すスクリーンショットまたはマシンチェックの行
• 標準が求めることと、この事例がそれを満たさない理由
• 具体的な修正策 — 1 行で済む場合は変更する値やルール、それ以外の場合は変更の概要

指摘は重大度の高い順、次に位置順で並べてください。問題のない成果物も明確な評価結果です。そのジャンル、使用状況、適用した参考資料を明記し、簡潔に締めくくってください。徹底しているように見せるため、重要性の低い指摘を加えてはいけません。1 つのパターンが多数の箇所にある場合は、2〜3 個の例と件数を挙げて、そのパターンを 1 回だけ報告してください。ルールの適用に正当な判断の余地がある場合は、欠陥と評価するのではなく、指摘内でその旨を示してください。

範囲と対象外

このスキルは、依頼された場合、またはマニフェストによるゲートの対象となる場合に、完成済みまたは制作中の成果物を評価します。デザインのガイダンスは行いません。文章のスタイルはレビューしません。文書の場合は、文章の質ではなく、レイアウト、階層、タイポグラフィ、読み進める構造を評価します。