run-toolcall-improve

name	run-toolcall-improve
description	「ハイジーン改善」「notes の教訓を反映して」と言われたとき、または出力崩壊からの復旧が落ち着いて run-toolcall-recover の notes.md に未反映のインシデント記録が溜まっているときに発動。
user-invocable	true
allowed-tools	Bash, Read, Write, Task

run-toolcall-improve — 記録からの自己改善（recover とは分離）

run-toolcall-recover が notes.md に積んだインシデント記録を読み、 繰り返しパターン・新しい検知署名・規律の穴を抽出して本体（SKILL.md / hook）に反映する。

形は orchestrated: メイン文脈が手順1〜5（読込→抽出→委譲→検証→記録）を指揮する。 ファイル編集だけをサブエージェント（Task, general-purpose）に dispatch し、 検証と履歴記録はメインで行う。fork はしない。

分離の理由: 復旧直後の文脈は汚染されている可能性が高く、その場で本体を編集すると 編集自体が脱線・破壊のリスクを持つ。改善は必ずクリーンな文脈で別途起動し、 実際のファイル編集はサブエージェントに委譲してメイン文脈から隔離する。

対象ファイル（これ以外に触れない）

すべてこのプラグイン配下のパス：

• skills/run-toolcall-recover/SKILL.md — 復旧の行動規律
• skills/run-toolcall-recover/notes.md — インシデント記録（読み取りのみ）
• hooks/detect-toolcall-leak.sh — 検知署名・block ロジック
• hooks/test-detect-toolcall-leak.sh — hook の回帰テスト（署名変更時にケース追加）
• skills/run-toolcall-improve/history.md（このスキル内）— 改善履歴（読み取り＋追記）
• この SKILL.md 自身（手順の改善が必要なとき）

変更対象は上記のプラグイン配下ファイルのみ。それ以外には絶対に触れない。

手順

1. 現状把握（メインで読むのはこの4ファイルだけ）

notes.md・recover の SKILL.md・hook・history.md を読み、記録と現行の規律/検知のギャップを見る。 history.md は反映済み事項の台帳。既に反映済みの教訓を二重反映しない。

2. パターン抽出

notes.md の記録を横断して以下を探す：

• 繰り返している症状・原因（2回以上出たら規律 or 検知に昇格候補）
• hook が拾えなかった漏れ署名（新しい壊れ方のトークン・タグ変種）
• 効いた手のうち SKILL.md に未記載のもの
• 誤検知・テスト時の罠（hook のテスト手順に反映すべきもの）

抽出結果が空（既に全部反映済み）なら、何も変更せず終了してよい。無理に変更を作らない。

3. 更新をサブエージェントに委譲

Task tool（subagent_type: general-purpose）に、具体的な編集指示を渡して委譲する。 指示に必ず含めること：

• 対象ファイルの絶対パスと、変更内容（何をどこへ）
• なぜこの教訓を昇格するのか：根拠となる notes.md の該当インシデント（日付・該当箇所）を必ず引用する。これを省くとサブエージェントが目標を見失い、出典のない自己流の編集に脱線する
• 制約: invoke/parameter 等のタグ例示は必ずコードフェンス内に置く／hook の fail-open（jq 不在・transcript 不読時 exit 0）と「クリーンになるまで block し続ける（撤退なし）」の設計を壊さない／コードフェンス除外による誤検知回避を壊さない
• 上記「対象ファイル」以外には触れないこと
• 完了後に変更点の要約を返すこと

4. 検証

サブエージェントの報告を鵜呑みにせず、メインで検証する：

• 変更ファイルを読み直し、意図どおりか確認（SKILL.md は整合性、hook は構文 bash -n）
• 当初抽出した notes.md のインシデントに、変更が実際に対応しているか突合する（手順2で挙げた教訓と委譲結果のズレを出口で潰し、目標ドリフトを閉じる）
• hook を変更した場合は回帰テスト必須（下記）

5. 改善履歴を記録

このスキルの history.md 末尾に「いつ・何を・なぜ更新したか」を1件追記する （次回の手順1で二重反映を防ぐ台帳。notes.md には書かない — あちらは純インシデントログ）。

hook の回帰テスト（テスト時の罠・必読）

既存の回帰テストスクリプト（このプラグインの hooks/test-detect-toolcall-leak.sh）をまず実行する （6パターン: leak/clean/fenced/単独court/文中court/単独タグ）。署名を追加・変更したら このスクリプトにケースを追加してから回す。

合成 transcript は 1行=1JSON の JSONL で作る。過去の誤判定の記録より：

• jq -n は既定で複数行 pretty 出力になり transcript として解析されない → 必ず jq -nc
• コードフェンスをバックスラッシュでエスケープすると実際の素の三連バックティックと変わり sed が一致しない → テストデータは素のバックティックで作る

テスト例（leak ケース。タグ文字列は変数経由で組み立てる。$HOOK は検知 hook の絶対パス）：

t=$(mktemp); tag='<invoke name="X"><parameter name="y">1</parameter></invoke>'
jq -nc --arg s "court $tag" '{type:"assistant",message:{content:[{type:"text",text:$s}]}}' > "$t"
echo "{\"transcript_path\":\"$t\"}" | "$HOOK"
# 期待: {"decision":"block",...} が出力される。clean/fenced ケースでは何も出力されない。

Gotchas

• これは delegate でも assign でもない。委譲先は契約を負う内部役（generator/evaluator）ではなく、編集を汚染文脈から隔離するための汎用 subagent にすぎない。指揮・抽出・検証・記録はすべてメイン文脈が持つ orchestrated な run-* スキルであり、prefix を delegate-* / assign-* に揺らさない。
• このスキル自身の地の文にもタグを生で書かない。例示は常にコードフェンス内。
• 検知は積極的でよい（通常出力に court/invoke 系タグはまず出ない）。ただし署名追加時は fenced 除外との相互作用を必ずテストする。
• hook は「表示前」やターン途中の漏れは捕捉できない（Stop はターン末の網）。この限界を「直す」方向の変更は提案しない — 記録済みの設計上の確定事項（examples/notes.md 2026-06-10）。

Files in this skill

• history.md — 改善履歴の台帳（いつ・何を・なぜ反映したか）。手順1で読み、手順5で追記する

Additional resources

• 復旧スキル: 同梱の run-toolcall-recover（その場の復旧と notes.md 記録）
• 検知 hook: このプラグインの hooks/detect-toolcall-leak.sh