自社で使っているハーネス(CLAUDE.md、hooks、skills などの一式)を、Claude Code に読ませて説明してもらうための質問例です。ハーネスの構成の型ごとに5本、計10本あります。
質問の文面には、システム名や固有のファイル名を入れていません。フォルダの種類と、読ませる順番だけを指定してあるので、そのまま貼れます。実際の名前は、質問を受けた Claude がそのフォルダから拾って返します。
使う前に
読ませたいハーネスのフォルダを、Claude Desktop のプロジェクトとして開きます。演習用の dl-training-app とは別のセッションにしてください。パーミッションモードは「手動」のままにします。
どの質問でも、先頭に次の文を貼ります。読むだけにする約束と、根拠を付けさせる約束と、秘密情報のファイルを開かせない約束です。
これから質問します。ファイルは一切変更しないでください。読むだけです。 答えには根拠として「ファイルパス:行番号」を付けてください。見つからなかったことは「見つかりませんでした」と書き、推測で埋めないでください。 .env や認証情報、パスワードを含みそうなファイルは開かないでください。
返ってきた答えは、そのまま信じません。根拠に書かれた行を VSCode で開いて、書いてあるとおりかを自分で見ます。件数や本数は、自分でも数えます。Day2 で扱う「AI の自己申告に頼らない」と同じ見方です。
質問は1回に1問にします。表で返させると、抜けが見つけやすくなります。急ぐ場合は、各型の1番と4番だけ試してください。
前置きは自動で付けられます。質問の枠の右上にある「前置きつきでコピー」を押すと、上の3行と質問が続けてコピーされます。
型A 1つのリポジトリに全部入っている構成
規約の文章、機械で止める設定、決まった段取りの手順、別の会話で動く役割が、1つのリポジトリの中に同居している構成です。入口は CLAUDE.md で、全 AI 共通の入口として AGENTS.md を取り込んでいることがあります。
質問A1 部品と役割の一覧
分かりたいこと: 部品の種類と、それぞれの役割。
このフォルダは AI 開発用のハーネスです。次の順で読んで、部品ごとの役割を表にしてください。 読む順: CLAUDE.md、AGENTS.md(あれば)、規約を分けて書いたフォルダ、.claude/settings.json、.claude/ 配下の hooks・skills・agents・scripts。 列: 部品 / 置き場所 / 役割 / 種類 / 根拠。 種類は次の4つから選んでください。「常に読ませる文章」「機械で止める設定」「決まった段取りの手順」「別の会話で動く役」。 最後に、このハーネスを2文で説明してください。何のために、どんな作りか、の順です。
見る場所は CLAUDE.md の冒頭にある概要の節と、何をどこに置くかを書いた節です。後者は、質問の「種類」の答え合わせになります。
合格の目安は、表の全部の行に根拠が付いていて、4つの種類に漏れなく分かれていることです。
質問A2 場面ごとの人とAIの分担
分かりたいこと: 改修1件の流れと、人と AI の分担。
このハーネスを使う人が、改修を1件頼まれてから終わるまでを、場面ごとに表にしてください。 列: 場面 / 人がやること / AI がやること / 使う skill か agent / 出来上がるもの / 根拠。 「AI が勝手にやらないこと」と「人の承認が要るところ」には印を付けてください。 skill と agent は、定義ファイルの description に書かれた「使う条件」と「対象外」も一緒に書いてください。
見る場所は CLAUDE.md にある開発の流れの一覧と、.claude/skills/ の各 SKILL.md の description、.claude/agents/ の定義ファイルです。
合格の目安は、ブランチの作成やマージのように「AI は行わない」と明記された作業が、AI の列ではなく人の列に入っていることです。
質問A3 きっかけと自動検査
分かりたいこと: きっかけと、自動で動く検査と、止まったときの結果。
.claude/settings.json の hooks と permissions を読んで、「利用者が何をしたら、何が自動で動くか」を表にしてください。 列: きっかけ / 対象のツール / 動くスクリプト / 何を検査するか / 止めるときの結果 / 根拠。 きっかけは、セッション開始、ファイルの書き込み前、書き込み後、シェル実行前、外部サービスへの書き込み前、のように書いてください。 スクリプトは実行せず、先頭のコメントとコードを読んで答えてください。 そのあと permissions の deny・ask・allow を種類ごとに数え、代表例を3つずつ挙げてください。
続けて、動きを確かめる質問です。かっこの中は、上の表の「何を検査するか」の列から、自分の言葉で選んで入れてください。
次の3つを頼まれたと仮定して、hooks と permissions のどれが反応するか、通るか止まるか、止まるならどんな文面が返るかを、根拠つきで答えてください。実行はしないでください。 1. (保護しているはずのブランチかフォルダに、変更を頼まれた) 2. (人がやる約束になっている git 操作を頼まれた) 3. (外部サービスへの書き込みを頼まれた)
見る場所は .claude/settings.json の hooks の部分と、.claude/hooks/ の各スクリプトの先頭コメントです。テストが同梱されていれば、期待する動きがテストケースとして書かれています。
合格の目安は、きっかけごとに止められるかどうかの違いが表に出ていることです。セッション開始のフックは止めずに情報を渡すだけで、書き込み前のフックは実行を止められます。書き込み後のフックは、済んだ書き込みを取り消さず、AI に直させる形になります。
質問A4 日常で効く部品
分かりたいこと: 日常で最初に覚える部品と、普段は使わない部品。
このハーネスの中で、日常の作業で一番効いている部品を3つ選んでください。 基準は3つです。使う頻度が高いこと、無いと事故や手戻りが起きること、機械が守ってくれること。 それぞれ、なぜ選んだか、無いと何が起きるか、初めて使う人が最初に覚える呼び出し方(skill の名前、コマンド、貼る文章)を書いてください。 逆に、普段は使わなくてよい部品も2つ挙げ、どんなときだけ使うかを書いてください。
見る場所は、CLAUDE.md の開発の流れ、各 SKILL.md の description に書かれた「使う条件」、開発者向けのマニュアルのフォルダです。
合格の目安は、呼び出し方が SKILL.md に書かれた条件と一致していることです。自動では起動せず、明示的に呼んだときだけ動く skill(frontmatter に自動起動を止める指定があるもの)を、見分けられているかも確かめてください。
質問A5 文章だけのルールと機械のルール
分かりたいこと: このハーネスの強さと、穴のありか。
このハーネスのルールを、「文章で頼んでいるだけのもの」と「hooks や permissions で機械が止めるもの」に分けてください。 1. 規約の文章から、破ると実害が出そうなルールを8つ選ぶ。 2. それぞれについて、機械で止める仕組みがあるかを settings.json と hooks で探す。あれば場所を、なければ「文章だけ」と書く。 3. 「文章だけ」のうち、機械に移したほうがよいものを2つ選び、どの hook に足すとよいか案を出す。今回は書き換えない。
見る場所は規約が書かれたファイル(CLAUDE.md、AGENTS.md など)、.claude/settings.json、.claude/hooks/ です。
合格の目安は、8つ全部に「機械」か「文章だけ」が付いていて、「文章だけ」のものについて、なぜ機械化されていないかの理由が言えることです。研修 Day1 の「文脈であって設定ではない」と同じ見方で、手元のハーネスに当てはめる練習になります。
型B 複数リポジトリの共通ルールを束ねる構成
複数のリポジトリに分かれたシステムで、横断の共通事項(規約とリポジトリ間の約束)を、個々の実装セッションに確実に反映させるための構成です。正本を1か所に置き、各リポジトリには薄い入口だけを置きます。ルールごとに、機械で守るか、AI が照合するか、人が判断するかの区別が付いていることがあります。
質問B1 課題と部品の対応
分かりたいこと: 課題の分け方と、部品の対応。
このパッケージの README と、常時読み込まれるルールのファイルを読んで、ハーネスの全体像を説明してください。 1. 何を解こうとしているか(1文)。 2. 課題をどう分けているか。その分け方ごとに、扱っている部品はどれか。 3. 層に分けて説明されていれば、層ごとに、実体になっているファイルを1〜3個ずつ。 4. 設計原則が書かれていれば、それぞれ「どのファイルのどの仕組みに現れているか」を1つずつ。書かれていなければ、その旨。 根拠はファイルパス:行番号で付けてください。
見る場所は README の冒頭にある「何を解こうとしているか」にあたる節と、常時読み込まれるルールのファイルの冒頭です。
合格の目安は、README に書かれた分け方、層、原則の全部が、実際のファイルに結びついていることです。結びつかない項目が出たら、そこが README と実物のずれです。
質問B2 改修1件の段階
分かりたいこと: 段階ごとの場所、人の役割、AI の役割。
改修1件が「依頼を受ける」から「正本へ戻す」までに通る段階を、手順書を読んで、順番に表にしてください。 列: 段階 / 実行する場所 / 呼び出すコマンド / 人がやること / AI がやること / 出来上がるもの / 止まって人に聞くべきとき / 根拠。 実行する場所は、全体を見る場所か、個別のリポジトリかで書いてください。 2つの場所の違いを、書き込める範囲の違いに注目して説明してください。 手順書が見つからない段階があれば、表の該当行を空欄にして、その旨を書いてください。
見る場所は、段階ごとの手順書の冒頭にある「実行する場所」の行です。配置の違いは、全体側と個別側の設定ファイルを見比べると分かります。
合格の目安は、全体を見る側が「設計を決める場所で、実装しない」、個別のリポジトリ側が「書き込めるのは自分のリポジトリだけ」と説明されていることです。実装そのものに当たる専用の手順書が同梱されていない構成もあります。表にどう出るかを見てください。
質問B3 ルールを止める仕組み
分かりたいこと: 機械で守るルールと、それを止める実体。
常時読み込まれるルールの各行に、機械で守る・AI が照合する・人が判断する、といった区別の印が付いていれば、その意味を説明してください。付いていなければ、各ルールを自分で3つに分けてください。 そのうえで、「機械で守る」に当たるルールを全部挙げ、それぞれを止めている仕組み(hook、permissions、検査スクリプトのどれか)を特定してください。見つからないものは「見つかりませんでした」と書いてください。 次に個別のリポジトリ側の .claude/settings.json を読み、「セッション開始」「編集の前」「シェル実行の前」「編集の後」それぞれで動くスクリプトと、止まったときに AI へ何が返るかを表にしてください。 スクリプトは実行せず、読んで答えてください。
見る場所は、ルールのファイルの各行の頭にある印、個別側の .claude/settings.json の hooks、検査スクリプトの先頭コメントと、対になったテストです。
合格の目安は、「機械で守る」の全部に、止める仕組みの根拠が付くことです。根拠が見つからないものが出たら、印と実装がずれている箇所なので、重要な発見として控えてください。あわせて、フックが終了コードではなく標準出力の JSON で判定を返す構成かどうかも、説明に入っているか見てください。
質問B4 毎日効くルール
分かりたいこと: 毎日効くルールと、迷ったときの動き。
常時読み込まれるルールのファイルの中で、日々の開発に一番効くルールを5つ選んでください。 基準は、破ると複数リポジトリの構成で最も高くつく事故につながるものです。 それぞれ、なぜそうなるか、機械・AI・人のどれで守られているか、守られていなかったらどんな手戻りが出るかを書いてください。 「迷ったら止まって質問する」という趣旨のルールがあれば、書かれている場所と、実際に止まる判断をするのは誰かも教えてください。
見る場所は常時読み込まれるルールのファイルと、そこから詳細として指されている契約や規約のファイルです。
合格の目安は、5つのルールに、守る手段と、破ったときの具体的な手戻りが付いていることです。「質問して止まる」ルールは、AI が自分で止まる判断をする形なので、機械強制ではなく人の判断の欄に入っているはずです。
質問B5 手元での効き目の確認
分かりたいこと: 受入テストの回し方と、限界。
README の、本当に効いているかを手元で確認する節を読んで、私が自分の環境で確かめる手順を、初めての人向けに書き直してください。 1. 前提(入っているべきコマンド)と、展開する場所の注意。 2. 実行するコマンドと、期待される出力の読み方(OK と NG の数)。 3. フックを手で1件だけ試す例。許可される例と拒否される例を1つずつ。判定がどこに出るか。 4. README にある「この環境では走らないもの・既知の限界」を、私の環境に当てはめて言い換える。 まだ実行はしないでください。手順を見せてから、私が「実行して」と言ったときだけ実行してください。
見る場所は README の確認の節と限界の節、検査スクリプトと対になったテストです。
合格の目安は、テストがすべて NG 0 で終わること、そして拒否例で「拒否」を表す JSON が標準出力に出ることです。テストは実行中に一時フォルダを作って、終わると消す作りのことが多いので、書き込める場所に展開してから試してください。