Claude Project Setup

新規プロジェクト（またはこのテンプレートから派生したプロジェクト）で、Claude Codeが最初から気持ちよく働けるように .claude/ 環境を整えるスキル。目的は「テンプレートを埋める」ことではなく、そのプロジェクト固有の開発フローに合った設定を対話で見極めて反映すること。テンプレートを機械的に流し込むだけでは、結局あとで手直しが発生して二度手間になる。

進め方の全体像

1. プロジェクトを自動検出する
2. 検出できなかった部分・曖昧な部分をユーザーに確認しながら埋める（開発者が常駐するかどうかもここで確認する）
3. .claude/settings.json を作る/更新する（開発者が常駐しない場合は権限・hookをより保守的に設計する）、あわせて検出した技術スタックに合わせて .gitignore を整備する
4. 繰り返し作業があれば、それぞれ Skill・Command・Subagent のどれが適切かを判断して雛形を作る
5. CLAUDE.md のビルド/実行/テストコマンド欄を埋める
6. 変更点をまとめて提示する

一度に全部をヒアリングしようとせず、段階を踏んで少しずつ確認していく。ユーザーは自分のプロジェクトについて全て把握しているとは限らないし、逆にこちらが自動検出で分かることまで聞くと煩わしいので、自動検出できることは検出し、分からないことだけ聞くというバランスを保つ。

Step 1: プロジェクトを自動検出する

以下のようなファイルをスキャンして、言語・パッケージマネージャ・テストランナー・リンター・ビルドコマンドを推測する。

• package.json（scripts フィールドに build/test/lint/dev コマンドが書かれていることが多い。packageManager フィールドや lockfile の種類（package-lock.json / yarn.lock / pnpm-lock.yaml）でnpm/yarn/pnpmを判別）
• pyproject.toml / requirements.txt / Pipfile（Poetry, uv, pip のどれか。pyproject.toml の [tool.pytest] 等でテストランナーも分かることがある）
• go.mod（Go）
• Cargo.toml（Rust）
• Gemfile（Ruby）
• リンター・フォーマッターの設定ファイル（eslint.config.js / .eslintrc*, .flake8 / ruff.toml / pyproject.toml の [tool.ruff] 等）。package.json の scripts.lint のようにコマンド自体は定義されていても、設定ファイルが存在せず実行すると失敗する状態もあり得るので、コマンドの有無と設定ファイルの有無は別々に確認する
• 既存の .claude/ 配下（settings.json, skills/, commands/, agents/）と CLAUDE.md の有無・内容
• 既存の .gitignore の内容（Step 3で追記する際、重複させたり意図を無視して上書きしたりしないため）

ここで見つけた情報は仮説として持っておき、次のステップでユーザーに確認する。ファイルが何もない完全に空のプロジェクトなら、その旨を伝えてどんな技術スタックにするかから聞く。

ロックファイル（package-lock.json 等）が1つも無い場合は、パッケージマネージャを確定できないので推測せずStep 2でユーザーに聞く。同様に、scripts.lint はあるのに対応する設定ファイルが見つからない、といった「コマンドはあるが実行できるか怪しい」状態を見つけたら、黙って無視せず後述のようにギャップとして扱う。

Step 2: 対話で補完する

自動検出で埋まらなかった項目、または検出結果が複数の解釈を許す場合（例: package.json はあるがテストコマンドが scripts に無い、ロックファイルが無くパッケージマネージャが決められない）は、AskUserQuestionなどでユーザーに確認する。まとめて聞きすぎず、自然な流れで聞いていく。AskUserQuestionが使える文脈ならそれを使い、使えない場合（ツールが利用できないサブエージェント文脈など）は通常の会話文で同じ内容を質問すればよい——手段よりも「ユーザーに確認する」という目的を優先する。

