critique

必須の準備

ユーザーは /critique を使ってこのワークフローを開始します。このスキルが有効になったら、$frontend-design を読み込んでください。デザイン原則、アンチパターン、Context Gathering Protocol が含まれています。先に進む前に、そのプロトコルに従ってください。デザインのコンテキストがまだない場合は、必ず最初に $setup を読み込んでください。さらに、インターフェースが何を達成しようとしているのかを確認します。

---

インターフェースが実際に機能するかどうかを、技術面だけでなく、デザインされた体験として包括的に批評します。デザインディレクターとしてフィードバックするように考えてください。

グレースケールテスト、アクションの優先順位付け、ラベルと値の扱いについては、hierarchy checklist を参照してください。 行の長さ、行間、ベースライン、配置、タイトルの節度については、text hierarchy and readability を参照してください。 ワーキングメモリの限界と8項目のチェックリストについては、cognitive load を参照してください。 見慣れたパターン、ターゲットのサイズ、フォーカスの扱い、オーバーレイの挙動を評価する際は、interaction design を参照してください。 インターフェースがサイト内検索、コマンドパレット、オートサジェスト、検索結果の関連性、または結果がない場合のリカバリーに依存しているときは、search and findability を参照してください。 批評がレガシーシステム、新旧の境界、移行候補、または運用上の高リスクなワークフローに関わる場合は、legacy modernization を参照してください。 アンチパターンをまとめた一覧については、ai slop detection を参照してください。 主要／副次／三次アクションを評価する際は、action hierarchy を参照してください。 色が意味を担っている場合は、semantic color を参照してください。 境界線、カードの使用、重なり、背景色の切り替えを判断する際は、surface separation を参照してください。 スクリーンショット、アイコン、メディアが読みやすさや仕上がりに影響する場合は、image treatment を参照してください。

階層、読みやすさ、認知負荷に関する指針として、共有の frontend-design リファレンスを標準として扱ってください。そのうえで、このスキルは評価、スコアリング、優先順位付けに集中させてください。

空の状態が関係する場合は、empty-state の考え方でゼロデータの画面そのものを評価し、より広範なアクティベーション、アハ体験、初回利用時のガイダンスは onboard の考え方で評価してください。

フェーズ1：デザイン批評

以下の観点からインターフェースを評価してください。

1. AIスロップの検出（最重要）

これが最も重要なチェックです。 2024〜2025年によく見られた、ほかのAI生成インターフェースと同じように見えませんか？

frontend-design スキルの禁止事項すべてと、ai slop detection リファレンスに照らしてデザインを確認してください。これらはAI生成の成果物に見られる特徴です。AIらしいカラーパレット、グラデーションのテキスト、光るアクセントを使ったダークモード、グラスモーフィズム、ヒーロー指標のレイアウト、同じようなカードのグリッド、汎用的なフォントなど、あらゆる兆候をチェックしてください。

判定方法：「AIが作った」と誰かに見せて、その人がすぐに信じるでしょうか？ もしそうなら、それが問題です。

2. 視覚的な階層

• 視線は最も重要な要素に最初に向かいますか？
• 明確な主なアクションがありますか？ 2 秒以内に見つけられますか？
• 適切な要素が目立っていますか？ それとも強調が均等に分散し、印象に残るものがありませんか？（フォン・レストルフ効果）
• サイズ、色、位置は重要度を正しく伝えていますか？
• 異なる重みを持つべき要素同士が視覚的に競合していませんか？
• 画面をグレースケールで見たと想像しても、階層は明確ですか？
• セクションタイトルは、紹介するコンテンツより控えめですか？ それとも注目を奪っていますか？
• アクションの階層が平坦になり、複数のボタンが同じくらい緊急に感じられませんか？

3. 情報設計と認知負荷

作業記憶のルールと 8 項目のチェックリストについては、cognitive-load を参照してください

