mcpField
F
frontend-checklist-global

frontend-checklist-global

github.com/thedaviddiasテスト・品質74.6k192 回インストール3 週間前に更新
リポジトリ

frontend-checklist-global について

frontend-checklist-global は、MCP によるルール検索をコード片や公開ページの監査に結び付けるレビュー用スキルです。根拠に基づく指摘を重視し、ルールや修正方法も取得できます。

主な機能

  1. 01MCP でフロントエンド規則を検索
  2. 02コード片や公開ページをレビュー
  3. 03カテゴリやワークフローで対象を絞る
  4. 04規則の詳細と修正案を取得
  5. 05根拠を重視して指摘を報告

活用シーン

  1. 01コンポーネントのアクセシビリティ確認
  2. 02公開ページのレンダリング HTML 監査
  3. 03カテゴリ別のフロントエンド実装確認

MCP 対応

このスキルは MCP ツールで規則を検索し、レビューを支援します。コードレビュー、ページ監査、規則検索・詳細取得、修正関連のツールを利用します。

インストール

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

$npx skills add https://github.com/thedaviddias/front-end-checklist --skill frontend-checklist-global

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

同梱ファイルreferences/categories.md

詳細

フロントエンドチェックリストの総合監査

このスキルは、フロントエンドチェックリストの全386ルールへのエントリーポイントを1つにまとめます。 ルールを記憶から思い出そうとするのではなく、MCP による検索を利用してください。

ワークフロー

  1. 貼り付けられたコード、ファイルの内容、または対象を絞ったコードレビューには、まず review_code を使用します。
  2. 公開ページのレンダリング済み HTML をすばやく監査する場合は、audit_url を使用します。
  3. search_rules、list_categories、get_workflow、get_quick_reference を使用して、対象範囲を絞るか広げます。
  4. 各問題について、get_rule、fix_rule、または explain_rule を使用して、具体的な修正方法を提示します。
  5. 場当たり的な検索よりチェックリストが適している場合は、get_checklist_rules を使用します。

監査の方針

  • 慎重に判断してください。推測に基づく幅広い指摘より、数を絞った確度の高い指摘を優先してください。
  • 表示されたコードやマークアップから直接裏付けられる場合に限り、問題を報告してください。
  • 小規模なコンポーネントやルートの監査では、考えられる改善点をすべて列挙するより、裏付けのある最も重要な1〜2件の指摘を優先してください。
  • スニペットだけからビジネス上の意図を推測しないでください。例:コードや周辺の文言で明示されていない限り、フィールドが必須だと決めつけないでください。
  • alt="" をデフォルトで問題として扱わないでください。装飾画像には空の alt が適切な場合があります。
  • 画像が装飾目的であることが明確な場合、仮説上の最適化ではなく具体的な問題がスニペットに示されていない限り、指摘なしとすることを優先してください。
  • <img ... alt="" aria-hidden="true"> のような装飾画像が単独で示されている場合、スニペットにレイアウトの不安定さを示す実際の根拠がない限り、問題なしのパターンとして扱ってください。
  • スニペットに問題がない場合、確信度の低い好みに基づく微調整を指摘として挙げないでください。弱い粗探しをするより、指摘しないことを優先してください。
  • より重大なユーザーへの悪影響やセキュリティ上の理由がスニペットに示されていない限り、autocomplete="off" 単体を欠陥として扱わないでください。
  • リンクプレビューカードでは、近くに表示されるテキストでリンク先がすでに示されていれば、装飾用のプレビュー画像やファビコンは問題ない場合があります。
  • スニペットに <html>、<head>、<body> などの実際のドキュメントコンテキストが含まれていない限り、React や JSX のフラグメントを完全な HTML ドキュメントとして扱わないでください。
  • Next.js やメタデータ駆動のページファイルをレビューする際は、head タグの欠落を指摘する前に、metadata、viewport、generateMetadata API を考慮してください。

