health-check

name	health-check
description	大きなサイクル完了後や定期メンテナンス時に使用。governance:check（決定的検査）を実行し、機械化できない意味的整合（コマンド直書き grep・npm ラッパー等価・メモリ整合）を検証して報告する（修正はしない）。
disable-model-invocation	true
argument-hint
allowed-tools	["Bash(git *)","Read","Grep","Glob","Agent"]

コードベースとドキュメントの衛生状態を検証する。発見事項を報告し、修正は行わない。

決定的検査の SSOT は npm run governance:check（scripts/governance-check.mjs・#587）である。 旧 Check 1・2・3・4・6・8・9・10 はそこへ機械化済み（下の各 stub が対応 G 番号を示す。Check 番号は序数参照の腐敗を避けるため振り直さない）。本スキルで実行するのは:

1. npm run governance:check を実行し、赤ならその全件を発見事項（Critical）として報告する
2. 機械化できない検査 — Check 5 の残置部分（コマンド直書き grep・npm 系ラッパーの等価判断）と Check 7（メモリ整合）— を従来どおり実施する

Check 1 — CLAUDE.md モジュール構成の乖離

→ npm run governance:check（G1・#587）が機械検査する。ここでは実行しない。 テストファイル除外（SSOT: vitest.config.ts の include）・basename 照合の意味論はスクリプト（scripts/governance-check.mjs）とそのテストが固定する。責務記述の内容の妥当性（索引の存在ではなく記述が実態と合っているか）は機械化できず、気づいた乖離があれば発見事項として報告する。

Check 2 — docs/architecture.md にファイル単位モジュール表が再導入されていないか

→ npm run governance:check（G2・#587）が機械検査する。ここでは実行しない。 責務宣言の正本は //! / TSDoc、CLAUDE.md は索引 + 横断不変条件（#562）という設計の回帰検知。

Check 3 — AGENTS.md ドキュメント参照の実在性

→ npm run governance:check（G3・#587）が機械検査する。ここでは実行しない（対象はガバナンス文書群全体に一般化された。検証コマンドの整合は Check 5 残置部分と G5/G6）。

Check 4 — SPEC.md セクション番号の連続性

→ npm run governance:check（G4・#587）が機械検査する。ここでは実行しない（番号連続性に加え、リポジトリ内の SPEC §N.x 参照の実在も検査対象）。

Check 5 — docs/build-commands.md コマンドの整合（SSOT）

コマンドの実在照合（npm run XXX → package.json scripts、cargo test -p <crate> → workspace members の package name）は npm run governance:check（G5・#587）が機械検査する。ここでは実行しない。

本 Check に残るのは意味判断を要する部分のみ:

