find-improvements

改善点の検出

対象範囲

別のリポジトリまたはより限定された対象が選択されていない限り、現在のリポジトリを分析します。パラメーターに関する質問をせずに開始し、利用できないリポジトリや曖昧なリポジトリは代替せずに報告します。

ユーザーが選択できるよう、バグを2件、リファクタリングを2件提案します。読み取り専用で作業してください。ファイルの編集、依存関係のインストール、チェックアウトの切り替え、修正の実装、コミット／PR／チケットの作成、スケジュールの変更は行わないでください。

依存関係

スキルの依存関係はありません

ワークフロー

分析

• 開始時刻、リポジトリ、ブランチ、HEAD SHAを記録します。リポジトリの指示、関連するアーキテクチャ、テストを読みます。ローカルの変更を保持し、コミット済みコードと区別します。
• 直近のコミット／差分から調査を開始し、前回の報告のSHAがHEADの祖先である場合は、そのSHA以降の変更を優先します。それ以外の場合は、確認した直近の範囲を明示します。新しいコミットがなくても、関連コードの調査を続けます。
• サブエージェントを正確に2つ起動します。一方には最大2件のバグ、もう一方には最大2件のリファクタリングを探させます。両者に対象範囲、基準点、読み取り専用の制約、候補の基準、分析期限を伝えます。指摘ごとにエージェントを起動したり、これらのエージェントにさらに委任させたりしないでください。委任できない場合は、単独での分析に黙って置き換えず、その制約を報告します。
• 実際に少なくとも10分間、積極的に調査・検証します。並行作業によってこの要件が短縮されることはありません。候補が4件早く見つかっても、引き続き疑って検証します。待ち時間で時間を埋めてはいけません。呼び出し元、契約、状態、データフローを追跡し、調査範囲を広げる前にリグレッションを優先します。根拠がある場合に限り、指摘をコミットに帰属させます。
• アクセス可能なオープンPR、過去の報告、ユーザーの判断を確認し、重複、作業中の項目、却下された案を調べます。確認できない情報源は明示します。サブエージェントの根拠を検証し、弱い指摘や重複する指摘は却下して、各カテゴリ内で価値と作業量の比に基づき順位を付けます。作業が阻まれた場合は、実際の所要時間と原因を報告します。

候補

**バグ：**実装部分を各30～60行程度変更することで修正できる、具体的かつ到達可能な動作上の誤り。テストの行数は含めません。コードと契約から、発生条件、期待される動作、結果として生じる影響を導きます。仮説的なリスク、スタイル上の好み、裏付けのない製品上の前提は除外します。有用な場合は既存テストまたは非変更の再現手段を使い、実行による検証とコード分析を区別します。

**リファクタリング：**テストを除く実装部分の変更が概ね200行以内で実現できる、動作を維持した改善。単純化、重複の削減、構造の変更と、具体的な保守上の利点を説明します。機能追加、見た目だけの変更、推測に基づく抽象化は除外します。

カテゴリごとにユーザーの許可がある場合にのみ、上限を増やします。見積もりは正直に示し、根拠または対象範囲から2件の提案を裏付けられない場合は、提案数を減らします。指摘を捏造しないでください。

結果

リポジトリ、ブランチ、HEAD SHA、確認した範囲、所要時間、対象範囲／検証上の制約をここで報告します。状態ファイルを使わずに後続の実行で参照できるよう、SHAを保持します。

Bugs（B1/B2）とRefactors（R1/R2）を使用します。各提案には次の内容を含めます。

• 発生条件と影響、または提案するリファクタリングとその利点。
• 行番号付きのファイルリンク、コードに基づく根拠、確認できている場合は関連コミット、検証内容、有用な再現手順またはリグレッションチェック。
• テストを除く実装の変更行数の見積もりと、維持すべき動作。

不足があれば明示します。最後にユーザーが選択できるよう提案を示し、実装したり、項目ごとに承認を求めたりしないでください。