critique

手順

ステップ 1：準備

デザイン原則、アンチパターン、コンテキスト収集プロトコルを含む /impeccable を呼び出します。先に進む前に、このプロトコルに従ってください。デザインコンテキストがまだ存在しない場合は、まず必ず /impeccable teach を実行してください。さらに、インターフェースが何を実現しようとしているのかを確認します。

ステップ 2：評価の収集

独立した評価を2つ開始します。バイアスを避けるため、どちらの評価者も、もう一方の評価結果を見る必要はありません。

独立性を保つため、各評価を別々のサブエージェントに委任することを推奨します。環境のエージェント起動メカニズム（Claude Code の Agent ツールや、Codex のサブエージェント起動機能など）を使用してください。サブエージェントには、構造化されたテキストで調査結果を返すよう指示してください。調査結果は、まだユーザーに出力しないでください。

現在の環境でサブエージェントを使用できない場合は、各評価を順番に実施し、次に進む前に調査結果を内部メモに記録してください。

タブの分離：ブラウザー自動化を使用できる場合、各評価では必ず新しいタブを作成してください。正しい URL がすでに開かれていても、既存のタブを再利用しないでください。これにより、2つの評価間でページの状態が干渉するのを防げます。

評価 A：LLM デザインレビュー

関連するソースファイル（HTML、CSS、JS/TS）を読み、ブラウザー自動化を使用できる場合は、ライブページを目視で確認します。そのために新しいタブを作成し、既存のタブは再利用しないでください。ページに移動した後、ドキュメントのタイトルを設定してタブに名前を付けます。

document.title = '[LLM] ' + document.title;

デザインディレクターの視点で評価してください。

AI っぽさの検出（最重要）：この画面は、ほかの AI 生成インターフェースと同じ見た目になっていませんか？impeccable スキルの禁止事項をすべて確認してください。AI らしい配色、グラデーションのテキスト、暗いグロー、グラスモーフィズム、ヒーローメトリクスのレイアウト、均一なカードグリッド、ありきたりなフォントなど、AI 生成を思わせる要素をすべて確認します。判断基準：「これ、AI が作ったんだ」と言われて、すぐにそう思いますか？

総合的なデザインレビュー：視覚的な階層（視線の流れ、主要なアクションの明確さ）、情報アーキテクチャ（構成、グルーピング、認知負荷）、感情への訴求（ブランドや対象ユーザーに合っているか）、発見しやすさ（操作可能な要素がわかりやすいか）、構図（バランス、余白、リズム）、タイポグラフィ（階層、読みやすさ、フォントの選択）、色（目的に沿った使い方、統一感、アクセシビリティ）、状態とエッジケース（空、読み込み中、エラー、成功）、マイクロコピー（明確さ、トーン、役立ち度）。

認知負荷（cognitive-loadを参照）：

• 8項目の認知負荷チェックリストを実施します。不合格数を報告します：0～1＝低（良好）、2～3＝中程度、4以上＝重大。
• 各判断ポイントで見える選択肢の数を数えます。4つを超える場合は指摘してください。
• プログレッシブディスクロージャーを確認します。必要になるまで複雑さが隠されていますか？

感情の流れ：

• このインターフェースはどのような感情を呼び起こしますか？それは意図したものですか？
• ピーク・エンドの法則：最も強い感情が生じる場面はポジティブですか？体験は良い形で終わりますか？
• 感情の落ち込み：支払い、削除、コミットなど、重要度の高い場面で不安が高まらないか確認します。進捗インジケーター、安心感を与えるコピー、元に戻すオプションなどのデザイン上の工夫はありますか？

ニールセンのヒューリスティクス（heuristics-scoringを参照）： 10項目のヒューリスティクスそれぞれを0～4で採点します。この採点結果はレポートに記載します。

次の内容を含む、構造化された調査結果を返してください：AI っぽさの判定、ヒューリスティクスのスコア、認知負荷の評価、うまく機能している点（2～3項目）、優先度の高い問題（内容・理由・修正案を含む3～5項目）、軽微な所見、そして鋭い問いかけ。

評価 B：自動検出

同梱の決定論的検出ツールを実行します。このツールは、25 種類の特定パターン（AI らしさを示す特徴と、一般的なデザイン品質）を検出します。

CLI スキャン：

npx impeccable --json [--fast] [target]

• [target] として HTML／JSX／TSX／Vue／Svelte のファイルまたはディレクトリを渡します（マークアップを含むもの）。CSS のみのファイルは渡さないでください。
• URL の場合は、CLI スキャンを省略します（Puppeteer が必要です）。代わりにブラウザーで視覚的に確認してください。
• 大規模なディレクトリ（スキャン対象のファイルが 200 件以上）の場合は、--fast を使用します（正規表現のみで検査し、jsdom はスキップします）。
• ファイルが 500 件以上ある場合は、対象範囲を絞るか、ユーザーに確認してください。
• 終了コード 0 = 問題なし、2 = 検出結果あり

