claude-md

/claude-md — CLAUDE.md ファイルの監査と改善

命名に関する例外（文書化済み）： skillforge のチェックリストでは、スキル名に claude または anthropic を含めることが禁止されています。このスキルは、実際の CLAUDE.md ファイルを対象にするため、名前の正確さに価値があるという理由から、意図的に例外としています。このライブラリでは、これを唯一の例外として扱ってください。

1つのスキルに2つのモードがあります。監査は、複数の CLAUDE.md ファイルにまたがる問題を見つけます（衛生状態の確認）。改善は、ベストプラクティスの基準に照らして1つのファイルを書き直します（構造）。どちらも、同じ基本原則に基づいています。

基本原則

削除可能性のテスト：「CLAUDE.md の各行について、次のように問いかけます。この行を削除したら、Claude は間違えるだろうか？ そうでなければ、削除します。」 — Anthropic、Claude Code のベストプラクティス

これが両モードを統一するルールです。監査モードでは、このテストを満たさない行を、乖離／無駄／重複として指摘します。改善モードでは、それらの削除を提案します。同じ診断を、異なる規模で行います。

もう1つ、両モードに共通する不変条件があります。**CLAUDE.md は git で追跡され、リポジトリを開くすべてのエージェントから見える状態にあります。**貼り付けられたシークレットは、長く残る情報漏えいです。両モードとも、シークレット漏えいの検出を P0 の指摘として扱います。

モードの振り分け

呼び出し	モード	実行内容
/claude-md（引数なし、./CLAUDE.md があるプロジェクト内）	自動 → 改善	ローカルの CLAUDE.md を改善します
/claude-md（引数なし、ローカルファイルなし）	自動 → 監査	プロジェクトのルート（例：~/Projects）以下にあるすべての CLAUDE.md ファイルをスキャンします
/claude-md improve [path]	改善	単一ファイルの構造を書き換えます（10項目の基準）
/claude-md audit [project|all|path]	監査	衛生状態をスキャンします：シークレット P0、乖離、重複、予算

両方のモードが適用される場合（例：CLAUDE.md がないフォルダーでの /claude-md improve）、このスキルは確認を求めます。

AGENTS.md にも適用（V2）

AGENTS.md は、エージェント間の標準です（Linux Foundation / Agentic AI Foundation が策定。Codex、Cursor、Gemini、Copilot、および30以上のツールが読み込みます）。ここに記載された基準、シークレットのスキャン、乖離の検出、予算のすべては、AGENTS.md にも同様に適用されます。両方が存在する場合は、両方を監査し、重複を指摘してください。適切なパターンは、単一の信頼できる情報源（AGENTS.md）を用意し、CLAUDE.md は薄いエイリアス／@import とすることであり、乖離する2つのファイルを維持することではありません。モノレポでは AGENTS.md が階層的に配置されるため、リポジトリ内で最も近いスコープの AGENTS.md も同様に扱ってください。

---

改善モード

Anthropic の公式ベストプラクティスと、コミュニティで検証されたガイダンスに照らして1つの CLAUDE.md を評価し、具体的な書き換え差分を提案します。適用するのは、ユーザーの承認後に限ります。

**実証結果に関する注意点が1つあります（Claude Code に特有）。**対象ファイルが短く（100行未満）、すでに Karpathy 形式のルールに沿っている場合、ルールをさらに追加すると Claude Code の品質が低下することがあります。Augment Code は2026年4月、OpenClaw の40件の PR を対象に、Auggie、Claude Code、Codex で Karpathy のルールをテストしました。3つすべてで速度とコストは改善しました（所要時間とツール呼び出しが3%〜8%減少）が、Claude Code の品質は全体で0.07低下しました（正確性 −0.07、完全性 −0.06、コード再利用 −0.05）。Auggie と Codex では変化がありませんでした。同社の仮説では、Claude Code のシステムプロンプトにはすでに同様の制約が含まれており、さらに重ねると探索が制限されます。Claude Code を対象に評価基準で9/10または10/10となった場合、デフォルトでは追加ではなく削減を推奨します。