• 構造は直感的ですか？ 新しいユーザーにも構成が理解できますか？
• 関連するコンテンツは論理的にグループ化されていますか？
• よく使われるパターンは、ユーザーがすでに期待しているとおりに動作しますか？ ナビゲーション、検索、テーブル、フィルター、フォーム、タブ、ドロップダウン、ページネーション、設定に不要な新しさがないか確認してください。
• 避けられる複雑さは、デフォルト値、事前入力、ガイダンスによってシステム側に取り込まれていますか？ それとも、ユーザーが手動で管理するよう押しつけられていますか？（テスラーの法則）
• 一度に選択肢を提示しすぎていませんか？ 各判断ポイントで見える選択肢を数えてください。4 個を超える場合は指摘してください。
• ナビゲーションは明確で予測可能ですか？
• 検索機能がある場合、意図、同義語、入力ミス、目的地として想定される候補を理解していますか？ それとも、内部用語を知らないユーザーに不利益を与えていますか？
• レガシーとモダンなフローが混在する場合、脆弱なステップが 1 つあるだけで、プロダクト全体が信頼できない、または一貫性がないと感じられませんか？
• 段階的な情報開示：複雑さは必要なときだけ示されますか？ それとも最初からユーザーに押しつけられていますか？
• 参照先の 8 項目の認知負荷チェックリストを実施してください。不合格数を報告してください：0～1 件＝低（良好）、2～3 件＝中程度、4 件以上＝重大。

4. 感情的な体験

• このインターフェースはどのような感情を呼び起こしますか？ それは意図したものですか？
• ブランドの個性に合っていますか？
• 信頼できる、親しみやすい、高級感がある、遊び心があるなど、あるべき印象を与えていますか？
• 対象ユーザーは「これは自分のためのものだ」と感じますか？
• 頻繁に行う操作は、ユーザーの作業の流れを保てるほど速く反応しますか？ それとも待ち時間が繰り返し発生し、集中を妨げていますか？（ドハティのしきい値）
• ピーク・エンドの法則：最も印象的な瞬間はポジティブですか？ 体験は確認、祝福、明確な次のステップなど、良い形で終わりますか？
• 感情の落ち込み：オンボーディング時の不満、エラー時の壁、機能の見つけにくさ、または重要な場面（支払い、削除、コミット）で不安が高まる箇所がないか確認してください。
• ネガティブな瞬間への介入：ユーザーが不満や不安を感じそうな場面で、デザインによる介入がありますか？（進行状況の表示、安心させる文言、元に戻すオプション、ソーシャルプルーフ）

5. 見つけやすさとアフォーダンス

• インタラクティブな要素は、見ただけで操作できるとわかりますか？
• ユーザーは説明がなくても何をすべきかわかりますか？
• 主な操作対象や頻繁に使う操作対象は、特にタッチデバイスで自信を持って使えるほど大きく、近くに配置されていますか？
• 強力な機能には、そのリスクに応じた保護策（権限、プレビュー、元に戻す、確認、履歴、または結果を明示する文言）がありますか？
• ホバー時やフォーカス時の状態は、有用なフィードバックを提供していますか？
• もっと見つけやすくすべき隠れた機能はありませんか？

6. 構成とバランス

• レイアウトのバランスは取れていますか？ それとも重心が偏り、不快に感じられますか？
• 余白は意図的に使われていますか？ それとも単に残っているだけですか？
• 間隔や繰り返しに視覚的なリズムがありますか？
• 非対称性は意図的にデザインされたものに見えますか？ それとも偶然に見えますか？
• グループの内側より外側に十分な余白がありますか？ それともグループの境界が曖昧ですか？
• 枠線は必要な構造上の役割を果たしていますか？ それとも、余白や背景のコントラストの弱さを補っているだけですか？
• カード、影、重なり、背景の切り替えは、明確な分離戦略に沿って使われていますか？ それとも複数の手法が重なり、雑然としていますか？

7. タイポグラフィによるコミュニケーション

• 文字の階層によって、最初に読むもの、次に読むもの、その次に読むものが明確に示されていますか？
• 本文は読みやすいですか？（行の長さ、間隔、サイズ）
• フォントの選択はブランドやトーンを強化していますか？
• 見出しのレベル間に十分なコントラストがありますか？
• 本格的な文字サイズの体系に見せるには、似たようなサイズが多すぎませんか？
• 行の長さに合った行間になっていますか？それとも、長い段落が窮屈に感じられますか？
• セクションタイトルは、担う役割に対して視覚的に目立ちすぎていませんか？
• リンクは、ウェイトや下線、ホバー時の表現を控えめにするよりも、色によって注目を集めすぎていませんか？
• 数値を見比べる必要がある場合、比較しやすいように数値列が揃っていますか？

