mcpField
C
critique

critique

github.com/plugin87デザイン・UI3.1k159 回インストール4 日前に更新
リポジトリ

critique について

デザインレビュー用スキルです。独立したエージェントに、必要なキットの確認、レビュー指示の読み込み、対象の描画、操作テストを行わせ、根拠に基づく指摘をまとめます。レビュー範囲を明記し、裏付けのない採点を避けます。

主な機能

  1. 01必要なキットファイルの確認
  2. 02指定されたレビュー指示への準拠
  3. 03デスクトップ・モバイル幅での画面描画
  4. 04操作テストと変化の記録
  5. 05ビジュアル・レスポンシブ監査の実行
  6. 06根拠付きの指摘と範囲の報告

活用シーン

  1. 01UI ファイルやディレクトリのレビュー
  2. 02レスポンシブレイアウトとテーマの確認
  3. 03画面操作への反応のテスト
  4. 04根拠を添えたデザイン評価の作成

インストール

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

$npx skills add https://github.com/plugin87/ux-ui-agent-skills --skill critique

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

詳細

あなたは現在、フォークされたコンテキストで実行されています。この作業につながった会話を見ることはできず、ユーザーに質問することもできません。また、ほかで得た情報は一切関係ありません。必要な情報はすべて以下またはディスク上にあります。

ステップ 0 — キットはありますか？

ls ${CLAUDE_SKILL_DIR}/../../../tokens >/dev/null 2>&1 && echo KIT_OK || echo KIT_MISSING

KIT_MISSING の場合、インストールされているのはスキルフォルダーのみです。これは npx skills add の動作です。そのことを率直に伝え、npx ux-ui-agent-skills init またはプラグインのインストールを案内して、そこで終了してください。開けなかったファイルの内容を推測してはいけません。

ステップ 1 — 批評者の指示をすべて確認します。

cat ${CLAUDE_SKILL_DIR}/../../../.claude/agents/design-critic.md

そのファイルがあなたへの指示書です。立場、決して破ってはいけない3つのルール、判定の形式が記されています。内容を読み、そのとおりに従ってください。ファイルが見つからない場合は、そのことを伝えて終了してください。指示書なしで批評を即興で行ってはいけません。指示を受けていない批評者は、レビューではなくセカンドオピニオンです。

ステップ 2 — 対象を特定します。

対象：$ARGUMENTS — ファイルまたはディレクトリです。

質問はできません。$ARGUMENTS が空、または指定されたものが存在しない場合は、渡された内容を正確に伝え、受け付ける対象を列挙して終了してください。推測した対象への批評は、実際の成果物に対する判定のように見えてしまうため、批評しないよりも悪い結果になります。

ステップ 3 — 見ずに批評することを拒否します。

ソースだけを見て書いた批評には価値がありません。対象をレンダリングして確認してください。画面またはハーネスごとに、幅 1280 と 390、ライトモードとダークモード、トランジション無効、ポインターを UI の外に置いた状態でスクリーンショットを撮ります。次に、すべてのコントロールをクリックし、実際に何が変わったかを書き留めます。何も変わらないコントロールがあれば、それは指摘事項です。

ステップ 4 — 引用する数値を集めます。

KIT=${CLAUDE_SKILL_DIR}/../../..
node $KIT/scripts/taste_audit.mjs      <file> && node $KIT/scripts/taste_audit.mjs <file> --dark
node $KIT/scripts/slop_tells.mjs       <file> && node $KIT/scripts/slop_tells.mjs  <file> --dark
node $KIT/scripts/verify_overflow.mjs  <file|dir>
node $KIT/scripts/verify_responsive.mjs <file|dir> --scale=1.25

実際に出力された内容を報告してください。これらはヒューリスティックです。観察した内容を示すものであり、良し悪しを決めるものではありません。問題なく実行できても、弁明にはなりません。キットに含まれる、意図的に欠陥を仕込んだフィクスチャは、両方のテーマですべてのチェックを通過しますが、そのどれもシニアデザイナーなら差し戻す内容です。

ステップ 5 — 判定を記述します。

design-critic.md に指定された形式で、判定、シニアデザイナーが差し戻す3つの理由、そして各指摘事項の根拠を示す表を記述してください。ファイル名と要素を明記します。「間隔がしっくりこない」は指摘事項ではありません。「カード内の 12px の余白とカード間の 12px の余白が同じため、グループ全体がひとまとまりに見える」は指摘事項です。

表現を和らげたり、バランスを取るために「良い点」のリストを水増ししたりしないでください。

ステップ 6 — 毎回、評価範囲を明記します。

これは判断であり、測定ではありません。パーセンテージは算出されず、このリポジトリのどのパーセンテージもセンスを評価するものではありません。そのことを出力に記載してください。

批評が返ってきた後

このスキルを呼び出したセッションで対応してください。フォーク内ではありません。

批評を踏まえて対応します。Critical と Major の指摘事項をすべて修正し、/gate を再実行してから、変更した箇所をもう一度批評してください。残る指摘事項が Minor または Enhancement になった時点でループを終えます。疲れたからといって終えてはいけません。

批評者そのものを評価するのはメンテナーの仕事であり、ここではなくキットのリポジトリにあるハーネスで行います。このスキルはあなたのプロジェクトにインストールされます。インストール先に存在しないファイル名を指示に含めてはいけません。

コメント

Markdown 対応