評価基準

一次資料を根拠とする10項目のチェックです。各推奨事項にはルールを明記しています。

#	ルール	出典
R1	200行未満にする。 長くなるほど指示への遵守度が下がります。	Anthropic — Claudeがプロジェクトを記憶する仕組み
R2	すべての行について削除可能かを検証する。	Anthropic — Claude Codeのベストプラクティス
R3	具体性：検証可能なほど具体的な指示にする。 「シニアエンジニアとして振る舞う」などは不可です。	Anthropic — Memory docs
R4	重要なルールを強調する。 IMPORTANT:／YOU MUST／NEVER。控えめに使ってください。すべてのルールがIMPORTANTなら、どのルールも重要ではなくなります。	Anthropic — Best Practices
R5	Markdownの構成：見出し＋箇条書き。 内容の詰まった段落は避けます。	Anthropic — Memory docs
R6	5つの標準セクションを含める（Commands、Architecture、Rules、Workflow、Out-of-scope）。	コミュニティの合意＋Anthropic /init template
R7	Hard Rulesセクションは15項目以下にする。 それを超えると、ルールが見落とされます。	コミュニティ（zodchiii thread、130万回表示）
R8	3層の階層を正しく使う。 ファイル間では、グローバルルールを~/.claude/CLAUDE.md、プロジェクトルールを./CLAUDE.md（git）、個人ルールを./CLAUDE.local.md（gitignored）に記述します。層をまたいで重複させないでください。1つのファイル内では、優先度順に並べます。最上位には変更不可のルール、中段には状況に応じたルール、下段には参照情報や利便性のための情報を置きます。指示の予算が限られている場合、優先度の低い項目から先に圧縮されます。	Anthropic — Best Practices；Fraser（Medium、2026年5月）
R9	特定のファイルにのみ適用される指示は、.claude/rules/*.mdにパススコープ付きルールとして記述する。	Anthropic — Advanced Patterns PDF
R10	自動メモリが記録する内容や、標準ツールの説明は含めない。 Claudeがpackage.jsonから把握できるスタックの詳細や、すでに知っている標準ツール（git、gh、npm、pnpm、bun、cargo、python、node、tsc、eslint、prettier、make）に行数を費やさないでください。カスタムラッパーや、プロジェクト固有で自明でない呼び出し方法だけを記述します。	コミュニティ＋Anthropic auto-memory docs；Fraser（Medium、2026年5月）

改善モードの手順

Phase I-1：SCOPE

1. 対象ファイルを特定します。候補が複数ある場合は一覧を示して確認します。
2. ファイル全体を読みます。サイズ（行数、文字数）を確認します。
3. 層をまたぐ重複を検出するため、同じ階層にあるファイルを読みます。
   • ~/.claude/CLAUDE.md（プロジェクトファイルを改善する場合）
   • ./CLAUDE.local.md（存在する場合）
   • ./.claude/rules/*.md（パススコープを使用しているか確認）

Phase I-2：MEASURE

可能な範囲で10項目の評価基準をプログラムによって確認します。

LINES=$(wc -l < "$TARGET")                                   # R1
grep -c -iE 'IMPORTANT|YOU MUST|NEVER' "$TARGET"             # R4
grep -c '^#' "$TARGET"                                       # R5
# R10: cross-reference against package.json / pyproject.toml / Cargo.toml / etc.

行レベルの根拠を含む、ルールごとの採点表を作成します。

Phase I-3：PROPOSE

変更を3つのカテゴリに分類します。

削除（R2またはR10に違反する行）：

- DELETE line N: "[content]"
  Reason: [R2 — would Claude actually make a mistake without this?]
  OR: [R10 — auto memory captures this from package.json]

追加（R6に基づき、不足している標準セクション）：

+ ADD section "## [Section Name]" with:
  [proposed content based on actual project — read package.json, README, .git/config]

書き換え（具体性に関するR3＋強調に関するR4）：

~ REPLACE line N: "[vague content]"
  WITH: "[concrete, verifiable rewrite]"
  Reason: [R3: was vague | R4: high-impact rule needs IMPORTANT prefix]

Phase I-4：PRESENT

## CLAUDE.md Improvement Proposal

**File:** [path]
**Current size:** N lines (R1 budget: 200)
**Rubric pass rate:** M of 10

### Summary
- DELETE: K lines
- ADD: L sections
- REWRITE: J lines
- Net change: ±N lines (final: M lines)

### Proposed Diff
[full diff with reasons]

Apply these changes? (yes / partial / no)

Phase I-5：APPLY

変更箇所だけを適切に修正するにはEditツールを使います。Writeでファイル全体を上書きしてはいけません。変更は一度に1つずつ適用します。すべての変更後に、次の手順を実行します。

1. 再度測定し、新しいサイズと評価基準の合格率を表示します。
2. 「その後、/claude-md auditを実行して、新たなずれが生じていないか確認してください」と提案します。
3. ファイル内に明らかなパススコープ付きサブセクションがある場合は、.claude/rules/<topic>.mdに分割するよう提案します（R9）。

5 つの標準セクション（R6 の詳細）

R6 で高いスコアを獲得する CLAUDE.md には、以下のセクションが含まれています。不足しているものがあれば、作成を提案してください。

1. ## Project（1～2 行：これは何か、誰が使うか）
2. ## Stack（1～3 行：フレームワーク、言語、デプロイ先）
3. ## Commands（ビルド／開発／単体テスト／全テスト／Lint／型チェック — 短く、正確に）
4. ## Architecture（フォルダー → 目的の対応付け。ディレクトリ一覧全体ではありません）
5. ## Rules（15 項目未満。禁止事項も含みます。特に重要なルールを強調します）
6. ## Workflow（ユーザーが Claude にタスクへどう取り組んでほしいか：変更を最小限にする、確認してから進めるかそのまま実行するか、コミット規約）
7. ## Out of scope（Claude が触れるべきではないファイル／連携機能）

効果が積み重なる重要度の高い指示

ファイルにスコープ制御や安全性に関するルールが本当に不足している場合に使える候補です。**前述の「追加せずに削る」という注意点が適用されます。**すでに方針が整っている Claude Code の対象でスコアが 9～10/10 の場合、これらを大量に追加しないでください。Claude Code のシステムプロンプトには、その大半がすでに組み込まれており、さらに追加すると品質が低下します（Augment Code、2026 年 4 月）。実際に確認された問題を解消する 1～2 項目だけを追加し、それ以外は省略してください。

スコープと安全性（最も効果が大きい — コストが高く、元に戻しにくいミスを防ぎます）：

• 現在のタスクに直接関係するファイル、関数、行のみを変更してください。依頼されていないリファクタリング、名前変更、書式変更は行わないでください。他の問題は最後に報告し、手を触れないでください。
• 既存の内容を大幅に変更する場合（セクションの書き換え、構成の変更、トーンの変更など）は、変更を行う前に停止し、変更内容とその理由を説明して、確認を待ってください。
• ファイルの削除、コードの上書き、レコードの削除、依存関係の削除を行う前に、停止して影響範囲を列挙し、現在のメッセージで明示的な確認を求めてください。「以前に言及されていた」ことは確認にはなりません。
• 本番環境での実行前に、セッション内での確認が必須となる操作：デプロイ／プッシュ、マイグレーションやスキーマの変更、外部 API 呼び出し、取り消し不可能な影響を伴うあらゆるコマンド。 (停止を 100％確実に守らせる必要がある場合は、実効性のある強制手段として PreToolUse フックを使用してください。CLAUDE.md の遵守率は約 80％が上限です。)
• コーディングタスクの後は、必ず次の内容を記載して締めくくってください：変更したファイル、ファイルごとの 1 行の概要、意図的に触れなかったファイル、フォローアップが必要かどうか。
• 決して .env ファイルや秘密情報をコミットしないでください
• 明示的な確認なしに git push --force を決して実行しないでください

ワークフロー：

• 重要：コードを変更するたびに型チェックを実行してください
• 変更は最小限にし、無関係なコードをリファクタリングしないでください
• 論理的な変更ごとに個別のコミットを作成し、巨大なコミット 1 つにまとめないでください
• 2 つの方法のどちらにするか迷った場合は、両方を説明して、私に選ばせてください
• アーキテクチャに関する判断や、単純ではない機能の場合は、コードを書く前に段階を追って問題に取り組んでください。考え方と不確かな点を示してから、実装してください。

コミュニケーション（Claude Code では追加による効果が最も小さい項目 — システムプロンプトに大半がすでに組み込まれています。特定の問題が確認された場合にのみ追加してください）：

• 回答の長さはタスクの複雑さに合わせてください。質問の言い換えや締めくくりの要約で水増ししないでください。
• 事実、統計、日付、技術的な詳細について確信がない場合は、もっともらしい内容で穴埋めせず、その旨を明確に伝えてください。

文言は、Karpathy に由来するルール集（Fraser、2026 年 5 月、「Dep」スレッド、2026 年 5 月）から引用しています。見出しで示される統計（「正確度 65％ → 94％」、開発者 1 人あたりの金額、スター数）は、実測結果ではなく、マーケティング上の例示です。引用するのはルールの文言であり、数値ではありません。

含めてはいけないもの（アンチパターン）

• 人格に関する指示（「シニアエンジニアとして振る舞う」など）
• リンターがすでに処理するコードフォーマッターのルール
• 階層間で重複するルール
• README 全体や巨大なドキュメントの @-imports（起動時にコンテキストウィンドウに読み込まれます）
• Claude が自動メモリで独自に学習する情報
• （V2）自動生成された大量の情報。 /init を実行して放置したり、LLM が生成したコンテキストファイルを貼り付けたりしてはいけません。管理された調査では、厳選されたコンテキストファイルはトークンのオーバーヘッドが約20％でタスク品質を約4ポイント向上させますが、自動生成されたものはタスクの成功率を約0.5～2％低下させ、コストを20～23％増加させます。徹底的に厳選してください。コンテキストは多ければよいというものではありません。（arXiv 2026、AGENTS.md の効率性に関する調査）

---

監査モード

すべてのプロジェクトにわたって CLAUDE.md ファイルをリントし、監査します。記述と実際のコードが食い違っている箇所、漏えいしたシークレット、重複ブロック、記述的な行と指示的な行のバランス、150～200個の指示上限に近づいているファイルを検出します。

CLAUDE.md ファイルは古くなります。実際には、複数のプロジェクトで古くなった CLAUDE.md が見つかることがよくあり、ときにはシークレットが漏えいしているファイルも見つかります。このモードでは、どちらの問題も一度の処理で検出します。

監査モードの手順

フェーズ A-1：検出

1. プロジェクトのルート（コードの保存場所に合わせて、例：~/Projects、~/work）の下にあるすべての CLAUDE.md を検索します。

   find ~/Projects ~/work -name 'CLAUDE.md' \
     -not -path '*/node_modules/*' -not -path '*/.venv/*' -not -path '*/vendor/*' 2>/dev/null
   

2. 各ファイルについて、対象プロジェクトとサイズ（行数）を記録します。

フェーズ A-2：シークレットスキャン（必ず最初に実行）

各 CLAUDE.md で、確度の高いシークレットのパターンを grep で検索します。漏えいは P0 の検出事項であり、その後のフローを中断するため、このフェーズをほかの監査より先に実行します。

検出するパターン：

• (?i)(secret|token|api[_-]?key|password)\s*[:=]\s*['"]\S{8,}['"]
• (?i)auth[_-]?secret\s*[:=]\s*\S{8,}
• Base64 形式に似た JWT プレフィックス：eyJ[A-Za-z0-9_-]{10,}
• 認証情報が埋め込まれた URL：https?://[^:/\s]+:[^@\s]+@
• Stripe/OpenAI/Anthropic のキーのプレフィックス：sk_live_、sk_test_、pk_live_、sk-ant-、sk-proj-
• Supabase/Neon の接続文字列：postgres(ql)?://[^:]+:[^@]+@

**一致が見つかった場合：**ファイルに 🔴 P0 LEAK の印を付けます。該当行、マッチしたパターン、必要な修正内容を報告します。修正内容は、ソースシステムでシークレットをローテーションし、CLAUDE.md では環境変数名のみを参照するように編集し、git 履歴を消去することです（git filter-repo --path CLAUDE.md --invert-paths または BFG）。

フェーズ A-3：記述の不一致を検出

CLAUDE.md に記載された各項目を、実際のコードと照合します。

1. MCP サーバー — settings.json / .mcp.json / mcp.json と差分を確認します
2. API ルート — CLAUDE.md に記載された名前のルートを grep で検索し、それぞれが src/app/api/ またはルートファイルに存在することを確認します
3. Cron ジョブ — 記載された数と、実際の */cron* ファイル / vercel.json の Cron / wrangler.toml のトリガー数を比較します
4. 環境変数 — 記載された各環境変数が .env.example に記載されているか、コードで読み取られている（process.env.<NAME> / os.environ["<NAME>"]）ことを確認します
5. 外部サービス — 矛盾を検出します（「Brevo SMTP を使用」と記載されているが、コードでは @getbrevo/brevo REST クライアントをインポートしているなど）
6. ディレクトリ構成 — 記載されたディレクトリと ls の出力を比較します

