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

skills提案 2026-08-30

2026-08-30

提案1: LEARNINGS.mdループでCLAUDE.mdを自己成長させる

何が良くなるか CLAUDE.mdは一度書いたら陳腐化しがちですが、ifAt7nkaTwwが紹介する「セッション終了時に学び・失敗・修正点を追記→週1回で整理」というループを仕組み化すると、使うほど精度が上がる設定ファイルになります。t1EtbULiF4Qや82_9N72SOekが指摘する「CLAUDE.mdは200行程度に軽量に保つ」という原則とも相性が良く、肥大化ではなく「入れ替え」で鮮度を保てます。pGro_uKt-_Mの「巨大な自動ワークフローより、日常はroutines/hookで積み上げる方が実用的」という助言にも沿った運用です。

導入手順

  1. プロジェクト直下にファイルを作成:
touch LEARNINGS.md
  1. CLAUDE.mdに以下を追記(ifAt7nkaTwwの運用をそのまま採用):
## LEARNINGS運用
- セッション開始時に LEARNINGS.md を読み、要約して「処理済み」と示すこと
- セッション終了前に、このセッションの新しい学び・失敗・要調整点を LEARNINGS.md に追記すること
  1. .claude/settings.jsonにSessionStartフックを追加し、内容を毎回コンテキストへ自動注入する:
{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          { "type": "command", "command": "cat LEARNINGS.md 2>/dev/null || true" }
        ]
      }
    ]
  }
}
  1. 週1回、次のプロンプトを実行して棚卸しする(ifAt7nkaTww):
LEARNINGS.mdの古い項目を削除・重複マージ・原則として統合して整理して
  1. 月1回程度、/doctorを実行してCLAUDE.md/スキル側の無駄な指示も合わせて診断する(82_9N72SOek, t1EtbULiF4Q, pGro_uKt-_M)。

提案2: 実装前に要件を詰める「grill-me」スキルの導入

何が良くなるか -QFHIoCo-Ko・M6mYodf0dJM・DjXZYBhj1W8・Evh_xAfqZU8と複数のナレッジが独立に言及しており再現性が高いテクニックです。「plan modeは放っておくと早々にプランを出したがる」(-QFHIoCo-Ko)ため、明示的に「まだプランを書くな、質問を続けろ」と縛るスキルを挟むことで、曖昧な指示のまま実装が進む事故を防げます。DjXZYBhj1W8では要件定義フェーズにこそ高性能構成(Fable 5 + 高エフォート)を割き、実装フェーズは通常構成でよいとしており、「上流に投資する」設計思想の入口になります。

導入手順

  1. スキル用ディレクトリを作成:
mkdir -p .claude/skills/grill-me
  1. .claude/skills/grill-me/SKILL.mdを以下の内容で作成(-QFHIoCo-Koの骨子を反映):
---
name: grill-me
description: 実装に入る前に要件を詰めるための壁打ちスキル。ユーザーが機能追加・仕様変更・新規プロジェクトなどのブリーフを渡してきた時に使う。単純な修正依頼や既に仕様が明確なタスクには使わない。
---

# grill-me

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

- 決定木の枝を1つずつ解決せよ(複数の論点を同時に聞かない)
- 各質問には推奨回答(デフォルト案)を添えよ
- 1問ずつ聞け。まとめて質問しない
- 十分な合意が取れるまで実装計画(プラン)を書き始めるな
- 合意が取れたら、変更予定モジュール一覧とテスト方針を含むPRDをファイルに出力して終了する
  1. 呼び出し方は/grill-me <ブリーフ>のように自然言語のブリーフを渡す運用にする(-QFHIoCo-Ko)。
  2. PRDが出力されたら/clearしてから実装フェーズに入り、実装時の入力はPRDファイル1つに絞る(goOZSXmrYQ4, M6mYodf0dJM)。

提案3: 検証指示の棚卸し+レビュー専用サブエージェントへの分離

何が良くなるか 8-AntQFFJA4・t1EtbULiF4Q・82_9N72SOekはいずれも「Opus 5系モデルはデフォルトで自己検証・自己修正するため、スキルやCLAUDE.mdに『確認して』『検証して』『自己修正して』と書くと、サブエージェントによる過剰検証が走ってトークンを大量消費する」と指摘しています。一方でcehtaE2YCxc・M6mYodf0dJM・TAcCfKXEfjo・8VNLFKCQFa8は「自己採点は甘くなるので、検証だけは別コンテキストのサブエージェントに切り出すべき」とも述べており、矛盾するようで実は役割分担の話です。インラインの検証指示は削り、検証は明示的に別エージェントへ委譲する、という形に既存スキルを整理すると、無駄なトークン消費を抑えつつレビュー精度は落ちません。

導入手順

  1. 既存スキル群に冗長な検証指示が残っていないかグレップで洗い出す:
grep -rn "確認して\|検証して\|見直して\|自己修正" .claude/skills/ CLAUDE.md
  1. ヒットした箇所のうち、単なる「最後にチェックして」的な念押しは削除する(82_9N72SOek: 「書くとかえって時間とトークンの無駄になる」)。
  2. 品質を担保したい工程だけ、具体的な評価基準を持つ検証専用エージェントに置き換える。.claude/agents/reviewer.mdを新規作成:
---
name: reviewer
description: 実装完了後のコードレビュー専任。元のspec/PRDとの受け入れ基準の突き合わせと、リポジトリのコーディング標準(無ければコードスメル基準)との照合を行う。
---

あなたは実装内容を批判的にレビューする専任エージェントです。
自分では実装しません。以下の2軸で具体的な採点ポイントを示して評価してください。
1. 元のPRD/specの受け入れ基準を満たしているか
2. リポジトリのコーディング標準(無ければMartin Fowler的コードスメル基準)に沿っているか
「良い」で終わらせず、指摘は重大度順に列挙すること。
  1. CLAUDE.mdには「検証はサブエージェントに任せる場面と上限だけ」を一文で明記し、細かい手順は書かない(8-AntQFFJA4):
## サブエージェント運用
- コードレビュー・検証フェーズのみ reviewer サブエージェントを使う。他の場面での多用は避ける。
  1. 整理後は/doctorで残留トークンを再確認する(t1EtbULiF4Q)。