ce-simplify-code

コードの振る舞いを厳密に維持しながら、明瞭さ、再利用性、品質、効率性を高めるためにコードを簡素化し、価値のないテストやコメントを削除してください。コンパクトさよりも、読みやすく明示的なコードを優先してください。行数を減らすことが目的ではありません。

モード

入力から mode:pipeline トークンとすべての proof-test:<path> トークンを取り除いてから、残りを対象範囲として読み取ってください。proof-test のパスはステップ 3 のためのコンテキストであり、対象範囲ではありません。呼び出し元が複数指定する場合もあります。

• パイプライン：mode:pipeline が含まれている場合、または今回の実行をユーザーが現在のメッセージで依頼していない場合。別のスキルの一工程、または完了時点などにエージェント自身が開始した実行が該当します。現在の作業のみを対象とし、質問したり返答を待ったりせずに修正を適用して、ステップ 5 の要約を呼び出し元に返してください。この要約は呼び出し元の記録用です。コミット、PR の本文、その他の成果物に貼り付けないでください。
• スタンドアロン：ユーザーが現在のメッセージで今回の実行を依頼した場合。依頼内容が対象範囲と重点を定めます。依頼に「指摘を修正するだけ」と書かれていない限り、編集を始める前に指摘事項を報告してください。references/standalone-report.md を今読み、報告した指摘事項を適用する前にも再度読んでください。

ステップ 1：対象範囲の特定

次の順に対象範囲を確定してください。

1. ユーザーが指定した範囲を最優先とし、広げないでください。スタンドアロンモードでは、リポジトリ全体、特定の領域、またはパスを指定できます。
2. それ以外の場合、Git 管理下では、現在のブランチとそのベースとの差分を使用します。使用可能なベースがない場合は、ステージ済みと未ステージの変更（git diff HEAD）を使用してください。
3. Git 管理下でない場合、または差分がない場合は、ユーザーが指定したファイル、または会話の前の段階で編集されたファイルを使用してください。

パイプラインモードでは、呼び出し元が指定した範囲があればそれを使用し、なければブランチの差分を使用します。その範囲内で、現在の作業によって追加または変更されたテストとコメントのみを削除してください。

上記のいずれでも対象範囲が空の場合、パイプラインモードでは「簡素化するものはありません」と報告して終了します。スタンドアロンモードでは、references/standalone-report.md の説明に従って、何を簡素化するかユーザーに尋ねてください。

事前確認。 対象範囲に人が作成した実質的なコードがなく、ドキュメント、生成ファイル、ベンダー提供ファイル、依存関係やロックファイル、または機械的な変更のみの場合は、簡素化するものはないと報告し、レビュアーに確認せずに終了してください。コードとそれ以外が混在する範囲では、コードとそのテストのみを対象として残してください。この確認では変更の種類を考慮し、規模は考慮しません。小さく明示的に指定された範囲でも実行し、規模やコストのしきい値は呼び出し元が設定します。

プラットフォームのタスク追跡機能が利用できる場合は、レビュアーごとにタスクを作成せずに、レビュー、適用、検証の結果を表示してください。利用できない場合は、チャット上でタスクリストを模擬せずに続行してください。

Step 2: レビューエージェントを並行して起動する

利用できる場合は、プラットフォームのサブエージェント機能（Claude Code の Agent／Task、Codex の spawn_agent）を使って汎用サブエージェントを起動します。それ以外の場合は、レビューをインラインまたは順次実行します。レビュー担当者ごとに、このスキルのディレクトリからプロンプトアセットを読み込み、解決済みのスコープ（差分全体またはファイル一式）、モード、証明テスト、ユーザーの制約、スコープに適用されるプロジェクト標準（またはそのファイルパス）とともに、ファイルの全文をサブエージェントのプロンプトとして渡します。

• references/personas/code-reuse-reviewer.md
• references/personas/code-quality-reviewer.md
• references/personas/efficiency-reviewer.md
• スコープにテストが含まれる場合は references/personas/test-value-reviewer.md
• スコープにコメントが含まれる場合は references/personas/comment-reviewer.md

テストのみ、またはコメントのみを対象とする単独の依頼では、該当するレビュー担当者のみを実行します。

レビューを開始する前に references/reviewer-dispatch.md を読みます。このファイルには、完全なハーネス、レビューエージェントの解放、権限モードに関する説明があります。

