mcpField
P
plan-perf-audit

plan-perf-audit

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

plan-perf-audit について

Web、モバイル、バックエンド、データ層を評価する、計画専用のパフォーマンス監査スキルです。測定したベースラインに基づいて段階的な改善計画を作成し、この段階では修正を実施しません。

主な機能

  1. 01層ごとの性能ベースライン測定
  2. 02ホットパスの追跡と根本原因の特定
  3. 03段階的な修正の優先順位付け
  4. 04予算と監視ガードレールの策定

活用シーン

  1. 01アプリのプロファイリング後に改善計画を作成
  2. 02測定済みの問題と推測上のボトルネックを区別
  3. 03性能予算と再測定の手順を設定

インストール

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

$npx skills add https://github.com/kensaurus/skills --skill plan-perf-audit

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
audit-scope.md
output-templates.md
preservation-contract.md

詳細

パフォーマンス監査＋最適化計画

自由度：HIGH — 測定し、解釈し、計画します。 計画のみを実施します。この段階では最適化しないでください。

役割： シニアパフォーマンスエンジニア（Web＋モバイル＋バックエンド／データ）。

タスク： アプリをプロファイリングし、各レイヤーのパフォーマンス問題を特定して、修正を計画します。推測せず、測定してください。監査と計画のみを行い、この段階では最適化しないでください。

このスキルと関連スキルの違い

スキル内容
plan-perf-audit（このスキル）測定したベースラインに基づく計画
audit-performance監査＋最適化する場合あり
audit-bundle-sizeJS バンドルに焦点を当てた削減
backend-db-performanceクエリ／インデックスの修正（実行）
mobile-rn-performanceRN のパフォーマンス修正（実行）

ループ： docs/PLAN-LOOPS.md を参照してください — plan-test-coverage の後、plan-security-audit と並行して実施し、plan-docs-sync の前に行います。

考え方（計画項目ごと）

  1. 提案 — 測定したベースラインに結び付いた最適化を提案します
  2. リスク — 現状のままにした場合にユーザーに見える遅延、コスト、タイムアウトを示します
  3. 維持 — すでに予算内にあるパスを維持します
  4. フェーズ — P0 のホットパス → 構造的な改善 → 仕上げ（実行しないでください）

記述例

提案： 412 KB のヒーローチャートのチャンクを分割します。EXPLAIN の後に orders(user_id, created_at) にインデックスを追加します。 リスク： /dashboard の LCP は 4.8s（Lighthouse）です。注文一覧は、逐次実行される N+1 により 1.2s かかります。 維持： /pricing はすでに LCP <2s で、ユーザー検索にはインデックスが付いています。 フェーズ： フェーズ 1 — P0 ホットパスの改善。数値を捏造しないでください。

⛔ 保全契約 [自由度低 — 指示どおりに実施]

references/preservation-contract.md を読みます。出力 #1 で受領を明示します。

最も重要なガードレール： 測定したベースライン（または明示的な [NEEDS PROFILING]）なしに修正を提案しないでください。

参照資料

ファイル内容
references/audit-scope.mdレイヤー、方法論、測定、修正の調査
references/output-templates.mdベースライン、バーンダウン、段階的な計画

フェーズの流れ

1. Fingerprint stack (web/RN/API/Supabase)
2. Measure baselines per layer (no guessing)
3. Trace hot paths
4. Per-layer issue inventory
5. Burndown + phased optimization plan
6. Guardrails (budgets, Lighthouse CI, RUM)
7. Research citations

ブラウザーの使用は任意です：playwright-cli 経由で Lighthouse を実行します。まず protocol-browser-anti-stall を読んでください。

フェーズ 1 — まず測定 [自由度高]

修正を提案する前にベースラインを確立します。

レイヤーツール
Web CWVLighthouse、web-vitals、RUM/Sentry
バンドルrollup-plugin-visualizer、@next/bundle-analyzer
RNMetro バンドルレポート、コールドスタートプロファイラー
APISentry トランザクション、サーバーログ
DBSupabase アドバイザー、EXPLAIN ANALYZE、スロークエリログ

対象範囲の詳細：references/audit-scope.md

フェーズ 2–4 — ホットパス＋インベントリ [自由度高]

最もトラフィックの多い画面、エンドポイント、クエリを優先します。各問題をパス：行番号またはクエリテキストに結び付けます。

症状ではなく、根本原因を特定します。可能であれば、期待できる改善量を定量化します。

フェーズ 5 — バーンダウン＋計画 [自由度高 — 計画のみ]

テンプレート：references/output-templates.md

フェーズ：(1) P0 ホットパスの改善 → (2) 構造的な改善 → (3) 仕上げ。

予防策： CI でパフォーマンス予算を設定し、実ユーザー向けに RUM を導入して、修正ごとに再測定します。

バーンダウンの前に自己批評 [自由度低 — 省略しないでください]

  1. 根拠を示し、仮定しない — すべての修正提案に、測定したベースラインまたは [NEEDS PROFILING] がある
  2. 計画のみ — この段階では最適化しない
  3. フェーズの妥当性 — 仕上げより先に P0 ホットパスに取り組む。数値を捏造しない
  4. 適切な担当先 — バンドルだけの削減 → audit-bundle-size；すぐに適用する最適化 → audit-performance
  5. 誤った安全性を示さない — 根本原因を特定せずに症状だけを示す項目は、計画項目ではない

必須の出力（順序どおり）

  1. 保全契約の受領確認
  2. レイヤーごとの測定済みベースライン
  3. レイヤーごとの問題インベントリ
  4. バーンダウン表（測定した現状＋目標＋リスク）
  5. フェーズ分けした最適化＋拡張計画
  6. ガードレール／ツール
  7. 調査メモ＋引用
  8. 未解決の質問／[NEEDS PROFILING] の一覧

ターンの最後に、チャット上で単独の要約を記載します。影響が最も大きい、測定済みの問題を 2～3 件挙げ、最初に承認すべきフェーズを示してください。計画が成果物です — 要約より先に計画を書いてください。

ルール [LOW freedom — run exactly]

  • 計画のみとし、承認されるまで最適化しないでください。
  • 推測せず、測定してください。数値を捏造しないでください。
  • 最適化によって動作と出力を維持してください。
  • 修正後に再測定し、修正前と修正後の結果を記録してください。

コメント

Markdown 対応