skills提案 2026-08-02

2026-08-02

前提: このナレッジをどう読んだか

30日分のナレッジは、モデル論・ツール紹介の差はあれど「常時ロードされるコンテキストを削り、たまにしか要らない手順はスキルへ逃がす」「モデル/エフォートを役割で分ける」「体感ではなく失敗しうる基準（eval）で判定する」の3点に収束していた。以下はその3点を、いまの ~/.claude/ と AI-knowledge パイプラインに当てはめた提案。

提案1: グローバル CLAUDE.md の開発ログ規約を `write-devlog` スキルへ退避する

何が良くなるか

現在 ~/.claude/CLAUDE.md には「開発ログ運用ルール」（frontmatter の型、本文の見出し、バックテスト記録の追加ルール、インボックス、週次レビュー）が約100行入っており、全プロジェクト・全セッションの起動時に無条件でロードされている。しかしこの内容が実際に必要なのは「ログを書いて」と言われた瞬間だけで、通常のコーディングセッションでは1行も使わない。

2026-08-01-pGro_uKt-_M（Claude Code開発者本人の解説）が明言している通り、「毎セッション読まれる CLAUDE.md には短く常に真な事だけ。長い・たまにしか要らない手順（例: 成果物の検証手順）はスキルにし、CLAUDE.md からは『必要なら読め』と参照させる」が正しい構成。いまのログ規約はこの「たまにしか要らない長い手順」の典型。
2026-08-01--QFHIoCo-Ko（Matt Pocock）も 「CLAUDE.md やシステムプロンプト常駐部分を極小に保つ。ここが膨らむと、作業を始める前からダムゾーンに入る」 と同じ結論。
2026-07-31-8-AntQFFJA4 の「CLAUDE.md は 200行でも長い」、2026-08-01-vp6Dlx5aHDU の「CLAUDE.md は常時注入される高価な領域」も同方向。
さらに 2026-08-01-M6mYodf0dJM によれば、スキルを user invoked（ユーザー起動型） にすれば description すらシステムプロンプトに載らない（38スキルで660トークン）。ログ規約は「ログを書いて」と自分で言うタイミングでしか使わないので、この設計が最も相性が良い。

削減効果は実測すべき（2026-08-01-pGro_uKt-_M の「safe mode で素の性能を測り /context で読み込み量を確認」）が、常駐分がほぼゼロになり、代わりに必要時だけ全文が読まれる。

導入手順

まず現状を計測しておく（前後比較用）。空セッションで:

claude
# セッション内で
/context
/doctor

2026-08-01-pGro_uKt-_M にある通り /context は空セッションでも約3%（システムプロンプト＋組み込みツール）を消費するので、それを超えた分が自分の設定分。/doctor は「Claudeが自力で推論できる内容」を削る方向で提案してくれるので、そのまま承認して構わない。

スキルを作る:

mkdir -p ~/.claude/skills/write-devlog

~/.claude/skills/write-devlog/SKILL.md:

---
name: write-devlog
description: 「ログを書いて」「開発ログを残して」と言われた時、logs/ に規定フォーマットの開発ログを作成する
---

# 開発ログを書く

読み手はAI。人間の可読性より「過去の経緯を辿れること」を優先する。
目的は車輪の再発明と方針のブレの防止。

## 書く前に

`logs/` の既存ログを検索し、関連する project / tags のログを読む。
特に既存ログの「却下・保留」を確認し、過去に却下した選択肢を再提案しない。
`supersedes` で上書きされた古いログの結論を最新として扱わない。

## 置き場所

- 保存先: プロジェクト直下の `logs/`
- ファイル名: `YYYY-MM-DD-project-topic.md`（集約フォルダで衝突しない一意な名前）

## frontmatter（AIが埋める。ユーザーにYAMLを書かせない）

```yaml
---
date: YYYY-MM-DD          # 当日
project: <現在のフォルダ名>
type: conversation        # conversation / analysis / backtest / retro
tags: [キーワード]          # 会話内容から判断
related:                  # 経緯として繋がるログ（拡張子なし）
  - YYYY-MM-DD-project-topic
supersedes: <ファイル名>    # 過去の決定を覆した場合のみ。古いログは消さない
---

取引・バックテスト関連の時のみ追加: vi: strategy:（IC / credit-spread / long-gamma 等）pnl:

本文

## やったこと
（コードの詳細はGitにあるので簡潔に）

## 決定と理由
（理由が肝心）

## 却下・保留
（試したが採用しなかった案とその理由 ← 重複検討を防ぐ核心）

## 次にやること / 未解決

埋められない項目は空でよい。

バックテストを記録する場合

条件・要約指標・解釈・却下理由のみ書く。生の時系列・全トレード履歴は別ファイル（parquet等）にパスで示す。記録は結論が動いた時だけ。

分類の定まらないアイデア

logs/inbox.md に追記する。後の会話で適切なログへ振り分ける。


3. `~/.claude/CLAUDE.md` を、以下の3行だけに置き換える（残りは全部スキルへ移した）:

```markdown
# 開発ログ

