Instruction Refactor

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

対象と完了条件

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

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

必要な資料を選ぶ

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

判断すること	読む資料
サイズ、frontmatter、runtime の仕様	official-criteria.md
指示・文書・Skill の書き方	instruction-writing.md
承認ポリシーの追加・修正	approval-policy.md
重複、責務、発火条件、過剰な工程	checklist.md の該当観点
外出し・統合・削除などの改善を適用	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 は依頼と既存の承認範囲に従う。