scripts.lint はあるのに設定ファイルが見当たらない、のような「検出はできたが実際に動くか怪しい」項目については、ユーザーに直すよう強制する必要はない。気づいたことをそのままStep 5のCLAUDE.mdやStep 6の報告で一言触れておけば十分——プロジェクトの状態を偽って「動く」と書かないことが大事。

使うAIツールの確認

Claude Code以外のAIコーディングツール（Codex、Cursor等）も併用するかを確認する。併用する場合、.claude/settings.json のdenyやhookはそれらのツールでは一切強制されない（安全ルールはルート AGENTS.md 経由の指示ベースになる）ため、次の2点をセットアップに反映する：

• CI・ブランチ保護（Step 3の「GitHubを使う場合」）の優先度を一段上げる——ツールに依存しない唯一の強制層になるため、GitHubを使わない構成なら再考を促す
• 運用ルールをCLAUDE.mdに書くときは、安全に関わるものは AGENTS.md 側に書く（CLAUDE.mdはClaude Codeしか読まない。AGENTS.mdの冒頭に書かれた一本化の方針に従う）

Step 6の報告でも、Claude Codeと他ツールで守られる範囲が違うこと（READMEの「使うAIツールによる強制力の違い」）を必ず伝える。

開発体制の確認（非エンジニアモードの判定）

このステップでもう一つ必ず確認したいのが「このプロジェクトに開発者が常駐するか」。例えば「開発者がおらず、Claude Codeにコードを書かせて非エンジニアが運用する」「エンジニアが1人だけで、その人が離脱したら誰も中身を見られない」といった体制では、Step 3以降で提案する内容を変える必要がある——コマンドの意味やリスクを判断できる人が周りにいない前提に立つと、権限設計やhookの積極性が変わってくるため。

AskUserQuestionなどで直接尋ねる。技術的な聞き方ではなく、「このプロジェクトのコードに何か問題があったとき、気づいて直せるエンジニアは常駐していますか？」のように相手が答えやすい聞き方をする。曖昧な返事（「今はいないが将来採用予定」等）の場合は、現時点でエンジニアがいない状態として扱う——将来の話より今のリスクを優先する。

この確認結果を「非エンジニアモード」として以降のステップに反映する。エンジニアが常駐すると分かった場合は、今まで通り技術的な判断はユーザーに委ねる場面を増やしてよい。

このステップで特に聞きたいのは「繰り返し行う作業」。例えば：

• デプロイ手順
• 特定のフォーマットでのコードレビュー
• DBマイグレーションやシードデータ投入
• 決まった構成のドキュメント生成
• 定型的な調査・リサーチのフロー

これらが挙がったら、それぞれについて Skill / Command / Subagent のどれとして実装するのが自然か を判断する。判断はこちらが主体的に行ってよいが、迷う場合はユーザーに聞く。判断の目安（絶対のルールではなく、あくまで目安）：

