mcpField
A
audit

audit

github.com/educlopezテスト・品質407948 回インストール1 週間前に更新
リポジトリ

audit について

`ui-craft` のサブスキルで、UI のアクセシビリティ、パフォーマンス、レスポンシブ対応を監査します。まず画面を確認し、優先度付きの指摘と構造化された Craft Report を作成します。

主な機能

  1. 013 種類のビューポートで画面を撮影
  2. 02アクセシビリティ、性能、レスポンシブの検査
  3. 03レビュー表で指摘を優先度順に整理
  4. 04範囲と判定をまとめた Craft Report

活用シーン

  1. 01リリース前の UI レビュー
  2. 02アクセシビリティとレスポンシブの問題発見
  3. 03アニメーションと描画処理の評価

MCP 対応

スクリーンショット撮影には Playwright MCP を優先し、ほかのブラウザー自動化手段も代替として挙げています。

インストール

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

$npx skills add https://github.com/educlopez/ui-craft --skill audit

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

詳細

コンテキスト： このサブスキルは、より広範な ui-craft スキルを構成する視点のひとつです。ui-craft スキルもインストールされている場合は、まずその SKILL.md を読み、Discovery + Anti-Slop + Craft Test を確認してから、以下の個別の視点を適用してください。

$ARGUMENTS の UI を技術的に監査します。ui-craft スキルを読み込み、監査の視点を適用してください。

ステップ 0：画面のキャプチャ（必須）

コードだけのレビューでは不十分です。すべての監査／批評は、ユーザーに見える画面から始めます。以下を順番に試し、利用可能な最初の方法を使ってください。

  1. Playwright MCP — playwright MCP サーバーを利用できる場合は使用します。デスクトップ（1280×800）、タブレット（768×1024）、モバイル（375×812）の 3 つのビューポートで、ページ全体のスクリーンショットを撮影します。アプリが対応している場合は、ダークモードも撮影します。
  2. ブラウザの DevTools／Chrome MCP — 2 番目の選択肢です。同じビューポート一式を使用します。
  3. その他のブラウザー自動化ツール（agent-browser、cursor-ide-browser）— 3 番目の選択肢です。
  4. ユーザーに依頼する — 最後の手段です。自動化ツールを利用できない場合は、作業を進める前にユーザーにスクリーンショットを依頼します。具体的に依頼してください。
    • 「ビジュアルレビューにはスクリーンショットが必要です。次のものをご提供ください。
      • 1280px（デスクトップ）でのページ全体
      • 768px（タブレット）でのページ全体
      • 375px（モバイル）でのページ全体
      • 対応している場合は、それぞれのダークモード」

画面をキャプチャするか、提供してもらうまではレビューを始めないでください。自動化ツールが利用できなかった場合は、そのことをユーザーに明示してください。コードだけのレビューに黙って切り替えてはいけません。

ユーザーがスクリーンショットの提供を断った場合は、コードのみでレビューを行い、制約を明示するため、レポートの先頭に [CODE-ONLY REVIEW — visual issues not assessed] を付けてください。

注： 監査では調整項目に依存しません。アクセシビリティとパフォーマンスは調整できません。

対象範囲（必須チェック項目）：

  1. アクセシビリティ — references/accessibility.md を読んでください。
    • すべてのインタラクティブ要素で :focus-visible が見えること
    • キーボードで操作でき、フォーカストラップがないこと
    • タッチターゲットが 44px 以上であること（モバイル）
    • 状態を色だけで示していないこと
    • フォームのラベル、エラーとの関連付け、必須項目の表示
    • すべてのアニメーションで prefers-reduced-motion が尊重されていること
  2. パフォーマンス — references/motion.md の Rendering Performance セクションを読んでください。
    • アニメーションには transform／opacity のみを使用していること（width／top／height は使用しない）
    • transition: all がないこと
    • will-change の適用範囲を操作中に限定し、操作後に解除すること
    • 画像に width／height または aspect-ratio が指定されていること（CLS 対策）
    • スクロール／リサイズのハンドラーでレイアウトのスラッシングがないこと
  3. レスポンシブ — references/responsive.md を読んでください。
    • モバイルファーストのブレークポイントを使用し、固定幅のコンポーネントがないこと
    • 固定要素で env(safe-area-inset-*) を考慮していること
    • タッチ領域が重なっていないこと
    • 320px 幅で横スクロールが発生しないこと

出力形式 — SKILL.md の Review Format の表を使用してください。

BeforeAfterWhy

指摘事項を優先度別に分類してください。Critical（操作性／アクセシビリティを阻害）→ High-impact（すぐに気づく問題）→ Quick wins（仕上げ）。

依頼されない限り、コードを書き換えないでください。まず指摘事項を報告し、編集の承認を待ってください。

最後に Craft Report（references/review.md → Craft Report）を付け、上記の指摘事項の表を含めてください。Checked には対象範囲（アクセシビリティ／パフォーマンス／レスポンシブと、確認したビューポート）を記載します。Passed には確認して問題がなかった項目を記載します。承認前の Changed は空欄にします。Verdict には最優先事項を記載します。問題がない監査でも必ず作成してください。アクセシビリティ／パフォーマンス／レスポンシブに問題がなかったことも、監査結果です。

次のステップ： /harden — 指摘事項を実際の本番環境向けテストに反映します（第 1 段階）。

コメント

Markdown 対応