critique

critique skill の概要

critique skill でできること

critique skill は、ページ・機能・コンポーネントを「単に動く UI」としてではなく、「設計された体験」として評価するための、構造化された UX レビューのワークフローです。視覚的ヒエラルキー、情報設計、感情的トーン、認知負荷、ユーザビリティのヒューリスティクスを確認し、曖昧な感想ではなく、具体的な改善フィードバックに落とし込むようモデルを導きます。

critique skill を導入すべき人

この critique skill は、インターフェースに対して素早く UX 監査に近いフィードバックを得たいデザイナー、フロントエンドエンジニア、プロダクトチーム、AI ビルダーに向いています。特に、スクリーンショット、実際に動くページ、完成済みコンポーネントがあり、「このデザインどう思う？」のような汎用プロンプトより一段深いレビューが欲しい場面で有効です。

最も適したジョブ

critique を使うべきなのは、実際の課題が「このインターフェースはなぜ機能しているのか、あるいは失敗しているのか。ユーザーはどこでつまずくのか。何を最優先で直すべきか」を知りたいときです。デザインレビュー、公開前チェック、AI 生成 UI の粗さの洗い出し、優先順位づけが重視される critique for UX Audit の運用に特にフィットします。見た目の良し悪しだけでは終わらない点が強みです。

この skill が他と違う点

critique の大きな差別化ポイントは、評価フレームが明確に“意見を持っている”ことです。広い意味でのデザインコメントで終わらず、AI slop パターンの検出、ヒューリスティクスのスコアリング、ペルソナベースの検証まで明示的に行います。そのため、一般的な critique prompt よりも診断的で、再現性の高い出力になりやすいのが特徴です。

使う前に押さえるべき依存関係

この skill は、実運用では単体完結ではありません。リポジトリ内の指示では、まず /frontend-design skill を使い、そのコンテキスト収集プロトコルに従うことが前提になっています。まだ十分なデザイン文脈がない場合は、critique の前に /teach-impeccable を実行するよう記載されています。導入前に理解しておくべき最大のハードルは、この依存関係です。

critique skill の使い方

インストール時の前提とリポジトリパス

critique skill は pbakaus/impeccable の .agents/skills/critique にあります。skill loader を使う場合は、そのリポジトリからインストールし、critique skill を選択してください。環境がリポジトリ直接指定の skill 読み込みに対応しているなら、指定先は次のとおりです。

• pbakaus/impeccable
• skill: critique

インストール前に手動で中身を確認するなら、まず次を読むのが近道です。

• .agents/skills/critique/SKILL.md
• .agents/skills/critique/reference/cognitive-load.md
• .agents/skills/critique/reference/heuristics-scoring.md
• .agents/skills/critique/reference/personas.md

最初に critique skill を入れる前に読むべきこと

これを、ただ貼り付けて使える prompt snippet と考えないでください。この skill は、事前にデザイン文脈があることを前提にしています。リポジトリでも /frontend-design は必須扱いで、critique を実行する前にそのコンテキスト収集プロトコルに従うよう求めています。ここを省くと、モデルが目標・対象ユーザー・インターフェースの意図を把握できないため、出力品質は目に見えて落ちます。

critique skill に必要な入力

critique skill をしっかり活かすなら、最低でも次を渡すのが理想です。

• レビュー対象のインターフェース領域
• スクリーンショット、または明確な見た目の説明
• プロダクトの目的
• ターゲットユーザー
• ユーザーが完了したい主タスク
• プラットフォーム、ブランド、アクセシビリティ、コンバージョン目標などの制約

最小限の入力でも動きますが、何をもって成功とするかがモデルに伝わっていると、critique の精度は大きく上がります。

もっとも効果的な呼び出し方

この skill の引数ヒントは [area (feature, page, component...)] です。実際には、次のように対象範囲を具体化して呼び出すのが有効です。

• critique checkout page
• critique onboarding modal
• critique dashboard sidebar
• critique pricing page for UX Audit

critique my app のような広すぎる依頼より、対象を絞ったほうが、改善に直結するフィードバックを得やすくなります。

曖昧な依頼を強い critique prompt に変える

弱い依頼:

• “Critique this UI.”

