refactor-scoutlisted

# スカウト隊の単独実行 /ml-pipeline を回さずに、任意のファイル・ディレクトリ・差分に対して スカウト隊による検出→提案→適用のリファクタリングを行う。 ## 進め方 1. **対象とレンズの確認**: - 対象(ファイル / ディレクトリ / 差分)が指定されていなければ確認する - レンズの指定があればそのスカウトだけ、無ければ7体全員を使う (例: 「命名と重複だけ」→ scout-naming と scout-duplication のみ) 2. **偵察**: 該当スカウトをサブエージェントとして起動し、対象を渡す。 複数体の場合、エージェントチーム機能が使える場合は並列、 無ければ逐次で1体ずつ実行する(単独利用では逐次でも実用的な時間で終わる)。 3. **統合**: 提案をファイル:行番号順に連結する(要約・書き直しをしない)。 2体以上が同じ箇所(±2行以内)を指摘した提案に [一致] マークを付ける。 4. **提示と選択**: 統合リストをユーザーに提示し、どれを適用するか確認する。 - 「全部」「[一致]だけ」「番号指定」���いずれでも選べるようにする - ユーザーの選択なしに適用しない(パイプライン外では実装者の 自動判断ではなく、ユーザーが判断する) 5. **適用**: 選ばれた提案を、このセッション(メイン)が1つずつ適用する。 動作不変が前提。スカウトにコードを書かせない。 6. **検証**: 適用後にプロジェクトのテストを実行する。優先順: CLAUDE_EVAL_CMD が設定されていればそれ、無ければ tests/ がある場合に `uv run --with pytest python -m pytest tests/ -q`、どちらも無ければ テスト実行をスキップした旨を報告に明記する(黙って省略しない)。 **復元契約**: 適用は**既存ファイルの編集のみ**とし、新規ファイルを作る 提案は採用しない(復元を git checkout で完結させるため。6.7 の制約と 同じ)。適用開始前に作業ツリーがクリーンであることを確認してから 始める(クリーンでなければ先にコミットを促す)。テストが失敗したら、 適用した提案を**全て** `git checkout -- <触ったファイル>` で一括で戻し (開始時クリーンなので復元は適用の取り消しと正確に一致する)、失敗した テストと戻した提案の一覧を報告する。原因の切り分けが必要なら ユーザーの指示で提案を1件ずつ適用し直す。 7. **報告**: 適用した提案 / 見送った提案 / テスト結果を報告する。 ## パイプライン(手順6.7)との違い | | 手順6.7(自動) | このスキル(単独) | |---|---|---| | 起動 | CLAUDE_REFACTOR_SWARM=1 で自動 | ユーザーの依頼で任意 | | レンズ | 常に7体全員 | 選べる(既定は全員) | | 適用判断 | 実装者が判断 | ユーザーが選択 | | 対象 | パイプラインの差分 | 任意のファイル・ディレクトリ | ## 注意 - コミットはユーザーに確認してから行う(`refactor(scout): <要約>` 形式) - 動作が変わる提案は適用しない(それはリファクタではなく変更