モデルの選択。 現在のハーネスで既知のオーバーライドが利用できる場合は、これらのレビュー担当者にプラットフォームのバランスの取れた中位モデルを使用します。Claude Code では Sonnet クラスです。Codex では、アクティブなディスパッチ機能でモデルまたはカスタムエージェントを明示的に選択できる場合に限り、このモデル階層を適用します。タスクの指示だけでは別のモデルは選択されません。それ以外の場合はオーバーライドを省略し、親モデルを継承します。動作しないディスパッチより、親モデルでレビューを実行する方が適切です。

ユーザーまたはプロジェクトのアクティブな指示、あるいは現在のプロンプトで、このサブエージェントに使用するモデルが指定されている場合は、上記の既定の階層ではなく、そのモデルを使用します。指定方法は、サブエージェントのモデル階層、プロンプトアセット名、または起動するサブエージェントを示すものです。そのような指示がない場合は、このサブエージェントの役割に設定されたモデルを、上記の既定の階層より優先します。

Step 3: 問題を修正する

サブエージェントからの返答、またはインラインでのレビュー結果を問わず、すべてのレビュー結果が揃ってから作業を進めます。単独モードでは、依頼に修正のみを行うよう記載されていない限り、問題を報告してここで終了します。それ以外の場合は、有益な指摘を直接反映し、誤検知や価値の低い指摘は、ユーザーに確認せずに対応を見送ったものとして記録します。

指摘の評価に必要な場合は、解決済みのスコープ外も調査できますが、編集できるのはそのスコープと、必要なインポート／エクスポート行に限られます。ユーザーがファイルまたはディレクトリを指定したスコープでは、これらのインポート／エクスポート行もその範囲内になければなりません。変更可能な境界の外を編集する必要がある修正は見送ります。

各修正は、出力、エラー、副作用、実行順序を維持しなければなりません。それを確認できない場合は、修正を見送ります。

安全チェックを決して簡略化して取り除かないでください。 信頼境界の検証、データ損失防止、セキュリティチェック、アクセシビリティ上の配慮を維持します。これらを弱めたり削除したりする指摘は見送ります。

証明テストを保護してください。 パイプラインモードでは、現在の作業の動作を示すために使用した各テストを、そのまま維持します。対象は各 proof-test: パス、またはそれがない場合はセッションの証拠に記載されたテストです。これらを削除、弱体化、改名、移動、統合、書き換えたり、テスト専用コードを削除または改名したりするレビュー担当者の指摘は見送ります。そのテストが対象とする本番コードへの、動作を維持する変更は適用します。どのテストが該当するか判断できない場合は、現在の作業で追加または変更したテストを削除も書き換えもしません。

呼び出し元から渡された構造上の固定事項を尊重してください。 構造固定の制約とともに渡されたプランのパスはコンテキストであり、スコープではありません。その session-settled: の技術的決定事項を維持します。意図的な重複や分離も保持してください。

ステップ 4：動作が維持されていることを確認する

プロジェクト全体の型チェックとリンターを実行します。影響範囲に応じたテストを実行します。ローカルな変更には対象を絞ったテスト、共有部分や広範囲に影響する変更にはより広い範囲のテストを実行し、テストランナーで対象を絞れない場合は全テストを実行します。

失敗があった場合は、チェック名と関連する出力を報告します。単純化によって生じた失敗は修正するか、原因となった変更を元に戻します。チェックに合格するためにテストを弱めたり、削除したりしてはいけません。テストを削除できるのは、テストの価値に関する判断による場合のみです。その判断で名前が挙がった残りのテストは、その後もすべて合格する必要があります。

テストスイート、リンター、型チェックのいずれも設定されていない場合は、要約でその旨を明記します。確認を黙って省略してはいけません。

ステップ 5：要約する

既に適切だった点と改善した点を要約します。再利用性、品質、効率、テスト、コメントごとに適用件数を報告し、スキップした件数、チェック結果、制約をコード化できなかったために残したコメントがあれば、その旨を報告します。変更がなかった場合は、その旨を伝えます。削除した行数の純減を成功の指標にしてはいけません。パイプラインモードでは、この要約でスキルは終了しますが、ターンは終了しません。呼び出し元の次のステップは、この要約の後に続きます。