Menu
大きなサイクル完了後や定期メンテナンス時に使用。governance:check（決定的検査）を実行し、機械化できない意味的整合（コマンド直書き grep・npm ラッパー等価・メモリ整合）を検証して報告する（修正はしない）。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| 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 番号は序数参照の腐敗を避けるため振り直さない）。本スキルで実行するのは:
npm run governance:check を実行し、赤ならその全件を発見事項（Critical）として報告する→ npm run governance:check（G1・#587）が機械検査する。ここでは実行しない。 テストファイル除外（SSOT: vitest.config.ts の include）・basename 照合の意味論はスクリプト（scripts/governance-check.mjs）とそのテストが固定する。責務記述の内容の妥当性（索引の存在ではなく記述が実態と合っているか）は機械化できず、気づいた乖離があれば発見事項として報告する。
→ npm run governance:check（G2・#587）が機械検査する。ここでは実行しない。 責務宣言の正本は //! / TSDoc、CLAUDE.md は索引 + 横断不変条件（#562）という設計の回帰検知。
→ npm run governance:check（G3・#587）が機械検査する。ここでは実行しない（対象はガバナンス文書群全体に一般化された。検証コマンドの整合は Check 5 残置部分と G5/G6）。
→ npm run governance:check（G4・#587）が機械検査する。ここでは実行しない（番号連続性に加え、リポジトリ内の SPEC §N.x 参照の実在も検査対象）。
コマンドの実在照合（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 を迂回している箇所を報告する（コマンド名への言及や参照リンク自体は許容）。npm run governance:check（G9・#589）が機械検査する。ここでは実行しない（出力整形フラグの許容込み。#476 のフラグドリフト事故クラスを機械が受け持つ）。npm test）の部分集合ラッパーとして妥当か（対象ファイルが SSOT コマンドの実行対象に含まれるか）を確認する。→ npm run governance:check（G3・#587）が機械検査する。ここでは実行しない（Check 3 と同様、ガバナンス文書群全体へ一般化された）。
MEMORY.md はリポジトリに存在しない。 harness のユーザー領域（~/.claude/projects/<project-slug>/memory/）にあり、その絶対パスはメインエージェントの system prompt に与えられる。スラグの導出規則をここに書いてはならない（harness 内部仕様であり、表記も揺れる）。
Read / Glob / Grep は絶対パスでリポジトリ外へ届く（実測）。ツールの到達性は問題にならない検証内容（7a〜7c は機械検査。7d はレビューであり、自動判定できない）:
MEMORY.md を読み、リンク先のメモリファイルが実在するか確認する。存在しないファイルへの参照を報告するdescription が内容と合っているか簡易チェックする（ファイルを読んで比較する）Glob で全列挙し、MEMORY.md に載っていない孤児ファイルが無いか確認する。索引だけを母集団にすると、ディスク上にあるが索引に無いメモリは永遠に見えない（#492）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] は「実行者がパスを持たない」という状態であって、逃げ道ではない。
[Skipped] を返したら、パスを持つ委譲元はパスを渡して再委譲する。[Skipped] をそのまま最終報告へ持ち上げてはならない[Skipped] が残るのは、実行環境そのものにメモリ領域が与えられていない場合だけであるこれは規範であって機構ではない（受容する性質）。実行者が「パスを持たない」「読んだが整合していた」と偽ることを、文書は反証できない。防御は 2 つだけ — 根拠を要求すること（偽るコストを上げる）と、Skipped を可視化すること（黙って消えられなくする）。--no-verify と同格の best-effort として扱う。
→ npm run governance:check（G7・#587）が機械検査する。ここでは実行しない（マッチ 0 件の検知。glob 意味論は harness の配送判定の近似であることはスクリプト側に明記済み）。
→ npm run governance:check（G8・#587）が機械検査する。ここでは実行しない。
「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 にしておけば楽」という抜け道になる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 ゼロ）は省略してよい。サマリーは常に出す（根拠行を含む）workspace/plan.md の完成後、実装着手前に使用。計画の影響範囲・不変条件・スコープの漏れを検証する。
GitHub issue から作業を開始するときに使用。実装の前段階（ブランチ作成・調査・計画・計画レビュー）までを行う。
コード変更を伴うタスク（機能追加・バグ修正・リファクタリング）の実装時に使用。実装からコミット作成まで自律的に行う（計画が要る変更は /start-issue へ）。
開発サイクル完了時（実装・レビュー・追加修正まで済んだ後）に使用。教訓の抽出・残タスクの振り分け・RETROSPECTIVE.md 更新を行う。
UI モード・状態遷移・ガード条件の追加・変更時、または計画レビュー時に使用。既存モードとの直交性・リセット経路・入力分岐・SPEC §8.6 整合を検証する。
worker スレッド・channel・フレーム drain・Tauri listener・スレッド/窓をまたぐ共有状態・フレーム内 live-read を追加/変更したとき、または async 関数を追加/変更したとき、あるいは計画レビュー時に使用。送信から適用までの窓での状態競合リスクを検証する。