不一致が見つかった場合は、CLAUDE.md の行、実際のコードの事実、修正のための一行編集を報告します。

フェーズ A-4：重複と構成のチェック

1. 重複するセクション見出しを検出します（^## 、^### が2回以上出現）
2. 類似した段落を検出します（異なる2行の最初の60文字が同一）
3. 同じファイル内の別の行と矛盾する行を報告します

フェーズ A-5：指示の予算と規範的な指示の割合

1. 指示を数えます。命令動詞（Always、Never、Use、Don't、Prefer、Avoid、Run、Check、Write、Edit、Follow）で始まる行、または「Rules／Conventions／Do／Don't」という見出しの下にある箇条書きの項目が対象です。
2. 予算のしきい値：
   • ≤ 100 件の指示：🟢 健全
   • 100–200 件：🟡 要監視

   • 200 件：🟠 予算超過 — 分割または削減を提案

3. 記述的な内容と規範的な指示を分類します。
   • 記述的 = コードにすでに示されている内容を説明するもの（「これは Next.js と Postgres を使ったアプリです」）
   • 規範的 = Claude に何をすべきか指示するもの（「マイグレーションを編集するときは、up と down の両方を追加してください」） 割合を報告します。記述的な行は予算の無駄です。

フェーズ A-5.5：フック候補の検出