開発の経緯・決定は `logs/` 配下の Markdown に残す（読み手はAI）。
ログを書く / 過去の経緯を調べる時は `write-devlog` スキルを読むこと。
分類の定まらないアイデアは `logs/inbox.md` に追記する。

効果測定: 再度 claude を起動して /context を実行し、1 で控えた値と比較する。

注: 2026-07-31-lGFX5eJ7TTw にある「CLAUDE.mdマネジメント」スキルを入れて自動監査させる手もあるが、常駐物を増やす提案なので、まずは手作業でのこの1回の移設を推奨する。

提案2: `claude -p` のモデルを役割で分け、日次パイプラインの枠消費を下げる

何が良くなるか

scripts/lib.py:80 の run_claude() はモデル指定なしで claude -p を呼んでおり、4つの呼び出し全部が同じモデルで走っている（summarize.py:25 動画要約 / collect_news.py:91 ニュース選別 / discover_videos.py:74 発掘採否 / propose_skills.py:38 週次提案）。このうち上3つは 毎日22:00に自動で、字幕全文という長いペイロードに対して、定型フォーマットで出力させる実行部隊タスク。

ナレッジは複数動画で一貫して同じことを言っている:

2026-07-31-twoxdjtgUcc: 「最強モデルは司令塔に置く。設計・レビューを高性能モデルに固定し、実装の実行は Sonnet 5 など安価なモデルに任せる（人材配置と同じ発想）」
2026-07-31-7yst8Ee_lH0: 同様に「賢いが高コストなモデルは設計・プランニングに使い、実装はSonnetのサブエージェントへ」
2026-08-01-vp6Dlx5aHDU: 「/model の切り替えを使う。探索・定型作業と、難しい設計判断とでモデルを使い分けるとコストのバランスが取れる」
2026-08-01-pGro_uKt-_M: 「/usage で5時間枠を何が食っているか特定する」

日次の定型要約を Sonnet 5 に落とし、判断が要る週次の skills 提案（＝この文章を生成しているタスク）だけ上位モデルに残すことで、毎日の枠消費が下がり、日中の対話セッションに枠を回せる。要約品質が落ちた場合は提案3の eval で検知できる。

導入手順

scripts/lib.py の run_claude() にモデル指定を追加する:

def run_claude(instruction, payload="", timeout=600, model=None):
    # Untrusted text (subtitles, web content) flows into this prompt via `payload`.
    # Explicitly disable tool use so a prompt-injection can't get claude -p to act
    # (run Bash, edit/write files, fetch URLs, etc.) instead of just answering.
    cmd = ["claude", "-p", instruction,
           "--disallowedTools", "Bash,Edit,Write,NotebookEdit,WebFetch,WebSearch,Agent,TodoWrite"]
    if model:
        cmd += ["--model", model]
    proc = subprocess.run(cmd, input=payload, capture_output=True, text=True, timeout=timeout)
    if proc.returncode != 0:
        raise RuntimeError("claude failed: %s" % proc.stderr[:500])
    return proc.stdout.strip()

併せて lib.py に役割定数を置く:

# 定型・大量処理は実行部隊モデル、判断が要るものだけ上位モデル
MODEL_WORKER = os.environ.get("AIK_MODEL_WORKER", "claude-sonnet-5")
MODEL_PLANNER = os.environ.get("AIK_MODEL_PLANNER", "claude-opus-5")

呼び出し側4箇所を書き換える:

ファイル:行	タスク	指定
`scripts/summarize.py:25`	動画要約（定型・長文入力）	`model=lib.MODEL_WORKER`
`scripts/collect_news.py:91`	ニュース選別・要約	`model=lib.MODEL_WORKER`
`scripts/discover_videos.py:74`	発掘動画の採否判定	`model=lib.MODEL_WORKER`
`scripts/propose_skills.py:38`	週次 skills 提案（判断もの）	`model=lib.MODEL_PLANNER`

例:

out = lib.extract_json(lib.run_claude(instruction, payload, model=lib.MODEL_WORKER))

手動で1回流して差を見る:

cd ~/GitHub/AI-knowledge
python3 scripts/summarize.py
git diff data/videos/

数日運用したら claude セッション内で /usage を実行し、5時間枠の内訳が改善したか確認する。品質が落ちていると感じたら AIK_MODEL_WORKER を上位に戻すだけで切り戻せる（環境変数で外出ししてあるため）。

