skills提案 2026-08-09

以下、蓄積された30日分のナレッジのうち、複数ソースで繰り返し確認されている論点に絞って3件提案します。

提案1: 設定棚卸しスキル（cc-config-audit）で常駐コンテキストを削る

何が良くなるか

ナレッジで最も繰り返されている主張が「CLAUDE.md・スキル・プラグイン・フックは起動時に常駐するので定期的に捨てろ」です（『Claude Code開発者が語る、AIエージェント活用の最重要ポイント』、『Opus 5を完全解説』、『新モデルOpus 5が予想以上に凄かった』）。特にOpus 5世代では「作ったら検証して修正して」「自己修正して」といった検証系の指示がデフォルト挙動と二重になり、過剰検証でトークンを浪費します。既存スキルは一斉見直しすべき、と明言されています。

現在このアカウントにはsuperpowers一式・dataviz・write-devlog など多数のスキルが入っており、まさに棚卸しの効果が出やすい状態です。棚卸しは一度きりでなくモデル世代ごとに必要なので、手順自体をスキルに固定します。

導入手順

1. ベースラインを計測する。『最重要ポイント』回で示された基準に沿って、素の状態と現状の差を数値で出します。

# 通常起動 → /context で現在の消費を記録
claude
# → /context

# 自前設定を全無効化した状態と比較（空セッションでも約3%は必ず消費される）
claude --safe-mode
# → /context

差が大きいほど自分の設定が食っている分です。safe modeで普段のタスクが問題なく回るなら、削減して構いません。

2. 自動診断を順に流す。役割が違うので3つとも実行します。

• /doctor — CLAUDE.md・プラグインのトークン削減提案（承認制で1件ずつ確認可）
• /checkup — 使っていないスキルなど不要物の整理提案
• /insights — 利用履歴から非効率な使い方とCLAUDE.mdに足すべきルールを提案

3. /doctor が見ないスキル本文を手当てする。『Opus 5が凄かった』回で指摘されている通り、/doctor はスキルの呼び出し部分しか調整しないので、中身は別途指示が必要です。まず検証系の文言を機械的に洗い出します。

grep -rniE "検証して|確認して|自己修正|見直して|verify|double-?check|サブエージェントで.*レビュー" \
  ~/.claude/skills ~/.claude/CLAUDE.md ~/.claude/plugins

ヒットした箇所をClaude Codeに渡して「Opus 5の既定挙動と重複する検証指示を削除して」と指示します。

4. これを再現可能にするため、以下を ~/.claude/skills/cc-config-audit/SKILL.md として保存します。

---
name: cc-config-audit
description: 新モデルリリース後や /context の消費が気になる時に、CLAUDE.md・スキル・プラグインを棚卸ししてコンテキスト常駐分を削る
---

# 設定棚卸し

1. `/context` の値を記録。`claude --safe-mode` 起動時との差が自前設定のコスト（空セッションの下限は約3%）。
2. `/doctor` → `/checkup` → `/insights` を順に実行し、提案を1件ずつ判断する。
3. `~/.claude/skills` と `~/.claude/CLAUDE.md` を読み、以下を削除候補として列挙する:
   - 既定挙動と重複する検証・自己修正の指示
   - 汎用ベストプラクティス（モデルが既に知っている内容）
   - リポジトリを見れば分かる情報（起動コマンド、ディレクトリ構成など）
   - 旧モデルの弱点を補うために書かれた記述
4. 残すのは「短く常に真」なものだけ。過去に実際にやらかしたミス、既定と異なる方針、自分/チーム固有の事情。
5. 長い手順・たまにしか要らない知識はスキルへ逃がし、CLAUDE.md からは参照だけ書く。
6. 削除案は必ず差分として提示し、適用は人間の承認後に行う。

5. 棚卸しを忘れないよう、/schedule で月次実行を登録しておきます（『Rampのエンジニア』回の「巨大ワークフローより routines を積む」方針に沿った軽量な使い方）。

提案2: /prime コマンド + grill-me スキルで、セッションの入口を固定する

何が良くなるか

Matt Pocock回（『完全解説：AIコーディングのワークフロー』『mattpocock/skills』）と『何でも作れる完全版エージェント型コーディング・ワークフロー』が共通して言っているのは、作業の起点を必ずコマンド/スキル呼び出しにすることです。そうするとコンテキストに「スキル＋依頼文」しか載っていない最もクリアな状態で設計判断ができます。

もう一点、/compact は要約という堆積物を残して以後の判断を鈍らせるため、成果物をファイルに書き出してから /clear する、という主張がMatt Pocock回にあります（他の回では /compact を勧めていますが、ここでは理由が明示されている後者を採ります）。この運用の要は「クリア後も参照できるファイルが残っていること」なので、spec/ticketsをファイル化する工程とセットで導入します。

導入手順

1. セッション冒頭用のコマンドを作ります。スキルではなくコマンドにするのは、「自分で起動する定型ワークフローはコマンド、エージェントが自律的に読む知識はスキル」という使い分け（『完全版ワークフロー』回）に従うためです。.claude/commands/prime.md:

---
description: セッション開始時にプロジェクトの現状を把握する
---

以下を実行し、最後にレポートを出力せよ。

1. README と CLAUDE.md、`docs/` 配下の索引を読む
2. ディレクトリ構造を把握する（深さ2まで）
3. `git log --oneline -20` と `git status` を確認する
4. `logs/` の直近の開発ログを新しい順に3件読む

レポート:
- 現状の理解（5行以内）
- 直近の作業で未完了と思われるもの
- 次にやるべきことの候補

追加の指示: $ARGUMENTS

logs/ を読ませる行は、この環境の開発ログ運用（write-devlog）を /prime に接続するためのプロジェクト固有カスタマイズです。『完全版ワークフロー』回でも「汎用テンプレートのまま使い続けず、プロジェクト固有の指示を追記していく」ことが推奨されています。

