audit

audit skill の概要

audit skill でできること

audit skill は、ページ・機能・コンポーネントに対して、構造化された技術的な UX Audit を実行します。アクセシビリティ、パフォーマンス、テーマ適用、レスポンシブ挙動、フロントエンドのアンチパターンといった観点から実装品質を確認し、P0 から P3 の重大度とアクションプラン付きのスコアレポートを返します。

audit skill を使うべき人

この audit skill は、フロントエンドチーム、デザインエンジニア、リリース済み UI をレビューするプロダクトデザイナー、そして「この UI をざっくり批評して」ではなく、再現性のある技術レビューを必要とする AI ユーザーに最適です。特に、実装上の具体的な欠陥やリスクを洗い出したい UX Audit に向いています。

audit skill が最も向いている用途

次のような問いに答えたいときは audit を使うのが適しています。

• 「このページの技術的な問題点は何か？」
• 「今すぐ優先して直すべき重大な問題はどれか？」
• 「このコンポーネントは実際にアクセシブルでレスポンシブに機能しているか？」
• 「修正に入る前に、どんな実装アンチパターンがあるか？」

これはリデザイン用ツールではありません。問題点を記録・整理し、その後に別のコマンドや人間が修正できるようにする診断用 skill です。

この audit skill の違い

最大の違いは、レビューの構造化にあります。audit は、順位のない所感リストを返すのではなく、次のことを前提に設計されています。

• 複数の品質観点を一度に確認する
• 各観点を一貫した基準でスコア化する
• 技術的欠陥と主観的なデザインの好みを切り分ける
• コメントの羅列ではなく、優先順位付きの指摘を返す

インストール前に知っておくべき重要な制約

このリポジトリでは、audit は /frontend-design と組み合わせて使うことが明示されています。さらに、まだデザインコンテキストが存在しない場合は、先に /teach-impeccable を実行する必要があります。これは重要です。audit は、スクリーンショットや断片的なコードだけからプロダクト意図を推測するのではなく、事前に集めた文脈を前提に監査を行うためです。

audit skill の使い方

導入コンテキストと呼び出し方法

このリポジトリの SKILL.md には、専用の audit install コマンドは記載されていません。そのため、導入方法は利用する skill runner に依存します。skills 対応環境では、audit skill を名前で呼び出し、ページ・機能・コンポーネントなどの対象領域を渡して使います。定義されている引数ヒントは次のとおりです。

[area (feature, page, component...)]

実際の呼び出し例:

• audit checkout page
• audit pricing table component
• audit onboarding flow

必須の前提ステップを先に実行する

この audit skill を使う前に、リポジトリで必須とされている準備を行ってください。

1. /frontend-design を実行する
2. そのコンテキスト収集プロトコルに従う
3. まだデザインコンテキストがない場合は、先に /teach-impeccable を実行する

これは単なる補足ではありません。ここを省くと、audit がプロダクト意図を誤読したり、アンチパターンの分類を誤ったり、文脈不足のまま価値の低い指摘を返したりする可能性があります。

audit skill に必要な入力

audit は、曖昧な対象名だけを渡すよりも、具体的な材料が揃っているほど精度が上がります。良い入力には、通常次のような情報が含まれます。

• 正確な監査対象の画面・機能
• リンク、スクリーンショット、コードパス
• 想定ユーザーフロー
• 対象デバイスやブレークポイント
• 既知の問題箇所
• デザインシステムのルールやパフォーマンス予算などの制約

弱い入力例:

• “Audit my app”

より強い入力例:

• “Audit the mobile checkout page in the signed-in flow. Focus on accessibility, responsive issues, and performance regressions affecting form completion. Primary files are app/checkout/page.tsx and components/PaymentForm.tsx.”

粗い依頼を良い audit プロンプトに変える

audit usage をより実用的にするには、1つの依頼の中にスコープ、根拠、期待する出力形式をまとめて入れるのが効果的です。強いプロンプトの型は次のとおりです。

• target: page, feature, or component
• context: who uses it and on what devices
• evidence: URL, screenshots, or code files
• focus: dimensions you care about most
• output: ask for scores, severity, and action plan

例:
“Run the audit skill on the account settings page. Review accessibility, keyboard navigation, semantic structure, responsive behavior, and theming consistency. Use the attached screenshots and inspect SettingsPanel.tsx. Return a scored report by dimension, list issues with P0-P3 severity, and end with the top fixes to schedule first.”

