mcpField
R
review

review

github.com/paragonhqデザイン・UI043 回インストール5 週間前に更新
リポジトリ

review について

review は、開発者やデザイナー向けの構造化されたインターフェースレビュー用スキルです。調査した証拠を、場所と具体的な修正案を伴う優先度付きの指摘と判定にまとめ、主観的な採点は行いません。

主な機能

  1. 01対象範囲と技術スタックの確認
  2. 02根拠と場所を示す指摘
  3. 03影響度に基づく重大度の順位付け
  4. 04プロジェクトの規約に沿った修正案
  5. 05阻害要因を示す判定

活用シーン

  1. 01画面やコンポーネントのレビュー
  2. 02フローやコード差分の評価
  3. 03UIとアクセシビリティ修正の優先順位付け

インストール

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

$npx skills add https://github.com/paragonhq/stealth-skills --skill review

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

詳細

レビュー

レビューとは、変更すべき項目を、箇所、修正内容、理由とともに列挙したものです。それ以外は意見です。このスキルでは、そのリストを作成します。

姿勢

  • 好みではなく、証拠を示します。指摘には path/file.tsx:42 のように箇所を記載し、現在の状態を示します。箇所を示せないなら、指摘ではありません。
  • プロジェクトの流儀に沿って修正します。Tailwind を使っているなら、修正はクラスです。トークンがあるなら、修正ではそのトークンを指定します。異なる技術スタックの採用を求めるのは、指摘ではありません。
  • 本当に確認したうえでの短いリストは、網羅的に見せるためだけに水増しした長いリストより優れています。指摘は最大15件です。それ以上ある場合は、影響の大きい上位15件を挙げ、残りがあることを一文で伝えます。
  • 意図的な選択は指摘ではありません。密度、角丸、語調、配色は、コントラスト、フォーカス、ヒット領域、状態の欠落といった厳格なルールに違反しない限り、開発者が決めることです。
  • 「検討してください」とは言いません。何を変更すべきかを明確に伝えます。

1. 範囲

レビューを始める前に、何をレビューするのかを明示します。画面、フロー、コンポーネント、差分などです。依頼でブランチやPRが指定されている場合は、変更されたファイルと、それらが影響する画面が対象です。画面が指定されている場合は、その画面のすべての状態を375pxと1440pxで確認します。

範囲が広すぎて信頼できる確認ができない場合は、1つの完全なフローに絞り、対象のフローと除外した項目を伝えます。確認していない画面もレビューしたかのように伝えてはいけません。

2. 事前調査

判断を下す前に、2分間で以下を確認します。

  • フレームワーク、スタイリングシステム、コンポーネントライブラリ、モーションライブラリ、アイコンセット。
  • トークン:色、間隔、イージング、角丸、z-indexの定義場所。指摘ではこれらの名称を指定します。
  • 文書化された規約:CLAUDE.md、AGENTS.md、CONTRIBUTING.md、デザインドキュメント。文書化された規約に反する問題は、個別の箇所ごとではなく、規約に対して一度だけ報告します。
  • 実行方法。インタラクティブな動作のレビューには、インターフェースの起動が必要です。ソースのみを確認する場合は、その旨を伝えます。

3. 次の順序で確認する

根本的な問題は、見た目の仕上げに隠れていることがあります。重要な指摘が表面的な指摘に埋もれないよう、基礎から順に確認します。

順序領域確認項目
1機能画面上の主要な操作は明確か。完了できるか。妨げになるものはないか。
2アクセシビリティキーボードで操作できるか、フォーカスが見えて管理されているか、コントロールに名前が付いているか、コントラストは十分か、div onClick がないか、色だけで状態を伝えていないか、動きを減らす設定に対応しているか
3状態読み込み、空、エラー、一部表示、処理中、無効、成功の各状態。データ到着時のレイアウトシフト。スピナーの表示タイミング
4文言ボタンの動詞、文頭以外の大文字化を避ける表記、次の手順を示すエラー、操作方法を示す空状態、残ったプレースホルダーテキスト
5余白スケールから外れた値、不均一なリズム、コンポーネントのマージン、配置、375pxでのガター、横スクロール
6文字サイズの種類が多すぎないか、サイズだけで階層を表現していないか、サイズごとの行間と字間、等幅数字、重要なテキストの切り詰め、行末に残る短い語
7表面トークン外の16進カラー値、テーマごとの境界線と影、アクセントの使いすぎ、両方のテーマの確認、選択表示とスクロールバー
8インタラクションホバー効果に適切な条件が設定されているか、アクティブ状態があるか、無効状態と処理中状態が区別されているか、処理中に幅が変わらないか、コピー時のフィードバック、Escapeキーの処理とフォーカスの復帰
9モーションtransition: all、表示時のease-in、製品UIで300msを超える時間、キーボード操作に伴うアニメーション、scale(0)、終了アニメーションの欠落、動きを減らす設定への対応
10仕上げタイトル、ファビコン、OG、外部リンクのマーカー、画像の寸法、固定ヘッダーに隠れるアンカー、404

