optimize

計測します。ボトルネックを見つけます。ボトルネックを最適化します。再計測します。終わりです。

Method

1. ベースライン。 遅さを決定論的なコマンドで再現します。以下を記録します:
   • ウォールタイム、CPU時間、メモリ、アロケーション、クエリ数、ネットワークコール(該当するもの)
   • 入力特性の例
2. 目標。 数値目標を述べます。「より速く」は目標ではありません。「p95 < 200ms」が目標です。
3. プロファイル。 言語に応じた適切なツールを使用します:
   • Node: --prof, clinic.js, 0x
   • Python: cProfile, py-spy, scalene
   • Apex: Salesforceデバッグログ分析 (/siftcoder:sf-debug)
   • SQL: EXPLAIN ANALYZE
   • ブラウザ: DevTools Performance タブ
4. 実際のボトルネックを特定します。 予想外のことが多いです。他の場所を最適化するのは無駄です。
5. 修正案を仮説立てます。 なぜそれが効果的なのか、どの程度改善するのかを述べます。
6. 最小限の変更を適用します。
7. 再計測します。 改善が確実で目標を満たしている場合 — 終わります。そうでない場合は、元に戻して別の仮説を試します。
8. 回帰テストを追加します。 パフォーマンステスト(適切な許容差付き)を追加して、改善を失わないようにします。

Output shape

Goal:         <numeric target>
Baseline:     <metric snapshot>
Profile:      <hotspot identified — function or query, w/ %>
Hypothesis:   <fix description, expected gain>
Change:       <diff>
After:        <new metric snapshot>
Improvement:  <delta>
Status:       ✓ goal met | ✗ goal not met (revert)

Rules

• ベースラインなしに最適化しないでください。 「より速く」は計測できません。
• プロファイリングなしに最適化しないでください。 直感はホットパスの50%以上で間違っています。
• 目標は数値で表します。 P95、スループット、メモリ、クエリ数。
• 変更がメトリクスを改善しない場合は元に戻してください。 推測的な最適化はコードを腐らせます。
• 改善に対してパフォーマンステストを追加してください。 そうしないと6ヶ月後に静かに回帰します。

Anti-patterns

• 「クリーンなコードはより速い」 — 時々、多くはそうでない
• キャッシュヒット率を計測せずにキャッシュを導入する
• ブロッキングされていない同期コードを非同期化する
• 1日に1回実行されるコードを早期最適化する
• マクロな問題が未解決の状態で、読みやすさを損なってマイクロ最適化する

When NOT to use

• 明確さのためのリファクタリング(パフォーマンス目標なし) — /siftcoder:refactor
• コード削除(小さい方が良いが、パフォーマンス駆動ではない) — /siftcoder:zen
• バグ修正 — /siftcoder:fix

Subagent dispatch

• 対象の最適化作業には general-purpose
• 読み取り専用のプロファイリング診断には investigator
• Salesforceの場合: /siftcoder:sf-debug parse <log> — 専用のデバッグログ分析

Value over native CC

CCはリクエストで最適化します。CCは当然のこととして、ベースライン + プロファイル + 数値目標 + 改善がない場合は元に戻す、を要求しません。このスキルは、実際の最適化とカーゴカルト的な最適化を区別する規律を強制します。