code-optimizer

コードの最適化

次の優先順位に従って、コードのパフォーマンス上の問題を分析します。

分析の優先順位

1. パフォーマンスのボトルネック - O(n²) の処理、非効率なループ、不要な反復
2. メモリリーク - 解放されていないリソース、循環参照、増え続けるコレクション
3. アルゴリズムの改善 - 用途に適した、より優れたアルゴリズムやデータ構造
4. キャッシュの機会 - 繰り返される計算、冗長な I/O、メモ化の候補
5. 並行処理の問題 - 競合状態、デッドロック、スレッドセーフでない問題

編集前のリポジトリ同期（必須）

既存のリポジトリ内でファイルの作成、更新、削除を行う前に、現在のブランチをリモートと同期します。

branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin
git pull --rebase origin "$branch"

作業ツリーがクリーンでない場合は、先にスタッシュしてから同期し、その後復元します。

git stash push -u -m "pre-sync"
branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin && git pull --rebase origin "$branch"
git stash pop

origin がない場合、pull を実行できない場合、または rebase／stash の競合が発生した場合は、続行せず、ユーザーに確認してください。

ワークフロー

前提条件

変更を行う前に、次の手順を実行します。

1. 現在のブランチを確認します。すでにこのタスク用のフィーチャーブランチにいる場合は、スキップします
2. ブランチ命名規則（例：feat/、feature/ など）をリポジトリで確認します
3. リポジトリの規則に従って新しいブランチを作成し、切り替えます。規則がない場合は、次を使用します：feat/optimize-<target>
   • 例：feat/optimize-api-handlers

1. 分析

1. 対象のコードファイルまたはディレクトリを読みます
2. 言語、フレームワーク、実行環境（Node.js、CPython、ブラウザーなど）を特定します
3. 各優先カテゴリについて、順番に分析します
4. 見つかった問題ごとに、パフォーマンスへの影響を見積もります（例：「API の応答時間を約500msから約50msに短縮」）
5. 検出結果を深刻度の高い順（Critical が先）に報告します

2. 修正の適用

1. 最適化レポートをユーザーに提示します
2. 承認を得たら、深刻度が Critical／High の問題から修正を適用します
3. 変更のたびに既存のテストを実行し、リグレッションがないことを確認します
4. テストが存在しない場合は、変更を適用する前にユーザーへ警告します

応答形式

見つかった問題ごとに、次の形式を使用します。

### [Severity] Issue Title
**Location**: file:line_number
**Category**: Performance | Memory | Algorithm | Caching | Concurrency

**Problem**: Brief explanation of the issue

**Impact**: Why this matters (performance cost, resource usage, etc.)

**Fix**:
[Code example showing the optimized version]

ステップ完了レポート

主要なステップを完了するたびに、次の形式でステータスレポートを出力します。

◆ [Step Name] ([step N of M] — [context])
··································································
  [Check 1]:          √ pass
  [Check 2]:          √ pass (note if relevant)
  [Check 3]:          × fail — [reason]
  [Check 4]:          √ pass
  [Criteria]:         √ N/M met
  ____________________________
  Result:             PASS | FAIL | PARTIAL

チェック名は、そのステップで実際に検証する内容に合わせてください。合格には √、不合格には × を使い、簡単な補足を加える場合は — を使います。「Criteria」行には、満たした受け入れ基準の数をまとめます。「Result」行には、総合的な判定を記載します。

フェーズごとのスキル固有チェック

フェーズ：Prerequisites — チェック項目：Branch setup、Naming convention detected、Feature branch created

フェーズ：Analysis — チェック項目：Issue detection、Priority categories covered、Impact estimated、Findings sorted by severity

フェーズ：Apply Fixes — チェック項目：Fix application、User approval obtained、Existing tests run、No regressions introduced、Critical issues resolved、Warnings documented

深刻度

• Critical：クラッシュ、深刻なメモリリーク、または O(n³) 以上の計算量を引き起こす問題
• High：パフォーマンスへの大きな影響（O(n²)、ブロッキング処理、リソースの枯渇）
• Medium：負荷時に顕在化する影響（冗長な処理、最適でないアルゴリズム）
• Low：軽微な改善（マイクロ最適化、パフォーマンス向上を伴うスタイルの改善）

言語固有のチェック

