claude-md-doctor

CLAUDE.md Doctor — 検査手順

このリポジトリのエージェント指示ファイルを検査します。決定論的な作業はスクリプトが担当し、その間の判断はあなたが行います。スクリプトがすでに測定した内容を再評価したり、ステージを省略したりしないでください。レポートでは作業状態マニフェストを検証し、省略されたステージを明らかにします。

以下の定義を使用します。

• SCRIPTS = ${CLAUDE_SKILL_DIR}/scripts — Claude Code は実行時に ${CLAUDE_SKILL_DIR} をこのスキル自身のディレクトリに置き換えます。そのため、作業ディレクトリやスキルのインストール方法にかかわらず、スクリプトを解決できます。そのまま使用してください。自分でスキルの場所を探さないでください。
• REPO = 調査対象のリポジトリ（引数が指定されている場合はその引数、指定されていない場合は現在の作業ディレクトリ）。
• WORK = REPO/.claude-md-doctor/work（スクリプトのデフォルトです。--work を指定すると移動できます。たとえば、ユーザーのリポジトリへの書き込みを避けるため、一時ディレクトリに移動できます。自分のものではないリポジトリでは、こちらを優先してください）。

ステージ 0 — 事前確認

python3 --version を実行します。python3 が見つからない場合は終了し、このスキルには Python 3.9 以降が必要であること（標準ライブラリのみを使用し、インストールは不要です）をユーザーに伝えてください。

ステージ 1 — 受け入れ

python3 SCRIPTS/intake.py --repo REPO --work WORK

次に WORK/intake.json を読みます（小さなファイルです）。後の判断のため、次の点に注意してください。

• プロジェクトの CLAUDE.md は、AGENTS.md を指すポインター（is_pointer）ですか？ これは公式に推奨されている健全なパターンです。検査対象は参照先です。ポインターファイルを「短すぎる」と診断してはいけません。pointer_style を確認してください。symlink と import は機能しますが、bare-text は壊れたポインターです。@ のない AGENTS.md だけが書かれた通常ファイルでは、Claude Code は参照先を読み込みません。これは @ を1文字追加するだけで修正できる重大な問題です。ただし、シンボリックリンクがテキストに変換された、フェッチ直後のコピーを調査している場合は除きます。
• 祖先スコープおよびユーザースコープのファイルは、セッションが読み込むコンテキストですが、リポジトリ側では修正できません。これらについては言及しますが、依頼がない限り変更を指示しないでください。
• スコープが orphan-agents のファイルは、リポジトリに AGENTS.md があるものの、それを指す CLAUDE.md がないことを意味します。Claude Code は何も読み込みません。 公式の1行の修正方法（@AGENTS.md を含む CLAUDE.md を作成する）を示す重大な問題です。ポインターが存在した時点で AGENTS.md 自体が検査対象になるため、それについても静的検査を最後まで実施してください。
• メモリファイルが一つもない場合、空のレポートを作成して終了しないでください。代わりにモード B（以下）に切り替え、セッション履歴を調べて初期カルテを作成してください。セッション履歴もない場合に限り、/init の実行と積極的な刈り込みを提案し、それ以外の検査を実施できなかった理由を記して、検査を終了します。

ステージ 2 — バイタルチェック

python3 SCRIPTS/vitals.py --work WORK

WORK/vitals.json を読みます。測定はスクリプトが行い、解釈はあなたが行います。検出項目に関する注意：

• init_boilerplate は、ファイルの冒頭に /init の標準出力がそのまま残っていることを意味します。生成後に一度も刈り込まれていないことを示す目印です。
• emphasis_per_100_lines では、強調表現の有無ではなく密度が重要です（強調表現を少量使うことは公式に推奨されています）。
• dated_per_100_lines が高い場合、セッションログや変更履歴が蓄積している可能性があります。
• 大きなファイルで imperative_ratio が非常に低い場合、指示ではなく説明文書になっている可能性があります。サンプルを読んで判断してください。この検査が存在するのは、妨害行為の手引きを含む CLAUDE.md の事例（arcan）があったためです。
• 各ファイル単体ではなく、全体の読み込み対象を評価してください（launch_loaded_combined とファイル数）。個々には健全なファイルでも、合計すると常時読み込まれるコンテキストが大きくなることがあります。また、ファイル間の重複や矛盾は、ファイル単位では見えません。全体の読み込み対象が問題の場合は、段階的な対策を提案してください。まず重複を統合し、次に必要時に読み込むファイルを指す簡潔なルーター／索引を設け、最後に常時読み込む不変条件を1画面にまとめ、手順はスキルに移します（引用 ID surface-bloat）。