ブラウザーでの視覚的な確認（ブラウザー自動化ツールが利用可能で、対象が表示可能なページの場合）：

オーバーレイはユーザー向けの視覚的な補助です。ユーザーのブラウザー上で問題箇所を直接強調表示します。オーバーレイのスクリーンショットを撮るためにページをスクロールしないでください。代わりに、コンソール出力を読み取って結果をプログラムで取得してください。

1. ライブ検出サーバーを起動します：

   npx impeccable live &
   

   標準出力に表示されるポート番号（自動割り当て）を控えてください。固定するには --port=PORT を使用します。
2. 新しいタブを作成し、ページに移動します（ローカルファイルの場合は開発サーバーの URL、または直接 URL を使用します）。既存のタブは再利用しないでください。
3. javascript_tool を使ってタブにラベルを付け、ユーザーが識別できるようにします：

   document.title = '[Human] ' + document.title;
   

4. ページを先頭までスクロールし、スクリプトを挿入する前にページが最上部にあることを確認します。
5. javascript_tool でスクリプトを挿入します（PORT は手順 1 で控えたポート番号に置き換えます）：

   const s = document.createElement('script'); s.src = 'http://localhost:PORT/detect.js'; document.head.appendChild(s);
   

6. 検出ツールがオーバーレイを表示するまで 2～3 秒待ちます。
7. impeccable パターンを指定して read_console_messages を使い、コンソールから結果を読み取ります。検出ツールは、すべての検出結果を [impeccable] プレフィックス付きで記録します。オーバーレイのスクリーンショットを撮るためにページをスクロールしないでください。
8. クリーンアップ：完了したらライブサーバーを停止します：

   npx impeccable live stop
   

複数のビューがある対象では、代表的な 3～5 ページにスクリプトを挿入します。挿入に失敗した場合は、CLI の結果のみで続行してください。

返す内容：CLI の検出結果（JSON）、ブラウザーのコンソールでの検出結果（該当する場合）、および確認した誤検出。

ステップ 3：統合批評レポートの作成

両方の評価を統合し、1 つのレポートにまとめます。単純に連結しないでください。LLM によるレビューと検出ツールの評価が一致する点、検出ツールが LLM の見落としを検出した点、検出結果が誤検出である点を織り交ぜて説明します。

デザインディレクターのような視点でフィードバックを構成します。

デザインの健全性スコア

heuristics-scoring を参照してください

Nielsen の 10 ヒューリスティックのスコアを、次の表に示します。

#	ヒューリスティック	スコア	主な問題
1	システム状態の可視性	?	[具体的な所見、または問題がなければ「n/a」]
2	システムと現実世界の一致	?
3	ユーザーによる制御と自由	?
4	一貫性と標準	?
5	エラーの予防	?
6	想起より認識	?
7	柔軟性と効率性	?
8	美的でミニマルなデザイン	?
9	エラーからの回復	?
10	ヘルプとドキュメント	?
合計		??/40	[評価帯]

スコアは率直に付けてください。4 は本当に優れている場合のスコアです。実際のインターフェースの多くは 20～32 点です。

アンチパターンの評価

ここから始めてください。 AI が生成したように見えますか？

LLM による評価：AI らしさを示す特徴について、独自に評価します。全体的な美的印象、レイアウトの画一性、ありきたりな構成、個性を出す機会を逃している点を取り上げます。

決定論的スキャン：自動検出ツールが検出した内容を、件数とファイルの場所を含めて要約します。見落としていた追加の問題を検出ツールが見つけた場合は記載し、誤検出があれば明示します。

視覚的オーバーレイ（ブラウザーを使用した場合）：検出された問題を強調表示するオーバーレイが、ブラウザーの [Human] タブに表示されていることをユーザーに伝えます。コンソール出力で報告された内容を要約します。

全体的な印象

率直な感想を簡潔に述べます。うまくいっている点、うまくいっていない点、最大の改善機会を 1 つ挙げます。

うまくいっている点

うまくできている点を 2～3 個取り上げます。効果がある理由を具体的に説明します。

優先度の高い問題

影響の大きい設計上の問題を3〜5件、重要度順に示します。

各問題にP0〜P3の重大度を付けます（重大度の定義はheuristics-scoringを参照してください）。

• [P?] 問題：問題を明確に示します
• 重要な理由：ユーザーにどのような悪影響を与えるか、目標をどのように損なうか
• 修正方法：具体的な対処法
• 推奨コマンド：対処に使えるコマンド（次の中から選択してください：/animate、/quieter、/shape、/optimize、/adapt、/clarify、/layout、/distill、/delight、/audit、/harden、/polish、/bolder、/typeset、/critique、/colorize、/overdrive）

ペルソナ別の懸念点

personasを参照してください

このインターフェースの種類に最も関連するペルソナを2〜3人、自動選択します（参照資料の選択表を使用してください）。.github/copilot-instructions.mdにimpeccable teachが作成した## Design Contextセクションがある場合は、対象ユーザーやブランドの情報から、プロジェクト固有のペルソナも1〜2人作成してください。

