critique

critique skill の概要

critique は何のためのものか

critique skill は、UI/UX の観点からインターフェース、機能、ページ、コンポーネントを評価するための skill です。「見た目は良いです」といった曖昧な感想ではなく、何が機能していて、何が機能していないのか、そしてその理由は何かを整理して伝えたい人向けです。UI/UX Design のための構造化された critique skill を必要とするプロダクトデザイナー、創業者、PM、QA 的な視点を持つレビュー担当者、そして結果を説明しなければならない AI agent に適しています。

実際に何をするのか

この critique skill は、ビジュアル階層、情報設計、感情的な響き、認知負荷、ヒューリスティックチェック、そして実行可能な改善提案を軸にしています。実務上の役割は、単なる判定ではなく意思決定の支援です。つまり、引っかかりを特定し、品質を採点し、次のデザイン反復につながるフィードバックを出すことです。

どんなときに最適か

レビュー、評価、監査、比較といった依頼に対して、一般的なプロンプトではなく再現性のある方法を使いたいときに critique を使います。デザインの文脈が手元にあり、ユーザーの目的、制約、対話品質の違いまで含めて丁寧に見たい場合に特に向いています。

主な判断ポイント

この repo は、気軽なコメントではなく、より深い critique 作業を想定しています。差別化ポイントは、コンテキスト収集のステップ、独立した評価、ペルソナベースのテスト、そしてスコアリングを前提にした評価です。そのため、レビュー担当者のバイアスを減らし、観察結果を具体的なアウトプットに落とし込みたいときに有効です。

critique skill の使い方

critique skill をインストールする

skill 内で案内されているインストール方法は skills manager 経由です。npx skills add pbakaus/impeccable --skill critique を使います。これは、一回限りのプロンプトにコピペするのではなく、agent workflow の中で skill を使えるようにしたいときの critique のインストール手順です。

適切な入力を与える

critique の利用パターンでは、レビュー対象となる領域、たとえば feature、page、component を指定する必要があります。argument-hint も明確で、プロダクト全体を丸ごと投げるのではなく、絞り込まれた対象を渡す前提です。良い入力例は、「初回利用のモバイルユーザー向けに checkout の shipping step を critique して」や、「この dashboard の filter panel を認知負荷と分かりやすさの観点で critique して」のようなものです。

まず読むべきファイル

素早く critique の手がかりをつかむには、まず SKILL.md を読み、その次に評価品質を形作る補助リファレンスである reference/cognitive-load.md、reference/heuristics-scoring.md、reference/personas.md を確認します。これらのファイルには、どのように採点するのか、何を重視するのか、どのユーザー視点を再現するのかが書かれています。

完成度の高い prompt 形にする

より良い prompt には、デザインの目的、対象ユーザー、プラットフォーム、そして何が変わったのかが含まれます。たとえば、「新規 enterprise admin 向けの onboarding modal を critique して。目的は離脱率の低減。文脈は desktop web、4 ステップ中の 2 ステップで、コピーとレイアウトは昨日変更された」といった形です。こうしておくと、skill が一般論に流れず、実際の失敗要因に集中しやすくなります。

critique skill FAQ

critique は UI/UX Design 専用ですか？

いいえ。最も強い用途は UI/UX Design ですが、階層、分かりやすさ、インタラクション品質が重要な、インターフェースに近い体験であれば他にも使えます。ユーザー向けのフローやレイアウトを評価できないなら、critique skill はおそらく適切ではありません。

critique は通常の prompt とどう違うのですか？

通常の prompt は、主観的なコメントを返しがちです。critique skill には、コンテキスト収集、独立した評価、ペルソナテスト、スコアリングという方法論があります。この構造があることで、出力はより信頼しやすく、比較しやすく、次のアクションに結びつけやすくなります。

使うのにデザインの専門知識は必要ですか？

いいえ。critique skill はレビューのフレームを与えてくれるので、初心者にも役立ちます。最も重要なのは十分なコンテキストを渡すことです。つまり、そのインターフェースが何をするのか、誰向けなのか、成功の定義は何かを伝えることです。それがないと、強力な critique skill でも一般的なフィードバックに流れやすくなります。

critique を使わないほうがよいのはいつですか？

純粋な技術デバッグ、ブランディングだけのレビュー、インタラクション設計要素のないコンテンツ編集には使わないでください。スコアも根拠もない、素早い主観的な意見が欲しいだけなら、これもあまり向いていません。

critique skill を改善する方法

skill により鋭い brief を与える

品質を最も大きく引き上げるのは、より良いコンテキストです。対象の画面、ユーザー種別、デバイス、ビジネス目標を入れてください。「pricing table を critique して」では弱く、「mobile でプラン比較をする SaaS buyer 向けの pricing table を、適格な trial start を増やす目的で critique して」のほうがはるかに良いです。

意見だけでなく根拠を渡す

すでに違和感のある箇所が分かっているなら、どこで、なぜそう感じるのかを伝えます。問題だと思う flow step、ラベル、状態、スクリーンショット上の領域を挙げてください。そうすると critique は、表面的な変更を蒸し返すのではなく、本当の usability issue に集中できます。

よくある失敗パターンに注意する

最も多い失敗は、対象物の指定があいまいで、レビューが広すぎるコメントになることです。もう一つは、ユーザーのタスクを示さずに「feedback」を求めることです。その場合 critique は意図を推測するしかありません。UI/UX Design の critique では、ユーザーが完了すべき主要アクションと、accessibility、mobile behavior、時間的制約などの条件を入れるほどレビューが良くなります。

1 回目の結果を踏まえて再実行する

最初の critique で、重大な問題と見た目の微調整を切り分けます。そのうえで、最もリスクの高い箇所だけを対象にもう一度 skill を実行します。2 回目は、すべてを再レビューさせるよりも、階層、コピーの分かりやすさ、認知負荷など、範囲を狭めて critique を依頼するほうがうまくいきます。