ステージ 3 — 記録の確認

python3 SCRIPTS/refcheck.py --work WORK

WORK/refcheck.json を読みます。次の判断を行います。

1. 失敗を確認し、そのまま繰り返さないでください。 missing ／ machine_specific ／ glob_empty の各参照と、missing の各コマンドについて、 引用されたファイルと行を開き、実際の参照であることを確認してください（パスのように 見えるだけの文章ではありません。API エンドポイント、MIME タイプ、Git の参照、 削除済みと文章中で説明されているファイルは、よくある誤検出です）。各誤検出は、 理由とともに dismissed_refs に記録してください。レポートには確認済みの指摘のみが 表示され、却下した項目は折りたたまれた注記で開示されます。
2. スクリプトでは確認できない、検証可能な主張を抽出してください。メモリファイル内の 数えられる主張（「374 ファイルにわたる 3,540 件のテスト」「12 個の UI コンポーネント」 「ESLint の設定ファイルがない」など）が対象です。手間のかからないものは、簡単なコマンド （ファイル数の確認、設定ファイルの検索など）で検証してください。ユーザーから依頼されて いない限り、テストスイートやビルドは実行しないでください。それぞれを verified ／ drifted ／ unverified とし、詳細を 1 行で記録してください。コストのかかる項目は、 正直に unverified としてください。

ステージ 4 — 履歴のバックテスト

intake でセッションディレクトリが見つからなかった場合（sessions.dir が null の場合）に限り、このステージをスキップしてください。その場合はチャットでその旨を伝えてください。レポートの「履歴」セクションにも、その旨が記載されます。

4a — トランスクリプトを要約する

python3 SCRIPTS/sessions.py --work WORK

4b — メモリファイルをルールブックに分解する（あなたの判断）

WORK/rulebook.json を記述します（スキーマは backtest.py の冒頭に記載されています）。 ガイダンス：