カバレッジチェックリスト

  • フォーム:ラベル、アクセシブルなボタン名、明示的なボタンタイプ、autocomplete ヒント、パスワードフィールドの autocomplete、コードで明示されている検証のセマンティクスを確認してください。
  • 画像:width/height、loading、srcset/sizes、画像の意味が明確に伝わるか、または装飾目的かを確認してください。小さな SVG ロゴや装飾目的が明らかなアセットを遅延読み込みすべきだと決めつけないでください。また、実際のレイアウトシフトのリスクがスニペットに示されていない限り、小さな装飾用区切り線に明示的な寸法を求めないでください。画像が装飾目的であり、支援技術からも隠されている場合は、指摘しないことを強く優先してください。
  • メタデータ:ファイルがメタデータを担当する場合に限り、title の配置、canonical URL の動作、meta description、Open Graph の網羅性、構造化データを確認してください。
  • モーション:負荷の高いアニメーションプロパティを確認し、transform/opacity を優先してください。継続的なモーションには prefers-reduced-motion への対応を必須としてください。
  • モーション:カウンターや視覚的なウィジェットが毎フレームアニメーションする場合、視差効果の低減への対応に加えて、アニメーションの方式がメインスレッドに不要な負荷を加えていないかを評価してください。
  • セキュリティ:target="_blank" のリンクに noopener noreferrer があるか、安全でないフォームの送信先、パスワード入力のベストプラクティス、サードパーティスクリプトによるブロッキングを確認してください。
  • 構造:重複する id、リストのセマンティクス、表のヘッダーを慎重に確認してください。単純な表では、推測に基づく行ヘッダーや外側のレイアウトランドマークの問題より、列ヘッダーとの関連付けの欠落を確度の高い指摘として優先してください。
  • 構造:表示されている見出しがすでに単純な表を紹介している場合、キャプションの欠落は、ヘッダーとの関連付けの欠落より確度の低い改善点として扱ってください。

ルールに基づく主なポイント

画像には明示的に幅と高さを設定する
  • 意味のあるコンテンツ画像の問題を優先して指摘します。CSSですでに安定した領域が確保されている場合、装飾用の小さなSVGや装飾のみのアセットは優先度の低い例外とします
  • リスクが低い例外の例:<img src="/divider.svg" alt="" aria-hidden="true"> は、目に見えるレイアウトシフトの証拠がない限り、これだけを理由に指摘しないでください
  • <img> には、画像の本来の寸法に合わせた width 属性と height 属性を必ず設定します
  • アスペクト比を維持しながら画像を伸縮できるよう、CSSで height: auto を併用します
  • 寸法の指定漏れは、画像による累積レイアウトシフト(CLS)の主な原因です
装飾要素を支援技術から隠す
  • 装飾画像には alt=''(空)を使用します。alt='image' にしたり、altを省略したりしないでください
  • 装飾用のSVGやアイコンには aria-hidden='true' を追加します
  • 装飾のみのビジュアルにはCSSの background-image を使用します
  • Role='presentation' を指定すると、要素の意味的な役割が取り除かれます
  • スニペットから実際のレイアウト不安定性が確認できない限り、装飾用の小さなアセットについてパフォーマンス上の問題を自動的に指摘しないでください
アニメーションにはtransformとopacityを使用する
  • レイアウトを発生させずにGPUで合成できるのは、transformとopacityだけです
  • 要素を独立したコンポジターレイヤーに昇格させる will-change: transform は、必要な場合に限って使用します
  • 単純な効果には、JavaScriptのアニメーションライブラリよりもCSSトランジションやアニメーションを優先します
  • アニメーションを必要としないユーザー向けに、prefers-reduced-motion を尊重してアニメーションを無効にします
モーションの軽減設定を尊重する
  • prefers-reduced-motion メディアクエリを使用し、必須でないアニメーションを無効にします
  • コンテンツを1秒間に3回を超えて点滅させないでください(発作のリスクがあります)
  • モーション軽減が有効な場合は、モーションをopacityや色のトランジションに置き換えます
  • アニメーションを一時停止または無効にするためのユーザーコントロールを用意します
スクリーンリーダー向けにセマンティックなテーブルマークアップを使用する
  • 見出しには <th> 要素を使用し、scope='col' または scope='row' を指定します
  • テーブルの目的を説明する <caption> を追加します
  • レイアウト目的でテーブルを使用せず、代わりにCSS GridまたはFlexboxを使用します
  • セル結合を含む複雑なテーブルでは、id と headers を使用します
  • 隣接するセクション見出しが明確な単純なテーブルでは、<caption> の欠落よりも scope の欠落を優先して指摘すべき場合が多くあります
テーブルの見出しを適切に定義する
  • すべてのテーブル見出しに <td> ではなく <th> を使用します
  • 見出しとの関係を明確にするため、scope="col" または scope="row" を指定します
  • すべてのデータセルが少なくとも1つの見出しに関連付けられていることを確認します
  • 単純なテーブルでは、キャプションに関する推奨事項を追加する前に、見出しの関連付けの修正を優先します
  • わかりやすい見出し行で scope="col" が欠落している場合は、これを最初に修正するのが最も明確な対応となることが多くあります
コストの高いDOMの読み取り・書き込み操作を最小限にする
  • DOMの読み取り(offsetHeight、getBoundingClientRect)とDOMの書き込み(スタイルの変更)を交互に行わないでください
  • すべての読み取りを先にまとめて行い、その後にすべての書き込みを行います
  • 視覚的な更新には requestAnimationFrame を使用します
  • DOMへの要素の一括挿入には DocumentFragment または innerHTML を使用します
  • よりシンプルなCSSや更新頻度を下げる方法で対応できる場合は、多数の表示コンポーネントに対して毎フレームReactの状態を更新しないでください
アクセシビリティに配慮してフォームを検証する
  • aria-describedby を使用して、エラーメッセージをフィールドに関連付けます
  • aria-invalid を使用して、検証状態を示します
  • required または aria-required を使用して、必須フィールドをプログラムで指定します
  • フィールドの近くにインラインのエラーメッセージを表示します
  • エラーの表示を色だけに頼らないでください
パスワード入力フィールドを安全にする
  • 正しいautocomplete属性とともに type='password' を使用します
  • パスワードの表示・非表示を切り替える、アクセシブルなコントロールを用意します
  • 要件を示すパスワード強度インジケーターを表示します
  • パスワードを平文で保存または送信しないでください
  • 適切な入力フィールド名を使って、パスワードマネージャーに対応します
視認できるカスタムフォーカスインジケーターを用意する
  • 視認可能な :focus-visible による代替を用意せずに、outline: none または outline: 0 を使用しないでください
  • キーボード操作中のみインジケーターを表示するには、:focus ではなく :focus-visible を使用してください
  • フォーカスインジケーターは、隣接する色に対して 3:1 のコントラスト比を確保する必要があります(WCAG 2.2)
  • 高品質なフォーカスリングにするため、オフセット付きの 2px 以上の実線アウトラインを用意してください
  • フォーカスリングを疑似要素で描画する場合は、正しい位置指定要素を基準に配置され、overflow: hidden で切り取られていないことを確認してください

既知の安全なパターン

装飾用区切り線
  • 安全な例:<img src="/divider.svg" alt="" aria-hidden="true">
  • これはデフォルトで安全な装飾パターンとして扱ってください。コード断片に実際のレイアウトシフトのリスクも示されていない限り、alt テキストや寸法の不足を指摘しないでください。
クライアント側で処理する React フォーム
  • 安全な例:<form onSubmit={event => event.preventDefault()}><label htmlFor="q">Search</label><input id="q" type="search" /></form>
  • クライアント側での送信処理が明示され、フォームコントロールにもほかにアクセシビリティ上の問題がない場合は、method や action を必須としないでください。
Next Metadata API
  • 安全な例:export async function generateMetadata() { return { title: 'Docs', description: 'Reference' } }
  • コンポーネントファイルに文字どおりの <head> マークアップがないというだけで、canonical-url、meta description、Open Graph タグの不足を推測しないでください。