CLAUDE.md の指示には強制力がありません。コミュニティのエビデンスによると、遵守率は約 70～80% です。絶対的な命令として書かれたルールも、この上限を気付かれないまま下回ります。決定論的に聞こえるルールをスキャンし、フックへの変換候補として提示します。

次のパターンを対象にします。

• NEVER、Never、Always、MUST、Do not で始まり、その後に動詞が続く行
• 破壊的なコマンドを指定するルール：rm -rf、git push --force、git reset --hard、DROP TABLE、truncate、vercel --prod、gcloud ... delete
• コミット前に 100% の検証を必須とするルール：lint、typecheck、test がコミット前に成功している必要があるという内容

該当する項目ごとに、行を報告し、hook-candidate に分類して、適切なフックの種類を特定します。

• 破壊的なコマンドのゲート → 終了コード 2 を返してブロックする PreToolUse フック
• コミット前の検証 → git commit に対する PreToolUse、またはファイルの Edit／Write に対する PostToolUse
• 編集後に必ず実行するチェック → PostToolUse フック

報告文：「このルールは決定論的に見えますが、強制力のない領域にあります。100% 強制するには、.claude/settings.json のフックに変換してください。フックの目的を記録する文書として CLAUDE.md の行を残すか、削除してください。」Anthropic hooks docs と、強制力のない指示の遵守率が約 80% であることを引用してください。