• ファイル内のすべての指示を分解してください — ルールブックは指示の完全な一覧です。強制適用ラダーの「N / M」が正直な数値であるためには、M がファイル全体を指している必要があります。マッチャーを付けるのは、機械的にチェック可能なルールだけにしてください。つまり、Bash コマンドや Edit/Write の内容に現れる禁止事項と必須事項、および ordering による終了順序ルールです。判定クラスのルールや、まだ機械化できないルールは、分類のみのエントリ（強制適用ブロックのみで、マッチャーなし）として登録してください。意味的なルールに正規表現を無理に当てはめてはいけません。情報提供のみの内容（事実、アーキテクチャ、API のセマンティクス）はルールブックに含めないでください。
• 編集／書き込みイベントで照合可能なテキストは、1 行目の PATH: <file_path> に続く（切り詰められた）新しい内容です。パスベースのルールは ^PATH: .*… を起点にし、内容ベースのルールは本文を対象にしてください。
• 保守的な正規表現を記述してください（偽陽性より偽陰性を優先）。scope.paths / scope.exclude_paths を使ってファイル単位のルールの対象を限定し、そのファイルの履歴を低コストで調べられる場合は、git log --follow --format=%aI -- <file> を使って各ルールに introduced の日付を設定してください。ルールが存在する前に終了したセッションは、遵守状況の評価対象にしてはいけません。
• 各ルールの強制適用方式（enforcement ブロック。スキーマは backtest.py の冒頭に記載）を分類してください。複合ルールはまず条項に分割し、各条項を個別に分類します。分類は、確実に検出できる最も低コストの手段にしてください。hook（イベントストリームの正規表現：Bash／編集／パス／ツール入力／出力のゲート、順序、頻度 — ルールを judge に委ねる前に、イベント順序や恒常的な不変条件への置き換えを試してください）、linter／test（成果物に対する静的解析：lint ルール、規律を検証するテスト、import グラフの境界 — scope_kind: file|project を記録）、または judge（LLM だけが採点できる場合）から選びます。判定者でも採点できないルールはルールではありません。vague と診断してください。既存の強制適用を検出してください。リポジトリに説明されているテスト／lint／hook がすでにある場合は、current_layer をそれに設定してください。そのようなルールは健全な参照先であり、処方対象にしてはいけません。current_layer は組織レベルのルールプラットフォーム（検出器／テレメトリーを一元管理するチーム全体のルールブック）を指す場合もあります。これは、リポジトリ横断ルール、judge クラスの大規模監査、リポジトリごとの設定では管理できない警告→ブロックの段階的なロールアウトに適しています。 分類したすべてのルールに、固有のトークンを示す echo_regex（反抗の証拠を検出するため）と origin（root/nested/rules。コンパクション後に真に欠落し得るのは root 以外のルールのみ）を指定してください。また、enforcement ブロックで against_prior: true|false も判定してください。つまり、そのルールがなくても、最先端モデルはこれをデフォルトで実行するでしょうか。with-prior ルールで高い遵守率が示されても、従ったのではなく偶然かもしれません（引用 ID harness-if）。これを健全な状態として称賛するのではなく、診断で冗長性候補としてフラグ付けしてください。また、skill への移動を処方する場合、その移動は手順のみに適用してください。制約を skill の説明に格下げすると、優先度が測定可能なほど低下します（プロジェクトファイルはツール／skill の説明より優先されます）。 エンジンのセマンティクス（リバースエンジニアリングする必要はありません）：
• 「Opportunities」 ＝ 正規表現ルールではマッチャーが発火した回数（違反＋遵守＋コンテキストのヒット）、順序ルールでは変更されたセッション数です。ゼロの場合、「ルールが一度も適用されなかった」か「スコープが間違っている」可能性があります。パススコープ付きルールで発火がゼロの場合は、適用されないと判断する前に、スコープ内のイベントがセッションにまったく含まれていないことを確認する ネガティブコントロール を1回実行してください。
• scope.paths はファイルパスを持つイベントだけをフィルタリングします。bash イベントはパスフィルターを通過します（パスがないためです）。bash と編集の両方を対象とするルールで bash を除外する必要がある場合は、正規表現にパス制約（^PATH: …）を含めてください。
• exclude_paths と repo_only は、順序ルールの変更件数のカウントにも適用されます。
• 編集／書き込みでマッチ可能なコンテンツは、新しいコンテンツの約1200文字までに切り詰められます（bash コマンドは約600文字です）。先頭行のルールには問題ありませんが、ファイル末尾やサイズに関するルールはコンテンツ正規表現では表現できません。
• 簡略化されたセッションは、イベントオブジェクトを含むトップレベルの JSON 配列です。
• 編集前の読み取り順序は、まだ表現できません（ordering.require は bash コマンドにのみマッチします）。このようなルールは機械化されていないフックとして分類し、正規表現で無理に対応しないでください。

4c — エンジンを実行する

python3 SCRIPTS/backtest.py --work WORK

4d — サンプルを検証する（必須 — マッチャーにはバグがあります）

WORK/backtest.json を読んでください。発火したすべてのルールについて、違反と遵守の両方のサンプルを読み、それぞれが真陽性であることを確認してください。誤検知が1つでもあるマッチャーは、rulebook.json で修正してからエンジンを再実行します。このループは低コストであり、結果を信頼できるものにするための要です。サンプルの発火がすべて確認できた場合に限り、backtest.json で "verified": true に設定してください（ファイルを編集します）。そうしないと、レポートには「provisional」バナーが表示されます。

