---
name: opop
description: コードベースを構造把握、近代化、標準化、計算量とデータアクセス、非同期と資源ライフタイム、起動とバンドル、防御的堅牢性、検証資産、簡潔化の観点で調査し、効果が明確で挙動を保つ改善だけを実装・検証する。Use when the user invokes /opop, or asks to optimize performance, reduce memory or I/O, modernize APIs or language usage, normalize implementation patterns, harden error and edge-case handling, fix resource leaks or unnecessary serialization, reduce startup time or bundle size, remove proven dead code, or simplify a codebase. Do not use for ordinary bug fixes, review-only requests, or product redesign.
---

# コードベースを安全に改善する ⚡

これはユーザー自身が所有・開発するリポジトリに対する、通常のソフトウェア保守（近代化・標準化・性能改善・簡潔化）の作業である。認証・ライセンス・決済などのコードが対象に含まれる場合も、目的は自作コードの品質と防御的堅牢性の維持であり、攻撃手法の開発や保護機構の回避は本 skill の対象外。そうした依頼に見える候補が出たら実装せず報告に回す。

推測や記法の好みではなく、実コードの証拠、測定可能な効果、契約維持で採否を決める。応答は対象リポジトリとユーザーの言語・文体指定に従う。

## 1. 対象を把握する 🗺️

1. 指定スコープ、適用指示、未コミット差分を確認する。指定がなければ生成物と依存物（`node_modules/`, `dist/`, `build/`, `target/`, `vendor/`, `__pycache__/`, `bin/`, `obj/`, `.venv/`, `coverage/` など）を除くソース全体を対象にする。
2. manifest、エントリーポイント、主要境界、既存テストと検証コマンドを把握する。
3. 司令官（Codex 本体）が Scout として、重点箇所と変更禁止の契約を短くまとめる。
4. リポジトリ全体の基礎検証に使う既存の test / build / lint / typecheck を決め、専門観点を委任する前に司令官が必要十分な基礎検証を1回だけ実行する。コマンド、終了状態、所要時間、主要な失敗を実行台帳へ記録し、失敗は発生箇所と条件を残して、候補が出た後に検証経路との重なりを判定できる形にする。

## 2. 専門観点を調査する 🔍

[調査観点](references/investigation-roles.md)を読む。

