AI-knowledgeニュース論文動画Claude Codeコマンド

skills提案 2026-08-16

2026-08-16

以下、蓄積ナレッジ（logs/ 配下の CC Tips 30日分）を読んだうえで、いま最も効く3件に絞りました。共通の軸は「常駐コンテキストを削り、起点と終点だけをスキルで固定する」です。

提案1: 設定棚卸しスキル cc-config-audit（Opus 5 向けに「検証指示」を一斉撤去する）

何が良くなるか

2026-08-01-pGro_uKt-_M.md（Claude Code開発者の話）と 2026-08-01-t1EtbULiF4Q.md が一致して指摘しているのは、CLAUDE.md・スキル・プラグイン・フックは起動時に常駐するコストであり、新モデルが出るたびに棚卸しすべきということです。特に Opus 5 では「作ったら検証して」「自己修正して」という指示が逆効果で、過剰検証のサブエージェントが走ってトークンを溶かします（2026-07-31-8-AntQFFJA4.md「既存スキルは一斉に見直すべき」）。

さらに 2026-08-01-t1EtbULiF4Q.md は重要な穴を指摘しています——/doctor はスキルの「呼び出し部分」しか見ず、中身のトークンは診断しない。つまり /doctor を打つだけでは棚卸しは終わりません。この差分を埋める手順をスキルに固定します。

また 2026-08-01-M6mYodf0dJM.md の「38スキル導入して /context 660トークン」は、descriptionを短くしユーザー起動型にすることで達成されています。自作スキルもこの型に揃えます。

導入手順

mkdir -p ~/.claude/skills/cc-config-audit

~/.claude/skills/cc-config-audit/SKILL.md:

---
name: cc-config-audit
description: 新モデルのリリース後や月次で、CLAUDE.md・スキル・フックの常駐トークンを棚卸ししたいときに使う
---

# 設定棚卸し

ユーザー起動専用。以下を順に実行し、最後に削減量を報告する。

## 1. 基準値の記録
- `/context` の数値をユーザーに実行してもらい、現在の消費量を記録する
- 空セッションでも約3%（システムプロンプト+組み込みツール）は消費される。それ以上が自分の設定分

## 2. `/doctor` を回す
- ユーザーに `/doctor` を実行してもらい、提案は1件ずつ承認させる
- 残す基準: 過去に実際にやらかしたミス、その理由、デフォルトと異なる点
- 消す基準: リポジトリを見れば分かること、汎用ベストプラクティス

## 3. スキル本体のトークン監査（/doctor がカバーしない領域）
- `~/.claude/skills/` と `.claude/skills/` 配下の SKILL.md を読み、以下を報告:
  - 200行を超えるもの → 参照ファイルに分割し「必要なら読め」に変える候補
  - description が長いもの → 短く精密にし、ユーザー起動型に寄せる候補
  - 汎用ベストプラクティスしか書いていないもの → 削除候補

## 4. 検証系指示の撤去（Opus 5 対応）
以下を実行し、ヒットした箇所をユーザーに提示して削除可否を確認する:

    grep -rniE '検証して|確認して修正|自己修正|self-review|verify.*then.*fix|必ずテストを実行' \
      ~/.claude/CLAUDE.md ~/.claude/skills ./CLAUDE.md ./.claude 2>/dev/null

「デフォルトで入っている挙動を明示している」記述は削除。
ただし採点基準つきの明示的レビュー（別コンテキストのサブエージェント起動）は残す。

## 5. 強い制約を判断委譲に書き換える
ルール調の記述は「周囲のコードと同じように読めるコードを書く」のような
判断を委ねる書き方に置き換える候補として提示する

## 6. 差分報告
削った行数と、再度 `/context` を実行した結果を並べて報告する

作った直後に一度回し、/doctor の後で safe mode（自前の CLAUDE.md/スキル/プラグインを全無効化）で普段のタスクを1本流す（2026-08-01-pGro_uKt-_M.md）と、そもそも要らなかった設定が判別できます。

提案2: LEARNINGS.md ループを SessionStart フックで自動化する

何が良くなるか

2026-08-16-ifAt7nkaTww.md の LEARNINGS.md ループが、蓄積系ナレッジの中で最も再現手順が具体的です。「セッション開始時に読む → 終了時に学びを追記 → 週1で刈り込む」。2026-07-31-SHnTh-PkXtE.md の「はまった課題を保存すると次回数分短縮」、2026-08-13-IFLvSQatkx4.md の「その場で直すだけでなく原因になった前提を書き足す」も同じ構造です。

ただし読み込み側を人間の記憶に頼ると必ず腐るので、そこはフックで機械的に強制します（フックは推論と無関係に発火する、2026-07-31-SHnTh-PkXtE.md）。SessionStart フックの標準出力はそのままセッション冒頭のコンテキストに入るため、これは確実に動く経路です。逆に追記側は判断が要るのでユーザー起動スキルに置きます。

なお、あなたの既存運用（logs/ 配下の開発ログ、logs/inbox.md）とは役割を分けてください。開発ログ = 何を決めたか、LEARNINGS.md = Claude 自身の失敗パターンです。混ぜると両方が肥大化します。