選択した各ペルソナについて、主要なユーザー操作を順にたどり、見つかった具体的な懸念点を列挙します。

Alex（パワーユーザー）：キーボードショートカットが見つからない。主要操作に8回のクリックが必要。モーダルによるオンボーディングを強制される。離脱リスクが高い。

Jordan（初めて使うユーザー）：サイドバーのナビゲーションがアイコンのみ。エラーメッセージに専門用語（「404 Not Found」）が使われている。ヘルプが見当たらない。手順2で離脱する。

各ペルソナにとって問題となる具体的な要素や操作を特定してください。一般的なペルソナの説明ではなく、何が機能しなかったのかを書いてください。

軽微な所見

対処する価値のある細かな問題を簡潔に記します。

検討すべき質問

よりよい解決策につながる、考えを促す質問：

• 「主要な操作をもっと目立たせるとどうでしょうか？」
• 「ここまで複雑である必要はありますか？」
• 「自信を持てるデザインにするには、どうすればよいでしょうか？」

留意点：

• はっきり伝えてください。曖昧なフィードバックは、全員の時間を無駄にします。
• 具体的に伝えてください。「一部の要素」ではなく、「送信ボタン」と書いてください。
• 問題点だけでなく、それがユーザーにとってなぜ重要なのかも伝えてください。
• 「検討してみてください」だけで済ませず、具体的な提案をしてください。
• 優先順位を厳格に付けてください。すべてが重要なら、何も重要ではありません。
• 批判を和らげないでください。優れたデザインをリリースするには、開発者に率直なフィードバックが必要です。

ステップ4：ユーザーに質問する

所見を提示した後、実際に見つかった問題に基づいて、的を絞った質問をします。推測できない点を明らかにするため、ユーザーに直接尋ねてください。回答はアクションプランに反映されます。

次のような質問をします（見つかった問題に合わせて調整し、一般的な質問はしないでください）。

1. 優先する方向性：見つかった問題を踏まえ、今もっとも重視したい分野を尋ねます。例：「視覚的な階層、色の使い方、情報過多に問題が見つかりました。まずどの分野から取り組みますか？」上位2〜3個の問題分野を選択肢として提示してください。

2. デザインの意図：批評でトーンの不一致が見つかった場合、それが意図的かどうかを尋ねます。例：「インターフェースが無機質で企業的な印象です。意図したトーンですか、それとも、もっと温かみのある／大胆な／遊び心のある印象にしたいですか？」見つかった問題を解決できるトーンの方向性を2〜3個、選択肢として提示してください。

3. 範囲：ユーザーがどこまで対応したいかを尋ねます。例：「問題がN件見つかりました。すべて対応しますか、それとも上位3件に絞りますか？」選択肢として「上位3件のみ」「すべての問題」「重大な問題のみ」などを提示してください。

4. 制約（任意。関連する場合のみ質問）：所見が多くの領域に関わる場合、変更対象から外すべき箇所があるか尋ねます。例：「現状のままにしておくセクションはありますか？」これにより、ユーザーが完成済みと考えている箇所に計画が及ぶのを防げます。

質問のルール：

• 各質問では、レポートで見つかった具体的な問題に触れてください。「対象ユーザーは誰ですか？」のような一般的な質問はしないでください。
• 質問は最大2〜4個にしてください。ユーザーの時間を尊重してください。
• 自由回答式ではなく、具体的な選択肢を提示してください。
• 所見が明確な場合（例：明らかな問題が1〜2件のみの場合）は、質問を省略してステップ5に進んでください。

ステップ 5：推奨アクション

ユーザーの回答を受け取った後、ステップ 4 で示されたユーザーの優先事項と対象範囲を反映した、優先順位付きのアクション概要を提示します。

アクション概要

ユーザーの回答に基づき、推奨コマンドを優先順位順に列挙します。

1. /command-name：修正する内容の簡潔な説明（批評結果から具体的な状況を示す）
2. /command-name：簡潔な説明（具体的な状況を示す） ...

推奨ルール：

• 推奨できるコマンドは次のものに限ります：/animate、/quieter、/shape、/optimize、/adapt、/clarify、/layout、/distill、/delight、/audit、/harden、/polish、/bolder、/typeset、/critique、/colorize、/overdrive
• まずユーザーが明示した優先事項の順に並べ、次に影響度を考慮します
• 各項目の説明には、コマンドが重点的に対応すべき内容を十分に記載します
• 各優先課題を適切なコマンドに割り当てます
• 対応する課題がないコマンドは省きます
• ユーザーが対象範囲を限定した場合は、その範囲内の項目のみを含めます
• ユーザーが対象外とした領域に手を加えるコマンドは除外します
• 修正を推奨する場合は、最後のステップとして /polish を含めます

概要を提示した後、ユーザーに次のように伝えます。

これらのコマンドは、1 つずつでも、まとめてでも、お好きな順番でも実行するよう依頼できます。

修正後に /critique を再実行すると、スコアの改善を確認できます。