言及は使用ではありません。 最もよくある誤検知は、ルールに違反するのではなく、ルールについて 話している セッションです。危険性の文書化、違反箇所の検索、ルール自体の記述、コミットメッセージや撤回での引用などが該当します。正規表現では議論と違反を区別できません。ルールの文面がその場で繰り返されるため、これらは最も深刻な原因である defiance-proven として分類されます。リポジトリ内のドキュメントが独自のルールを引用している場合は、こうした誤検知を想定し、そのイベントが禁止された操作を 実行した のか、単に言及しただけなのか、抜粋を確認してください。独自の規約を文書化しているリポジトリでは、こうした誤検知が大量に発生します。該当する発火を除外し、操作にアンカーを置いてマッチャーを絞り、scope.exclude_paths でメモリファイルやドキュメントの編集を除外してください。 その後、diagnosis.json の rule_verdicts にルールごとの判定を記録します。

"rule_verdicts": {
  "R1": {"verdict": "healthy|ignored|mixed|inert", "note": "one line of judgment"}
}

（これは一般的な共通部分です。Stage 5 のスキーマが正式なもので、unmeasured|abandoned|undocumented が追加されます。マイニングしたルールには undocumented を指定します。）

inert（対象期間内の機会がゼロ）は失敗ではなく、調査結果です。その意味、つまりルールがすべてのセッションでコンテキストを消費したものの、一度も必要にならなかったことを説明してください。

エンジンは、すべての違反を原因別にもトリアージします。defiance-proven（エージェントが自身のテキストでルールを繰り返した後に違反した — リマインダーはすでに行われていたものの、効果がなかった）、defiance（新しいコンテキスト）、dilution（後半のターン／大量のコンテキスト）、absence-risk（圧縮境界後の非ルートルール）です。判定する前に原因を確認してください。原因によって対策が変わります。defiance-proven ならブロックモードが正当化されます。dilution ならケージではなく、簡素化やパススコープが必要です。absence なら再注入フックが必要です。サンプルの検証中に分類が妥当か確認してください（2ターン目の違反に dilution が付いている場合は、占有率の代理指標が誤作動したことを意味します。その旨を記載してください）。順序ルールに関する注意点：判定はトランスクリプトごとに行われます。サブエージェント／ワークツリーのワークフローでは、必須コマンドが別のトランスクリプトで実行されている可能性があります。実行したという会話メッセージ（「verify green」）は証拠になりません。判定にはその主張を記載し、その後にリポジトリの編集があったかを確認してください（編集があれば、義務が再び発生します）。

4e — 強制適用の提案をコンパイルする

python3 SCRIPTS/compile.py --work WORK

これにより WORK/enforcement/ が作成されます。ルールごとの提案書 PROPOSALS.md、汎用ガードスクリプト、ルールごとの設定ファイル（デフォルトは警告モード。反抗の証拠があるルールは最初からブロック）、および設定スニペットが含まれます。自分でインストールしてはいけません。また、ユーザーの .claude/settings.json を編集してはいけません。 グッドハートの法則に関する注意（引用 ID specbench）：目に見えるパターンゲートは、ルールを守らなくても通過できます。ルールに実際の成果（テスト合格、ビルド成功）がある場合は、パターンを grep するゲートではなく、成果を検証するゲートを優先してください。提案の保存場所と、確認後に有効化するものであることをユーザーに伝えてください。

4f — ギャップ分析：セッションで繰り返し指示されているのに、ファイルに書かれていないこと

python3 SCRIPTS/mine.py --work WORK

WORK/candidates.json を読み、残ったグループをルールブックと照合します。繰り返し現れるシグナル（修正のまとまり、失敗→修正されたコマンドの組み合わせ、繰り返されるユーザーの否定）に該当する既存ルールがない場合、そのルールはユーザーがセッションのたびに手作業で指示し続けているものです。以下のモード B2 と同様に判断してください。一度限りのものや stale グループは除外します（自動モードのブロックはすでにマイナーによって除外されています）。採用した各欠落項目について、状態を undocumented（重大度 warn、証拠は抜粋 1～2 件）とする診断を追加します。重要な量になった場合は、"mode": "gap" を指定した WORK/chart.json（スキーマは generate.py の冒頭に記載）を作成し、python3 SCRIPTS/generate.py --work WORK を実行して PROPOSED-ADDITIONS.md を生成します。全体の予算に注意してください。提案する追加内容によって、この同じ評価で測定したサイズ目標を超えてはいけません。