導入手順

  1. 読み込み側（プロジェクトの .claude/settings.json）:
{
  "hooks": {
    "SessionStart": [
      {
        "matcher": "startup|clear",
        "hooks": [
          {
            "type": "command",
            "command": "test -f \"$CLAUDE_PROJECT_DIR/logs/LEARNINGS.md\" && head -c 4000 \"$CLAUDE_PROJECT_DIR/logs/LEARNINGS.md\""
          }
        ]
      }
    ]
  }
}

head -c 4000 が事実上の上限になります。ここが溢れたら刈り込みのサインです（設定変更は /update-config に任せても構いません）。

  1. 追記側スキル mkdir -p ~/.claude/skills/tzk-learn、~/.claude/skills/tzk-learn/SKILL.md:
---
name: tzk-learn
description: セッションを閉じる前に、今回の失敗パターンと抜けていた前提を LEARNINGS.md に追記したいときに使う
---

# 学びの追記

このセッションを観察対象として、以下の4点だけを抽出する。推測で埋めない。

1. ユーザーが私の出力を修正した箇所と、その修正の意図
2. 私が知らずに進めたが、実は前提として必要だった情報
3. 既存のスキル/CLAUDE.md がカバーできていなかった状況
4. うまくいったテクニック（次回も再現したいもの）

`logs/LEARNINGS.md` に日付見出しで追記する。1項目1〜2行。
該当なしなら「該当なし」と述べて何も書かない（水増し禁止）。

## 週次の刈り込み
「今週分をマージして」と言われたら:
- 古い項目・すでに設定へ反映済みの項目を削除
- 重複を1行に統合
- 3回以上出てきたパターンは原則に昇格させ、CLAUDE.md への追記案として提示
  1. 月1回の深掘りとして、2026-08-16-ifAt7nkaTww.md のログマイニングを打つ:

このプロジェクトの JSONL 履歴を検索して、CLAUDE.md の改善点を分析して。私がイライラしている箇所と、セッションをまたいで同じ質問をしているパターンを挙げて

提案3: 起点と終点だけを短いスキルで固定する（tzk-grill / tzk-verify）

何が良くなるか

提案1で汎用的な「検証して」を消したうえで、2026-08-08-cehtaE2YCxc.md が言う「実際には検証用サブエージェントを明示起動した方が安定する」を満たすのがこの提案です。両者は矛盾しません——常駐する曖昧な自己検証は消し、採点基準つきの明示的レビュー1本に集約する、が結論です。

起点側の根拠は 2026-08-01--QFHIoCo-Ko.md。「作業の起点は必ずスキル呼び出しにする」「短いスキルほど効く」で、grill me は数行しかありません。plan mode は放っておくと早々にプランを出したがるので、それを抑える役目です。終点側は 2026-08-01-M6mYodf0dJM.md の「自分で書いたコードを自分でレビューさせると自己肯定的になる」＋レビューは2軸（spec の受け入れ基準／コーディング標準、無ければコードスメル基準）、および 2026-08-04-JWhICz1QR8M.md の「執筆者とチェック役を別呼び出しに分ける」。

間の実装フェーズは /clear で切ります（2026-08-01--QFHIoCo-Ko.md「compact は要約という堆積物を残す」、2026-08-01-goOZSXmrYQ4.md の「計画をファイル出力 → クリア → 実行」）。spec がファイルに残っていればクリア後も @ 参照で継続できます。

導入手順

mkdir -p ~/.claude/skills/tzk-grill ~/.claude/skills/tzk-verify

~/.claude/skills/tzk-grill/SKILL.md（短さが本体。増やさない）:

---
name: tzk-grill
description: 実装前に要件を詰めたいときに使う。ブリーフを渡すと合意まで質問を続ける
---

- まだプランを書くな。合意に達するまで容赦なくインタビューせよ
- 決定木の枝を1つずつ解決せよ
- 各質問に推奨回答を添えよ
- 1問ずつ聞け

合意後、`logs/specs/<slug>.md` に出力する。
必ず含める: 問題定義 / 解決方針 / 受け入れ基準 / **変更予定モジュール一覧** / **テスト方針**
出力したら「/clear して実装に入れ」と伝えて終わる。

~/.claude/skills/tzk-verify/SKILL.md:

---
name: tzk-verify
description: 実装が一段落したあと、別コンテキストのサブエージェントに成果物をレビューさせたいときに使う
---

# 検証

サブエージェントを1体だけ起動する。会話の経緯は渡さず、**差分と spec ファイルだけ**を渡す。

サブエージェントへの指示に必ず含める採点軸:
1. `logs/specs/<slug>.md` の受け入れ基準を1つずつ満たしているか（満/未/不明で判定）
2. 二重実装がないか（既存の同等関数を探してから答えること）
3. 破壊的変更の有無（認証・ネットワーク・データ書き込み）

出力は**重大度順**に列挙させる。
1〜3のセキュリティ/認証/破壊的変更に該当する指摘は人間が必ず読む対象として明示する。
「問題なし」と言う場合も、上の3軸それぞれについて何を確認したかを書かせる。

運用は /tzk-grill <ブリーフ> → spec 出力 → /clear → @logs/specs/xxx.md を渡して実装 → /tzk-verify。まずこの1本を安定させてから広げてください（2026-08-11-bcM9dP_uXJU.md「一度に多くのワークフローを作らず、まず1つを安定させる」）。

着手順の推奨: 提案1 →（削れた状態を確認してから）提案2 → 提案3。提案3のスキルを先に足すと、提案1で削るべき対象が増えてしまいます。