seenry-review

Seenry Review

コードの意図ではなく、実際にレンダリングされたものを評価してください。すべての指摘は目に見える具体的なもので、優先順位が付けられ、最小限の修正案を伴う必要があります。基準にはSeenry システムのルールを使用してください。グリッドと余白、コンポーネントごとのタイポグラフィ上限、同心円状の角丸、アクセントカラーを1色にすること、一貫したページシェル、そしてアンチスロップリストです。

自分で画面を構築した場合は、そのことを伝え、自己レビューとして評価してください。新しいエージェントコンテキストで行うほうが望ましいです。

好みではなく証拠

示せる事実を報告してください。測定値、スクリーンショット、不合格となったチェック、数値を伴うルールなどです。プロジェクトが意図的に選び、一貫して適用している密度、角丸、文体を、自分なら別のものにしたというだけでは指摘になりません。以下のトリガーは厳しく確認し、好みについては指摘を控えてください。徹底しているように見せかけるために水増しした長いレビューより、実際に調査したうえでの短いレビューのほうが優れています。「対応すべき指摘なし」も有効な結果です。

見つけた時点で重大（画面の重要度が低くても、他の指摘と平均化して評価を下げてはいけません）：

• アクセシブルな名前、視覚的に見えるフォーカス、またはキーボード操作の手段がないインタラクティブなコントロール
• 320px、200％ズーム時、またはキーボード表示中にコンテンツやコントロールが切れる、重なる、または操作できなくなる
• 実際にレンダリングされる背景上で、テキストやコントロールのコントラストが必要な比率を下回っている
• 色だけ、または動きだけで状態や意味を伝えている
• prefers-reduced-motion を無視する動き、または1日に100回以上行われる操作やキーボード操作によるアクションに対するアニメーション
• 確認、取り消し、または明確な区別のない破壊的アクション
• 完全な値を確認する手段がない切り詰められたコンテンツ、または復旧手段のないエラー
• 意味と合わない用途で使われているセマンティックカラー（安全なアクションに危険色を使用するなど）
• 最終版として公開された仮素材（画像の代わりのグラデーション、ダミーテキスト、偽の推薦文）

より安価な修正を優先してください。 有効な最も早い方法を提案してください。削除する（行間で十分なスペースが得られるなら余分な行を削除する、本来不要なアニメーションを削除する）、プラットフォームの機能を使う（ネイティブ要素、ネイティブのフォーカスリング）、プロジェクトのトークンやコンポーネントを再利用する、値を修正する、の順に検討し、その後で初めて新しいものを追加してください。

まとめてください。 根本原因が同じなら、すべての該当箇所を1つの指摘にまとめてください。指摘は最大15件までとし、トリガーに該当するものを先に報告してください。上限によって指摘を省略する場合は、件数を伝えてください。

モードを選択する

ユーザーの依頼	モード
「このページ、画面、またはサイトをレビュー／批評／監査して」	画面レビュー
「このブランチ／PR／コミット／変更内容をレビューして」	変更レビュー：ベースとの差分に対して git diff を実行し、変更された UI 画面を列挙して、変更前後をレンダリングし、該当箇所のみをレビューします
「このコンポーネントをストレステストして／壊してみて」	ストレステスト
「アクセシブルか／WCAG に準拠しているか」	画面レビュー。アクセシビリティの確認のみを行い、チェックリストを使用します
「アニメーションをレビュー／改善して」「どこをアニメーションさせるべきか」	モーションレビュー
「これはどう作られたのか／このインタラクションを説明して」	説明

画面レビュー

1. 表示する。 ページを幅 1440 と 390 で開きます（横方向のはみ出し確認には 320 も使用します）。それぞれスクリーンショットを撮影します。ポインターとキーボードで主要な操作を試します。
   • 動きの確認より先に、フロー全体をレビューします。 コンポーネントの目的、利用者がどのようにたどり着くか、意味のある各操作とその目に見える結果を説明します。見つけやすさ、適切な戻る／キャンセル／閉じる動作、フォーカスの復帰、関連する空／エラー／無効状態、操作の繰り返しや中断、スマートフォンでの表示を確認します。該当しない状態は理由を添えて該当なしとし、未テストの状態は未検証のままにします。
   • フローに適した方法で閉じられるようにします。 確認ダイアログでは、ネイティブのモーダル動作に従い、キャンセルと Escape を使用できます。ナビゲーションフローでは戻る操作を使用できます。すべてのダイアログに追加の閉じるボタンや X ボタンを必須にしないでください。元の位置に戻るコントロールは、直接展開するカードやトグルフローにおける空間的な基準であり、すべてのダイアログに共通する要件ではありません。既存のコントロールには、わかりやすい名前、操作しやすいターゲット、視認できるフォーカス、正しい動作が必要です。
