folder-specific-claude-and-agents-md

フォルダー CLAUDE.md の作成

対象フォルダー内に、内容を絞った CLAUDE.md を作成し、それを指す AGENTS.md シンボリックリンクも作成します。このファイルには、グローバルな CLAUDE.md ではカバーされない、フォルダー固有のコンテキストを今後のエージェント（Claude Code、Codex など）に伝えます。

背景資料：library/claude-code/claude-and-agents-md.md。

手順

ステップ 1：対象フォルダーを確認し、ファイルを作成する必要があるか確認する

ユーザーに対象フォルダーを尋ねます。<workspace-root>/ 配下の絶対パスを使用します。

複数のセッションをまたいで必要となるコンテキストがある場合に限り、ファイルを作成します — 進行中で変化し続ける作業、固有の規約、継続中の意思決定などです。静的な参考資料だけを置いたフォルダーには不要です（エージェントは必要に応じて読めます）。判断に迷う場合はユーザーに尋ねます。

ステップ 2：フォルダー内のすべてのファイルを最後まで読む

• まず ls -la を使い、ファイルとサブフォルダーを列挙します。
• すべての Markdown、設定ファイル、重要なソースファイルを読みます。
• 大規模な tldraw/Vite サブプロジェクトの場合：package.json、src/App.tsx、代表的なモジュールファイルを 1 つ、フォルダー独自の module-details.md 形式のファイルを読みます。
• ざっと読むことや、読み飛ばすことはしないでください。ユーザーが後で編集する際には、全体を把握している必要があります。

ステップ 3：候補となる内容の箇条書き案を作成する

ファイルを書く前に、セクションごとに分類した箇条書き案をユーザーに提示し、先に意見をもらいます。該当しないセクションは省略します。

• 製品 / 目的 — このフォルダー／プロジェクトの概要、現在の状態、主要な指標
• アバター / 対象者 — 誰を対象とするか（該当する場合）
• 重要なファイル — 重要な各ファイルの役割を一行で記述し、フォルダー間参照を含めます（@path/file.md インポート構文を使用）
• 制約（禁止事項） — 明確な禁止事項。このファイルで最も効果の高い内容です。
• 規約 — ユーザー特有の言い回し、ステータス絵文字（✅ 🟡）、命名パターン、「通常行う」パターン
• 確定した決定事項 — 合意済みで日付が記載され、再検討してはならないこと
• 背景 — 作業の枠組みとなる履歴、権威性、信頼性
• ユーザーとの協業方法 — このフォルダーに特化した協業スタイル
• マーケティングの切り口 / ポジショニング — 対外向けの場合
• 主な洞察 — 調査がある場合、調査から得られた最も顕著な 3～5 件のシグナル

ステップ 4：ユーザーと内容を調整する

• 回答は簡潔にします。ユーザーは IDE で直接編集します。
• ユーザーがファイルを編集したら、再度読み、矛盾、誤字、欠けているルール、分類の誤りを指摘します。
• 求められない限り、ユーザーの編集を元に戻さないでください。

ステップ 5：ファイルを書く

• パス：<folder>/CLAUDE.md
• ファイルの目的を説明する一行のヘッダーから始めます。
• サブディレクトリのファイルを示すマーカー： 親フォルダーに独自の CLAUDE.md がある場合は、Apply root CLAUDE.md first, then this file. で始めます。
• ユーザーが承認したセクションに対応する ## 見出しを使用します。
• 散文より箇条書きを優先します。簡潔な箇条書きにします。
• フォルダー間参照： 散文で言及せず、@relative/path/file.md インポート構文を使用します。
• 詳細な参考資料： **Read when:** のトリガーを付記します（例：「Read when: writing offer copy」）。毎回すべてを読み込むのを防ぎます。

ステップ 6：AGENTS.md シンボリックリンクを作成する

cd <folder> && ln -s CLAUDE.md AGENTS.md

ls -la CLAUDE.md AGENTS.md で確認します。

ステップ 7：指示があった場合に限りコミットする

ユーザーから指示がない限り、ステージングもプッシュもしないでください。指示があった場合は、git add -A を実行し、Day N: 形式のメッセージでコミットしてからプッシュします。

ルール

• 内容を捏造しないでください。 すべての箇条書きは、フォルダー内で読んだ内容、またはユーザーが伝えた内容に基づいている必要があります。一般的な定型文は追加しないでください。
• 簡潔さを優先してください。 ユーザーは積極的に編集して短くします。最初から簡潔にしてください。
• フォルダー固有の内容に限定してください。 グローバルな CLAUDE.md（性格、日付、ポートなど）と重複させないでください。このフォルダーに固有の内容だけを記載してください。
• ファイルツリー、ディレクトリー一覧、コードから分かる技術スタックの詳細は記載しないでください。 エージェントが ls や grep で確認できる情報は、すぐに古くなり、トークンを無駄にします。構成ではなく、決定事項、ルール、背景情報を記載してください。
• 制約と慣例を分けてください。 厳格な「してはならない」ルールは制約（明示的な禁止事項）に記載してください。「通常は X をする」というパターンは慣例に記載してください。分けておくと、ルールが守られやすくなります。
• 明示的な例外がない限り、「常に」「絶対に」といった断定は避けてください。 例外的なケースがあると、断定的なルールは無視されがちです。「.env.example を除き、秘密情報をコミットしないでください」のほうが、「秘密情報を絶対にコミットしないでください」より適切です。
• ファイルを要約したり、自動的に短縮したりしないでください。 コンテキストの縮約は品質を低下させます。意図的に内容を増やし、手動で整理してください。ユーザーから短くするよう依頼された場合は、手作業で対応してください。
• メンテナンスのサイクルを回してください。 このファイルに記載しておけば防げたはずの内容についてユーザーから修正を受けた場合は、すぐにそのルールをファイルに追加してください。後回しにしないでください。
• ユーザーが絵文字を使っていない限り、絵文字は使わないでください（ステータスマーカーの ✅ 🟡 は例外です。すでに慣例として使われています）。
• コピーではなく、シンボリックリンクを使ってください。 編集内容を同期させるため、AGENTS.md はシンボリックリンクにしてください。
• 問題点を正直に指摘してください。 ユーザーの編集によって矛盾（例：あるセクションでは「X を販売する」、別のセクションでは「X を絶対に販売しない」と記載）が生じた場合は、ユーザーに指摘される前に知らせてください。