各領域には詳細なルールをまとめた専用スキル(a11y、states、ux-copy、space、type、surface、interaction、motion、polish)があります。対象の範囲に必要なものを読み込み、記憶だけを頼りにルールを再構成しないでください。

4. 重要度

レベル意味例
ブロッカータスクを完了できない人がいるキーボードトラップ、操作できないコントロール、主要なアクションのコントラスト比が3:1未満、エラー時に送信しても何も起きない
高頻繁に失敗したり、混乱したりする人がいるエラー状態がない、読み込み時にレイアウトがずれる、ホバー時にしか操作できることがわからない、ボタンのラベルが曖昧
中壊れている、または安っぽく感じられ、多くの人が気づく押下状態がない、transition: all、スピナーが一瞬表示される、タイトルが孤立している、全体的に間隔のスケールが合っていない
低熟練者なら気づくアイコンが1px低い、ラベルの字間、ダークモードでのシャドウ

レベルの高い順に並べ、次に、該当する人の多さと頻度で順位を付けます。主要なボタンにある低レベルの問題は、誰も訪れない設定ページにある中レベルの問題より優先されます。

5. 出力

表を1つだけ出力します。その前にはスコープ行と調査行以外は何も書きません。その後には判定と、該当する場合は除外リスト以外は何も書きません。

Scope: /settings/profile at 375px and 1440px, both themes, running locally.
Stack: Next.js, Tailwind v4 with tokens in globals.css, Base UI, Motion. Conventions: CLAUDE.md.

| # | Level | Where | Now | Change to | Why |
| --- | --- | --- | --- | --- | --- |
| 1 | Blocking | `ProfileForm.tsx:88` | `<div onClick={save}>` | `<button type="submit">` | not keyboard reachable; Enter does not submit |
| 2 | High | `ProfileForm.tsx:41` | error shown only as red border | message under field, `aria-describedby`, focus first invalid | user cannot tell what is wrong |
| 3 | Medium | `Avatar.tsx:12` | `transition: all 0.3s` | `transition: transform 120ms var(--ease-out-expo)` | `all` transitions layout properties; 300ms is slow for hover |
| … |

Verdict: Not ready. Fix 1–2, then 3–7 in this change; 8–12 can follow.
Excluded: the billing tab (separate flow), the mobile nav (not in scope).

表のルール:

  • Where はファイル名と行番号、またはソースなしで実行中のページをレビューする場合はセレクターです。
  • Now は文字どおり現状にあるもの、つまり値、マークアップ、観察した挙動です。
  • Change to はプロジェクトの慣習に沿った具体的な置き換えです。「改善する」や「検討する」ではありません。
  • Why は1つの節で、ルール名ではなくユーザーへの影響を記します。
  • 4項目すべてが揃っていない行は認められません。好みに関する行も認められません。

判定は次のいずれかです:Ready、Ready after blocking fixes、Not ready。どの指摘が判定の条件となるかを明記してください。

6. やってはいけないこと

  • レビューの中でコンポーネントを書き直さないでください。レビューは指摘の一覧であり、修正は依頼された場合に別途行います。
  • 同じ問題を発生箇所ごとに列挙しないでください。「14個のファイルにあるtransition: all」は、件数と使用すべきトークンを含めて1行にまとめます。
  • スコープ上必要のなかったものがないことを指摘しないでください(印刷用スタイルシートに「ダークモードがない」など)。
  • 採点しないでください。スコアはありません。指摘一覧と判定を示します。
  • ほかがよくできているからといって、ブロッカーの指摘を和らげないでください。

返す前のセルフチェック

  • スコープとスタックを記載した
  • 各行に実際に確認した場所がある
  • 見つけた順ではなく、影響度順に並べた
  • 15件以下である
  • すべての修正案がプロジェクトの慣習に沿っている
  • 判定に条件となる行を明記した
  • 表に好みに関する内容がない

カタログより

コメント