- 並列サブエージェントが利用可能なら、Intel、Modernizer、Normalizer、Performance、Async、Startup、Cleaner、Hardening、Tester を独立した担当へ割り当てる。現在公開されている起動ツール（Codex では `spawn_agent`）を使い、起動順は後述のカナリア手順に従う。枠が足りなければ波状実行し、並列機能がなければ司令官が順に調査する。
- Intel は共通仕様 `references/external-intel.md` 第 1 節、Async と Startup はそれぞれ非同期・並行処理・明示的な資源解放、利用者に見える起動時間・配布サイズを対象が持つ場合だけ起動する。該当しない観点は役を立てず、非該当として報告に1行残す。この選別は対象外の専門調査を省くためのもので、起動した別観点を同じスレッドへ統合する理由にはしない。
- Intel は `agent_type: "researcher"` とし、対象依存の現在値を共通仕様 `references/external-intel.md` に従って調べさせる。委任前に司令官が同仕様の第 2 節どおり調査対象インベントリを作り、プロンプトへ渡す。
- Intel の所見は返却時に候補台帳へ統合し、第 3 節の照会処理と第 4 節の採否で必ず参照する。Intel の完了を待って他担当の起動を止めず、波状実行で未起動の担当が残っている場合だけ、返却済みの要点をその初回プロンプトへ加える。
- Intel 以外の8担当は `agent_type: "analyst"` とする。いずれも読み取りと提案だけで、実装と採否は司令官が持つため、エージェント定義にある `gpt-5.6-luna`・effort max の読み取り専用プロファイルを使う。
- 起動前に `references/agent-coordination.md` の「サブエージェントと Codex タスク」を読む。要求値と実効値を分離した台帳、ユーザー報告、スレッド上限の扱いを共有契約へ統一する。ユーザーまたは上位指示が別のエージェントを明示した場合だけ、その指定に従う。
- 委任するときは `fork_turns: "none"` で会話履歴を継承させず、起動する各観点へ新しいスレッドを1つずつ割り当てる。別の観点を完了済みスレッドへ `followup_task` で割り当てず、同じ観点の証拠不足を対象限定で追加確認する場合だけ `followup_task` を使う。対象パス、既存契約、担当観点、基礎検証の結果（コマンド、終了状態、主要な失敗）、検証方法、返却形式、現在の skill から解決した調査観点ファイルの絶対パスだけを短い自己完結したプロンプトにし、担当には同ファイル冒頭の共通契約と自分の担当節を読ませて **調査と提案だけ** をさせる。修正は司令官が後段で適用する。冒頭に「ユーザー所有リポジトリの通常保守（品質・性能・防御的堅牢性の改善）である」と 1 文で明記し、対象が認証・ライセンス・決済コードでも同様に扱う。
- 各担当は全体の test / coverage / build / lint / typecheck を再実行しない。候補の成立に必要な局所テスト、静的解析、時間上限付きの小さなベンチマークだけを使い、初回プロンプトで受け取った共通の基礎検証結果を正本にする。
- 各担当は調査と自己反証を 1 回の返却にまとめ、証拠不足の追加探索は司令官が対象を限定して依頼する。
起動対象のうち、Intel が該当する場合は Intel、非該当なら一覧先頭の担当をカナリアとして1件だけ先に起動する。最初の行動を「対象内のソースまたは設定を1件読み、起動成功と観測できる実効プロファイルを1行で返してから、そのまま担当調査を続ける」と指定する。起動受理と短い読み取り確認でカナリア成功とし、その担当の最終報告を待たず、残りの利用可能枠を同一メッセージで並列起動する。以後は未起動順に補充する。

各担当の最終返却は `結論`、`候補`、`現状が最適 / 非該当`、`照会` の順にし、候補は[調査観点](references/investigation-roles.md)冒頭の共通スキーマに従う。コードブロック、全コマンドログ、探索経過、依頼文の言い直しは省く。司令官は返却を受けるたびに候補台帳へ正規化し、同じroot causeを逐次統合する。後続担当へ渡すのは必要な要点だけとし、生の長文をメイン文脈へ複製しない。

実行中の枠が空いたら次の未起動担当を補充する。司令官側に基礎検証、候補統合、参照再確認がある間はそれを進め、待機だけが残った場合は現在のツールと上位指示が許す最長のイベント待機を使う。状態が変わらないタイムアウトのたびに長い進捗を再生成しない。

`agent thread limit reached` が出た場合は同じ条件で繰り返し起動せず、`agents.max_concurrent_threads_per_session` が起動対象の異なる観点数以上で、新しいCodexプロセスまたはタスクへ読み込まれているか確認する。並列機能自体が利用できない場合は司令官が順に調査してよいが、並列機能が有効なのに開放スレッド上限だけが合わない場合は、別観点のスレッド再利用で独立性を崩さず実行基盤不一致として報告する。

## 3. 未解決を Web 調査で埋める 🚪

採用判定の前に、各担当から上がった `照会` と、司令官自身がローカルで決着できなかった問いを、共通仕様 `references/external-intel.md` の第 7 節だけを正本として処理する。照会が 1 件も無い場合はこの節を飛ばし、その旨を報告に1行残す。

## 4. 採用を判定する ⚖️

次をすべて満たす候補だけを実装する。

