Claude Codeスキルの棚卸し監査と /make-diary コマンドの分割

Claude Codeに溜め込んだスキルとコマンドが、気づけば約100ファイル（自前73＋プラグイン由来約30）まで積み上がっていた。半年前に書いたdescriptionは古いモデル名を指し、似た名前のスキルが同じ言葉で発火を奪い合っている。今日はこれを全部机に並べさせて、1件ずつ判定を下させることにした。

「監査官」の姿勢で棚卸しさせる

依頼の仕方をひとつだけ工夫した。「整理して」ではなく、こう指示した。

Claudeに溜め込んだSkillを棚卸しし、「どれを・どうすべきか」を判定する。
甘く見ない「監査官」の姿勢で、問題を遠慮なく洗い出すこと。

「監査官」という役割を与えたのは、普通に頼むと「概ね良好です」で流される予感があったからだ。個人スキル29・プロジェクトスキル10・個人コマンド14・プロジェクトコマンド20・プラグイン由来約30の全ファイルを実物で読ませ、参照パスの実在まで検証させた。サブエージェントの報告を待つ間に、疑わしい衝突は本体側でも直接検証させる二段構えで進んだ。

結果、深刻な問題が7件出てきた。

• 壊れている: 1件。SKILL.md自体が存在せず、機能していないスキルがあった
• 二重定義: 2件。個人コマンドとプラグインで実質同一の定義が両方有効になっていた
• 陳腐化: 4件。存在しないスキル名への参照、旧モデル名（GPT-5.2表記）、現運用と矛盾する「git push=Auto deploy」の記述など
• トリガー衝突: 3組。「まとめて」「要約して」で summarize-meeting と summarization-technique が奪い合う、図解指示で drawio と svg-diagram が競合する、など
• 肥大化: /make-diary（816行）を筆頭に数件

全スキルに発火精度の採点（10点満点）を付けさせたのも効いた。7点未満には書き換え案がセットで付く。結果は memo/2026-07-02/skill-audit.md に保存させた。

修正計画を別ファイルに落とす

監査結果を見て、修正計画を別に作ってもらうことにした。最初はHTMLに落とすか迷ったが、監査memoがすでにマークダウンで根拠・採点・書き換え案まで揃っていたので、マークダウンのまま進めることにした。監査memoは「根拠置き場」としてそのまま残し、実行用の修正計画を skill-audit-fix-plan.md としてチェックボックス管理で切り出す構成だ。

計画の方針は非破壊優先。削除はすべて ~/.claude/backup/ への移動で行い、いつでも復元できるようにした。計画はCodexにもレビューさせ、致命的指摘3件のうち1件（二重定義の根本原因であるプラグインの処遇を先に決めるべき）を Phase 0 として計画に足した。

Phase 0〜5-1 を順次実行

計画に沿って修正を流した。プラグイン無効化、壊れ・二重定義の3件退避、description書き換え7件、プロジェクトスキル2件の作り直し。descriptionの書き換えは監査memoの案をそのまま使えたので、判断で止まる場面がほとんどなかった。

途中で拾いものが2つあった。

ひとつは監査エージェントの誤報告。「参照先ファイルが欠落している」と報告されたissueファイルが、確認したら .claude/issues/ に実在していた。報告を鵜呑みにして消していたら実在ファイルへの参照を壊すところだった。修正実行の前に参照先の実在を自分の目（＝メインセッションのツール実行）で確かめる工程を挟んでいたのが効いた。

もうひとつは編集の空振り。372行のコマンドを分割する際、Editの置換対象文字列が一致せず止まった。該当箇所を読み直させて正確な文字列を取得してから再実行、という素朴なリカバリで通過した。

ここまでで残るは大物の /make-diary 分割だけ。毎朝のパイプラインを壊すリスクがあるため、計画どおり別セッションに回した。

/make-diary は「動いているのに直す」価値があるか

816行の /make-diary について、正直「今動いているんだから、そのままでもいいかな」と思っていた。そこで修正内容を説明させたら、納得のいく答えが返ってきた。

816行の大部分はチェーン先コマンドの説明の写しだった。Step 9 は /check-earnings を呼ぶだけなのに、check-earnings.md 本体の手順をほぼ丸ごと再掲している。台湾売上・韓国輸出・ポートフォリオ更新のステップも同じ構造で、コミット手順も /commit と重複していた。つまり本体を直すたびに写しが古くなる構造そのものが陳腐化の温床だった。動作は一切変えず書き方だけ痩せさせるリファクタだと分かったので、GOを出した。引き継ぎ用のプロンプトを1行もらい、次のセッションにそのまま貼った。

分割リファクタの実行

別セッションでの作業は次の順で進んだ。

1. 旧版を .claude/backup/make-diary-2026-07-02.md にバックアップ
2. チェーン先の check-earnings.md / update-ticker-quarter.md / commit.md を読ませて重複箇所を特定
3. 固有テンプレ・詳細手順を .claude/references/make-diary/ に3本切り出し
4. 本体をチェーン先参照方式に書き換え

新設した参照ファイルは3本。

.claude/references/make-diary/
├── subagent-prompt.md        # 記事生成サブエージェントへの指示文
├── diary-template.md         # 統合日記のテンプレート
└── beat-monitoring-chain.md  # 決算チェーン（Step 9以降）の詳細手順

結果、816行 → 356行。半分以下になった。

検証は二重にかけた。見出し構成と重要トークン58個の機械チェックに加えて、独立のエージェントに新旧を意味レベルで照合させた。判定は「実運用が壊れる欠落・矛盾なし」。それでも旧版は消さない。次回の /make-diary が正常に走るのを確認するまで backup に置いたままにして、修正計画には復旧手順を1行書き足した。

不具合時: cp .claude/backup/make-diary-2026-07-02.md .claude/commands/make-diary.md

明日の朝、いつもどおり日記が生成されたら旧版を消す。

学び

• 「監査官」の役割指定は棚卸しに効く。甘い自己評価を封じて、削除・作り直しの判定まで踏み込ませられる
• 監査（根拠）と修正計画（実行）はファイルを分ける。監査memoにチェックボックスを混ぜると、根拠の読み物として腐る
• サブエージェントの「欠落」報告は実在確認してから消す。今日も1件、実在ファイルが「欠落」と誤報告された
• コマンドの肥大化はチェーン先の説明を写すことから始まる。呼ぶだけのステップは1行参照に留め、正はチェーン先に置く
• 動いているものを直すときは、旧版バックアップ＋復旧手順1行＋実運用での動作確認をワンセットにする。検証で「矛盾なし」が出ても、本番1回が通るまで退路を残す

明日やること

• 朝の /make-diary を通常どおり実行し、分割後の356行版で日記が最後まで生成されるか確認する
• 正常に走ったら .claude/backup/make-diary-2026-07-02.md を削除する
• 途中で止まったら復旧コマンドで旧版に戻し、どのStepで何が欠けたかを修正計画の5-2に追記する