skill-audit: skill 棚卸し
skill 数の増加に伴って org-delegate の work-skill 検索にノイズが増えるのを防ぐため、
定期的ではなく 状態ベースで棚卸しを行う。
skill 数増加そのものよりも「検索面のノイズ」が本丸。
本スキルは 3 つの観点（廃止 / 重複統合 / owner 明記）を機械的にチェックし、
変更提案を窓口 Claude にまとめて送る。自動で skill を削除・変更することはしない。
輸送層（transport）両系 — 既定 broker / opt-in renga: 本ファイル（および各スキル）の peer message・pane 操作は mcp__org-broker__* で書いてあり、ORG_TRANSPORT 無設定＝既定 broker ではそのまま従えばよい。ORG_TRANSPORT=renga（opt-in、切戻し可）では MCP サーバー名が renga-peers になり、完全修飾名が mcp__org-broker__* → mcp__renga-peers__* に機械置換される（引数形・セマンティクスは同一なので操作の論理は変わらない）。輸送依存で手順が変わる差は次の 3 点:
- 受信モデル（既定 = push 一次 =
claude/channel / pull フォールバック）: 既定 broker は push 一次に設計されている（runtime push-first 0.1.24+、設計 SoT は transport-lab docs/design/broker-native-roles.md §9）: 各ペイン同居の channel sidecar（server:org-broker-channel）が broker キューを ~1 秒間隔で claim→push し、notifications/claude/channel で本文を idle セッションへ注入する（「受けたら即応答」契機が生まれる）。ワーカー ack（to_id="worker-{task_id}"）・retro gate ack（to_id="dispatcher"）・ディスパッチャー handover 経路の send_message / check_messages / send_keys / inspect_pane は同じツール名（mcp__org-broker__*）で動く。pull はフォールバック層: sidecar 不在 / unhealthy（heartbeat timeout で delivery_mode=PULL）/ channel 非対応ペイン（codex pull-peer）/ claude.ai login 不在時は、各役割が自身の cadence で能動的に check_messages する（役割別 cadence: worker=ターン境界 / 完了後 bounded /loop・dispatcher=/loop 3m・secretary=ターン冒頭。「ナッジを見たら check_messages」prose は撤回せずこの fallback cadence として読む）。ORG_TRANSPORT=renga（opt-in）では、ワーカー報告・ディスパッチャー応答が <channel source="renga-peers" …> として in-band で push される（renga の in-band push と broker push 一次は同じ即応契機）。契約面は Surface 8 + push-primary amendment で push 一次が ratified 済み（2026-06-15、S3。pull は fallback として retain・renga 不変）。
- spawn 儀式（既定 = folder-trust 承認 + dev-channel sidecar 承認の 2 段）: 子ペイン起動時、既定 broker は
--mcp-config <broker> を注入し Claude Code の folder-trust プロンプトを画面判定で機械承認するのに加えて、push 一次のため channel sidecar を --dangerously-load-development-channels server:org-broker-channel で load し dev-channel 承認プロンプト（spawn-flow 3-3b）を画面判定で機械承認する（folder-trust + dev-channel の 2 段承認。詳細は .dispatcher/references/spawn-flow.md 3-2 / 3-3b、設計は broker-native-roles.md §9.5）。ORG_TRANSPORT=renga（opt-in）では --dangerously-load-development-channels server:renga-peers を注入し「Load development channel?」を画面判定で承認する 1 段。注: attention watcher は transport 非依存の CLI ペインであり、folder-trust / dev-channel いずれの 2 段承認の対象外（spawn 儀式の反転に巻き込まない）。 画面判定 = inspect_pane → claude-org-runtime dispatcher spawn-prompt-step が返した 1 手だけを send_keys する反復（runtime 0.1.43+）。盲目 Enter は禁止（folder-trust の初期カーソルは「No, exit」で、Enter 一発はワーカーを終了させる）。手順は spawn-flow 3-3b。
- エラー分岐（既定 = broker 拡張コード込み）: 既定 broker は shared codes（
pane_not_found / last_pane / invalid-params、Surface 6）に加え broker 固有 [token_invalid] / [session_invalid] / [tool_not_authorized] / [no_backend]（= adapter_unavailable）/ [nudge_failed] / [peer_not_found] / [name_taken] / [unknown_tool] を返しうる（未知コードは default-branch で escalate）。ORG_TRANSPORT=renga 時は broker 固有コードは発生せず shared codes + renga 固有コードのみ。
契約面の正本は docs/contracts/backend-interface-contract.md Surface 8（broker auth & delivery、ratified 2026-06-14）+ 末尾「Ratified amendment (2026-06-15): push-primary delivery」（S3。broker push 一次が既定の契約、pull は structural fallback として retain）、設計 SoT は transport-lab docs/design/broker-native-roles.md §9（push 一次）/ docs/design/ja-migration-plan.md §5・§8。opt-in renga は削除せず常時有効な fallback として維持する（切戻しの安全装置）。broker 実走（dogfood）は Epic #6 Issue G スコープであり、本ファイルの既定運用経路ではない（既定の二フレーム注記（Refs #604）: ここでの「既定 broker」はコード既定フレーム — tools/transport.py: DEFAULT_TRANSPORT が runtime 0.1.28 (Epic #586) で broker にフリップ済みで、ja 生成器・transport.resolve() はこのコードフレームで render するため生成面はこう表示する。別に運用既定フレームがあり、broker 実走 dogfood が Epic #6 Issue G まで未活性のため運用上の既定経路は renga。両フレームは指す対象（コード定数 vs 運用経路）が異なり矛盾しない。総説は root CLAUDE.md「輸送層（transport）両系」節。）
Step 1: 発火条件チェック（状態ベース）
以下をいずれも満たさない場合は 即終了（ログも残さない）。
# 候補キュー pending エントリ数（コードフェンス内のテンプレ例文は数えない）。
# 公開の skill-candidates.md（フォーマット定義のみ・エントリ常に空）と
# machine-local な skill-candidates.local.md（実エントリ）の
# 2 ファイルを CANDIDATE_ENTRY_PATHS と同順で読む。存在するファイルだけを
# 位置パラメータ（set -- / "$@"）に積む: これは bash・zsh・sh いずれでも
# 正しく複数引数へ展開される（未クォートの `$files` は zsh が単語分割せず
# awk に 1 引数として渡してしまい、`2>/dev/null` で fatal を握り潰して
# カウントが空になる — 実ハーネスの shell は zsh のため必須）。ファイルが
# 1 つも無ければ zero-arg awk が stdin でハングするのを避けて 0 を返す。
cand_count=$(set --; for f in knowledge/skill-candidates.md knowledge/skill-candidates.local.md; do [ -f "$f" ] && set -- "$@" "$f"; done; if [ "$#" -gt 0 ]; then awk 'FNR==1 { fence=0 } /^(```|~~~)/ { fence=!fence; next } !fence && /^- \*\*status\*\*: pending[ \t]*$/ { n++ } END { print n+0 }' "$@" 2>/dev/null; else echo 0; fi)
# work-skill 数（org-* は除外。ノイズ源となる work-skill 検索対象に合わせる）
work_skill_count=$(find .claude/skills -maxdepth 2 -name SKILL.md \
| grep -v '/org-' | wc -l)
cand_count >= 5 または work_skill_count >= 20 なら続行- どちらも満たさなければ終了（このとき報告は不要）
閾値と org-* 除外の理由は .claude/skills/skill-audit/references/rationale.md §1。
カウント定義の同期（重要）: 上記 2 つのカウント定義（pending は
^- \*\*status\*\*: pending の行一致 かつコードフェンス外（行頭 ``` /
~~~ で開閉するブロック内は除外）を 2 ファイル
knowledge/skill-candidates.md（公開・
フォーマット定義のみ）+ knowledge/skill-candidates.local.md（machine-local な
実エントリ。gitignore 済み）にわたり合算、work-skill は
find .claude/skills -maxdepth 2 -name SKILL.md | grep -v '/org-'）は、
オンデマンド curator の起動判定
tools/check_curate_threshold.py と
完全一致させること。読む 2 ファイルとその順序は同ファイルの
CANDIDATE_ENTRY_PATHS（Python SoT）と一致させる。pending カウントの
セマンティクスはさらに公開ファイル冒頭の運用ルール記載と合わせた
3 者同期（本 Step 1 / check_curate_threshold.py / skill-candidates.md 冒頭）。
いずれかを変更する場合は 3 箇所同時に更新する（tools/test_check_curate_threshold.py
の parity テストが drift を検出する — awk が読むファイル一覧が
CANDIDATE_ENTRY_PATHS と一致することも検査する）。
deferred（人間が見送った候補）は awk の完全一致から外れるので数えない。見送られた候補を
pending → deferred に更新する手順は .claude/skills/org-retro/SKILL.md Step 4.2 の 4（ワーカー委譲経由）、
status の定義は knowledge/skill-candidates.md「status の遷移」。
Step 2: 廃止候補の洗い出し
各 skill について以下を評価する。現時点で観測可能な項目のみを機械判定に使い、
観測不能な項目は「要確認」として人間判定に委ねる。詳細は references/audit-checklist.md を参照。
観測可能（機械判定に使える）:
- description と
SKILL.md 本文 Step 群の内容に明らかな乖離がある（本文内で完結）
knowledge/curated/ / knowledge/raw/ / .state/workers/ を {skill-name} で grep し、
直近 90 日の言及が 0 件（本プロジェクト内の観測範囲に限る）
観測不能（「要確認」扱い、廃止判定には使えない）:
org-delegate は work-skill を指示に埋め込むだけで「実際に採用されたか」を永続化しない
→ 言及検索は「検索で引っかかった」程度の情報にしかならない
廃止決定はしない。提案リストに載せるだけで、最終判断は人間に委ねる。
audit-checklist.md の 1.1 / 1.2 も同方針で詳細化済み。
Step 3: 重複統合候補の洗い出し
skill ペアを総当たりして以下を確認する:
- description の主題語（動詞・目的語）が重複している
- description 中のトリガ語（発動条件）が重なる
- 片方がもう一方の特殊化であり、パラメータ差し替えで兼用できる
重複の疑いがあるペアは「統合候補」としてリストアップする。
実際の統合判断は人間が行うので、ここでは候補提示のみ。
Step 4: owner 未明記の洗い出し
全 skill の SKILL.md frontmatter を読み、以下を確認する:
owner: または maintainer: フィールドが無い skill- あっても空文字列のもの
これらは「owner 未明記」としてリストアップ。
Step 5: 報告
org-broker の send_message(to_id="secretary", ...) で窓口 Claude に送る。
[skill-audit] 棚卸し結果
- 廃止候補: {n} 件 ({skill-name} 一覧)
- 統合候補: {m} ペア ({skill-a} × {skill-b} 一覧)
- owner 未明記: {k} 件 ({skill-name} 一覧)
発火条件: cand_count={cand_count} / work_skill_count={work_skill_count}
詳細: 判定根拠は本メッセージ末尾の一覧を参照。
人間承認後に削除・統合・owner 追記を実施してください。自動変更はしていません。
候補が 0 件（クリーンな状態）だった場合も報告する: 「棚卸し実行、変更提案なし」。
次回は次の閾値超過まで実行されないので、0 件でも実行した事実を残す意味がある。
トリガー経路
このスキルは自律的に走らない。以下のいずれかで起動する:
org-curate Step 6 で呼び出される（推奨経路）。
ディスパッチャーが worker クローズ時に tools/check_curate_threshold.py を実行し、
reasons[] に skill_candidates_pending / work_skill_count が立つと curator が
一時起動され、org-curate Step 6 が本スキルを発火する- 窓口が
knowledge/skill-candidates.local.md（実エントリ）を見て手動で起動する
- 人間が「棚卸しして」と依頼
/loop などの時間ベース起動はしない。提案までに留め自動変更しない理由とあわせて .claude/skills/skill-audit/references/rationale.md §2。