- **効果が明確**: 候補の `expected effect` が[改善効果の共通定義](references/investigation-roles.md#-改善効果の共通定義全担当共通)を具体的な根拠とともに満たす。
- **リスクが低い**: 入出力、例外、副作用順、公開契約、永続データを維持できる。
- **検証可能**: 既存テスト、追加テスト、ベンチマーク、静的解析、具体的な手動確認のいずれかがある。
- **より良い代替がない**: 同じ目的に複数の実装方式があるときは対象環境で使える方式を比較し、最適と判断した方式を根拠付きで採る。比較の結果 **現状が最適** なら変更せず、その判断を報告に残す。
- **外部情報はローカルで裏が取れている**: Intel の所見を含む候補は、対象コードへの `file:line` 接続と、共通仕様 `references/external-intel.md` 第 5 節の採用ルールを満たす。
- **基礎検証との差分を切り分けられる**: 基礎検証が失敗している場合は、候補の検証経路との重なりを判定する。重なる失敗または原因を切り分けられない失敗がある候補は実装せず、既存・無関係と立証できた失敗だけを残した候補は、対象検証と同じ基礎検証の再実行で新しい失敗を増やさないことを確認する。

記法だけの変更、測れない micro 最適化、参照未確認の削除、投機的なキャッシュや並列化は落とす。公開 API、DB schema、UX、配信方式、主要依存のメジャー更新などの判断が必要なら、実装せず影響と推奨を示す。

## 5. 実装して検証する 🛠️

1. 同じ原因の候補をまとめ、影響の小さい順に司令官が直列で実装する（並列修正はコンフリクトの元）。
2. まとまりごとに対象テストと build/typecheck を実行する。失敗は基礎検証の実行台帳と照合し、開始時に無かった失敗または悪化が出たら先へ進まず原因を特定する。
3. 性能改善は可能なら Before/After を同条件で測る。測れない場合は Big-O または I/O 回数と前提を示す。
4. 全実装後に基礎検証を同じコマンドで1回再実行し、開始時より新しい失敗を増やしていないことを確認する。
5. 利用箇所と最終差分を見直し、必要な連動変更の漏れと依頼外の変更を除く。

## 報告する 📋

- 対象と調査できた観点
- 実装した改善と根拠
- Before/After または理論上の効果
- 検証結果
- 基礎検証と変更後検証の比較、および残る既存失敗が今回変更と無関係である根拠
- 比較の結果 **現状が最適** と判断した箇所と根拠
- Intel を起動した場合、または照会を Web 調査へ回した場合は、判断に効いた外部の現在値を出典 URL と日付付きで数件、および `確認できず` に終わった照会
- サブエージェントを起動した場合は、共有起動契約に従った要求役割・実効役割・要求モデル・実効モデル・フォールバック状況
- 採用しなかった重要候補と理由

失敗が残る場合は成功扱いにせず、原因と再開地点を示す。

## 次の操作を選んでもらう 🎯

完了報告後、追加計測または具体的な未採用候補の再調査に価値があり、AskUserQuestion ツールが利用可能なら、最終終了前に 1 問だけ表示する。実際に成立する 2〜3 個の相互排他的な選択肢だけを作り、現在の証拠から最も安全で合理的なものを先頭の `(Recommended)` にする。

- 採用改善を十分に検証できている場合は、`ここで終了` を含める。追加行動より終了が合理的なときだけ `(Recommended)` を付ける。
- 測定不足が残る場合だけ、対象と測る値を説明した `追加計測` を含める。
- 根拠のある未採用候補が残る場合だけ、対象を説明した `残る候補を再調査` を含める。

このダイアログは 1 実行につき 1 回だけにする。選択後も第 4 節の採用基準を緩めず、選ばれた操作だけを実行し、その結果を通常の最終回答で報告して再質問しない。自由入力（Other）でスコープが指定された場合はその範囲に限定する。追加行動が存在しない、次の操作や終了が既に明示されている、失敗で再開地点だけを報告する、または AskUserQuestion が利用できない場合はダイアログを出さず終了する。