Instruction Refactor

---
name: "instruction-refactor"
description: "AGENTS.md・エージェント定義・スキルの肥大化、重複、競合、過剰な発火条件を整理する。指示の監査・改善を求められたとき、または指示編集で具体的な問題を見つけたときに使う。通常のコード整理は対象外。"
argument-hint: "[--scope=user|project|all] [--no-implement] [path]"
---

# Instruction Refactor

指示が必要な場面で届き、無関係な作業を縛らない状態へ整理する。行数削減自体を目的にしない。`/instruction-refactor` の明示指定でも使う。

## 対象と完了条件

親が対象、所有範囲、採否、受入、結果統合を持つ。`--scope=user|project|all` と対象 path は、呼び出し元が提供する情報から解決する。引数を shell の空白分割や glob で再解釈せず、特定 runtime の HOME を推測しない。不正・曖昧な指定は受入に影響するときだけ確認する。

`--no-implement` または監査・提案だけの依頼では、根拠付きの判定を返して終了する。改善を依頼されている場合は、対象内の修正と必要な検証まで進める。範囲外の変更だけ、具体案・影響・受入条件を示して確認する。

## 必要な資料を選ぶ

資料はこの `SKILL.md` の実体ディレクトリから解決し、今回必要なものだけ読む。

| 判断すること | 読む資料 |
|---|---|
| サイズ、frontmatter、runtime の仕様 | [official-criteria.md](references/official-criteria.md) |
| 重複、責務、発火条件、過剰な工程 | [checklist.md](references/checklist.md) の該当観点 |
| 外出し・統合・削除などの改善を適用 | [strategies.md](references/strategies.md) の性能保全ゲートと該当戦略 |

必要な場合だけ評価を read-only 担当へ委譲する。対象版・専有範囲・変更禁止・返却内容・実在確認した専門資料の絶対 path を渡し、担当自身が読む。子へこの親用工程を渡して再起動させない。担当は測定と根拠を返し、対象・report・記憶を保存しない。親が直接評価する場合も同じ専門資料を読む。

独立レビューが必要なら共有 `reviewer` の進行手順を使う。専門評価と結果の意味は、親が実在確認した `code-review-guidance` とその `references/result-contract.md` に従う。

## 調べて判断する

- `rg --files` などで範囲を列挙し、変更前の状態と実際の読者・呼出先を確認する。対象をサイズ超過だけで絞らない。
- サイズ監査では `wc -l` と frontmatter の文字数を測る。同種ファイル中央値の3倍以上は読解優先度の目安とし、欠陥やロード不可と断定しない。
- 通常は依頼と具体的な問題に関係する観点を選ぶ。全検査の依頼なら対象全件の定量・構造・発火条件を確認する。汎用性は明示依頼がある場合、または全検査の対象がユーザースコープの場合に独立に点検する。
- DRY を評価するときは、対象群を横断比較し、字句・意味の重複と固有差分を確認する。単一ファイルの重複整理では通読してクラスタを作る。
- 固有名の混入を疑う場合は実際の利用範囲や履歴と照合し、公開技術名・仮名とプロジェクト固有の前提を区別する。未確認は未確認として残す。

変更前に、対象範囲・観点、問題箇所、根拠、推奨する修正と影響を短く示す。仕様違反、推奨目安、今回の推測を分け、既存の承認を工程ごとに取り直さない。

## 改善して確認する

1. 変更前に `strategies.md` の性能保全ゲートを通す。原本の存在と、消費側が必要なときに読む経路を確認する。
2. 原因と直接関連する差分を適用する。明示された起動方式、必須の安全手順、外部操作の承認境界を保持する。`<!-- CORE -->` で囲まれた保護領域は明示承認なしに変更しない。
3. 重複統合では固有情報の包含を照合する。不要な指示を削る場合は、不要と判断した根拠を残す。参照先を追加するだけで読込経路を失わせない。
4. 実差分、変更した相対参照・metadata・生成物と配布先を確認する。削除した機能・用語が同じファイルの出力欄などに残っていないか検索する。
5. 発火条件を変えた場合は適用例と近接する非適用例、読込を変えた場合は該当モードの参照到達性を確かめる。スクリプト変更は関連する実行確認を行う。追加変更・失敗・未解決の懸念がなければ検証を終える。

結果には判断、変更ファイル、実測した変更前後の行数、実行した確認、未確認と見送り理由を示す。未読範囲や未実行の評価を成功としない。保存・commit・push は依頼と既存の承認範囲に従う。