audit skill が実際に評価する内容

リポジトリ上の定義では、この audit は次の5つの技術観点をカバーします。

• accessibility
• performance
• theming
• responsive design
• front-end anti-patterns

そのため、コード品質とユーザー体験の両方にまたがる問題を、検証可能な形で洗い出したい技術的な UX Audit に向いています。

期待できる出力

有用な audit 実行結果には、通常次の内容が含まれます。

• 観点ごとのスコア（一般的には 0-4）
• 観測可能な実装上の問題に紐づいた具体的な指摘
• P0 から P3 の重大度評価
• 次に進むための実行可能なアクションプラン

この構造が有効なのは、すべての指摘を同じ重さで扱うのではなく、「何から直すべきか」をチームで判断しやすくなるためです。

初めて使う人におすすめの audit workflow

最もスムーズな流れは次のとおりです。

1. /frontend-design でデザインとプロダクトのコンテキストを準備する
2. 監査対象を1つに絞る
3. コードパスやスクリーンショットを渡す
4. audit を実行する
5. スコア付きレポートを確認する
6. 上位の P0 と P1 をチケット化する
7. 修正後に再度 audit を実行する

最初からプロダクト全体を対象にせず、まずは1ページまたは1コンポーネントから始めるのがおすすめです。スコープが狭いほど、audit は具体的で説明責任のある指摘を返しやすくなります。

採用前に確認したいリポジトリの読み順

導入前に適合性を見極めたい場合は、次の順番で読むと判断しやすくなります。

1. SKILL.md で呼び出しルールと必須準備を確認する
2. “MANDATORY PREPARATION” セクションで依存関係を確認する
3. “Diagnostic Scan” セクションで評価カテゴリを確認する
4. 各観点のスコア基準と重大度ロジックを確認する

この skill は単一の SKILL.md として提供されているため、導入判断で見るべきポイントは隠れたツール類ではありません。受け入れるべきなのは、そのプロセスとスコアリングモデルです。

汎用プロンプトより audit skill が向いているケース

一般的なプロンプトでも目立つ UI の問題点は挙げられますが、次のような要件があるなら audit skill の方が強みを発揮します。

• レビュー間で一貫したスコアを付けたい
• スタイル評価ではなく技術評価をしたい
• 重大度ベースで優先順位を付けたい
• 複数の画面や機能に対して再現性あるチェックをしたい

複数ページにまたがって比較可能な監査を行いたいチームにとっては、この構造自体が実務上の利点になります。

よくあるセットアップの誤り

最も多い誤用は、audit を自由形式のデザイン批評として扱ってしまうことです。リポジトリでは、これは汎用デザインレビューではなく、コードレベルの audit だと明記されています。ブランド表現、レイアウトの好み、ビジュアルの方向性だけを、実装上の根拠なしに尋ねるのであれば、その使い方はこのツールに合っていないか、ワークフローが不完全です。

audit skill FAQ

この audit skill はアクセシビリティ専用ですか？

いいえ。アクセシビリティは重要な1観点ですが、それ以外にも performance、theming、responsive design、anti-patterns を確認します。アクセシビリティ単体のレビューではなく、より広い技術的 UX Audit が必要なら audit の方が適しています。

audit は初心者にも向いていますか？

はい。どの画面・機能・コンポーネントを見てほしいのかを明確にできるなら、初心者でも使えます。スコアと重大度のモデルによって、「何か違和感がある」を、実行可能な欠陥リストに変えやすくなります。初心者が陥りやすい最大の落とし穴は、前提となるコンテキスト収集を飛ばしてしまうことです。

audit を使うにはコードへのアクセスが必要ですか？

必須ではありませんが、コードにアクセスできると出力品質は大きく上がります。スクリーンショットや実際のページから始めることはできますが、この skill は本質的に実装志向です。semantic、ARIA、構造、anti-patterns に関して信頼できる指摘が欲しいなら、コードパスを渡す価値は大きいです。

audit を使わない方がいいのはどんなときですか？

次のような目的には audit は向きません。

• クリエイティブなリデザイン
• コピーライティングのフィードバック
• プロダクト戦略の助言
• 純粋に見た目だけのブランド批評
• 同じステップで直接コード修正まで求めること

この skill は診断と優先順位付けのためのものであり、解決策の実装そのものを担うものではありません。