プレビューカードの画像
  • 安全な例:<img src={resource.image} alt="" className="object-cover" /><img src={favicon} alt="" width={20} height={20} />
  • リンクプレビューやリソースカードの UI では、隣接するテキストですでにリンク先の名前が示されている場合、装飾用のプレビュー画像やファビコンに空の alt を使用しても問題ありません。より確かな根拠がない限り、小さなファビコン画像にレスポンシブ画像やレイアウトシフトの問題を指摘しないでください。
アスペクト比を指定したメディアラッパー
  • 安全な例:<div className="aspect-2/1 overflow-hidden"><img className="object-cover w-full h-full" ... /></div>
  • ラッパーが安定したアスペクト比でメディア領域をすでに確保している場合、子のプレビュー画像に寸法がないことを理由に、自動的に指摘しないでください。
疑似要素によるフォーカスリング
  • 安全な例:focus-visible:outline-none focus-visible:after:ring-2 after:absolute after:inset-0
  • フォーカススタイルが疑似要素に依存している場合は、正しい位置指定要素を基準にリングが配置されていることを確認してください。代替リングが確実に機能することが明らかな場合に限り、ネイティブのアウトラインを削除しても安全です。
フレームごとに更新する React カウンターアニメーション
  • 安全な例:requestAnimationFrame(animate); setCount(Math.floor(eased * target))
  • 複数のコンポーネントで requestAnimationFrame による状態更新を繰り返すことがコードに直接示されている場合、具体的なパフォーマンス上の懸念となります。
シンプルなデータテーブルのヘッダー
  • 安全な例:<thead><tr><th>Priority</th><th>Rule</th><th>Title</th></tr></thead>
  • シンプルなデータテーブルでは、行ヘッダーや外側のレイアウトランドマークについて推測するより、まず列ヘッダーに関する指摘を慎重に行ってください。
近接する見出しとテーブル
  • 安全な例:<h2>Issues</h2><table><thead>...</thead><tbody>...</tbody></table>
  • 近くに見えるセクション見出しが、すでにテーブルの文脈を示している場合があります。テーブルの目的が曖昧でない限り、キャプションを必須とする前に、scope やヘッダーとの関連付けに関する指摘を優先してください。

競合の解決

  • 装飾画像に関する指針と寸法に関する指針が競合する場合、コード断片に目に見えるレイアウトの不安定さが示されていない限り、装飾画像に関する指針を優先してください。
  • ゼロ件となる例:独立したコンポーネント内の <img src="/divider.svg" alt="" aria-hidden="true"> は、コード断片に実際のレイアウトシフトの根拠も示されていない限り、alt テキストや寸法について指摘しないでください。
  • フォームが onSubmit で明確にクライアント側処理される場合、従来のサーバー送信用 method や action 属性を必須としないでください。
  • ファイルが Next.js の metadata API を使用している場合、文字どおりの <meta> や canonical-url のマークアップがないことから、head タグの不足を推測しないでください。

対象範囲

  • アクセシビリティ:89 ルール(重大 9、高 25)
  • CSS:31 ルール(高 10)
  • HTML:34 ルール(重大 3、高 12)
  • i18n:5 ルール
  • 画像:25 ルール(重大 1、高 15)
  • JavaScript:26 ルール(重大 1、高 12)
  • パフォーマンス:43 ルール(重大 1、高 22)
  • プライバシー:5 ルール(高 2)
  • セキュリティ:22 ルール(重大 4、高 10)
  • SEO:93 ルール(高 19)
  • テスト:13 ルール(高 7)

評価基準

  • 正確なファイル、ルート、セレクター、またはコードスニペットに紐づく指摘を優先してください。
  • 重大度が重大または高の問題を優先してください。
  • スニペットだけでは十分な文脈がわからない場合は、断定せず不確実性を説明してください。
  • MCP ツールでルールや修正プロンプトを取得できる場合は、一般的なアドバイスを避けてください。
  • 自動的に問題が見つからなかった場合は、問題がないと結論づける前に search_rules を使ってレビュー範囲を広げてください。

カテゴリの対象範囲とツールの振り分けについては、references/categories.md を参照してください。

MCP ドキュメント:https://frontendchecklist.io/mcp

コメント