2. 測定する。 node ../seenry/scripts/audit_page.mjs <url or file> --widths 1440,390,320 --shots <dir>（ページ監査）を実行します。このコマンドはシステム監査と光学監査を組み合わせたもので、あらゆるプロジェクトで動作します。フォントサイズ、ウェイト、ファミリー、角丸、シャドウ、グリッドからのずれ、入れ子になった角丸の違反、上限を超えたコンポーネント、横方向のはみ出しの合計を記録します。また、コンポーネントごとに、配置の基準線、わずかに揃っていないエッジ、光学的なインセットも記録します（配置）。グリッドオーバーレイを切り替えて、エッジが揃っているか確認します。
3. 次の順序で確認します。 前の項目に問題があると、後の項目を確認しても意味がないためです。
   • 目的と階層。 5 秒以内に、何のページか、対象者は誰か、次に何をすべきかがわかりますか。主要な操作は最も目立つコントロールになっていますか。
   • 素材と基準線。 実際の画像、アイコン、データを使っていますか。それともプレースホルダーですか。すべての要素が別の要素のエッジまたは中心線に揃っていますか。それとも浮いている要素がありますか。支配的な要素と詳細レイヤーはそれぞれ 1 つありますか。探索にあるスタジオ形式の批評を活用します。
   • レイアウト。 コンテンツのエッジは揃っていますか。セクションのリズム、グループ化（2x ルール）、読み進める順序、スマートフォンでのレイアウト変更は適切ですか。
   • タイポグラフィ。 コンポーネントとページごとのフォントファミリーの数、サイズ、ウェイト、見出しのウェイトと字間、行の長さ、折り返しを確認します。
   • 色と表面。 アクセントカラーの占める面積と役割、コントラスト、エレベーションの選択、角丸のファミリーと同心性を確認します。
   • コンポーネントと状態。 ホバー、フォーカス、アクティブ、無効、読み込み中、空、エラー、はみ出しを確認します。
   • コンテンツ。 コピーは具体的ですか、それとも一般的ですか。データは現実的ですか。主張には裏付けがありますか。
   • アクセシビリティ。 キーボード操作の経路、フォーカスの視認性、名前、コントラスト、ターゲット、ズーム、動きを減らす設定を確認します。
4. 必要に応じて、リファレンスと比較します。Seenry MCP を使い、同じ種類のページを優れたサイトから 2〜3 件取得し（page_type を指定して search_references を使用するか、list_sites と get_design を使用します）、異なっている具体的な関係性を示します。ベンチマークを参照してください。

レポート形式

重大度順に並べた1つの表に、根本原因ごとに1行を設け、すべての該当箇所を記載します。

Sev	Where	Now	Change to	Why
High	Hero.tsx:14	h1 72px / 800 / トラッキング 0 / 1.2	56px / 500 / −0.03em / 1.05	デフォルトの太いディスプレイ表示はテンプレートのように見えます。ベンチマークを参照してください
High	pricing, 390px	ティアがはみ出し、横スクロールが発生	ティアを縦に並べ、CTAを全幅にする	対応する幅でコンテンツが隠れます
Med	Card.tsx:8	角丸 16、内側余白 12、画像の角丸 16	画像の角丸 4	角の同心性がありません

• High：タスクを妨げる、対応サイズでコンテンツや操作を隠す、コントラストまたはキーボード操作の要件を満たさない、あるいは見ただけで生成物のように感じられる問題です。
• Med：階層、整合性、明瞭さを損なう問題です。
• Low：仕上げの問題です。