AI に「この UI をレビューして」と頼むのと audit は何が違いますか？

通常のプロンプトでは、スコア基準がなく、優先順位も弱い、ばらつきのあるフィードバックになりがちです。audit skill は、安定したレビュー形式、明確な重大度レベル、測定可能なチェックに基づく技術的な視点が必要な場合により適しています。

アプリ全体に対して audit を使えますか？

使うこと自体はできますが、導入初期は小さく始めた方がスムーズです。まずは1ページ、1フロー、または1コンポーネントを監査してください。スコープが大きすぎる依頼は、境界条件や代表的な根拠が十分でない限り、表面的な指摘にとどまりやすくなります。

audit skill を改善するには

audit 結果を良くするにはスコープを狭くする

audit の出力を改善する最も簡単な方法は、対象範囲を絞ることです。“Audit the dashboard” では広すぎることが多く、“Audit the table filtering experience on the dashboard at mobile width” くらい具体的にすると、より深く確認でき、優先順位付けも的確になります。

audit skill が検証できる根拠を渡す

入力の強さは、結果の信頼性に直結します。有効な根拠としては次のようなものがあります。

• URL または route
• 主要ブレークポイントでのスクリーンショット
• 影響を受けるコンポーネント
• 関連するコードファイル
• 再現手順
• 既知のアクセシビリティやパフォーマンスに関する不具合情報

この skill は、推測するより、検証できるときに最も強く機能します。

必要なレポート形式を明確に指定する

そのまま使える成果物が欲しいなら、出力形式を具体的に指定してください。たとえば:

• “Score each dimension 0-4”
• “Use P0-P3 severity”
• “Group findings by page section”
• “End with the top five fixes by user impact”

こうすることで、audit を実際の納品・運用フローに合わせやすくなります。

診断と修正を分ける

リポジトリでは、audit を明確に「記録・診断のステップ」と位置づけています。最初の実行で、診断、リデザイン、実装、コード修正までを一度に詰め込まないでください。まずはクリーンな audit レポートを取り、その後で優先度の高い指摘に対して別の skill やプロンプトを使って対応するのが効果的です。

最初の出力が弱いときは、狙いを絞った追加入力で改善する

最初の audit guide の出力が一般論っぽい場合、同じプロンプトをそのまま繰り返すのは得策ではありません。代わりに次の情報を追加してください。

• 足りていないコンテキスト
• より狭いスコープ
• 具体的なファイル
• 対象デバイスサイズ
• ユーザーフローの詳細
• 特に重視したい観点

「もっと詳しく」とだけ頼むより、2回目のプロンプトを改善した方が、通常は結果も良くなります。

audit で起きやすい失敗パターンを把握する

品質の低い audit 結果は、たいてい次のような条件で起こります。

• 前提コンテキストが不足している
• スコープが広すぎる
• スクリーンショットやコード参照がない
• 技術レビューではなく主観的なデザイン評価を求めている
• 関係のない複数の対象を1回の依頼に混ぜている

こうした状態では、レポートの実用性も説明可能性も下がります。

audit を継続的な QA チェックポイントとして使う

チーム運用でこの audit skill を最も活かせるのは、繰り返し使えるチェックポイントとして組み込むことです。

• リリース前
• 大規模な UI リファクタ後
• デザインシステム移行後
• アクセシビリティ不具合が溜まってきたとき
• レスポンシブの退行が目立ち始めたとき

この再現性こそが、単発レビューよりもスコアリングモデルの価値が高まる場面です。

最初の audit 後に優先順位付けをさらに磨く

初回の監査のあとには、次のような追質問が有効です。

• “Which P0 and P1 issues block release?”
• “Which findings are fastest to fix for the most user benefit?”
• “Which issues likely stem from shared components?”
• “Which problems should be solved in the design system rather than locally?”

こうした問いを重ねることで、audit は単なるレポートではなく、実行計画に変わります。

audit を適切な上流コンテキストと組み合わせる

このリポジトリでは /frontend-design が必須なので、audit for UX Audit はより大きなレビュー工程の一部として扱うべきです。

1. プロダクトとデザインのコンテキストを収集する
2. audit を実行する
3. 指摘を優先順位付けする
4. 実装向けワークフローに修正を引き継ぐ
5. 改善確認のために audit を再実行する

この流れで使う方が、audit skill を単独で使うよりも結果は安定します。