8. 目的のある色使い

• 色は単なる装飾ではなく、情報を伝えるために使われていますか？
• カラーパレットに統一感がありますか？
• アクセントカラーは適切な要素に注目を集めていますか？
• 色覚異常のあるユーザーにも機能しますか？（技術的に使えるだけでなく、意味が伝わりますか？）
• 色付きの面には適切な文字色が使われていますか？それとも、色の上に薄いグレーの文字が載ったような見づらい状態になっていませんか？
• パレットに体系性を感じられなくなるほど、場当たり的な色合いが多くありませんか？

9. 状態とエッジケース

• 空の状態：ユーザーの行動を促していますか？それとも、単に「ここには何もありません」と表示するだけですか？
• 読み込み状態：体感の待ち時間を短くしていますか？
• フォームや検索では、無害な入力の揺れを適切に受け入れていますか？それとも、正規化できる書式の細かな違いを理由にユーザーを拒否していませんか？（Postel の法則）
• エラー状態：役に立ち、ユーザーを責めない内容になっていますか？
• 成功状態：完了を確認し、次の手順を案内していますか？
• スクリーンショットは、表示サイズで読みやすいですか？
• アイコンの拡大縮小は、意図的に見える方法で行われていますか？粗く見えたり、ぼやけたりしていませんか？

10. マイクロコピーとトーン

• 文章は明確で簡潔ですか？
• 人間らしい語り口になっていますか？（このブランドにふさわしい人間らしさですか？）
• ラベルやボタンの意味は明確ですか？
• フローのどこかに、同意をわかりにくくする、キャンセルを妨げる、罪悪感をあおる文言、偽りの緊急性、望ましくない選択を迫る階層構造など、操作的な要素はありませんか？
• エラーの文言は、ユーザーが問題を解決するのに役立ちますか？

フェーズ 2：調査結果を提示する

デザインディレクターのように、フィードバックを構成してください。

デザイン健全性スコア

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

Nielsenの10のヒューリスティクスをそれぞれ0〜4で評価してください。以下の表で提示してください。

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

スコアは正直に付けてください。4点は、真に優れている場合に限ります。実際のインターフェースの多くは20〜32点です。

アンチパターンの判定

まずここから始めてください。 合格／不合格で判定してください。AI生成に見えますか？スキルの「アンチパターン」セクションにある具体的な兆候を列挙してください。率直に評価してください。

合格／不合格の判定の直後に、階層構造についての評価を一文で記載してください。

全体的な印象

率直な印象を簡潔に述べてください。うまくいっている点、うまくいっていない点、そして最大の改善機会を1つ挙げてください。

うまくいっている点

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

優先度の高い問題

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

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

• [P?] 問題点：問題を明確に示します
• 重要な理由：ユーザーにどのような不利益を与えるか、または目標の達成をどのように妨げるか
• 修正方法：具体的な対処方法
• 推奨コマンド：対処に使えるコマンド（以下から選択：/animate、/arrange、/critique、/extract、/polish、/optimize、/audit、/typeset、/bolder、/clarify、/delight、/adapt、/colorize、/quieter、/harden、/distill、/onboard、/normalize、/showcase）

表面的な細かな指摘よりも、階層構造の弱さ、恣意的なデザインシステム、アクションの優先順位の不明確さ、装飾の過剰さに関する問題を優先してください。

該当する場合は、次の問題を明示的に指摘してください：枠線が多すぎる、グループ分けが曖昧、フォントサイズが多すぎる、体系化されていない色合いが多すぎる、セクションタイトルが目立ちすぎる、アクションの優先順位が平坦化している、行の長さと行の高さが合っていない、「ラベル：値」というアンチパターン、リンクの色による強調が不要、数値列が右揃えでない、サーフェスの区別方法が弱い、スクリーンショットを縮小すると判読できない、アイコンを拡大すると粗くなる、レイヤーが明確に分離されておらず重なりが衝突している。