検出した言語に応じたチェックについては、references/language-checks.md を読みます（JavaScript／TypeScript、Python、Go、Rust、Java、および言語横断の一般的なパターンを対象）。対象コードの言語に該当するセクションだけを読み込んでください。

受け入れ基準

以下のすべてを検証できる場合のみ、実行は受け入れ可能です。

• 重大度（Critical、High、Medium、Low）ごとに分類した最適化レポートを生成すること — 少なくとも1つの重大度カテゴリが表示されるか、「問題なし」の分岐が実行されることを確認します。
• 報告される各問題に Location、Category、Problem、Impact、Fix が含まれること — レンダリングされたテンプレートの各フィールドが空でないことを確認します。
• Impact の記述に定量的な推定値が含まれること（例：「~500ms → ~50ms」、「O(n²) → O(n log n)」） — Impact の行に数値、計算量クラス、または変更前後の比較が含まれることを確認します。
• 修正はユーザーの明示的な承認後にのみ適用されること — Edit／Write ツールの呼び出し前に、エージェントが承認を求めていることを確認します。
• 修正を適用するたびに既存のテストを実行し、結果を報告すること — テストコマンドが実行され、合否が記録されていることを確認します。
• 編集前に、リポジトリの規約に従ったフィーチャーブランチをチェックアウトすること — git rev-parse --abbrev-ref HEAD の結果が feat/* またはリポジトリに相当する規約に一致することを確認します。
• 各フェーズで Result: PASS | FAIL | PARTIAL を含むステップ完了レポートブロックを出力すること — そのブロックがトランスクリプトに含まれていることを確認します。

期待される出力

listUsers() に N+1 クエリが含まれる Node.js ファイル src/api/handlers.js に対して、このスキルは次を出力します。

◆ Analysis (step 1 of 3 — src/api/handlers.js)
··································································
  Issue detection:           √ pass (3 issues found)
  Priority categories:       √ pass (Performance, Caching covered)
  Impact estimated:          √ pass
  Findings sorted:           √ pass
  Criteria:                  4/4 met
  ____________________________
  Result:                    PASS

### [Critical] N+1 query in listUsers
**Location**: src/api/handlers.js:42
**Category**: Performance

**Problem**: `users.forEach(u => db.query(...))` issues one query per user.

**Impact**: For 1000 users, ~1000 round-trips (~2000ms) → 1 batched query (~50ms). 40x speedup.

**Fix**:
\`\`\`js
const ids = users.map(u => u.id);
const rows = await db.query('SELECT * FROM orders WHERE user_id = ANY($1)', [ids]);
\`\`\`

期待される結果：問題ごとに1つのブロックを含み、Critical から Low の順に並べた Markdown レポートに続いて、フェーズ完了レポートが出力されます。最初から最後までの詳しい例については docs/README.md を参照してください。

エッジケース

• パフォーマンス上の問題が見つからない場合：「コードはすでに十分に最適化されています」という注記を出力し、ランタイムプロファイリングツール（perf、py-spy、Chrome DevTools）を推奨します — レポートを埋めるために、重大度の低い問題をでっち上げてはいけません。
• ファイルが2000行を超える場合：処理を停止し、対象とする関数／セクションをユーザーに尋ねます。黙って途中までに切り詰めてはいけません。
• テストが存在しない場合：修正を適用する前にユーザーに警告し、明示的な確認を求めます。黙って変更を適用してはいけません。
• 最適化によってテストが失敗する場合：git diff で範囲を確認し、ユーザーが取り消しを確認した後、git checkout -- <file> で該当する変更を直ちに元に戻します。強制プッシュは行わず、破棄する前に git stash で差分をバックアップし、作業を復元できるようにします。
• リポジトリに origin がない、または rebase に失敗する場合：復旧作業を行う前に停止してユーザーの確認を求めます。まず git status と git stash --dry-run 相当の確認を実行し、バックアップブランチ（git branch backup/pre-recovery）を作成します。明示的な確認なしに、破壊的な reset --hard や rm を実行してはいけません。
• 複数の言語が混在するプロジェクトの場合：各言語をそれぞれのチェックリストで分析します。Python コードに JavaScript のヒューリスティックを適用してはいけません。
• 時期尚早な最適化候補の場合：測定可能なホットパスが特定されていない限り、マイクロ最適化は対象外とします。プロファイルまたはベンチマークで裏付けられる場合に限り、重大度を Low として指摘します。