より良い依頼:

• “Critique this settings page for UX Audit. The goal is to help first-time users enable notifications without confusion. Audience is non-technical SMB owners. Prioritize visual hierarchy, cognitive load, and whether the main action is obvious.”

これが機能する理由:

• どのユーザー向けかを明示している
• どのタスクを見ればよいかがわかる
• 成功条件が示されている
• 何を優先して評価すべきかが伝わる

実務でのおすすめ workflow

実務上の critique guide フローとしては、次の順序が堅実です。

1. /frontend-design でコンテキストを集める
2. プロダクトの目標とユーザータスクを明示する
3. 対象の画面・機能・コンポーネントをそのまま critique に渡す
4. 指摘を重大度ごとに整理して出すよう求める
5. 初回レビュー後に、エンジニアリング制約やブランド制約を踏まえた修正版の提案を依頼する

critique と redesign を一度に求めるより、この流れのほうが安定して使えます。

critique skill が得意な評価

リポジトリを見る限り、critique skill が特に強いのは次の領域です。

• AI 生成 UI にありがちな凡庸なパターンの検出
• ヒエラルキーとわかりやすさの評価
• 認知的な過負荷の発見
• ヒューリスティクスに基づくスコアリング
• 関連ペルソナを使ったフローの耐性チェック

つまり、「見た目は整っているのにユーザーにはうまく機能しない」UI を切り分ける用途に向いています。

reference ファイルを活かす読み方

reference ファイルは、見た目以上に重要です。

reference/cognitive-load.md は、タスクそのものが複雑なのか、設計が悪いために複雑になっているのかをモデルが見分ける助けになります。その結果、提案の質も上がります。

reference/heuristics-scoring.md は、Nielsen のヒューリスティクスに沿った 0〜4 の具体的な採点フレームを追加します。複数画面を横並びで比較したいときに便利です。

reference/personas.md は、無条件に全部使うより、実際のオーディエンスに合う 2〜3 のペルソナを選んで使うのが効果的です。毎回 5 つすべてを適用すると、かえって焦点がぼやけます。

UX Audit 向けの critique prompt 例

目的が critique for UX Audit なら、出力形式も構造化して指定するのがおすすめです。たとえば次のように求めると使いやすくなります。

• 上位 5 件の usability risk
• ヒューリスティクスごとのスコアと短い根拠
• 選択したペルソナごとの想定失敗ポイント
• 優先度の高い修正から順に提示
• 変更しないほうがよい点

この形式なら、チームにそのまま共有しやすいレビューになります。

出力品質を下げるよくある誤用

もっとも多い誤用は、インターフェースもスクリーンショットもタスク文脈もないまま、デザインフィードバックだけを求めることです。もうひとつよくあるのが、critique skill をゼロから新しい UI を生成する用途に使うことです。この skill は、デザインシステム全体を発明するよりも、既存 UI を評価し、問題を優先順位づけするほうに適しています。

critique skill の FAQ

critique skill は初心者にも使いやすい？

はい。ただし、最低限の文脈を渡すことが前提です。初心者でも、1 画面と 1 つのユーザー目標を共有すれば、すぐに価値を得やすいです。逆にそれがないと、critique skill はもっともらしく見える一方で、本当のプロダクト課題を外したレビューになることがあります。

普通の critique prompt より良い？

多くの場合は良いです。価値は単なる言い回しではなく、レビュー枠組みが最初から組み込まれている点にあります。AI slop 検出、認知負荷分析、ヒューリスティクスのスコアリング、ペルソナテストが含まれるため、一般的な prompt より critique usage の一貫性が高くなります。

先に frontend-design skill は必要？

実質的には必要です。リポジトリでも必須として扱われています。critique install を初日から実用レベルにしたいなら、単体で使う前提ではなく、/frontend-design と組み合わせる前提で考えるのが無難です。

どんな成果物が最も相性がいい？

最適なのは、スクリーンショット、レンダリング済みページ、プロトタイプ、またはタスク文脈が明確な詳細インターフェース説明です。コードだけでも不可能ではありませんが、UI の挙動や見た目が説明・可視化されていないと、活用度は下がります。

critique を使わないほうがいいのはどんなとき？