2. 設計フェーズ用に、~/.claude/skills/grill-me/SKILL.md を作ります。Matt Pocock回の実物は数行だけです。「短いスキルほど効く／長大なフレームワークより自作の小さなスキルの方が制御可能」という主張そのままに、短く保ちます。

---
name: grill-me
description: 実装前に要件を詰める時に使う。ユーザーがブリーフを渡した段階で起動
---

合意に達するまで容赦なくインタビューせよ。

- 決定木の枝を1つずつ解決する
- 各質問には推奨回答を添える
- 1問ずつ聞く（まとめて聞かない）
- まだプランを書くな。質問を続けろ
- 合意できたら `docs/specs/<name>.md` に出力する:
  問題定義 / 解決策 / ユーザーストーリー / 実装上の判断 / **変更予定モジュール一覧** / **テスト方針**

最後の2項目を必須にするのは、仕様だけで完結させずコード側の設計を常に意識させるためです（Matt Pocock回で明示されています）。「まだプランを書くな」の一行は、plan modeが放っておくと早々にプランを出したがるのを抑えるためのものです。

3. 運用の型を固定します。

/prime
/grill-me <やりたいことの2〜3行>     ← ここで対話。specがファイルに落ちる
（specからチケットを切らせ、docs/tickets/ に出力）
/clear                                ← 議論のコンテキストは捨てる
（チケット1件ずつ。入力は @docs/specs/... と @docs/tickets/... だけ）

/clear はセッションの終わりではなく工程の一部として使います。実装フェーズの入力はプランファイル1つだけ、という形にすると、常に同じクリーンな初期状態から始められます。

4. コンテキスト残量を可視化します。Matt Pocock回では約100kを「ダムゾーン」、別回では140kを「スマートゾーンの上限」としており、いずれも境界の手前で作業単位を区切る前提です。statuslineへのトークン数常時表示は update-config スキルに「settings.json のstatusLineでコンテキスト消費量を表示させたい」と依頼して設定させるのが早いです。表示を入れないなら、実装に入る前に /context を打って「残りで足りる作業量か」を判断する習慣にします。

提案3: 採点基準つき adversarial-review スキルで、検証だけを別コンテキストに出す

何が良くなるか

ナレッジには一見矛盾する2つの主張があります。「Opus 5では検証指示を消せ」（『Opus 5を完全解説』）と、「検証サブエージェントを明示的に起動した方が安定する」（『ループエンジニアリング／グラフエンジニアリング』）です。これは切り分けで両立します — CLAUDE.mdやスキル本文に常駐させる「最後に検証して」は消すが、人間が明示的に起動する独立レビューは残す、です。提案1で前者を削るので、後者を受け皿として用意します。

効果の根拠も揃っています。単に「最後に確認して」と言うだけの自己リファインメントは精度向上にほぼ効果がないという研究が紹介されており（『ループエンジニアリング』回）、自分で書いたコードをメインエージェントにレビューさせると自己肯定的になって修正が甘くなる、とMatt Pocock回でも同じ指摘があります。効かせるには (a) 背景コンテキストを持たない別エージェントに渡す、(b) 具体的な採点基準を与える、の2点が必要です。

導入手順

1. ~/.claude/skills/adversarial-review/SKILL.md を作成します。

---
name: adversarial-review
description: 実装が一区切りした時、コミット前に使う。批判役のサブエージェントでレビューさせる
---

# 敵対的レビュー

メインエージェントは自分でレビューしないこと。必ずサブエージェントを起動し、
背景の会話を渡さずに以下の指示だけを与える。

## サブエージェントへの指示

対象: <diff またはファイル一覧>

次の2軸で評価せよ。

1. **仕様との突き合わせ** — `docs/specs/<name>.md` の受け入れ基準を1つずつ引用し、
   満たす / 満たさない / 判断不能 を根拠付きで判定する。
2. **コード品質** — リポジトリのコーディング標準ドキュメントと照合する。
   存在しなければ Martin Fowler 的なコードスメル基準にフォールバックする。
   **二重実装（既存コードと重複する実装）は必ず観点に含めること。**

## 出力形式

重大度順に列挙する。各項目は 該当箇所(file:line) / 問題 / 修正案。

- 重大: セキュリティ・認証・ネットワーク・アプリケーションロジックの破壊的変更
- 中: 仕様の未達、二重実装
- 軽: 命名・可読性

指摘ゼロなら「指摘なし」と書け。無理に項目を作るな。

## レビュー後

結果を `logs/reviews/<date>-<topic>.md` に書き出してから修正に入る。

重大度順の列挙と「重大なものだけ人間が必ず読む」という読み分け、二重実装を明示的に観点へ入れることは、いずれも『CA.ai #3』回で運用フェーズの実感として語られていたものです。結果をファイルに残すのは、各ステップを紙の記録として残すというグラフエンジニアリング回の方針です。

2. モデルを使い分けます。『ループエンジニアリング』回では「作成は軽量モデル、検証は高性能モデル」でコストを抑えつつ精度を確保する構成が紹介されています。レビュー起動時にサブエージェント側のモデルを上位に指定してください。

3. 提案1の棚卸しとセットで実施します。このスキルを入れる代わりに、CLAUDE.mdや他スキルに散っている「最後に検証して」「自己修正して」は削除します。両方残すと二重に検証が走り、Opus 5でトークンを大量消費する構図になります。

4. 定着してきたら、レビュー実行を /loop に載せます。『Rampのエンジニア』回の使い分け — 手順が既知で反復的な作業は loop、未知の探索が必要なタスクだけ dynamic workflow — に従い、レビューは手順が固まっているので loop 側が適切です。