• Command（.claude/commands/*.md）: 1つのアクションで完結する定型操作。引数を受け取ってすぐ実行に移るような、手続きが短くほぼ分岐のないもの。「/deploy」「/lint-fix」のようなショートカット向き。
• Skill（.claude/skills/*/SKILL.md）: 複数ステップにまたがる再利用可能なワークフロー。状況に応じた判断が必要だったり、スクリプトや参照資料（scripts/, references/）を伴う可能性があるもの。トリガーの文言だけで自動的に発動してほしい場合もこちら。
• Subagent（.claude/agents/*.md）: 特定の役割に特化し、使えるツールセットを絞ったり、メインの会話とは別の文脈で動かしたいもの。例えば「コードレビュー専任」「リサーチ専任」など、responsibility を明確に分離したい場合。

どれか一つに決め打ちする必要はなく、複数組み合わせても構わない（例: Skillの中からSubagentを呼ぶ）。作りたいものが無ければ、このステップはスキップしてよい——空のプロジェクトに使いもしないテンプレートを量産しても意味がない。

Step 3: .claude/settings.json を作る/更新する

検出したツールチェーンに応じて、安全に許可してよいコマンドを permissions.allow に提案する。例えば Node.js プロジェクトなら Bash(npm test:*), Bash(npm run lint:*), Bash(npm install:*) や、読み取り系のgitコマンド（git status, git diff, git log 等）のように、実行しても状態を壊さない・すぐ終わるコマンドを中心に許可する。破壊的な操作（rm -rf, git push --force など）は決して自動で許可リストに入れない。

このテンプレートの settings.json には、スタックを問わず危険な操作（rm -rf, git push --force, git reset --hard, git clean 等）と秘密情報の読み取り（.env, 秘密鍵, ~/.ssh 等）をブロックする permissions.deny のベースラインが最初から入っている。さらに、permissionルールは前方一致なのでフラグ後置の変種（例: git push origin main --force）をすり抜けてしまうことへの対策として、コマンドをトークン解析してフラグの位置に関係なく破壊的操作をブロックする PreToolUse hook（.claude/hooks/deny_dangerous_bash.py、回帰テスト同梱）も設定済みである。

このベースラインの扱いは開発体制で変わる（Step 2の判定を使う）：

• 非エンジニアモード: 削除・縮小・無効化しない。編集はマージで行い、denyとhookはプロジェクト固有の危険操作（本番DBへのマイグレーション実行コマンド、破壊的なデプロイコマンド等）を追加する方向にだけ動かす。
• エンジニアが常駐する場合: ベースラインは初期値であって聖域ではない。このブロックはエンジニアの正当なワークフロー（rebase後の git push --force-with-lease、実験を捨てる git reset --hard、git clean 等）とぶつかることがあるので、ユーザーから明示的な依頼があれば、そのルールを外すと何が守れなくなるかを説明した上で個別に緩和してよい。典型例: force-with-lease だけ許可したい → hookの --force 判定を「--force-with-lease は除外」に修正し、denyの Bash(git push --force:*) はそのまま残す（with-leaseはprefix不一致なので通る）。緩和はこのように依頼されたルール単位で行い、「邪魔だから」と一括で消さない。セットアップの対話で先回りして緩和を提案する必要はない——実際にブロックに当たってから調整すれば十分。

どちらのモードでも、hookの検出パターンを変更した場合は .claude/hooks/test_deny_dangerous_bash.py のテストケースを緩和内容に合わせて更新し、python3 .claude/hooks/test_deny_dangerous_bash.py で回帰テストを必ず実行する（緩和した挙動も「ブロックされないこと」をテストとして固定する）。

npm run dev や npm start のようにサーバーを起動して常駐させるコマンドは、壊れはしないが「終了しないプロセスを勝手に立ち上げてよいか」という別種の判断が入るので、機械的に他のコマンドと同列に許可リストへ入れず、必要そうであれば一言確認してから加えるくらいの慎重さでよい。

hooks はユーザーから明示的な要望（「コミット前に必ずlintを走らせたい」等）があれば追加し、無ければ触らない。hookは自動化された振る舞いを強制する仕組みなので、要望のないhookを勝手に仕込むとユーザーの意図しない動作を引き起こしかねない。

既存の settings.json がある場合は中身を読み、上書きではなくマージする形で編集する。特に enabledPlugins のような既存フィールドを消さないよう注意する。

enabledPlugins の "security-guidance@claude-plugins-official" と "commit-commands@claude-plugins-official" は、プロジェクトの性質を問わず常に true にする（該当キーが無ければ追加する）。他のプラグインと違って、これらは検出結果やユーザーの体制に応じて要否が変わるものではなく、どんなプロジェクトでも入れておいて損がない基礎的な安全網・作業効率化なので、判断や確認を挟まず毎回有効化してよい。

• security-guidance@claude-plugins-official: 編集・保存のたびに危険なコード パターン（yaml.load, pickle.load, 生の innerHTML, ハードコードされた秘密情報など）を即座に警告し、ターン終了時にはLLMによる差分レビュー、git commit時にはコードベース横断のエージェント的レビューまで行う3層構成のセキュリティチェック。Step 3の「非エンジニアモードの場合の追加対応」で説明する安全網の中核はこのプラグインが担うので、有効化した上で積極的に活用する（後述）。
• commit-commands@claude-plugins-official: /commit /commit-push-pr /clean_gone などのコミット・PR作成・ブランチ整理コマンドを提供する。非エンジニアモードでは特に、担当者が生のgitコマンドを手打ちする場面を減らせるので価値が大きい。

また、GitHubを使ってチーム開発をするかどうかをユーザーに確認する。する場合は、PRベースのレビューが発生する前提になるので、enabledPlugins の "github@claude-plugins-official" と "pr-review-toolkit@claude-plugins-official" を true にする（該当キーが無ければ追加する）。個人開発でGitHubを使わない、あるいはPRレビューをClaude Codeに任せる予定が無い場合は、無効のままにしてよい——使わない機能を有効化しても混乱を招くだけなので、必要性を確認してから有効化する。

GitHubを使う場合: CI・依存メンテナンス・ブランチ保護

hookやセキュリティレビューのプラグインは、すべて「Claude Codeのセッションの中」でしか効かない。設定が同期されていない別環境やGitHub上での直接編集はすり抜けるので、GitHubを使うプロジェクトではリポジトリ側にも検査の層を作る。具体的な雛形と注意点は references/ci-workflow-examples.md を読んでから作業すること。やることは3つ：

1. .github/workflows/ci.yml の生成: Step 1で検出したlint/test/auditコマンドからCIワークフローを作る。検出できていないコマンドを想像で書かない——初回から失敗し続けるCIは無いより悪い。lint/testが何も検出できていない場合でも、スタックに依存しないシークレットスキャン（gitleaks）のジョブだけは入れる（詳細は参照ファイルの「シークレットスキャン」節）。あわせてGitHubのSecret scanning / Push protectionの有効化も案内する。
2. .github/dependabot.yml の生成: 依存パッケージの脆弱性・更新を自動でPRとして届けさせる。誰もCVE情報を見ない体制でも、更新が「届く」状態にはなる。届いたPRを誰がどう処理するかの運用文をStep 5でCLAUDE.mdに残す。
3. ブランチ保護の案内: CIを置いただけでは失敗しても取り込めてしまう。デフォルトブランチへの直push禁止とCI成功のマージ条件化を、GitHub UIの手順（または合意の上で gh CLI）で案内する。リポジトリ内のファイルだけでは完結しない設定なので、案内した/しなかった・設定できた/できなかったをStep 6の報告に含める。

非エンジニアモードではこの層の重要度が一段上がる（ローカルの安全網をすり抜けた変更を最後に止める役割のため）ので、1〜3を省略しない。通常モードでは、既にCIが存在するなら重複して作らず、既存のCIにaudit系のジョブが無ければ追加を提案する程度にとどめる。

他にも以下のプラグインは、Step 1の検出結果からプロジェクトの性質がある程度読み取れるので、GitHubのケースと違って毎回ユーザーに確認する必要はなく、判断できるならこちらで決めてよい（迷う場合だけ聞く）：

• context7@claude-plugins-official: バージョン固有の最新ドキュメントを取得するプラグイン。外部ライブラリ・フレームワークに依存している（package.jsonのdependencies, pyproject.tomlの依存関係等が一定数ある）プロジェクトなら基本的に有効化して問題ない。依存がほぼ無い学習用スクリプトのような場合は無理に有効化しなくてよい。
• feature-dev@claude-plugins-official: コードベース探索・設計・品質レビューを含む機能開発向けワークフロー。複数ファイル・複数レイヤーにまたがるアプリケーション（Webサービス、API、それなりの規模のCLIツール等）では有効化する価値が高い。単一ファイルのスクリプトのような最小構成のプロジェクトでは、有効化しても使う場面が少ないので見送ってよい。
• frontend-design@claude-plugins-official: UI/UX実装のためのフロントエンドデザイン支援。検出した技術スタックにフロントエンド要素（React/Vue/Next.js等のUIフレームワーク、src/componentsのようなディレクトリ構成等）が無ければ無効のままにする。バックエンドAPIのみ、CLIツールのみのプロジェクトでは基本的に不要。

これらを有効化した場合も、Step 6で「何を・なぜ有効にしたか」を必ず報告する——ユーザーが把握しないまま静かに増えていくのが一番良くない。

非エンジニアモードの場合の追加対応

Step 2で「開発者が常駐しない」と分かった場合は、通常モードより一段保守的な設計にする。判断できる人が周りにいない前提なので、「便利だが分かる人が見ればリスクを許容できる」設定より「多少不便でも事故らない」設定を優先する。具体的には次の3点を必ず検討する。

1. 危険な権限を誤って許可しない

permissions.allow に入れるコマンドは、通常モードよりさらに絞る。読み取り系コマンド（git status, git diff, npm run lint, npm test 等、状態を壊さないもの）は許可してよいが、ファイルやリポジトリの状態を変更するコマンドは慎重に扱う。rm -rf, git push --force, git reset --hard, git clean のような汎用的に危険な操作はテンプレートの permissions.deny ベースラインで既にブロックされているので、非エンジニアモードではそれに加えてプロジェクト固有の取り返しがつかない操作（本番DBのマイグレーション実行、データ削除を伴うスクリプト、破壊的なデプロイコマンド等）をヒアリングから拾い、denyに追記して「間違って許可リストに追加されても弾かれる」二重の防御にする。迷うコマンドは allow にも deny にも入れず、都度確認（デフォルトのask）に委ねる——非エンジニアモードでは「速度より安全」を優先してよい。

権限を提案する際は、コマンドの技術的な意味だけでなく「これを許可すると何が起きうるか」を一言添えて説明する。例えば Bash(git push:*) を許可するなら「GitHub上のコードを書き換える操作を、確認なしで実行できるようになります」のように、技術用語に不慣れな相手でも影響範囲を判断できる言葉で伝える。

2. lint/testが誰にも実行されないまま放置されるのを防ぐ

通常モードでは「hookはユーザーが明示的に頼まない限り追加しない」としているが、非エンジニアモードではこの方針を変える。lint/testを見る人がいない組織では、Claude Code自身がコードを書いた後にlint/testを実行し忘れると、誰も気づかないまま壊れたコードが積み上がってしまうため。検出したlint/testコマンドがあれば、コミットやpush前に自動実行して失敗時はブロックするhook（例: git commit や git push を含む Bash コマンドを対象にした PreToolUse hookで、lint/testを実行し失敗したら非ゼロ終了で止める）を積極的に提案する。ユーザーには「こういうhookを追加しようと思いますが良いですか」と一言確認すれば十分——毎回細かい実装の是非を聞く必要はない。

lintやtestのコマンドがそもそも検出できなかった場合は、無理にhookを作らず、その旨をStep 6で伝える（品質を保証する手段が今は無い、という事実を隠さない）。

3. セキュリティレビューの仕組みを用意する

コードに詳しい人がいないと、脆弱なコードや秘密情報（APIキーやパスワードなど）の混入に誰も気づけない。ここは独自のhookを組み立てるより、既に有効化している security-guidance@claude-plugins-official（前述の通り常時有効）を主軸に据える方がずっと確実——正規表現の自作チェックより、編集のたびの即時パターン警告・ターン終了時のLLM差分レビュー・コミット時のコードベース横断レビューという3層を持つこのプラグインの方が検出範囲が広く、保守の手間もかからない。

• 非エンジニアモードだと分かったら、security-guidance が具体的に何をしてくれるか（保存するたびに危険なコードに気づいて教えてくれること、コミットのタイミングでもう一度チェックが入ること）をStep 6の報告で必ず一言説明する。有効化されているだけで安心してしまい、実際に何をしているか分からないのが一番良くない。
• そのプロジェクト固有に気をつけたいルール（例:「顧客テーブルへの書き込みは必ずこの関数を経由する」等）があれば、.claude/claude-security-guidance.md にMarkdownで書いておくとレビュー時にそのルールも加味されるようになる。非エンジニアモードでは、ヒアリングの中でそうした固有ルールが出てきたらこのファイルへの追記を提案する。ルールが特に無ければ無理に作る必要はない。
• GitHubでチーム開発する場合（Step 3で確認済みのはず）は、pr-review-toolkit@claude-plugins-official に加えて、ビルトインの /security-review スキルをマージ前に必ず実行する運用を、Step 5でCLAUDE.mdに明記する。誰か人間がレビューする代わりに、Claude自身にレビューさせる運用をデフォルトにするということ。
• これらはあくまで人間のレビューの代替であり完全な代替にはならない、という限界も併せてStep 6で伝える。過信させないことが大事。

.gitignore の整備

Step 1で検出した技術スタックに応じて、Gitで追跡すべきでないものを .gitignore に追記する。空のテンプレートのまま技術スタックが決まっていない場合は無理に埋めず、後述の「技術スタックを問わず追加してよいもの」だけにとどめる。

• 技術スタックを問わず追加してよいもの: .env / .env.*（秘密情報の誤コミット防止）、.DS_Store（macOS）、.claude/settings.local.json（個人用のローカル設定であり、コミット対象の .claude/settings.json とは役割が違う）
• Node.js系と分かったら: node_modules/, ビルド成果物（dist/, .next/, build/ など、フレームワークに応じて）
• Python系と分かったら: __pycache__/, *.pyc, 仮想環境ディレクトリ（.venv/, venv/）, *.egg-info/
• Go/Rust/Ruby等も同様に、そのエコシステムで一般的なビルド成果物・依存キャッシュのディレクトリを追加する

既存の .gitignore に同じ内容がある行は重複させず、既存の記述（コメントや独自の除外設定）は消さずに末尾へ追記する形でマージする。何を追加したかはStep 6の報告に含める——ユーザーが把握していない変更を静かに紛れ込ませない。

Step 4: 雛形ファイルを作成する

Step 2 で Skill/Command/Subagent を作ると決めたものについて、最低限の雛形を作成する。雛形止まりで終わらせず、ユーザーとの対話で分かった具体的な手順や判断基準を可能な限り書き込む。中身が空っぽの雛形は結局使われないまま放置されがちなので避ける。

• Command: .claude/commands/<name>.md（frontmatterに description 、本文に実行手順）
• Skill: .claude/skills/<name>/SKILL.md（frontmatterに name と description。description にはトリガー条件を具体的に書く）
• Subagent: .claude/agents/<name>.md（frontmatterに name, description, 必要なら tools の絞り込み）

作る雛形がデプロイまたはDBマイグレーションに関わる場合は、単なる手順の書き写しにせず、次のガードレールを本文に必ず組み込む。非エンジニアチームで最も取り返しがつかない事故はこの2つで起きるため。

• デプロイ手順の冒頭に「テスト（検出済みなら）を実行し、失敗したらデプロイを中止する」ステップを置く
• 「前のバージョンに戻す方法」（ホスティングサービスの切り戻し機能、再デプロイ手順等）をユーザーから聞き出して雛形内に明記する。壊れたときに参照されるのはこの記述と safe-rollback スキル（テンプレート同梱）なので、ここが空だと切り戻せない
• マイグレーションは「実行前に、何がどう変わるかを平易な言葉で説明して明示的な承認を得る」「down migrationまたはバックアップの存在を確認してから実行する」ことを手順に含める

Step 5: CLAUDE.md を更新する

このテンプレートの CLAUDE.md には次のようなプレースホルダーがある：

- **Build/run/test commands** — how to install dependencies, start the app, run tests, and lint
- **Architecture overview** — the high-level structure and how components interact
- **Key conventions** — any naming, formatting, or workflow rules specific to this project

Step 1・2で判明したビルド/実行/テスト/lintコマンドで、これらの箇条書きを具体的な内容に置き換える。すでに具体的な記述がある項目は上書きしない。アーキテクチャ概要やキー・コンベンションまで踏み込むかはプロジェクトの成熟度次第——コードがまだ無いなら無理に埋めず、分かる範囲（技術スタックの選定理由など）だけ書く。

非エンジニアモードの場合は、「Key conventions」やその近くに、Step 3で組んだ安全網（lint/testを強制するhook、security-guidanceによるセキュリティレビュー、マージ前の /security-review 実行など）を運用ルールとして明記する。これはClaude Code自身が将来このプロジェクトを触るときに安全網の存在を思い出すための記録であり、非エンジニアの担当者が「何がどう守られているか」を後から確認できるようにする意味もある。

あわせて非エンジニアモードでは、週1回の定期点検の運用もCLAUDE.mdに書き込む：「毎週決まった曜日に『健康診断して』とClaude Codeに依頼する（project-health-check スキルが発動し、Dependabotの更新・セキュリティアラート・CI失敗などを棚卸しする）」。誰の記憶にも頼らず、カレンダーの繰り返し予定1つで回る運用にすることが狙い。

さらに非エンジニアモードでは、次のテスト規約をCLAUDE.mdに必ず書き込む：「新しい機能や修正には、その動作を確認するテストを必ず添える。テストが書けない変更（設定のみ、見た目のみ等）の場合は、その旨と手動での確認方法を報告に明記する」。理由: この体制ではテストを書けと言える人がいないため、放っておくとテストの無いコードが積み上がり、lint/test強制hookもCIも「常に緑＝何も検査していない」形骸になる。防御層全体の実効性がこの規約に懸かっているので、通常モードのように「ユーザーの要望があれば」ではなく既定で入れる。

Step 6: 変更点をまとめて提示する

作成・変更したファイルの一覧と、それぞれの狙いを短くまとめてユーザーに伝える。特にpermissionsやhooksなど動作に影響する変更は、何を許可したか明示する。

非エンジニアモードの場合は特に、技術用語を最小限にして「何を防げるようになったか」「何は防げないか」を平易な言葉でまとめる。例えば「うっかりコードを壊すコマンドは事前にブロックされます」「テストが通らないコードはコミットされません」「これはあくまで簡易チェックなので、重大な変更は人にも見てもらうことをおすすめします」のように、相手が自分たちの安全性をどこまで信頼してよいか判断できる報告にする。security-reviewやlint/testのhookが「無い」項目があれば、それも隠さずに伝える。

あわせて、テンプレートに同梱されている2つの運用スキルの存在を必ず紹介する。

• safe-rollback: 「アプリが壊れた・元に戻したいと思ったら、原因を自分で探そうとせず、そのまま『壊れたので戻したい』とClaude Codeに伝えれば、安全な手順で復旧します」——この一言があるだけで、事故時にユーザーが危険な自己流の回復（強制的なリセット等）へ走るのを防げる。
• go-live-checklist: 「アプリを公開したくなったら『公開したい』と伝えれば、公開して大丈夫かの監査が先に走ります」——公開はこのチームにとって最も重大な操作なので、監査を挟む習慣を最初に作っておく。

非エンジニアモードでは、これに加えて docs/working-with-claude-code.md（許可ダイアログの判断のしかた・報告の読みかた・頼みかたのコツをまとめた人間向けガイド）をチーム全員が最初に読むよう案内する。安全網の半分は人間側の行動でできているので、このガイドの案内を省略しない。