Stage 5 — 診断（判断をファイルに記述する）

WORK/diagnosis.json を作成します。

{
  "grade": "B",
  "chief_complaint": "One sentence, doctor-voice, the single biggest issue.",
  "history_note": "optional override for the History section",
  "stale_claims": [
    {"claim": "…", "file": "/abs/path", "line": 12,
     "status": "verified|drifted|unverified", "detail": "…"}
  ],
  "dismissed_refs": [
    {"ref": "the exact ref string from refcheck.json", "line": 46,
     "reason": "why it is a false positive (route not file, MIME type, described as deleted, …)"}
  ],
  "rule_verdicts": {
    "R1": {"verdict": "healthy|ignored|mixed|inert|unmeasured|abandoned|undocumented",
           "note": "one line of judgment; 'abandoned' = the repo's own history contradicts the rule (e.g. git shows the team doing the banned thing routinely) even if sessions were inert"}
  },
  "diagnoses": [
    {"state": "dead-ref|stale|vague|ignored|inert|redundant|contradictory|oversized|accretion|generated-unpruned|undocumented",
     "severity": "critical|warn|info",
     "title": "short name", "detail": "1–3 sentences, plain language",
     "file": "/abs/path", "line": 46,
     "evidence": ["short quoted lines or metric readouts"],
     "citations": ["official-200"],
     "prescription": "the concrete fix, imperative voice"}
  ],
  "prescriptions": [
    {"action": "repo-wide action", "rationale": "why", "citations": ["eth"]}
  ],
  "followup": ["re-run cadence; transcript-retention advice; what to fix first"],
  "share_note": "one quotable line for the public share card — dry doctor's wit backed by the findings. STRICT safety: no file paths, no rule text, no quotes from the repo, no session ids, nothing repo-identifying; aggregate truths only (e.g. 'The loudest rule was the broken one.'). Omit the field to use a deterministic fallback."
}

このステージのルール：

• すべての診断に証拠が必要です（引用した行、指標、失敗したチェックなど）。該当するものがあれば、引用 ID も記載してください。有効な ID と各ソースの主張は python3 SCRIPTS/report.py --list-citations で確認します。その ID のみを使用し、ソースが実際に裏付けている場合に限ってください。公式または研究による裏付けのないチェックは、その detail でヒューリスティックとして説明してください。
• 重大度は正直に評価してください：critical は、ファイルがエージェントに誤った情報を与えている（参照先が存在しない、主張が古い、矛盾がある）場合、または内容が読み飛ばされている（4 MiB）場合です。warn は、コンテキストを消費する、または遵守率を下げる場合（サイズ超過、強調の過剰、内容の蓄積）です。info は知っておく価値がある場合です。
• 構造だけに関する指摘には注意書きを付けてください：要因実験を行った唯一の研究では、検証した範囲で構造的な効果は見つかりませんでした（引用 ID mcmillan）。サイズや配置に関する経験則を、因果関係が確立した事実として示してはいけません。参照先の欠落や記述の乖離など、内容に関する指摘にはこのような留保は不要です。
• 評価基準：A = critical なし、warn は最大 2 件。B = critical なし、warn は 3 件以上。C = critical が 1～2 件。D = critical が 3 件以上。F = ファイルが積極的に誤解を招いている（大半が参照先の欠落または記述の乖離）か、読み込み不能。
• 修正できないスコープ（上位階層、ユーザー、管理対象のファイル）については、info の診断のみを生成できます。
• このツールのバージョン番号をレポート本文（診断、メモ、フォローアップ、主な問題点）に記載してはいけません。 レンダラーがレポートのフッターにバージョンを記載します。本文は時代に依存しない内容にしてください。読者は「v0.2」が何を意味するのか知りませんし、気にもしません。
• ポインター型のリポジトリは、通常、複数エージェントが利用します。 ポインターをたどって見つけた AGENTS.md が対象なら、Cursor／Codex／Copilot も利用している可能性があります。内容を Claude 専用の領域（.claude/rules/、スキル、フック）へ移す処方は、それらのエージェントから内容を隠してしまいます。適切であればそのような処方も行いますが、処方には「Claude 専用。他のエージェントが AGENTS.md を読む場合、この内容を利用できなくなります」とトレードオフを明記し、すべてのエージェントに必要な内容については、ファイル内での修正を優先してください。