ペルソナ別の懸念点

personasを参照してください

このインターフェースの種類に最も関連するペルソナを2〜3人、自動的に選択してください（参照ドキュメントの選択表を使用してください）。setupによってAGENTS.mdに## Design Contextセクションが追加されている場合は、対象ユーザーやブランド情報に基づいて、このプロジェクト固有のペルソナも1〜2人作成してください。

選択した各ペルソナについて、主要なユーザーアクションをたどり、見つかった具体的な問題点を列挙してください。

Alex（パワーユーザー）：キーボードショートカットが見当たりません。主要な操作に8回のクリックが必要です。強制的にモーダルでオンボーディングされます。⚠️ 離脱リスクが高いです。

Jordan（初回利用者）：サイドバーのナビゲーションがアイコンのみです。エラーメッセージに「404 Not Found」のような専門用語があります。ヘルプが表示されません。⚠️ ステップ2で離脱します。

具体的に記述してください。各ペルソナにとって問題となる要素や操作を正確に挙げてください。一般的なペルソナの説明ではなく、何が妨げになったのかを書いてください。

軽微な所見

対応を検討する価値のある、小さな問題を簡潔に記します。

留意事項：

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

フェーズ 3：ユーザーに質問する

調査結果を提示した後、実際に見つかった内容に基づいて、的を絞った質問をします。推測できないことについては、ユーザーに直接確認してください。回答をもとにアクションプランを作成します。

以下のような質問をします（具体的な調査結果に合わせて調整し、一般的な質問はしないでください）。

1. 優先する方向性：見つかった問題に基づいて、今ユーザーが最も重視しているカテゴリを尋ねます。例：「視覚的な階層、色の使い方、情報過多に問題があることがわかりました。どの領域から取り組みましょうか？」上位 2～3 個の問題カテゴリを選択肢として提示します。

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

3. 範囲：どの程度取り組みたいかを尋ねます。例：「N 個の問題が見つかりました。すべて対応しますか、それとも上位 3 件に絞りますか？」「上位 3 件のみ」「すべての問題」「重大な問題のみ」などの範囲を選択肢として提示します。

4. 制約（任意 — 関連する場合のみ質問）：調査結果が多くの領域に及ぶ場合、変更してほしくない箇所があるか尋ねます。例：「現状のままにしておくべきセクションはありますか？」これにより、ユーザーが完成済みと考えている箇所に手を加えずに済みます。

質問に関するルール：

• すべての質問でフェーズ 2 の具体的な調査結果に触れてください。「対象ユーザーは誰ですか？」のような一般的な質問はしないでください
• 質問は最大 2～4 件にとどめ、ユーザーの時間を尊重してください
• 自由回答ではなく、具体的な選択肢を提示してください
• 調査結果が明確な場合（例：明らかな問題が 1～2 件のみの場合）は質問を省略し、フェーズ 4 に進んでください

フェーズ 4：推奨アクション

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

アクション概要

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

1. /command-name — 修正する内容の簡潔な説明（批評で見つかった具体的な状況）
2. /command-name — 簡潔な説明（具体的な状況） ...

推奨に関するルール：

• 次のコマンドのみを推奨してください：/animate、/arrange、/critique、/extract、/polish、/optimize、/audit、/typeset、/bolder、/clarify、/delight、/adapt、/colorize、/quieter、/harden、/distill、/onboard、/normalize、/showcase
• まずユーザーが明示した優先事項に沿って並べ、その後に影響度の高い順に並べてください
• 各項目の説明には、コマンドが何に重点を置くべきかを判断できるだけの文脈を含めてください
• 優先課題ごとに適切なコマンドを割り当ててください
• 対応する問題がないコマンドは省略してください
• ユーザーが範囲を限定した場合、その範囲に含まれる項目のみを記載してください
• ユーザーが変更しない箇所を指定した場合、その箇所に手を加えるコマンドは除外してください
• 修正を推奨する場合は、最後のステップとして /polish を含めてください

概要を提示した後、ユーザーに次のように伝えてください。

これらを一つずつ、すべてまとめて、またはお好みの順番で実行するよう依頼できます。

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