performance

name	performance
description	This skill should be used when the user asks to "optimize performance", "reduce bundle size", "fix slow rendering", or mentions "パフォーマンス", "最適化", "バンドルサイズ", "メモリリーク", "再レンダリング". Measurement-first approach. Covers bundle optimization, rendering, state management, memory/storage management. Takes optional argument: /performance <target-component or instruction>
argument-hint	<対象コンポーネント or 指示>
allowed-tools	Read, Glob, Grep, Edit, Write, Bash(git *), WebSearch, WebFetch, Agent, mcp__context7__resolve-library-id, mcp__context7__query-docs
context	main

Performance Optimization

計測ファーストのアプローチでパフォーマンス最適化を実施する。 CLAUDE.md の方針を厳守すること。プロジェクト固有のコードパターンは docs/development-patterns.md を参照。

前提条件

参照ファイル	用途	スタブ時のフォールバック
docs/project.md	コマンド	project-config.md §3 を直接参照
docs/development-patterns.md	パフォーマンスパターン	project-config.md §2, §11 を直接参照

基本姿勢

• 計測なき最適化は行わない — 推測ではなくデータに基づく
• 最適化前後の数値を必ず比較する（Before/After）
• 可読性を犠牲にする最適化は最終手段
• 過剰な最適化を避ける（体感可能な改善がない場合は見送る）
• 既存テストを壊さない

使い方

/performance <対象コンポーネント or 最適化指示>

引数は省略可能。省略した場合はユーザーに対話的に確認する。 ファイルパスを指定した場合はそのファイル周辺のパフォーマンスを分析する。

例

/performance ダッシュボードの初期表示が遅い
/performance src/features/assignment/components/AssignmentTreeGrid.tsx
/performance バンドルサイズを最適化する

出力先

• 最適化コード: src/ 配下（プロジェクトのディレクトリ構成に従う）
• レポート: 会話内で提示（計測ツールの生データは testreport/perf/ に保存）

他スキルとの連携

前工程	本スキル	後工程
/implementing-features	/performance	/code-review

最適化カテゴリ

1. バンドル最適化

• バンドル分析ツールでバンドル構成を可視化
• 動的インポートによるコード分割
• tree-shaking の確認（副作用のある import を排除）
• ビルドサイズを計測

2. レンダリング最適化

• プロファイラーでボトルネックを特定
• メモ化（フレームワーク提供のメモ化API）の適切な使用
• 不要な再レンダリングの検出と排除
• コンポーネント分割による再レンダリング範囲の最小化

注意: メモ化は実測でボトルネックが確認された場合のみ追加する。予防的なメモ化は行わない。

3. 状態管理最適化

• docs/development-patterns.md に記載された状態管理のアンチパターンを回避する
• 個別フィールドの購読（オブジェクト全体ではなく必要なフィールドのみ）
• 状態更新の最小化

4. メモリ・ストレージ管理

• ストレージクォータ監視
• 大規模データの分割保存戦略
• 不要データのクリーンアップ

最適化ワークフロー

1. ボトルネック特定 — ユーザー報告または計測ツールで問題箇所を特定
2. ベースライン計測 — 最適化前の数値を記録
3. 原因分析 — プロファイリング結果から根本原因を特定
4. 🚏 分析ゲート — ボトルネックと最適化方針を提示し、確認を待つ
5. 最適化実装 — 影響範囲を最小限に抑えた変更を行う
6. 効果検証 — 最適化後の数値を計測し、Before/After を比較
7. テスト確認 — プロジェクトの検証コマンド（docs/project.md 参照）を実行
8. 🚏 完了ゲート — 効果レポートを提示

出力契約

🚏 分析ゲート出力

フィールド	型	必須	制約
ボトルネック箇所	ファイルパス:行番号	✅	計測データに基づく特定
計測値	数値+単位	✅	推測値は不可。計測方法を明記
原因分析	テキスト	✅	根本原因を1〜3文で説明
最適化方針	箇条書き	✅	実施する最適化を優先順に列挙
予想改善効果	テキスト	条件付き	定量的に見積もれる場合

🚏 完了ゲート出力

フィールド	型	必須	制約
Before/After比較	テーブル	✅	指標名, Before値, After値, 改善率
テスト結果	X pass / Y fail	✅
カバレッジ	行: X% / 分岐: Y%	✅	ベースラインとの差分
静的解析	エラー: X件	✅

語彙制約

用語	定義
ベースライン	最適化前の計測値。比較の基準
ボトルネック	計測によって特定された性能劣化の主因
改善率	(Before - After) / Before × 100（%表記）
体感改善	ユーザーが知覚可能な応答速度の変化

構造制約

• Before/Afterテーブルの指標は同一条件で計測すること
• 計測値には必ず単位を付記する（KB, ms, 回, 件）
• 「推測」「おそらく」による最適化判断は記載禁止

PASS条件: Before/After 全指標が改善(悪化した指標がある場合は理由を明記)/ テスト・静的解析がベースラインと同数以上パス / 計測値なしの最適化提案が0件。

レポートフォーマット

# パフォーマンス最適化レポート: [対象の概要]

## 概要
- 対象: [最適化した機能/コンポーネント]
- カテゴリ: バンドル / レンダリング / 状態管理 / メモリ
- 変更ファイル数: X

## ボトルネック分析
- 箇所: `ファイルパス:行番号`
- 計測値: [数値+単位]（計測方法: [方法]）
- 原因: [根本原因の説明]

## Before / After

| 指標 | Before | After | 改善率 |
| ---- | ------ | ----- | ------ |
| [指標名] | [値+単位] | [値+単位] | [X%] |

## 実施した最適化
1. [変更内容と理由]

## テスト結果
- テスト: X pass / Y fail
- カバレッジ: 行: X% / 分岐: Y%
- 静的解析: エラー 0件

## 注意事項
- [副作用やトレードオフがあれば記載]

ドキュメント同期

最適化による変更後、影響を受ける docs/ ファイルを必ず更新する。

変更内容	更新対象
コードパターン・最適化パターンの発見	docs/development-patterns.md
feature構成の変更（lazy load等）	docs/architecture.md
ストアの分割・統合	docs/project.md
依存パッケージの追加	docs/project.md

Git操作

• --no-verify は使用禁止（pre-commit / pre-pushフックを迂回しない）
• フック失敗時はエラーの原因を修正する
• --force は原則禁止

禁止事項

• 計測なしでの最適化（「たぶん遅い」での着手禁止）
• docs/development-patterns.md に記載されたアンチパターンの使用
• 可読性を著しく損なうマイクロ最適化
• 既存テストを壊す変更
• --no-verify によるフック迂回

関連参照(必要に応じて Claude が load)

@.claude/quality-gates.md @.claude/pitfalls.md