• AGENTS.md「変更後の検証を実行する」や .claude/skills/*/SKILL.md に コマンド本体（cargo XXX / npm XXX / npx XXX の具体的な引数を含む実行コマンド）が直書きされていないか grep する。docs/build-commands.md の SSOT を迂回している箇所を報告する（コマンド名への言及や参照リンク自体は許容）。
• hook の cargo コマンド ↔ カテゴリ A の照合は npm run governance:check（G9・#589）が機械検査する。ここでは実行しない（出力整形フラグの許容込み。#476 のフラグドリフト事故クラスを機械が受け持つ）。
• node/vitest 系のみ本 Check に残る: hook の検査（tsc 直接起動・単一テストファイルの vitest 実行）が SSOT コマンド（npm test）の部分集合ラッパーとして妥当か（対象ファイルが SSOT コマンドの実行対象に含まれるか）を確認する。

Check 6 — docs/development-principles.md 参照の実在性

→ npm run governance:check（G3・#587）が機械検査する。ここでは実行しない（Check 3 と同様、ガバナンス文書群全体へ一般化された）。

Check 7 — MEMORY.md 参照の実在性

MEMORY.md はリポジトリに存在しない。 harness のユーザー領域（~/.claude/projects/<project-slug>/memory/）にあり、その絶対パスはメインエージェントの system prompt に与えられる。スラグの導出規則をここに書いてはならない（harness 内部仕様であり、表記も揺れる）。

• リポジトリ内を Glob して見つからないことは、発見事項ではない。
• Read / Glob / Grep は絶対パスでリポジトリ外へ届く（実測）。ツールの到達性は問題にならない
• このチェックを委譲するときは、メモリ領域の絶対パスをサブエージェントのプロンプトに明記する。 サブエージェントは system prompt を継承せず、パスを知らない。渡し忘れると、サブエージェントは見えないものを「無いもの」として報告する（#489 で実測）

検証内容（7a〜7c は機械検査。7d はレビューであり、自動判定できない）:

1. 7a — 索引 → ファイルの実在: MEMORY.md を読み、リンク先のメモリファイルが実在するか確認する。存在しないファイルへの参照を報告する
2. 7b — 索引 ↔ 本文の一致: 各メモリファイルの description が内容と合っているか簡易チェックする（ファイルを読んで比較する）
3. 7c — ファイル → 索引の実在（逆方向）: メモリ領域を Glob で全列挙し、MEMORY.md に載っていない孤児ファイルが無いか確認する。索引だけを母集団にすると、ディスク上にあるが索引に無いメモリは永遠に見えない（#492）
4. 7d — 事実鮮度のレビュー: 今サイクルで実測により覆した前提・変更した設定・仕様変更があるなら、そのキーワードと概念名でメモリ本文を grep し、該当する主張を更新または削除する。索引の description で関連性を判断してはならない — description は本文の派生要約であり、覆された一文がそこに現れるとは限らない（#488: push-before-pr-create の description は正確なまま、本文が消滅した機構を述べていた）。実施は /retrospective「Step 6」が担う

Check 7 が保証するのは索引整合性であって、全メモリの事実鮮度ではない。 7d はある主張が今も真かを読んで考えるしかなく、機械判定できない。ゆえに 「全メモリが現在の事実と一致する」と報告してはならない — 書けない全称主張は false green を作る（AGENTS.md「全称表現は前提条件とセットで書く」）。

結論には根拠を添える。「発見事項なし」も同じである — 7a はリンク先ごとの実在の可否を、7c は Glob の全列挙と索引の突き合わせを、一覧で示す。/plan-review と同じ規律であり、根拠のない「確認済み」は確認したことにならない。証跡の無い「発見事項ゼロ」は、実施していないのと区別が付かない。

判定（三値。「異常あり」「異常なし」「見ていない」を同じ記号で書かない）:

• パスが与えられており、リンク切れ・description の不一致がある → 発見事項として報告する
• パスが与えられており、メモリ領域が空（MEMORY.md 未作成） → 正常（メモリ未初期化）。発見事項ではない。ただし 「空」は列挙の結果として示す（Glob の出力を根拠に添える）。実行方式を問わず「空だった」と自己申告してはならない。誤ったパスも空に見える ため、委譲先が空を観測したときは、渡したパスが正しいか委譲元が確認する
• パスが与えられていない（実行者がパスを持たない） → [Skipped] 検証不能 と報告する。「不在」と報告してはならない（存在しない欠陥をでっち上げることになる）

[Skipped] は「実行者がパスを持たない」という状態であって、逃げ道ではない。

• インライン実行のメインエージェントは system prompt から絶対パスを得られるため、Skip は正当化されない
• 委譲先が [Skipped] を返したら、パスを持つ委譲元はパスを渡して再委譲する。[Skipped] をそのまま最終報告へ持ち上げてはならない
• ゆえに最終報告に Check 7 の [Skipped] が残るのは、実行環境そのものにメモリ領域が与えられていない場合だけである

これは規範であって機構ではない（受容する性質）。実行者が「パスを持たない」「読んだが整合していた」と偽ることを、文書は反証できない。防御は 2 つだけ — 根拠を要求すること（偽るコストを上げる）と、Skipped を可視化すること（黙って消えられなくする）。--no-verify と同格の best-effort として扱う。

Check 8 — .claude/rules/ パスパターンの有効性

→ npm run governance:check（G7・#587）が機械検査する。ここでは実行しない（マッチ 0 件の検知。glob 意味論は harness の配送判定の近似であることはスクリプト側に明記済み）。

Check 9 — スキル定義の整合性

→ npm run governance:check（G8・#587）が機械検査する。ここでは実行しない。

Check 10 — docs/build-commands.md ↔ .github/workflows/* の対応

「CI/CD メモ」対応表とワークフローの機械照合（表のコマンド・wrapper スクリプトパスが表記 workflow の run: に現れるか・workflow ファイルの実在）は npm run governance:check（G6・#587）が担う。ここでは実行しない。

残るのは意味判断のみ: 表のトリガー記述（「PR 自動」「対象 paths を含む PR」等）が実際の on:/paths 設定と合っているか、「workflow で実行されているが表に無いコマンド」の逆方向、およびカテゴリ A〜C の必須コマンドが対応表に漏れていないか（G6 は表の行駆動なので、表に載っていない必須コマンドは機構の母集団に入らない）。気づいたずれを Warning で報告する。

出力

# Health Check Report

## 発見事項

### [Critical / Warning / Info] <カテゴリ>
- <具体的な乖離の説明>

## 実施できなかったチェック

### [Skipped] Check 7 — メモリ領域の絶対パスが与えられていない

## サマリー
- チェック項目数: N（実施: M / Skipped: K）
- 発見事項: N件（Critical: N / Warning: N / Info: N）
- 根拠 — governance:check の出力（照合母集団の件数行）と exit code、Check 7 の実在列挙

• Critical / Warning / Info は発見事項（コードベースに乖離がある）。[Skipped] は発見事項ではない（前提が満たされず、検査そのものが走らなかった）。「異常なし」と「見ていない」を同じ記号で書かない。
• [Skipped] が正当なのは、文書化された前提を満たせない場合に限る。 現状その前提を持つのは Check 7 のみ（メモリ領域の絶対パスが与えられていない）。governance:check の実行と Check 5 残置部分は前提が常に満たされるため、それらが Skipped になること自体が発見事項（検査基盤の異常）として報告する。この限定が無いと「面倒な検査は Skipped にしておけば楽」という抜け道になる
• 「All checks passed.」と書けるのは、発見事項ゼロ かつ Skipped ゼロのときだけである。 Skipped が 1 つでもあれば「M passed, K skipped」と書く（M = 実施数）
• 「根拠」行は実行の証跡であって発見事項ではない。 Critical/Warning/Info（乖離あり）でも [Skipped]（未実行）でもない第3のカテゴリであり、発見事項カウントにも「All checks passed」判定にも算入しない。検査が母集団を絞り込むとき（現状は Check 1 の test 除外）に「何をどれだけ照合したか」を接地させる。省くと「差分ゼロ」が「照合していない」と区別できなくなる（Check 7 の証跡規律・AGENTS.md「照合は SSOT に対して行う」の一般化）。将来ほかの検査が根拠を出す余地は塞がない
• 該当が無いセクション（発見事項ゼロ / Skipped ゼロ）は省略してよい。サマリーは常に出す（根拠行を含む）