Project Health Check

放置されると静かに危険が積み上がる項目を、一度にまとめて棚卸しするスキル。目的は「異常を見つけて驚かせること」ではなく、やるべきことを優先度付きの短いリストにして、次の行動につなげること。異常が無ければ「異常なし」と一言で終えてよい——毎回長いレポートを出すと読まれなくなる。

Step 1: 安全網の自己点検

最初に、このプロジェクトの安全網自体が劣化していないかを確認する。時間が経つと「誰かがsettings.jsonを触ってdenyが消えていた」「hookのファイルが消えていた」という静かな劣化が起きうるが、安全網は消えても何も起きない（起きなくなるだけ）ので、定期点検以外に気づく機会がない。

python3 scripts/verify_safety_net.py

このスクリプトが無い場合（テンプレート外のプロジェクト等）は、最低限 .claude/settings.json の permissions.deny にベースライン（rm -rf, force push, git reset --hard 等）が残っていること、hooks に deny_dangerous_bash.py が設定されていてファイルが実在することを手で確認する。

失敗・欠落があれば、それはこの健康診断で最優先の報告事項（Step 3の「今すぐ対応」）。何がいつから守られていなかったかをユーザーに平易に伝え、テンプレートの状態への復旧を提案する。

Step 2: 点検項目を集める

以下を確認する。使えないもの（GitHub未使用、gh 未認証等）はスキップし、スキップした事実を報告に含める（「見ていない項目」を「問題なし」と誤解させない）。

GitHub側（gh CLIを使用）

gh pr list --author app/dependabot --state open   # 未処理のDependabot PR
gh api repos/{owner}/{repo}/dependabot/alerts --jq '[.[] | select(.state=="open")] | length'   # セキュリティアラート（権限が無ければスキップ）
gh run list --limit 10   # 直近のCI実行。失敗が続いていないか
gh pr list --state open   # 長期間放置されているPR

ローカル

• コミットSHA/digestで固定しているCI依存の陳腐化: .github/workflows/*.yml の uses: がコミットSHA固定の場合、Dependabotが更新PRを出すので通常はここでの手作業は不要。ただし run: 内でdocker imageをdigest固定している場合（例: secret-scan.yml の gitleaks）はDependabotの追従対象外なので、ここで手動確認する。最新版は gh api repos/<owner>/<repo>/releases/latest --jq .tag_name 等で調べ、大きく遅れていれば更新を提案する（バージョンを上げるだけでなく、コメントに残した旧digestとの差分を確認し、新digestに固定し直す）。
  • 更新前にライセンスが変わっていないかを確認する: gh api repos/<owner>/<repo>/license --jq .license.spdx_id がこれまでと違う値（MIT 等の一般的なOSSライセンスから、NOASSERTION や独自ライセンスへ）になっていたら、無料利用に条件が付いた可能性がある。実例として gitleaks-action（gitleaks CLIとは別リポジトリ）はv2.0.0でMITから独自ライセンスに変わり、Organizationでの利用にライセンスキー登録を要求するようになった。ライセンスが変わっている場合はその場で固定し直さず、「新しいバージョンは利用条件が変わっている可能性がある」とユーザーに伝えて判断を仰ぐ——バージョンを上げる/上げないは技術的な当たり外れの問題ではなく、登録や費用が発生しうる意思決定なので、エンジニアが常駐しないチームでは特に無自覚な追従を避ける
• 依存の脆弱性: スタックに応じて npm audit / pip-audit / govulncheck ./... / cargo audit 等（CLAUDE.mdに記載のコマンドを優先）
• 未コミットの変更が残っていないか（git status）。数日前の作業が放置されている場合、次の作業と混ざる事故のもとになる
• リモートに対して未pushのコミットが溜まっていないか（git log @{u}.. が使えれば）
• マージ済み・長期間更新のないローカルブランチ（git branch --merged 等。削除はこのスキルでは行わず、報告だけにとどめる。整理したい場合は /clean_gone を案内する）
• lint/testの実行（CLAUDE.mdにコマンドがあれば）。「今この瞬間、手元のコードは健康か」の基本線

Step 3: 優先度を付けて報告する

集めた結果を次の3段階に仕分けして報告する。技術用語には一言説明を添える。

• 今すぐ対応: 悪用可能なセキュリティアラート（severityがhigh/critical）、失敗し続けているCI、テストの失敗。放置すると事故または「壊れているのが普通」の状態につながるもの
  • secret-scan（gitleaks）の失敗はこの一括対応の対象外にし、必ず個別に扱う: まず本物の秘密情報かどうかを確認し、本物ならそのキーの無効化・再発行を先に行う（go-live-checklist Step 2と同じ方針）。誤検知だと確認できた場合のみ .gitleaks.toml にallowlistを追記する（ファイル冒頭のコメントに手順あり）。どちらか判断できない場合は、判断できないこと自体をユーザーに伝えて先に進まない
• 今週中に対応: Dependabotの更新PR（CIが通っているものは取り込みを提案）、中程度の脆弱性、放置PR
• 気に留めておく: 古いブランチ、軽微な更新、未pushコミット

それぞれについて「次の一手」を具体的に添える（例: 「『DependabotのPRを取り込んで』と言ってもらえれば、CIが通っていることを確認して取り込みます」）。ユーザーが依頼すれば、その場で対応してよい——ただしDependabot PRの取り込みは必ずCI結果（無ければローカルでのtest実行）を確認してから行い、確認できない場合はその旨を伝えて判断を仰ぐ。

Step 4: 記録する

点検した日付と主な結果を1〜3行でCLAUDE.mdの近く（docs/health-check-log.md があればそこ、無ければ作成を提案）に追記する。前回の点検からの差分（「先週2件だったアラートが5件に増えている」等）は、単発の数字より意味のある情報なので、記録があれば必ず比較する。