code-optimizer

---

name: code-optimizer description: > 並列スペシャリストエージェントを用いた深度的なコード最適化監査。各エージェントは、パターンベースの検出(Grep/Glob)を使用して、パフォーマンスアンチパターン、非効率性、および最適化されていないコードを検出します。既存の実装にアンカリングバイアスが生じるのを回避するため、事前にソースコード全体を読まずに実行します。すべての最適化ドメインに対応: データベースクエリ、メモリリーク、アルゴリズム計算量、並行処理、バンドルサイズ、デッドコード、I/O&ネットワーク、レンダリング/UI、データ構造、エラーハンドリング、キャッシング、ビルド設定、セキュリティ-パフォーマンス、ロギング、インフラストラクチャ。使用場面: 「コードを最適化したい」「パフォーマンス問題を見つけたい」「コード品質を監査したい」「アプリを高速化したい」「ボトルネックを見つけたい」「パフォーマンスのためのコードレビュー」「アンチパターンを見つけたい」「コード効率を改善したい」「レイテンシを削減したい」「パフォーマンスを最適化したい」「コードスメル検出」「遅いコードを見つけたい」「このプロジェクトを最適化したい」「パフォーマンス監査」「コード最適化」。また以下の場合にもトリガー: 「optimizar codigo」「encontrar cuellos de botella」「mejorar rendimiento」。

tags: [gsd-2, skills, code-optimizer, performance, devops, security, database, code-review, compliance]

| # | ドメイン | 参照ファイル | 検出項目 |
|---|---------|------------|---------|
| 1 | データベース&クエリ | `references/database-queries.md` | N+1クエリ、SELECT *、インデックス欠落、ORM乱用、接続プーリング |
| 2 | メモリ&リソース | `references/memory-resources.md` | メモリリーク、クローズされていないリソース、大規模な割り当て、ループ内での文字列連結 |
| 3 | アルゴリズム計算量 | `references/algorithmic-complexity.md` | O(n^2)パターン、不要な反復処理、検索に不適切なデータ構造 |
| 4 | 並行処理&非同期 | `references/concurrency-async.md` | 順序的なawait、非同期内のブロッキング、競合状態、無制限の並行処理 |
| 5 | バンドル&依存関係 | `references/bundle-dependencies.md` | 重いインポート、未使用の依存関係、重複ライブラリ、遅延ロード欠落 |
| 6 | デッドコード&冗長性 | `references/dead-code-redundancy.md` | 未使用エクスポート、コメントアウトされたコード、デッドブランチ、重複ロジック |
| 7 | I/O&ネットワーク | `references/io-network.md` | 順序的なリクエスト、バッチ処理欠落、重複排除欠落、圧縮欠落 |
| 8 | レンダリング&UI | `references/rendering-ui.md` | 再レンダリング、仮想化欠落、レイアウトスラッシング、アニメーション性能 |
| 9 | データ構造 | `references/data-structures.md` | 不適切なデータ構造、不要なコピー、非効率なシリアライゼーション |
| 10 | エラー&レジリエンス | `references/error-resilience.md` | タイムアウト欠落、エラー抑止、リトライ欠落、サーキットブレーカー欠落 |
| 11 | キャッシング&メモ化 | `references/caching-memoization.md` | メモ化欠落、無効化なしのキャッシュ、冗長なAPI呼び出し |
| 12 | ビルド&コンパイル | `references/build-compilation.md` | 本番環境に含まれた開発用コード、最適化フラグ欠落、遅いテスト、Docker問題 |
| 13 | セキュリティ-パフォーマンス | `references/security-performance.md` | 暗号化乱用、レート制限欠落、ReDoS、SQLインジェクション脆弱性 |

**オプションエージェント**(関連スタックが検出された場合にスポーン):
- ロギング&オブザーバビリティ (`references/logging-observability.md`) — ロギングフレームワークが検出された場合
- 設定&インフラストラクチャ (`references/config-infra.md`) — Docker/デプロイメント設定が検出された場合

### エージェントプロンプトテンプレート

各エージェントは以下のプロンプト構造を受け取る必要があります:

You are a {DOMAIN_NAME} optimization specialist. Your job is to find performance anti-patterns in the codebase at {PROJECT_ROOT}.

CRITICAL RULES:

1. DO NOT read source code files before searching. This avoids anchoring bias.
2. First, read your reference file: {SKILL_DIR}/references/{REFERENCE_FILE}
3. Use Grep and Glob to search for the patterns described in the reference file.
4. Only read 5-10 lines of context around each finding to confirm it's a real issue.
5. Skip patterns that don't match the project's stack: {DETECTED_STACK}

Tech stack detected: {DETECTED_STACK} Project root: {PROJECT_ROOT}

For each finding, report:

• File: path:line_number
• Pattern: what anti-pattern was detected
• Severity: CRITICAL / HIGH / MEDIUM / LOW
• Current code: the problematic snippet (keep short)
• Why it's slow: brief explanation of the performance impact
• Optimal fix: the recommended solution (code snippet or approach)
• Estimated impact: qualitative improvement expected (e.g., "10x faster for large lists")

If you find 0 issues in your domain, report "No issues found" — this is a valid outcome. Sort findings by severity (CRITICAL first).

### ステップ3: 報告書の統合

すべてのエージェントが完了した後、その結果を単一の優先順位付けられた報告書に統合します:

1. すべてのエージェントからすべての結果を収集
2. 重複排除(異なるエージェントが同じコードを異なる理由でフラグできます)
3. 重要度でソート: CRITICAL > HIGH > MEDIUM > LOW
4. ファイルごとにグループ化(ユーザーがファイル単位で修正できるように)
5. 最終報告書を以下の内容で提示:
   - エグゼクティブサマリー: 重要度別の結果の総数、最も影響の高い上位3つ
   - ファイルごとに分類された詳細な結果
   - 改善計画: 最高から最低の影響の順序で列挙された修正リスト

### 報告書形式

```markdown
# コード最適化監査報告書

## エグゼクティブサマリー
- **X**件の重大な問題、**Y**件の高、**Z**件の中、**W**件の低
- 最も影響の高い上位3つの修正:
  1. [簡潔な説明] — [予想される影響]
  2. [簡潔な説明] — [予想される影響]
  3. [簡潔な説明] — [予想される影響]

## ファイル別の結果

### `path/to/file.ts`

| # | 重要度 | ドメイン | パターン | 修正方法 | 影響 |
|---|--------|---------|---------|---------|------|
| 1 | CRITICAL | データベース | ループ内のN+1クエリ | prefetch_relatedを使用 | クエリ数を50分の1に削減 |
| 2 | HIGH | 非同期 | 順序的なawait | Promise.allを使用 | 3倍高速化 |

[... 結果を持つ各ファイルについて以下を繰り返し ...]

## 改善計画

修正の優先度順実装ステップ:

1. **[CRITICAL] `api/users.py`内のN+1クエリを修正**
   - 現状: ループがユーザーごとにuser.postsをクエリ
   - 修正: queryset に prefetch_related('posts') を追加
   - 影響: N+1を2クエリに削減

2. **[HIGH] `services/sync.ts`内のAPI呼び出しを並列化**
   - 現状: 5つの順序的なawait fetch()呼び出し
   - 修正: Promise.all([fetch1, fetch2, ...])
   - 影響: 同期操作が約5倍高速化

[... すべての結果について続行 ...]