ステージ 6 — レポート

python3 SCRIPTS/report.py --work WORK

次に、共有しても安全なカードとバッジを生成します。

python3 SCRIPTS/card.py --work WORK

card.svg（投稿用の診断カード）とclaude-md-health.svg（README バッジ）は、 report.html と同じ場所に生成されます。どちらも設計上、集計データのみを含みますが、 ユーザーに安全に投稿できると伝える前に、カードを一度確認してください。スクリプトが 出力するバッジのスニペットを、README に追加するよう提案します。

生成されたreport.htmlを開くかユーザーに送信し、チャットで次の内容をまとめます。 評価、主訴、上位 3 件の所見、そして最も価値の高い処方箋を 1 つ伝えます。レポートの 保存場所も伝えてください。report.py が INCOMPLETE 警告を出力した場合は、欠けていた ステージとその理由を伝えます。

モード B — カルテのない患者（メモリファイルがない場合は、履歴から作成）

インテークでメモリファイルがまったく見つからなかった場合、またはユーザーが履歴から CLAUDE.md／フック／lint の提案を生成するよう依頼した場合は、ここに進みます。 ただし、リポジトリにすでにメモリファイルがある場合は、モード B を実行しないでください。 通常の診察を行い、ステージ 4f（ギャップ分析、 "mode": "gap" → PROPOSED-ADDITIONS.md）を通じて生成依頼に応えます。そうすれば 既存のファイルが診察対象のままとなり、インテーク時の説明（「メモリファイルが存在しない」） も正確なままです。 履歴には、まだ書き起こされていないルールブックがすでに含まれています。ユーザーが 繰り返し入力する修正、正しいコマンドを実行するまで失敗するコマンド、セッション開始時に 毎回再導出される事実、ユーザーが拒否するツール呼び出しです。モード B では、履歴をもとに 初回のカルテを作成します。

それでも、まずステージ 2 と 3 を実行してください。空の状態ならすぐに完了し、マニフェストの 記録も正確に保たれます。また、「毎セッション読み込まれるトークンが 0」というのが、 患者の基準となるバイタルです。

B1 — 要約して抽出する

python3 SCRIPTS/sessions.py --work WORK
python3 SCRIPTS/mine.py --work WORK

candidates.jsonには、5 つのカテゴリ（修正、失敗からの回復、再発見、拒否、前置き）に 分類された、機械的な事前フィルタリング済みのシグナルと、起動時の負荷の推定値が 含まれています。語句ベースのマーカーは約 65～75％の精度になるよう調整されています。 あなたが判定を行ってください。このファイルにある内容は、まだルールではありません。

B2 — 候補を判定する（あなたの判断）

すべての項目をトリアージします。

• ルールとは、ユーザーが今後も支持する、長く有効な内容です。繰り返しの修正が 一貫した結論に収束するもの（「pnpm を使う」「直接 push しない」など）、 失敗から修正に至る組み合わせで、その修正が体系的なもの（誤ったランナー、 間違ったディレクトリ、環境変数の不足など）、繰り返し現れるuser-rejected／ permission-ruleの拒否が該当します。命令形の 1 行で記述します。
• 事実とは、エージェントが何度も再導出しているリポジトリの知識です。再発見グループに あるビルド／テストコマンドや、前置きのクラスターにあるレイアウト／コンテキストが 該当します。
• 採用を見送るものは、一度きりの好み、タスク固有の指示、staleと示されたもの （リポジトリの状態がすでに変わっている可能性があります）、確信を持って一般化できない 抜粋です。自動モード分類によるブロックはマイナーによってすでに除外されています。 meta.automode_blockedにのみ表示されるため、復活させないでください。特筆すべき 見送り項目とその理由を記録してください。レポートでその内容が開示されます。
• 再発回数のしきい値は、グループ化されたカテゴリ（failure_recovery、rediscovery、 denials、preambles）ですでに適用されています。修正にはしきい値がなく、マーカーに 該当するメッセージは 1 件でもあなたの判定対象になります。そのため、修正は最も厳しく 判断してください。一度きりの修正をルールとするのは、その内容が明らかに長く有効な 場合に限ります。そのうえで、すべての項目に意味のテストを適用します。ユーザーはこの 1 行に賭けるだろうか？ 迷った場合は見送ってください。抽出した草案は、小さく保つことで 信頼を得られます。さらに、再現率を抜き取り確認してください。マーカー語のない単純な 事実の修正は事前フィルターで見逃されます（meta.known_gaps）。抽出結果が少ないようなら、 要約されたセッションを 1～2 件選び、ユーザーのテキストに目を通してください。