フェーズ A-6：レポート

プロジェクトごとに、重要度別にまとめて出力します。

# CLAUDE.md Audit Report — <timestamp>

## Summary
- 6 CLAUDE.md files scanned
- 1 P0 LEAK (acme-web)
- 2 projects with drift (data-pipeline, saas-app)
- 0 over budget
- 3 projects clean

---

## acme-web 🔴 P0 LEAK
**File:** ~/Projects/acme-web/CLAUDE.md (142 instructions)

### Leaks (P0 — rotate before any other work)
- Line 38: `AUTH_SECRET=...` (value redacted in report)
  - Fix: replace with `The AUTH_SECRET env var is required; see .env.example`
  - Rotate the secret in production, then `git filter-repo --path CLAUDE.md --invert-paths`

### Drift
- Line 52: claims "Brevo SMTP" — code uses REST (`@getbrevo/brevo` at src/lib/email.ts:4)
  - Fix: change to "Brevo REST API via @getbrevo/brevo"

### Duplicates
- "## Email" heading appears at lines 50 and 89

フェーズ A-7：修正の提示（対話形式）

レポートの後に、「 に提案した編集を適用しますか？ [y/N]」と尋ねます。確認後にのみ適用してください。P0 LEAK の修正を自動適用してはいけません。これらには、ユーザー自身が実行する必要のあるシークレットのローテーションと Git 履歴のクリーンアップが必要です。