補足: 2026-07-31-8-AntQFFJA4 と 2026-07-31-t1EtbULiF4Q は「Opus 5 では『作ったら検証して修正して』という指示を消せ（過剰検証でトークンを浪費する）」と警告しているが、scripts/prompts/*.txt 4本を grep した限り検証系の指示は入っていなかったので、こちらは対応不要。今後プロンプトを書き足す時に混入させないこと。

提案3: プロンプト変更の回帰を検知する `eval-prompts` スキルを作る

何が良くなるか

scripts/prompts/*.txt（video_summary / news_digest / discovery_judge / skills_proposal）は今後も手を入れていく資産だが、現状 tests/ にあるのは Python の単体テストのみで、プロンプトを書き換えた時に出力が劣化したかを判定する手段がない。提案2でモデルを下げるなら尚更、判定基準が要る。

2026-08-01-news（MCP/ツール系ニュース）: 「smevals は、CLAUDE.md やスキルのプロンプトを書き換えた際の効果測定に使える。体感ではなく小さな eval で回帰を検知する」
2026-08-01-pGro_uKt-_M: 「完了条件(eval)を先に書く。『失敗しうる』チェックであることが必須」「evalの賞味期限は2〜3世代。全部パスするようになったら捨てて、今失敗している箇所から新しく作る」
2026-08-01-M6mYodf0dJM: 「自分で書いたコードをメインエージェントにレビューさせると自己肯定的になる。サブエージェントでクリーンなコンテキストからレビューさせると精度が上がる」 → 採点も、プロンプトを書いた本人セッションではなく独立実行にする。

固定の入力フィクスチャに対してプロンプトを流し、観点ごとに合否を出すだけの軽い仕組みで足りる。

導入手順

固定フィクスチャを用意する（実際に良い出力が出た日のものを凍結する）:

cd ~/GitHub/AI-knowledge
mkdir -p tests/evals/fixtures
# 既存の良い要約と、その元になった字幕を1本ずつ置く
cp data/videos/2026-07-31-8-AntQFFJA4.md tests/evals/fixtures/video_summary.expected.md
# 字幕は再取得して保存（リポジトリには入れず .gitignore してもよい）
yt-dlp --write-auto-sub --skip-download --sub-lang ja \
  -o 'tests/evals/fixtures/video_summary.input' \
  'https://www.youtube.com/watch?v=8-AntQFFJA4'

観点（＝失敗しうる完了条件）を書く。tests/evals/criteria/video_summary.md:

# video_summary の合格条件

以下を1つでも満たさなければ FAIL。

1. frontmatter に title / date / type / url / tags が全て存在し、JSON として妥当な値である
2. 本文が箇条書きのみで構成され、地の文の段落がない
3. 各項目が「何をすればよいか」を含む（感想・要約だけの項目は0件であること）
4. 字幕に存在しない固有名詞・コマンド・数値が登場していない（ハルシネーション）
5. 項目数が 5〜15 の範囲
6. 日本語で書かれている

スキルを作る:

mkdir -p ~/.claude/skills/eval-prompts

~/.claude/skills/eval-prompts/SKILL.md:

---
name: eval-prompts
description: AI-knowledge の scripts/prompts/*.txt を書き換えた後、固定フィクスチャで出力の回帰を検知する
---

# プロンプトの回帰チェック

体感で「良くなった気がする」は採用しない。下記を実行し、FAIL が出たら
プロンプトを直すか、基準側が古いなら基準を更新する。どちらを直したかを必ず報告する。

## 手順

1. 変更対象のプロンプト名を確認する（video_summary / news_digest / discovery_judge / skills_proposal）
2. 対応する `tests/evals/fixtures/<name>.input` を入力として、変更後のプロンプトを実行する

   ```bash
   claude -p "$(cat scripts/prompts/<name>.txt)" \
     --disallowedTools "Bash,Edit,Write,NotebookEdit,WebFetch,WebSearch,Agent,TodoWrite" \
     < tests/evals/fixtures/<name>.input > /tmp/eval-<name>.out

採点は必ずサブエージェント（Task）に投げる。自分で書いたプロンプトを自分で採点すると甘くなる。サブエージェントには以下だけを渡す:
- tests/evals/criteria/<name>.md（合格条件）
- /tmp/eval-<name>.out（今回の出力）
- tests/evals/fixtures/<name>.input（ハルシネーション判定用の原文）
出力形式: 条件番号ごとに PASS / FAIL と、FAIL の場合は該当箇所の引用。最後に総合判定を1行。

基準の寿命

全条件が安定して PASS するようになったら、その criteria は役目を終えている。いま失敗している観点に書き換える。パスするだけの eval は残さない。


4. 使い方: プロンプトを編集したセッションで `/eval-prompts` を呼ぶ。提案2のモデル変更を入れる時も、変更前後で1回ずつ回して比較する。

> `2026-08-01-M6mYodf0dJM` の「description を短く精密にし、ユーザー起動型にする」に従い、上の2スキルとも description は1文に抑えてある。増やしすぎると `2026-08-01-pGro_uKt-_M` が警告する「起動時に常駐する設定」そのものになるので、スキルも定期的に棚卸しすること。

skills提案 2026-08-02

前提: このナレッジをどう読んだか

提案1: グローバル CLAUDE.md の開発ログ規約を write-devlog スキルへ退避する

本文

バックテストを記録する場合

分類の定まらないアイデア

提案2: claude -p のモデルを役割で分け、日次パイプラインの枠消費を下げる

提案3: プロンプト変更の回帰を検知する eval-prompts スキルを作る

基準の寿命

提案1: グローバル CLAUDE.md の開発ログ規約を `write-devlog` スキルへ退避する

提案2: `claude -p` のモデルを役割で分け、日次パイプラインの枠消費を下げる

提案3: プロンプト変更の回帰を検知する `eval-prompts` スキルを作る