次のようなケースでは critique は向きません。

• 実装コードを深くレビューしたい
• アクセシビリティ準拠監査をそれ単体で完結させたい
• analytics ベースでコンバージョン低下の原因を特定したい
• 既存インターフェースがない状態で全面 redesign をしたい

これは UX に特化した評価役であり、専門監査の代替ではありません。

複数のデザイン案を比較できる？

はい。比較スコアリングやトレードオフ整理を求めれば、並列比較にも十分使えます。比較を公正に保つには、各案に対して同じタスク文脈と同じ対象ユーザー文脈を与えることが重要です。

critique skill を改善する方法

画面だけでなく、インターフェースの目的を伝える

critique の結果を改善するうえで最も効果が高いのは、そのインターフェースが何を達成すべきなのかを説明することです。リポジトリでも明示的に求められています。どれだけ美しい画面でも、主タスクが曖昧なら失敗しますし、この skill はまさにそこを見抜くよう設計されています。

重大度・根拠・修正案まで求める

行動につながる出力が欲しいなら、critique skill に次の形式で findings を整理させるのが有効です。

• issue
• なぜ重要か
• UI 上の根拠
• severity
• 推奨される修正

こうすると、ふわっとした感想に流れにくくなり、レビューの優先順位もつけやすくなります。

実際のオーディエンスに合う persona を選ぶ

ペルソナ検証は、関連する archetype だけを選んだときに強く機能します。たとえば次のような使い分けです。

• onboarding なら first-time user
• 情報量の多い dashboard なら impatient power user
• 金融系や破壊的操作を含む flow なら anxious user

すべての persona を毎回使うと、critique が散漫になりがちです。

弱い prompt を具体的な制約で補強する

より強い critique guide prompt には、次のような制約を含めると効果的です。

• mobile-only
• brand cannot change colors
• must keep current information architecture
• engineering team can only make low-effort fixes this sprint

制約があることで、提案が現実的になります。

典型的な失敗パターンを見逃さない

もっともありがちな失敗は、実際のユーザータスクと結びつかない、広くて見栄えのするだけのフィードバックです。初回出力が汎用的すぎると感じたら、次のような追質問で絞り込むと効果的です。

• “Which issue most likely blocks task completion?”
• “What would confuse a first-time user in the first 10 seconds?”
• “Which recommendation has the highest impact with lowest implementation effort?”

ヒューリスティクスのスコアは慎重に使う

スコアは比較や優先順位づけには便利ですが、精密すぎる数字の印象を生みやすいという弱点もあります。各スコアの下に短い根拠も必ず付けるよう求めると、critique skill の評価が、恣意的な数値ではなく、実際に見えている UI の問題に結びつきやすくなります。

critique skill は 2 パスで回す

質の高い workflow は次の 2 段階です。

1. first pass: 問題を診断する
2. second pass: 現実の制約下で解決策を磨く

診断と redesign を分けることで、論点が明確になり、提案の信頼性も上がりやすくなります。

最初の critique 後に出力を改善する

初回実行のあとには、次の情報を返すと精度が上がります。

• ユーザー理解に関する誤った前提の修正
• 修正版状態のスクリーンショット
• モデルが無視した制約
• チームが同意した指摘・同意しなかった指摘

critique skill は、一発判定の審査役として使うより、反復的な reviewer として扱ったほうが伸びます。

critique skill が最も強みを出せる場面で使う

この critique skill が特に価値を発揮するのは、見た目は整っているのに UX 上の問題を隠していそうなインターフェースです。たとえば AI 生成の landing page、dashboard、onboarding flow、settings panel、情報密度の高い feature surface などです。こうした場面では、アンチパターン検出と認知負荷のフレームが、追加の情報価値を大きく生みます。

導入前に理解しておくべきトレードオフ

トレードオフは明快です。critique は、通常の prompting よりも厳密な UX フィードバックを返してくれますが、それは十分な文脈を渡し、この skill のはっきりした評価フレームを受け入れる場合に限られます。軽い場当たり的な意見だけ欲しいなら、普通の prompt のほうが速いこともあります。一方で、再現性のある critique for UX Audit を回したいなら、この skill のほうが適しています。