B3 — マイニングしたルールをバックテストで検証する（根拠）

機械的にチェックできる承認済みルールごとに、標準形式の WORK/rulebook.json エントリを作成します（スキーマは backtest.py の先頭にあります。「source」を {"file": "mined-from-history", "line": 0} に設定し、 適用方法を分類して、「echo_regex」を指定します）。次に、以下を実行します。

python3 SCRIPTS/backtest.py --work WORK
python3 SCRIPTS/compile.py --work WORK

バックテストの件数がルールの根拠になります。マッチャーが、ルールの着想元となった履歴の中で何も検出しない場合、そのマイニングルールは偽陽性です。破棄してください。検出結果はステージ 4d と同じ方法でサンプル検証します。compile は、フック適用クラスのマイニングルールについて、レビュー後に有効化するフック案を作成します。生まれながらにして機械化されているため、最適な CLAUDE.md の記述はガードが適用するものです。

B4 — チャートを作成してドラフトを生成する

WORK/chart.json を作成します（スキーマは generate.py の先頭にあります）。承認済みの事実とルールを記載し、マイニングまたはバックテストに基づく「occurrences」／「sessions」、項目ごとの「evidence」抜粋、「startup_tax」（candidates.json の「est_tokens」／「sessions」をコピーします。この推定値は、繰り返し実行される探索コマンド自身の記録と結果に基づくものなので、推定値としてそのまま記載します）、および「declined」リストを含めます。次に、以下を実行します。

python3 SCRIPTS/generate.py --work WORK

これにより、レポートの隣に PROPOSED-CLAUDE.md が生成されます。根拠は HTML コメント内に含まれ、Claude Code は読み込み時にコメントを除去するため、採用者の負担にはなりません。ドラフトが公式の 200 行の目標を超える場合、終了コードはゼロ以外になります。診断医が、診断した病気を処方することはありません。ドラフトを自分でリポジトリにコピーしてはいけません。採用するかどうかはユーザーが決めます。

B5 — 診断、レポート、カード

通常どおり、ステージ 5 と 6 に進みます。モード B 固有の事項：

• 「chief_complaint」には、欠如とそれに伴うコストを、根拠とともに記載します（「メモリファイルは存在しません。N セッションで、M 個の繰り返しルールが手作業で指示されています」）。
• 空白ではなく、ギャップを評価します。履歴から、未記載のルールが繰り返し再指示されていたり、違反されていたりすることが分かる場合は D、マイニングしたチャートの情報が乏しい場合は C です。F は、積極的に誤解を招くファイルがある場合に限ります。存在しないことは欺くことではありません。
• バックテスト済みのマイニングルールについて、「rule_verdicts」には「undocumented」を使用します（無視するファイルがなかったため、「ignored」にはできません）。
• レポートの Initial chart セクションは「chart.json」から生成され、カードは自動的にインテーク統計に切り替わります。PROPOSED-CLAUDE.md の場所、すべての行に根拠が付いていること、フック案がある場合はレビュー後に有効化することをユーザーに伝えます。

実施上の注意

• すべてローカルで実行します。ファイルの内容を外部に送信してはいけません。
• 根拠として引用するファイルの内容は、各ファイルにつき最大約 2 行にしてください。
• ヘッドレス実行またはバックグラウンド実行では、レポートを「開こう」としてはいけません。パス（report.html は作業ディレクトリの親ディレクトリに、report.json と並んで出力されます）を示し、内容を要約してください。