---

品質基準（両モード共通）

すべてのチェックを満たした場合にのみ、実行は合格です。それ以外の場合は、問題のある推奨事項を書き直してください。

• 削除／ドリフトの指摘にはすべて、それが適用するルールを記載します（improve では R1～R10、audit では具体的なドリフトの種類）
• 追加内容にはすべて、実際のプロジェクトデータを使用します（package.json、pyproject.toml などを読み込みます）。汎用的なプレースホルダーは使いません
• 書き換えではすべて、「もっと明確にする」といった表現ではなく、具体的な置き換え案を提示します
• 「consider」、「perhaps」、「you might want to」は提案に使いません。すべての提案を、具体的で採否を判断できる形にします
• 要約には推定値ではなく、正確な件数を記載します
• audit モードでは、P0 LEAK の指摘をほかの監査内容より必ず先に提示します

落とし穴（どちらのモードにも該当）

• 自動適用しないでください。 必ず承認を得てください。変更は必要最小限にとどめ、ファイル全体を書き換えることは避けてください。
• プロジェクトのコンテキストを捏造しないでください。 提案の根拠を実際のプロジェクトデータに置くため、package.json／pyproject.toml／Cargo.toml／Gemfile／README.md を確認してください。
• .claude/rules/ への自動分割を提案しないでください。 提案はしても、決めるのはユーザーです。
• シークレットをローテーションしたり、Git の履歴を消去したりしないでください。 監査では漏えいを報告し、対処方法を案内します。ローテーションと履歴の消去はユーザーが行います。
• リポジトリ全体に特定のスタイルを押し付けないでください。 各リポジトリ固有の文体を尊重します。改善モードで書き換えるのは構成であり、文体ではありません。
• 問題のない行を指摘しないでください。 削除可能性のテストを満たさない行は、実際にそのテストに不合格である必要があります。「もっと簡潔にできるかもしれない」程度では不十分です。
• 間違いが初めて発生したときにルールを追加しないでください。 MEMORY.md または一時的なリストに記録してください。2回目に発生した後でのみ、CLAUDE.md に追加します。これにより、シグナル対ノイズ比を高め、実際の間違いを防がないままファイルを肥大化させるノイズルールを減らせます。（出典：Redreamality、2026年4月）
• ユーザーのパスをハードコードしないでください。 $TARGET、$HOME、$1 を使用してください。/Users/<name>/... は使用しないでください。

変更履歴

V2（2026-05-27）

skillforge optimize を使用して最適化しました（AI ネイティブなリポジトリ／AGENTS.md のベストプラクティスに関する成果調査）。

