mcpField
C
critique

critique

github.com/tranz007デザイン・UI4844 回インストール8 週間前に更新
リポジトリ

critique について

Critiqueは、意図や文脈に照らしてデザイン、コンテンツ、実装を評価するスキルです。根拠に基づいて重大な問題を優先し、好みではなく具体的な改善の方向を示します。

主な機能

  1. 01プロジェクトの文脈に沿ったレビュー
  2. 02事実、推論、不明点の区別
  3. 03ユーザー目標と操作状態の確認
  4. 04信頼性とプライバシーのリスク特定
  5. 05影響度に応じた指摘の優先順位付け

活用シーン

  1. 01デザインや製品成果物のレビュー
  2. 02意図したUXに対するコード変更の確認
  3. 03実際の課題に基づく選択肢の比較

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/tranz007/ux-skills --skill critique

インストール後、Claude Code で/critiqueを入力して読み込まれたか確認します。

詳細

批評

個人の好みではなく、背景と目的に照らして成果物をレビューします。

常に

  • 背景 — ユーザーに同じ情報を繰り返し求める前に、すでに分かっていることを確認します。製品の目的や成果によって回答が変わる場合は .ux/INTENT.md を参照し、タスクに必要な追加のプロジェクト情報だけを読み込みます。
  • ユーザー — 影響を受ける人々、その目標、タスク、状況、利用可能な根拠に基づいて考えます。ユーザーのニーズ、行動、ペルソナを捏造しません。
  • 根拠 — 違いが重要な場合は、判明していること、推測したこと、仮定したこと、不明なこと、意見が食い違っていることを区別します。
  • システム — 新しいものを考案する前に、確立された製品用語、コンポーネント、パターン、ルールを優先します。
  • 明快さ — 役立つ要点を先に述べ、必要最小限の構成にし、一般的な AI の冗長表現を取り除きます。
  • 信頼 — 根拠、要件、理由、実装状況、コンプライアンスを捏造しません。
  • 成果 — 複数の段階にわたる重要な作業では、意図を常に把握します。継続性の維持が必要な場合に限り、小さな .ux/STATE.md を使用し、仕上げよりも影響の大きい未解決の問題を優先して、完了を宣言する前に実際の体験が意図に沿っているかを検証します。

これらのルールが回答に重大な影響を与えない限り、ユーザーに繰り返し説明しないでください。

ユーザーとタスクが明確な場合や、不足情報によって作業が大きく変わらない場合は、調査上の質問、ペルソナ、ディスカバリーの取り組みを持ち込まないでください。

評価の根拠を確立する

成果物と、関連する .ux/ のコンテキスト、根拠、デザインシステムのパターン、アクセシビリティのルール、既知の制約、過去の決定事項を、必要最小限の範囲で確認します。実装をレビューする場合は、意図された UX の情報源だけでなく、実際のコードや差分も確認します。

目的が不明確な場合は、目的を踏まえずに批評すると誤解を招く場合に限り、慎重な推測を先に示すか、質問します。

関連する観点からレビューする

この作業に関係する観点だけを使います。

  • ユーザーの目標とタスクの明確さ
  • 根拠と、裏付けのない仮定
  • 情報の優先順位と認知的負荷
  • 操作、分岐、中断、復旧
  • 状態の網羅性
  • コンテンツと用語
  • アクセシビリティとインクルーシブな利用
  • 一貫性とデザインシステムへの適合
  • エンジニアリングまたはサービス上の依存関係
  • 信頼、プライバシー、関連する場合の影響

必要に応じて比較する

複数の選択肢を比較する場合は、実際の課題に基づいて重要な判断基準を定め、すべての選択肢を同じ基準で評価します。比較を見た目の優劣にすり替えないでください。「どれも選ばない」も妥当な推奨です。

実装との乖離をレビューする

成果物がコードや PR の場合は、UX の挙動に変更や欠落がないか確認します。状態、復旧、永続化、コンテンツ、デザインシステムの利用、フォーカスやキーボード操作、受け入れ基準上の意図を確認します。

差分だけでは実行時の挙動は証明できません。推測を事実として示すのではなく、引き続き検証が必要な点を伝えます。

指摘事項に優先順位を付ける

失敗、排除、損失、誤解、重大な実装上の乖離を招く可能性が高い問題を先に述べ、細かな仕上げの指摘は後に回します。

どの挙動や要素が問題なのか、それがなぜ重要なのかを示し、改善の方向性を推奨します。何が問題なのかを示さずに「階層を改善する」のような曖昧なコメントをしないでください。

成果物の出来が良い場合は、言葉を費やしすぎず、良い点を確認します。問題を捏造しないでください。

ガードレール

見た目やコードの確認だけでアクセシビリティへの準拠を断言しないでください。調査結果を捏造しないでください。根拠なく、確立されたシステムのパターンより新しさを優先しないでください。

対比例

悪い例:

視覚的な階層を改善し、CTAを目立たせ、フォームを簡潔にして、アクセシビリティも検討してください。

良い例:

必須の旅行日が有効になる前に、主要なアクションが実行可能に見えます。これでは誤った操作の手がかりとなり、フォームの準備が整う前にユーザーが先へ進もうとしてしまいます。日付が有効になるまでアクションを実行できないようにするか、送信前に必要な修正が明確にわかるよう、早い段階で検証結果を表示してください。

理由:良い批評は、具体的な動作を指摘し、その影響を説明したうえで、一般論ではなく改善の方向性を示しています。

例

  • 「エンジニアリングチームに見せる前に、これをレビューしてください。」
  • 「厳しめに批評してください。」
  • 「ユーザーの課題に照らして、2つのアプローチを比較してください。」
  • 「意図したユーザー体験に照らして、このPRをレビューしてください。」

コメント