続けて、両方の幅におけるシステム監査の合計、検証した内容、検証していない内容（モーション、スクリーンリーダー、デバイス）を記載し、最後に1行で判定します。判定は Ship、Fix then ship（Medのみ）、または Block（Highが1つでもある場合）です。依頼されていないページの書き換えは行わず、修正の適用を提案してください。

変更レビュー

確認するのは「この変更でインターフェースが悪化したか？」であり、「このコードベースのどこに問題があるか？」ではありません。

1. 対象範囲を特定します。 PR、ブランチ、またはコミット範囲が指定されている場合は、それを使用します。指定がない場合は、デフォルトブランチとのマージベース以降のコミットと未コミットの変更を対象にします。それらがなければ未コミットの変更のみを対象にします。それもなければ、レビュー対象を確認するために質問して作業を止めます。
2. 変更ファイルを対象画面に展開します。 トークン、共有コンポーネント、スタイルシートの変更は、それを使用するすべての画面に影響します。それらの画面を列挙してください。影響を受ける状態を、変更前（worktree または git stash）と変更後の両方で2つの幅に描画し、どちらにもページ監査を実行してください。
3. 削除された行を確認します。 フォーカススタイル、aria-* 属性、alt テキスト、視差効果を抑制するブロック、min-width: 0、ラベル、エラー処理を削除する変更は、追加コードに問題がなくてもリグレッションです。
4. 変更内容を、明記された意図に照らして評価します（PRの説明、コミットメッセージ）。展開が途中までしか完了していない場合は、指摘事項として扱います。
5. すべての指摘を分類します。 Introduced（新たな問題）、Regression（以前は機能していたものが機能しなくなった問題。見ただけで高いリスクを示す要因に関するリグレッションはHigh）、Pre-existing（最大3件まで報告し、判定には含めず、独立したセクションに記載）に分類します。
6. トークンを迂回するハードコード値は、ファイル名と行番号を添えて指摘します。正確性、セキュリティ、パフォーマンスの確認は通常のコードレビューに委ねます。

モーションレビュー

対象範囲内のすべてのトランジション、アニメーション、ジェスチャーを一覧にします。それぞれについて、頻度のティア、目的、ツール、プロパティ、時間、イージングまたはスプリング、中断時の挙動、モーション低減設定とホバーによる制御を記載し、seenry-motion のビルド順序と Never ship テーブルに照らして評価します。DevTools の Animations パネルで、通常速度と10%の速度の両方で確認してください。さらに、見逃された機会（連続性が必要な唐突な切り替わり、フィードバックのない押下など）と、採用しなかった候補（即時のままにすべきものと、その理由）も列挙します。表形式で報告してください。

ストレステスト

スクラッチページでコンポーネント単体を描画し、現実的なバリエーションをすべて同時に画面に表示します。

• コンテンツ：空、1文字、標準的な長さ、2倍の長さ、5倍の長さ、改行されない文字列（URL、メールアドレス）、絵文字とCJK、サポートされている場合はRTL、画像なし、件数 0 / 1 / 99+ / 1,000,000、負の数。
• 状態：デフォルト、ホバー、フォーカス可視、アクティブ、無効、読み込み中、エラー、成功、選択済み、展開済み。
• コンテナ：幅 240、320、390、768、1200。ズーム 200%。文字間隔の拡大。
• 入力：マウス、キーボードのみ、タッチエミュレーション、短時間の連続クリック、トランジション途中での反転。

バリエーションのグリッドをスクリーンショットに撮り、システム監査と text collisions を実行し、失敗を表形式で報告します。保持するよう依頼されていない限り、終了後にスクラッチページを削除してください。

説明

観察した内容、どのように構築されていると考えられるか、そしてそのタスクで機能する理由の順に説明します。観察した内容と推測した内容を分けてください。実際のサイトでは、DOM と計算済みスタイルを確認します。動きについては、通常の速度でフレームを記録するか、コマ送りで確認してください（スクリーンショットだけではタイミングは証明できません）。Seenry MCP では、get_page_motion と get_design を使うと、記録と計測済みスタイルを取得できます。最後に、ブランドアセットをコピーせずに、その仕組みをユーザーの製品に応用する方法を説明します。