• AGENTS.md に対応 — CLAUDE.md だけでなく、エージェント横断の標準を監査・改善します。CLAUDE.md と AGENTS.md の重複を指摘し、信頼できる情報源を1つにするよう推奨します。
• 制御実験のエビデンス（厳選したものは +4pp、自動生成したものは −0.5～2%／コスト +20～23%）とともに、「自動生成しない」というアンチパターンを追加しました。既存の「追加ではなく削減する」という方針を強化します。
• 成果目標：このスキルは、複数のハーネスでエージェントの動作に実際に影響するファイルを改善し、その効果を損なう肥大化を積極的に防ぎます。出典：AGENTS.md 効率性調査（arXiv 2026）; agents.md 標準; Augment Code の AGENTS.md ガイド。

関連スキル

スキル	用途
/claude-md improve	1つのファイルを、ベストプラクティスに沿うよう構成面から書き換える
/claude-md audit	多数のファイルを対象に、衛生状態／乖離／シークレットをスキャンする
/init（Anthropic 組み込み）	現在のプロジェクトの状態から、CLAUDE.md のひな形を生成する
compound-engineering:ce-compound-refresh	同じ方針ですが対象が異なり、docs/solutions/ を更新します

参考資料

Anthropic の一次資料：

• Claude がプロジェクトを記憶する仕組み
• Claude Code のベストプラクティス
• Anthropic のチームによる Claude Code の活用方法（PDF）
• Claude Code の高度なパターン（PDF）

コミュニティ資料（一次資料と一貫しています）：

• HumanLayer — 優れた CLAUDE.md の書き方
• zodchiii — 出力を10倍にした CLAUDE.md ファイル（130万回閲覧）
• abhishekray07/claude-md-templates
• Augment Code — OpenClaw における Karpathy のスキル（2026年4月） — 実証的な反証：すでに適切に調整されたシステムプロンプトに Karpathy のルールを重ねると、Claude Code の品質は −0.07 低下しました。
• Fraser — Claude Code のワークフローを10倍にする Claude.md 設定のヒント（Medium、2026年5月） — Karpathy の4つのルールに加え、CLI と重複する指示の回避やファイル内での優先順位付けなど、8つの項目を追加しています。
• "Dep" (@0xdepressionn) — Karpathy の CLAUDE.md ルール集（X、2026年5月） — Karpathy の4つの行動指針を拡張した、コミュニケーション7項目と行動・安全性7項目から成る話題の14項目セットです。上記の影響力の大きい項目のメニューにも反映されています。⚠️ 見出しにある数値（スター数82,000、精度65%→94%、週あたりの金額）は出典のない宣伝文句です。価値があるのはルールの文面であり、数値は引用できません。
• Redreamality — CLAUDE.md と AGENTS.md の詳細解説（2026年4月） — 2回目に登場した項目を昇格させるルールと、助言的な指示の上限を約80%とする考え方をまとめています。

関連する原則：

• Strunk & White — The Elements of Style — ルール17（「不要な語を省く」）は、Anthropic の削除可能性テストの根底にある原則です。

テスト

構造評価を実行します：

bash tests/eval.sh

動作をエンドツーエンドで検証するには：

1. 改善：任意のプロジェクトで /claude-md improve を実行します。評価表が R1〜R10 のすべてに言及していること、各変更が対応するルールを明記していること、「no」の回答では何も書き込まないこと、「yes」の回答では必要な箇所だけに変更が適用されることを確認します。
2. 監査：/claude-md audit all を実行します。漏えいがある場合に P0 LEAK セクションが最初に表示されること、ドリフトの検出結果に具体的なコード位置が記載されること、ファイルごとの指示量が報告されることを確認します。
3. 自動検出：CLAUDE.md があるプロジェクトで引数なしの /claude-md を実行すると improve が実行され、ローカルファイルがない ~/ では audit が実行されることを確認します。
4. モードの上書き：/claude-md audit ./CLAUDE.md を実行すると、監査の一部として単一ファイルの監査が実行され、対象が1つに限定されることを確認します。