verify-bootstrap

verify-bootstrap — repo に機械ゲートを立てる

人間がコードを読む速度は、AI が書く速度に追いつかない。だから構造的な正しさの判定は 機械に移す。この skill は repo ごとに、 その時点で最良の検査ツールを立てる。

この skill が持たないもの（設計上の中核）

ツール名の一覧を持たない。言語の検出テーブルも持たない。 ツールは陳腐化する （flake8 + black + isort → ruff は 2 年で起きた）。固定表を持てば表が腐り、 腐った表が repo に配られる。

持つのは 調べ方と契約だけ:

• repo の実態を列挙する手順（静的な言語リストを参照しない）
• category ごとに何を search-first に問うか
• 生成物 .claude/verify.sh の契約（global hook がこれだけを知る）
• strictness と陳腐化検知の規律

結果として、この skill が書かれた時点で存在しなかった言語・ツールでも同じ手順で回る。

モード

モード	起動条件	やること
bootstrap	.claude/verify.sh が無い	Step 1–6 を通す
audit	既にある（--audit / 「棚卸し」）	Step 1 を再実行し、.claude/verify.md の選定を search-first で引き直して差分を提案

Step 1 — repo の実態を列挙する（検出、静的表なし）

推測しない。実測する。

# 追跡ファイルの拡張子分布（上位）— 生成物・依存ディレクトリは除く
git ls-files | sed -n 's/.*\.\([A-Za-z0-9_]*\)$/\1/p' | sort | uniq -c | sort -rn | head -20
# ビルド/依存マニフェストの実在
git ls-files | grep -iE '(^|/)(pyproject\.toml|package\.json|Cargo\.toml|go\.mod|Gemfile|pom\.xml|build\.gradle.*|\*\.xcodeproj|Package\.swift|mix\.exs|composer\.json|Makefile|justfile)$' 
# 既存のゲート痕跡（重複導入の防止）
git ls-files | grep -iE '(pre-commit-config|lefthook|\.github/workflows/|trunk\.yaml|\.golangci|\.eslintrc|ruff\.toml)'

上のマニフェスト grep は発見の補助であって権威ではない。1 本目の拡張子分布が正本で、 grep に載っていない生態系が出てきたらそれを Step 2 にそのまま渡す（表を編集して この skill に足さない — 表を持たないことがこの skill の設計）。

散文・設定・スキーマも対象に含める。コードだけがゲートの対象ではない （Markdown の日本語 prose、YAML、CI 定義、シェルスクリプトはいずれも機械検査できる）。

Step 2 — category ごとに現時点の最適ツールを調べる

検出した生態系ごとに、6 category を埋める。埋まらない category は「無い」と明記する （空欄と「その言語には該当がない」は別物）。

category	問い
format	整形の正規化。差分ノイズを消し、レビュー対象を意味の変化だけにする
lint	構造的な誤り・複雑度・デッドコード
type check	型で表現できる契約。型なし言語なら「型注釈を段階導入する手段があるか」
security	危険な構文・秘密の混入（秘密スキャンは harness 側にもあるので重複を確認）
dependency	既知脆弱性・未使用依存・ライセンス
test	テストランナーとカバレッジ測定

予算系 rule（閾値を要する複雑度・関数/ファイル長・bundle サイズ等）は既定に頼らない。 主要 linter は予算系を既定 OFF で出荷するのが通例（閾値が opinionated なため）— 「最大 strict」の運用では構造的に素通りする（2026-08-28 実測でカバー 0 を確認 — 数値の正本は ADR-0056）。lint category を埋めるとき明示的に問う。stack の標準 toolchain が 既定で予算を持つ場合（例: SwiftLint の cyclomatic_complexity / file_length）は追認して verify.md に 1 行記録するだけでよい。閾値は global に定めない — repo 間で分布は数倍 割れる（同実測、正本は ADR-0056）。 既存 corpus 全件の分布を実測してから、現状の外れ値だけが赤くなる位置に置く （skill review-to-lint の免除境界の原則。ゲートを初日に赤くする閾値は設計ミス）。