[paveg]

概要

Anthropic の context engineering 記事（Claude 5 世代向けに Claude Code のシステムプロンプトを 80% 削減した話）の観点で dot_claude/rules/ 18 本と dot_claude/skills/ 21 本を点検し、重複と衝突を解消した。あわせて、同じ点検を次回から計測ベースで回せるように context-diet スキルを新設する。

監査の全記録は .ai/rules-skills-context-audit.md（git 管理外）にある。

何を直したか

指示の衝突

サブエージェントの委譲方針が 4 系統で食い違っていた。global CLAUDE.md「非自明なタスクでは毎回 codex-subagent」、workflow.md「subagent を積極的に」、ハーネス既定「要求がない限り AgentTool を呼ぶな」、メモリ「spawn は 1 万トークンの固定費」。記事が指摘する「同一リクエスト内で矛盾が衝突する」典型で、実行のたびに黙って解決する必要があった。

判断基準を workflow.md の Subagent Strategy に集約し、global CLAUDE.md の絶対命令を落とした。委譲するかどうかは起動固定費と inline の履歴増分を比較して決める、という書き方に変えている。

重複

chezmoi init --dry-run の罠が root CLAUDE.md / .claude/rules/chezmoi-templates.md / 永続メモリの 3 箇所に別文面で存在し、3 つとも同時にコンテキストへ載っていた。root CLAUDE.md に一本化し、chezmoi execute-template の記述だけ救出したうえで残り 2 つを削除した。

skill のコンテキスト効率

skill の本文は invoke 時のみ課金され、description は常にスキル一覧に載る。つまり常時コストは description 側にある。上位 6 本を圧縮し、手順の説明を本文へ移した。

skill	description before	after
pentest-parallel-prs	851	305
claude-md-layout	602	285
japanese-ai-writing-proofreader	522	346
pr-monitor	512	316
empirical-prompt-tuning	443	348
technical-writing	395	361

本文が長く references/ を持たなかった 2 本を分割した。empirical-prompt-tuning 302→169 行、pentest-parallel-prs 290→230 行。

分割中に、pentest の PR 作成手順が heredoc を指示していて gh-pr-body.md ルール（--body-file を使え）と矛盾していたので合わせて修正した。

pr-size.md が personal 機に届いていなかった

.chezmoiignore の除外は {{ if not .business_use }} の中にあり、PR size ルールは business 機だけに配る設計だった。ところが personal 機の ~/.claude/rules/pr-size.md には 4/26 時点のファイルが残っていた。chezmoi は ignore 対象になったファイルを削除せず管理から外すだけなので、22 行の旧版が孤児として残り、alwaysApply: true（Claude Code のスキーマには存在しない Cursor のキー）ごと毎セッション読み込まれ続けていた。

#171「always-loaded pruning」で 6 行に圧縮したのに自分のマシンでは一度もロードされない状態だったので、除外を解いて personal にも配ることにした。孤児は削除済みなので、次の chezmoi apply で圧縮版が入る。常時ロードは約 700 文字から 358 文字になる。

settings

switchModelsOnFlag: false を追加。safeguards がメッセージをフラグしたとき、黙って別モデルへ切り替える代わりにセッションを停止する。workflow.md のモデル tier 規律が気づかないうちに崩れるのを防ぐため。

effortLevel は検討のうえ不採用とした。バイナリのモデルカタログでは Opus 5 / Sonnet 5 / Fable 5 / Opus 4.8 の default_effort がいずれも high、フォールバックも ?? "high" なので、"high" を書いても現行モデルでは何も変わらない。唯一効くのは default_effort が xhigh の Opus 4.7 で、そこでは格下げとして作用する。未設定＝モデル既定追従が最適と判断した。

新設: context-diet スキル

コストは目標、挙動は制約。コンテキストコストを「いつ支払うか」で 3 分類し、計測してから削る。削減と同時に品質を守るため、行を触る前に「これはどの失敗を防いでいたのか」を言語化する工程を置いた。言語化できなければ cargo cult なので削ってよく、できたならその一文が回帰テストのケースになる。

最大の落とし穴は progressive disclosure 自身にある。誰も読まない references/ は、計測上は削減として記録される削除で、数字の上では改善に見える。そのため 4 つの逃がし方を「ハーネスが決める決定的な機構（paths: / hook 注入）」と「モデルが決める機構（references/ / skill 化）」に分け、トリガーが glob かツール呼び出しで書けるなら前者を選べとしている。

検証は generator-evaluator 分離に従う。削った本人は判定者として不適格なので、差分ではなく挙動をテストし、評価者は別に立てる。

flowchart LR
  A[always-on<br/>paths: なしの rule<br/>skill description<br/>CLAUDE.md] -->|毎ターン| P[コンテキスト]
  B[on-invoke<br/>SKILL.md 本文] -->|skill 発火時| P
  C[on-demand<br/>references/ / scripts/<br/>paths: 付き rule<br/>hook 注入 rule] -->|到達時のみ| P

Loading

scripts/measure.py が 3 クラスの文字数を出す。テストは tests/skills/context-diet/run-tests.sh に 8 アサーション、just test-skill-scripts へ配線済み。folded YAML（>-）の description を正しく畳めるかが要点で、この repo の skill は全部この記法を使っている。

レビューの観点

• dot_claude/rules/workflow.md — 委譲の判断基準が「常に委譲せよ」にも「常に inline」にも読めないか
• dot_claude/skills/context-diet/scripts/measure.py — frontmatter パーサが | / >- / プレーンスカラーを取り違えていないか
• CLAUDE.md — chezmoi 罠の記述が、削除した 2 箇所の情報を落とさず吸収できているか

計測結果

クラス	before	after	差
always-on	32,617	32,507	−110
on-invoke	125,570	121,238	−4,332
on-demand	75,755	89,000	+13,245

always-on がほぼ横ばいなのは、description で 1,364 減らした一方、委譲方針の集約で workflow.md が 980 増え、新設スキルの description が 274 増えたため。差引 −110 で計算は合う。

積み残し

計測で判明した最大の常時コストは workflow.md 単独の 7,154 文字で、always-on 全体の 22% を占める。skill の description 21 本の合計とほぼ同量。中身の大半は実装フェーズに入ってから読めば足りる手順なので、skill 化か paths: 付与で 2 割落とせる見込みだが、今回は逆に 980 文字増やしているため次回にまとめる。

検証

• just test 全通過（lint / zsh header lint / fmt-check / hook テスト 6 件 / skill script テスト 17 件）
• chezmoi execute-template < dot_claude/settings.json.tmpl が valid JSON を出力することを確認
• context-diet は TDD で作成。RED（スクリプト未作成で 8 件失敗）→ 実装 → GREEN を確認済み

🤖 Generated with Claude Code

[changeset-bot]

⚠️ No Changeset found

Latest commit: 43d96af

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR