Claude Code に毎回同じ指示をしなくて済むように、運用の土台をリポジトリ 1 本にまとめた

この記事はシリーズ「自律運用の土台を 1 本まるごと読む: claude-code-repository-base 全解剖」の第 1 回（全 10 回）です。

Claude Code に毎回同じ指示をしなくて済むように、ルール・フック・スキル・ツールを一式にまとめた公開リポジトリ kai-kou/claude-code-repository-base（MIT）を、実ファイルを引用し実際にコマンドを動かしながら読み解く連載です。掲載する実行結果と数値はすべて各回の執筆時点で採取し直し、検証したベースのコミット SHA を各回の冒頭に記します。

シリーズ全体の目次（クリックで開く）

• 第 1 回 Claude Code に毎回同じ指示をしなくて済むように、運用の土台をリポジトリ 1 本にまとめた（この記事）
• 第 2 回 git push origin main | tee log で保護が素通りしていたので、コマンド分割で塞ぎ直した（公開予定）
• 第 3 回 ベースを別リポジトリへ配る 2 経路を dry-run で動かす（apply-to-repo.sh と bootstrap.sh）（公開予定）
• 第 4 回 Stop フックを 5 本並べたら最初の 1 本しか読まれなかったので、ルーター 1 本に集約した（公開予定）
• 第 5 回 コンテキスト圧縮で作業が消えるのを、圧縮前後の二段 WIP コミットで防いだ（公開予定）
• 第 6 回 sandbox.enabled を true にしてもクラウドでは bwrap が無く、許可リスト外へ素通りだった（公開予定）
• 第 7 回 「確認してよいですか」を 6 種類に限定したら、それ以外は全部自律実行になった（公開予定）
• 第 8 回 ルールと教訓を増やし続けないために、常駐バイト予算と「昇格＝物理削除」を機械強制した（公開予定）
• 第 9 回 複数エージェントが同時に書くホワイトボードを、個別ファイル＋単一集約者で壊れなくした（公開予定）
• 第 10 回 10 回分を読み終えたら、自分のリポジトリに最初に持ち込む 3 つはどれか（公開予定）

検証時点: base kai-kou/claude-code-repository-base（MIT） HEAD e341b48（2026-09-04 JST）

対象読者は、Claude Code を業務で使い始め、セッションごとに同じ指示を繰り返している開発者です。

Claude Code を業務で使い始めた人は、たいてい同じところでつまずきます。セッションを開くたびに「main に直接 push しないで」「作業ブランチを切って」「PR を作る前に確認して」と、前回と同じ指示を書き直す羽目になるのです。指示を CLAUDE.md に書けば多少はましになりますが、フックも権限設定も運用ルールも自分で組み上げるのは骨が折れます。

これを一式でまとめて配布できないか、と考えた人がすでにいます。この連載で読み解く kai-kou/claude-code-repository-base（MIT）は、その答えの1つです。全10回かけて、実際にこのリポジトリを手元で動かしながら中身を読んでいきます。

このリポジトリが解決すること

README.md の冒頭にはこう書かれています。

Claude Code に「毎回同じ指示」をしなくて済むようにする、自律運用の土台。

ルール・スキル・フック・ツールを一式で導入し、実装から PR・マージまでを人間の確認を挟まず進める運用を、安全弁つきで敷くための汎用ベース。GitHub リポジトリならドメインを問わず使える。

「安全弁つきで」という一文が本連載の軸になります。README は導入によって得られるものを、保証レベル という2段階で説明しています。

• 🔒 機械的に強制されるもの: フックやスクリプトが実際にブロックする。たとえば main / master への直接 push は .claude/hooks/pre-git-push-check.sh が物理的に止めます。指示を忘れても事故が起きません。
• 📋 運用ルールとして定義されるもの: Claude がそれに従って動く前提のルール。たとえば「確認してよいですか、と聞いてよいのは6種類の場面だけ」という方針は docs/rules/user-confirmation-minimization.md に定義されていますが、これはコードが強制しているわけではなく、Claude がルールを読んで従う設計です。

この2段階を区別せずに「自動化されている」と一括りにすると、どこまでが機械的に保証され、どこからが運用ルール頼みなのかが見えなくなります。連載を通じて、各回の題材がどちらの保証レベルに属するかを都度確認していきます。

リポジトリの中身を数える

読み解く前に、まず規模感を掴んでおきます。実測は今回のセッションでこのリポジトリを再 clone し、その場で数え直したものです。

対象	実測値
.claude/hooks/*.sh	22 本
.claude/hooks/lib/*.sh	2 本
hooks 合計行数（*.sh 全体）	3,970 行
docs/rules/*.md（トップレベルのみ）	53 本
docs/rules/**/*.md（lessons/ 込み）	63 本
docs/rules 合計バイト数	851,482 バイト
docs/rules 合計行数	10,707 行
.claude/rules/*.md（Hot 層・全セッション常駐）	13 本
.claude/skills/（スキル本数）	19 個
tools/*.py	49 本・17,454 行
tools/*.sh	11 本・1,694 行

.claude/skills/ の内訳は apply-base audit-runner checkpoint claude-code-spec-sync code-review discussion-review interactive-guide pr-review-watcher project-manager project-sync research-runner retro-try-handler retrospective self-improvement-loop self-reviewer skill-audit skill-creator waiting-user-handler workflow-health-check の19個です。

数だけ見ると重厚に感じますが、docs/rules/ がトップレベル53本・約85万バイトある一方、実際に全セッションへ常時読み込まれる Hot 層（.claude/rules/）はそのうち13本だけです。残りはタスクに応じて必要なときだけ読みに行く Warm 層に置かれています。全部を常駐させるとコンテキストを圧迫するため、「常に要るもの」と「そのタスクに入ったときだけ要るもの」を分けているわけです。この分け方自体も、連載の後半（Part 4）で扱います。

全10回の地図

このリポジトリは機能ごとに読む部分が分かれているため、5部構成で10回に割っています。

Part	回	タイトル
1. 入口	第1回（本回）	運用の土台をリポジトリ1本にまとめた経緯と全体像
2. 実証編	第2回	git push origin main | tee log で保護が素通りしていた件をコマンド分割で塞ぎ直す
2. 実証編	第3回	ベースを別リポジトリへ配る2経路（apply-to-repo.sh / bootstrap.sh）を dry-run で動かす
3. フック運用編	第4回	Stop フックを5本並べたら最初の1本しか読まれなかった問題をルーター1本に集約
3. フック運用編	第5回	コンテキスト圧縮で作業が消えるのを圧縮前後の二段 WIP コミットで防ぐ
3. フック運用編	第6回	sandbox.enabled: true でもクラウドでは bwrap が無く許可リスト外へ素通りしていた件
4. ルール・思想編	第7回	「確認してよいですか」を6種類に限定し、それ以外を全部自律実行にする設計
4. ルール・思想編	第8回	常駐バイト予算と「昇格=物理削除」でルール・教訓の肥大化を機械強制で止める
5. 仕組みと出口	第9回	複数エージェントが同時に書くホワイトボードを個別ファイル+単一集約者で壊れなくする
5. 仕組みと出口	第10回	10回分を読み終えて、自分のリポジトリに最初に持ち込む3つを選ぶ

各回は冒頭にその回の前提回への1〜2行リンクを持たせます。たとえば第4回は「第2回の push ブロックを前提にする」、第9回は「連載を通じて初出のトピック」というように、依存関係が回ごとに違います。そのため、この地図さえ見ておけば、興味のある Part から読み始めても迷わずに済むはずです。全部読む必要はありません。

次回予告

第2回では、この連載で最初に実機検証する題材として main への直接 push を物理的にブロックするフック（.claude/hooks/pre-git-push-check.sh）を取り上げます。このフックには自己テスト（--self-test）が用意されているのですが、それを実際に走らせてみたところ、作った本人も気づいていなかったらしい疑陽性が1件見つかりました。パイプで結果をログに流すよくあるコマンドの書き方が、テストの検出ロジックをすり抜けていたのです。詳しい中身は次回に譲りますが、「セルフテストが緑でも安心しきれない」という話です。

この回のまとめ

同じ指示を繰り返さずに済む土台を作る、というモチベーション自体は多くのプロジェクトで共有できるものです。ただし「自動化されている」という言葉の中身は、実際には🔒（機械的に強制される）と📋（運用ルールとして定義される）という異なる強度が混ざっています。この連載では、10回を通じてこの区別を意識しながら、実際に手を動かして確認できる部分から順に読み解いていきます。

関連記事

• Claude Code screen reader mode入門 — 有効化3通りの仕組み
• Claude Codeの「壊れたループ防止」、実装まで覗いたら効いていた
• Claude Codeのhookマッチャー、ハイフン名がv2.1.195で動かなくなった

シリーズの前後の記事

• ⬅️ 前の記事: なし（この記事がシリーズの最初です）

• ➡️ 次回予告: 第 2 回 git push origin main | tee log で保護が素通りしていたので、コマンド分割で塞ぎ直した

  main への直接 push を止めるフックを実際に自己テストで回し、文字列一致では素通りしていた経路と、自己テスト自身に残っていた穴を見ます。