--- name: simplify description: >- 変更したコードを再利用・品質・効率の3観点でレビューし、振る舞いを維持して修正・検証する。simplify、コードを簡素化して、実装を整理して、と明示的に依頼されたときに使用する。 argument-hint: "[対象ファイル・ディレクトリ・base ブランチ・重点観点、またはレビューのみ]" disable-model-invocation: true --- # Simplify 変更済みコードの保守性と読みやすさを改善する。行数削減を目的にせず、既存実装の再利用と具体的に無駄な処理の解消を優先する。通常は修正まで行い、「レビューのみ」の依頼では指摘の報告で終了する。 ## 1. 対象と規約を確認する - ユーザーが指定したファイル・ディレクトリ・差分範囲・重点観点を優先する。明示したファイルやディレクトリは差分がなくても対象にする。引数は Claude Code では `$ARGUMENTS`、Codex ではスキルを呼び出した依頼文から読み取る。引数をそのままシェルで評価しない。 - 対象に適用される `AGENTS.md`、`CLAUDE.md`、参照される規約を読む。`@AGENTS.md` などの参照先も確認し、言語固有の規約を別のプロジェクトに持ち込まない。 - 既定の対象はブランチの差分全体と未コミット変更。ベースはユーザー指定を優先し、なければ利用可能な PR 情報の base を確認する。PR 情報がなければ、ローカルに存在するリモート既定ブランチ参照などから候補を特定する。現在のブランチ自身や単なる push 先の upstream をベースと見なさない。複数候補、ベース上での実行、参照不足などで判断できなければ質問する。ネットワーク取得や設定変更を自動で行わない。 - ベースと `HEAD` の merge-base を求め、`git diff ` でコミット済み・ステージ済み・未ステージの変更をまとめて確認する。ファイル一覧は `git diff --name-status `、未追跡は `git ls-files --others --exclude-standard` で確認する。削除・リネームも一覧に残す。未追跡の通常ファイルは依頼との関連を確認して内容を読む。機密情報、バイナリ、生成物、vendor、lock ファイルを無差別に読み込まない。 - Git 管理外ではユーザー指定または会話中の編集ファイルを使う。対象を確定できなければ質問し、回答を待つ。対象が空、またはコードの改善対象がない場合はその旨を報告して終了する。 - 修正前の状態を把握し、ユーザーの変更を保持する。既存の検証コマンドを確認し、実行可能なら関連チェックの修正前の結果も記録する。 ## 2. 3観点を並列レビューする以下の定義を読み、3担当を読み取り専用で実行する。観点の本文はここに複製しない。 | 担当 | 定義 | Claude Code の subagent_type | |---|---|---| | 再利用 | [simplify-reuse](../../agents/simplify-reuse.md) | `code-quality:simplify-reuse` | | 品質 | [simplify-quality](../../agents/simplify-quality.md) | `code-quality:simplify-quality` | | 効率 | [simplify-efficiency](../../agents/simplify-efficiency.md) | `code-quality:simplify-efficiency` | Claude Code では `Agent` / `Task` を使う。Codex では各ファイルの YAML frontmatter を除いた本文全体を、別々の汎用サブエージェントに渡す。これらのファイルは Codex のカスタムエージェント登録ではない。モデルと権限はセッションから継承し、Claude の `tools` などの frontmatter を Codex 設定に転用しない。各担当に次を渡す: - ユーザーの目的・制約・重点観点・レビューのみかどうか。 - 解決したベースと merge-base、対象ファイルの全一覧、全差分と対象の未追跡ファイルの内容。明示指定の既存ファイルには対象内容を渡す。 - リポジトリとインストール済みプラグインの絶対パス、および適用規約の内容または参照先。 - 対象外も再利用候補や呼び出し元の調査のために読めるが、編集・コミット・外部への投稿は禁止すること。 - 指摘ごとに `観点 / path:line または symbol / 根拠 / 具体的な改善 / 振る舞い維持の条件 / 関連箇所` を返すこと。根拠を確認できない案や好みだけの指摘は除外し、指摘がなければその旨を返すこと。ホストの同時実行上限内で3担当を起動する。枠が不足すれば分けて実行し、結果をすべて待つ。委譲機能が使えない場合は同じ定義を読み、親が3観点を逐次レビューする。失敗した担当は再実行または親が補完し、未実施の観点を完了扱いにしない。全差分が大きすぎる場合は関連モジュール単位に分割して全対象を確認し、黙って切り捨てない。実際に行った並列・分割・逐次方式を報告する。 ## 3. 統合して修正する全担当の結果を集約し、同じ原因の指摘を統合する。親が実コード・既存ヘルパー・呼び出し元を確認し、誤検出や効果の乏しい案を見送る。レビューのみなら、この時点で根拠付きの指摘と検証状況を報告して終了する。採用した改善は親が修正する。次の条件を守る: - 戻り値、出力、例外・エラー、ログ、検証、副作用、処理順序、公開 API と保存形式を維持する。振る舞いを変える必要がある案は自動修正せず、別の課題として報告する。 - セキュリティ・データ保護の確認や回帰テストを弱めない。テストやコメントを一括削除する工程は設けない。 - 既存ヘルパーが使えるなら再利用する。必要な共通化では定数・ラッパー・エイリアス・設定経由の利用と同パターンの関連箇所を追い、重複を増やさない。ただし、異なる責務を無理に統合したり、将来を想定した汎用基盤を作ったりしない。 - 修正は対象変更に必要な範囲に限る。ユーザーが編集可能範囲を明示した場合は、範囲外の変更が必要な案を見送って説明する。依存リポジトリの扱いは適用されるプロジェクト規約に従う。 - 既存の未コミット変更を上書き・破棄しない。レビュー中に対象が変わった場合は差分を読み直し、古い行番号や前提で編集しない。 ## 4. 検証して報告する修正後の差分を確認し、対象に応じたテスト・lint・型検査など、リポジトリが要求するチェックを実行する。共有コードを変更した場合は関連呼び出し元まで検証を広げる。必要なら意味のある回帰テストを追加する。検証失敗を通すためにテストを弱めない。今回の修正に起因する失敗は直すか、自分が加えた該当変更だけを戻す。既存の失敗と区別し、実行できないチェックは理由を示す。検証手段がなければ静的確認の限界を明記する。最終報告は、対象・ベース・実行方式、改善内容と理由、主な見送り事項、実行したコマンドと結果を簡潔に示す。修正不要ならその旨を明記する。スキルの実行だけを根拠にコミット・push・PR 投稿を行わない。