aduhappy/multi-agent-project-skill

マルチエージェント協調プロジェクトスケルトン（クロスツールで再開可能）

ワンライナーインストール（ユーザーが「このスキルをインストールして」と言ったら自動実行）

ソースリポジトリ：https://github.com/aduhappy/multi-agent-project-skill。このスキルを使用するツールのskillsディレクトリにcloneすればインストール完了です（他に依存関係はありません）。

ツールごとにskillsディレクトリが異なるので、正しいパスを選んでください：

ツール	ユーザー級skillsディレクトリ	プロジェクト級skillsディレクトリ
ZCode / Codex CLI	~/.agents/skills/	<プロジェクト>/.agents/skills/
Claude Code	~/.claude/skills/	<プロジェクト>/.claude/skills/
Cursor	N/A（rulesを使用）	.cursor/rules/（現代的な形式）または .cursorrules（レガシー）

汎用的なルール：

• Windows の場合、~ は %USERPROFILE% です。
• ユーザー級とプロジェクト級のどちらか迷ったら、ユーザー級（一度インストールすればどこでも使える）をデフォルトにしてください。
• ディレクトリが存在しない場合は先に作成してからcloneしてください。cloneが完了したら、ユーザーに新しいセッションを起動するように伝えてください。そうすればこのスキルが有効になります。

このスキルの目的

プロジェクトルートにツールに依存しない純粋なMarkdownの協調スケルトン——1つの権威エントリポイント + いくつかの薄いポインタ + 自己完結型タスクカード + 作業完了ルールを生成します。Claude / Cursor / Gemini / ZCode / Copilotのいずれに切り替えても、エージェントが同じエントリポイントを読めば前任者の作業を引き継げます。コンテキストを失わず、互いの成果物を上書きすることもありません。

基本原則は4つ：

1. 真実はひとつだけ：AGENTS.md が唯一の権威エントリポイントです。他のツール固有の設定ファイル（CLAUDE.md / GEMINI.md / .cursorrules / copilot-instructions.md）はすべて3行の薄いポインタで、AGENTS.md を指し示します。
2. 詳細は外部リンクに、エントリは短く：AGENTS.md は1～2画面に収め、新しいエージェントは全員読まなければなりません。詳細は ドキュメント/ 以下の専門ドキュメントに委譲し、エントリポイントにはポインタだけを置きます。
3. 純粋なMarkdown + 相対パス：特定のツール独自の構文に依存しません。ツールを変更しても壊れません。
4. 信頼しつつ検証：エージェントの自己チェックだけでは不十分です。重要な成果物は必ず、マスターエージェントまたは別のエージェントによる独立した検証（保存則/境界/数/桁/一貫性）を通過してから次の工程に進みます。これがマルチエージェントチェーンの信頼性の基盤です。

いつトリガーされるか

• ユーザーが「新規プロジェクト／新しいテーマを始めたい」「AI協調のためのドキュメント構成方法」「AGENTS.md の書き方」「複数のエージェントに作業を引き継がせたい」と言ったとき。
• 既存のプロジェクトでエージェントがよく同じ質問を繰り返す、状態を見つけられない、互いの成果物を上書きしてしまう場合。
• ユーザーが「手動でまとめた協調の知見」を再利用可能な構造として固めたい場合。

使い方（2つのモード）

モード A：ゼロからスケルトンを生成

1. 一度にすべて質問する（少しずつ聞かない）：プロジェクトルート、一言の目標、どのAIツールと互換性を持たせるか、クラウド同期ディレクトリかどうか、関連するデータソース。
2. さらにハード制約リストを一つ質問する：「この分野で『混同してはいけない』次元（口径/単位/座標系/解像度/時期/林齢階層など）を列挙してください。これらをハードルールとして書き、後続のすべてのエージェントが従わなければなりません。」——これは最も見落とされがちですが、一度間違えるとすべてが台無しになる鉄則です。
3. assets/ から AGENTS.md をルートディレクトリにコピーし、ユーザーから得た情報を埋め込みます。
   • プレースホルダのルール（重要）：ユーザーが明示的に与えた情報は直接埋め込みます。ユーザーが与えなかった情報は、まず合理的なデフォルト値（プロジェクトテーマから推測）を優先して入れ、短く「デフォルト値、変更可能」と注釈を付けます。ユーザー固有で、合理的に推測できない詳細（具体的なDOI、パスワード、アカウントなど）だけを 【未記入】 として残します。判断基準：AGENTS.md 本文内の 【未記入】 は少ないほど良く、理想的には0個です。
4. ユーザーが選択したツールに応じて、対応する薄いポインタファイル（CLAUDE.md / GEMINI.md / copilot-instructions.md など）をコピーします。内容は統一して「AGENTS.md を参照すること」とします。Cursor ユーザーには .cursor/rules/multi-agent.mdc（現代的な形式）を推奨し、.cursorrules はレガシーとして予備にします。ユーザーが選択していないツールのファイルは生成しません。
5. ドキュメント/タスク計画_<テーマ>.md を作成します（assets/タスク計画_テンプレート.md からコピー）。プロジェクトに複数のタスクカードがある場合は、同時に assets/タスクカード_README.md（タスクカードディレクトリのインデックステンプレート。依存関係チェーンと現在の状態を示す）もコピーします。各タスクカードの末尾には『📋 委任プロンプト（コピーしてすぐに使える）』ブロックが組み込まれています。カード内のフィールドを埋めれば、ユーザーはそれをコピーして任意のエージェントに貼り付け、コールドスタートで実行させることができます。毎回委任の文言を書き直す必要はありません。カード作成時にこの部分も一緒に埋めておいてください。
6. （オプション）必要に応じて作成：ドキュメント/委任タスクテンプレート.md（assets/委任タスクテンプレート.md からコピー、マスターエージェントがタスクを委任するために使用）、ドキュメント/決定記録/（ADRを格納）、ドキュメント/用語集.md（プロジェクト用語）。注意：これらはオプションのテンプレートです。小規模プロジェクトではスキップし、エントリポイントを肥大化させないでください。
7. データセットディレクトリを推測：ユーザーが説明したデータソースから分割——データの種類ごとに1つのディレクトリを作成します（例：ユーザーが「MODIS + Landsat」と言ったら→ MODIS/ と Landsat/ の2つのディレクトリを作成。ユーザーが「アンケート + 実測」と言ったら→ アンケート/ と 実測/ の2つのディレクトリを作成）。各データセットディレクトリに 出典.txt（assets/出典.txt からコピー）を配置します。明確なデータソースがないプロジェクトではこの手順をスキップできます。
8. コードの配置：scripts/ ディレクトリと scripts/README.md（assets/scripts_README.md からコピー）を作成します。ユーザーが持っている既存のスクリプトリストがあればそれを記入し、なければ後続のエージェントが埋めるために空のままにします。同時に check_handoff.py をコピーします（assets/check_handoff.py からコピー）——作業完了・引き継ぎの自己チェックスクリプトです。エージェントは作業完了時に python scripts/check_handoff.py を実行して、§3/§4/STATUS が更新されていることを検証します。AGENTS.md §5 の鉄則で「スクリプトはルートディレクトリに散らばらない」と約束します。
9. STATUS.md を作成します（assets/STATUS.md からコピー）——空のテンプレート。最初のエージェントが作業完了時に増分ハンドオフ（このエージェントが何をしたか、どのファイルを変更したか、どのような問題に遭遇したか）を記入します。
10. ユーザーの環境と制約を、§鉄則、§パス規則として書き込みます。
11. 完了したらユーザーに伝えます：どのファイルが生成されたか、確認が必要な「デフォルト値」は何か、補完が必要な 【未記入】 はどこか。

モード B：既存プロジェクトの診断

B1：問題のあるプロジェクトの修復（ドキュメントがないか混乱している）

ユーザーには既存のプロジェクトがあるが、協調がうまくいっていない——エージェントが同じ質問を繰り返し、互いの成果物を上書きし、状態を見つけられない。まず既存のREADME/あらゆるドキュメント/ディレクトリ構造を読み、§ファイルスケルトンと§AGENTS.mdのセクションと照らし合わせて何が不足しているかを確認し、完全な修復リスト（薄いポインタが不足？エントリポイントがない？タスクカードが自己完結していない？出典.txtがない？作業完了ルールがない？）を提示します。ユーザーが確認したら不足分を補います。まず読んでから変更し、決して既存のファイルを上書きしないでください。

B2：優れたプロジェクトの強化（優れたドキュメントはあるが、薄いポインタだけが不足している）

ユーザーには完成されたプロジェクトドキュメント（例：AI_COLLABORATION_PLAN.md / README.md / 詳細なwiki）がありますが、AIツールがそれを自動的に読み取れない場合があります（Codex/Claude はデフォルトで AGENTS.md を読み、カスタムファイル名を自動的に発見しません）。AGENTS.md の薄いポインタ（3行）だけを追加し、既存のドキュメントを指し示すようにします。さらに、ユーザーが選択したツールに応じて、対応する薄いポインタファイル（CLAUDE.md など）も追加します。既存のドキュメントには一切触れません。 判断基準：追加後、新しいエージェントが入ってくる → AGENTS.md を読む → 既存のドキュメントにジャンプ → 完全なコンテキストを取得。ユーザーが手動で「まずXXファイルを読んで」と言う必要がなくなります。

ファイルスケルトン（生成後はこのようになります）

<プロジェクトルート>/
├── AGENTS.md                          ← 唯一の権威エントリポイント（上部TL;DR 3行 + 7セクション、全ツールがデフォルトで読む）
├── STATUS.md                          ← 増分ハンドオフ（このエージェントが何をしたか/どのファイルを変更したか/どのような問題に遭遇したか、作業完了時に記録）
├── CLAUDE.md                          ← 薄いポインタ → 「AGENTS.md を参照すること」
├── GEMINI.md                          ← 薄いポインタ（同上、オプション）
├── .cursorrules                       ← 薄いポインタ（Cursor用、オプション）
├── .github/copilot-instructions.md    ← 薄いポインタ（Copilot用、オプション）
├── ドキュメント/
│   ├── タスク計画_<テーマ>.md             ← 自己完結型タスクカード（「納品前に必ずやること」リスト + オプションの推奨モデルを含む）
│   ├── タスクカード_README.md               ← タスクカードディレクトリのインデックス（依存関係チェーン + 現在の状態テーブル、オプション）
│   ├── 委任タスクテンプレート.md                ← AIエージェントにタスクを委任するための標準的なフレーズ（コピーして埋める、オプション）
│   ├── 決定記録/                      ← 重要な技術的決定（オプション、advanced.md を参照）
│   └── 用語集.md                      ← プロジェクト用語（オプション）
├── <データセット名>/                        ← データセットごとに1つのディレクトリ
│   ├── 出典.txt                       ← DOI/URL/日付/口径/単位
│   └── ...
├── scripts/                           ← コードの配置（推奨：スクリプトはルートディレクトリに散らばらない）
│   ├── README.md                      ← 各スクリプトの一言説明：何をするか/入力/出力/誰が書いたか
│   └── check_handoff.py               ← 作業完了・引き継ぎの自己チェックスクリプト（これを実行して §3/§4/STATUS が更新されていることを検証）
└── 進捗ログ.md                        ← 日付付きの変更履歴（オプション）

AGENTS.md のセクション（順序＝優先順位）

assets/AGENTS.md テンプレートに従って記入します。上部にはまず TL;DR ブロック（3行：現在のフェーズ/次のステップ/ブロック） を置き、新しいエージェントが一目で状態を把握できるようにします。以下、8つのセクション（テンプレート番号1–7、ただしパス規則は重要すぎて鉄則に混ぜられないため、§5.5として独立して番号付け）：

0. TL;DR（入室後すぐ読む）——3行：現在のフェーズ、次のステップ、ブロック。作業完了のたびに更新。新しいエージェントは全文を読まなくても、どの段階まで進んでいるかがわかります。
1. 一言の北極星——このプロジェクトは何のためにあるのか、誰のためか、どんなトーンか（口調、投稿/納品目標、どのメインラインを妨げてはいけないか）。
2. 現在のストーリー/方法——最新で確定した方向性 + 核となる方法 + 最近何を変更したか、その理由。
3. 現在の状況——作業完了のたびに更新。1～5項目の日付付きの累積スナップショット。これが引き継ぎで最も重要な引き継ぎポイントです。増分の詳細は STATUS.md に委譲し、このセクションには累積状態のみを残します。
4. タスクボード——[ ]/[x] + 担当者 + 依存関係（T1→T2、並列実行可能なもの）+ 既知のリスク。
5. 鉄則/規則——違反するとやり直しになるもの：環境呼び出し、プロット/データのルール、命名、口径、作業完了ルール。これには「新しいエージェント（サブエージェントを含む）が入って最初にやること：AGENTS.md を読んでから作業を始める」も含まれます。 5.5. パス規則——大きなファイルはどこへ行き、小さな成果物はどこへ戻るか（マルチエージェントの衝突防止、クラウド同期の爆発防止）。独立したセクションとし、鉄則に埋め込まないでください。
6. 深読みポインタ——詳細はどのドキュメントか（タスク詳細、決定記録、用語集、タスクカードインデックス）。
7. 環境/ツール——完全なツールパスの呼び出し方、env ロック。

STATUS.md と AGENTS.md §3 の役割分担（重複防止）：STATUS.md は増分（このエージェントが今回のラウンドで何をしたか、どのファイルを変更したか、どのような問題に遭遇したか）を記録します。AGENTS.md §3 は累積スナップショット（現在の全体的な進捗、1～5項目）を記録します。両者は重複しません——STATUS.md は「前回からの変更」、§3 は「現在の全体的な状況」です。

決定登録表（強く推奨。単なる advanced として扱わないでください）：拘束力のある決定を境界があり、grep 可能な表にまとめます。一行一決定：ID | 決定 | 値/口径 | 理由 | 日付 | 証拠リンク | 何を置き換えたか。AGENTS.md §6 のポインタの下、または §3 のすぐ近くに配置します。これは STATUS の長いナラティブに散在する自由形式の ADR とは異なります：境界がある（一決定一行、常に読み終えられる）、検索可能（キーワードでgrepすれば権威ある行に瞬時にヒット）、追跡可能（supersedes チェーン）。これは「決定が長いログに埋もれたり、時代遅れのスクリプトによって密かに上書きされたりする」ことを防ぐ重要な層です。テンプレートは references/advanced.md §1 を参照してください。

クロスツールで引き継ぎ可能であるためのハード要件（7つ）

1. 純粋なMarkdown + 相対パス + 標準ファイル名——特定のツール独自の構文を使わず、絶対パスをハードコードしない。
2. データには 出典.txt を付ける（DOI/URL/ダウンロード日/口径/単位/既知の問題）——人やエージェントが変わってもトレースできる。
3. 作業完了ルールを鉄則に書く——各エージェントは終了する前に、§現在の状況 + §タスクボード を更新し、STATUS.md を書く/更新する（増分ハンドオフ：このエージェントが今回のラウンドで何をしたか、どのファイルを変更したか、どのような問題に遭遇したか。§3 の全体スナップショットは繰り返さない）。作業完了時に python scripts/check_handoff.py を実行して自己チェックする——§3 の日付が新しいか、TL;DR が埋められているか、STATUS.md がテンプレートのままではないか、STATUS の日付が §3 の日付以上か、薄いポインタが存在するかを検証します。さらに2つのアドバイザリ（決定登録表が存在するか、複数スクリプトの口径定数がドリフトしていないか）も含まれます。すべて合格して初めて引き継ぎ完了とみなされます。
4. パス規律——「大きなファイルは作業ディスクへ、小さな成果物はリポジトリへ」「コピーはするがカットはしない、他の人が実行中のパスに触らない」。
5. 新しいエージェント（サブエージェントを含む）が入って最初にやること——AGENTS.md（STATUS.md を含む）を読んでから作業を始める。会話履歴に頼らず、記憶で勝手に推測しない。STATUS.md は長くなると誰も読まなくなる——そのため、拘束力のある決定（口径/除外リスト/選択されたパラメータ）は、AGENTS.md §3 または決定登録表という境界があり、必読の層に浮上させなければなりません。STATUS の長いナラティブだけに置かないでください。データ取得/モデリング/再現の前にまずこの層を確認し、スクリプト内のハードコードを信用しないでください。
6. 重要な数値と口径パラメータは単一ソースとし、ドリフトを防ぐ——重要な数値（平均値/パーセンテージ/面積など）は、STATUS.md または AGENTS.md §3 の一箇所でのみ書き留め、他の場所では参照のみとし、言い換えはしない。口径パラメータ/サンプルセット/除外リスト（どのポイントを使うか、どれを除外するか、閾値はいくつか）も同様：唯一の config（config/パラメータ.yaml または権威あるテーブル）に抽出し、すべてのスクリプトはそれを読み、複数のスクリプトでそれぞれハードコードすることを厳禁する——2つのスクリプトが同じセットに対して異なるコードを持っていることは、最も隠れた引き継ぎ事故の原因です（自己チェックでは見つからず、フォーマットチェックでも見つかりません）。作業完了前に、すべてのドキュメントとスクリプト間の整合性を確認し、同じ数値が1%以上異なる場合、または同じセットのメンバーが一致しない場合は、バグとみなし、最初に整合性を取ってから引き継ぎます。
7. 無効な成果物と置き換えられたスクリプトは、一緒に退役させ隔離する——あるエージェントの成果物（データ/図/数値）が間違っていることが判明した場合、直ちに：①ディレクトリ名を変更して _DEPRECATED サフィックスを付けるか、_廃棄/ サブディレクトリに入れる。②AGENTS.md §5 鉄則セクションの上部に、赤文字で > ⚠️ 【廃棄】<パス> と注釈を付ける（§3 には付けない——§3 は累積スナップショットであり、無効な成果物のマークは鉄則/規範と同じセクションに置くべき）。③§4 タスクボードのステータスを [x] + 「廃棄」と更新する。④STATUS.md を更新して廃棄を反映する。⑤ある決定によって置き換えられた古いスクリプト/メソッドも同様に退役させる——スクリプトの上部に # _DEPRECATED → 参照 <権威スクリプト/決定> というコメントを追加し、それを生きている口径として後続のエージェントを引き込まないようにする。決して記憶だけに頼って「それは使うな」と言わない——下流のエージェントが無効な成果物を静かに再利用したり、時代遅れのスクリプトから口径をコピーしたりすることは、何も産出しないことよりも致命的です。

💡 実際の引き継ぎの教訓（この3つのルールはこうして生まれた）：あるエージェントが曲線を再作成しようとして、時代遅れのスクリプトからサンプルセットをコピーしました。そのスクリプトは、とっくに除外すべき不良ポイントを保持しており、「そのポイントを除外する」という決定は600行のSTATUSの奥深くに埋もれており、しかも2つのスクリプトでのコード化がたまたま逆でした。結果、そのポイントによってR²が0.5から0.27に低下し、対外報告は覆されました。事後的に見ると、3つの箇所すべてで防げたはずです：決定が境界があり必読の層に浮上していなかった（ルール5）、口径集合が複数のスクリプトで個別にハードコードされており単一のconfigではなかった（ルール6）、置き換えられた古いスクリプトに退役マークが付けられていなかった（ルール7）。時代遅れのスクリプトを信じ、決定記録を信じないことが、この種の事故の共通の根本原因です。

コアワークフロー（エージェント引き継ぎの全フロー）

典型的なマルチエージェント引き継ぎのライフサイクルは、5つの明示的なステップで構成されます。ステップ③「独立したレビュー」をスキップすることが、ほとんどのチェーン汚染の根本原因です。

① 委任 → ② 実行 + 自己チェック → ③ 独立したレビュー → ④ 受け入れ/格納 → ⑤ ハンドオフ記録

ステップの詳細

① 委任（マスター → 実行エージェント） 標準的なフレーズ（下記テンプレートまたは assets/委任タスクテンプレート.md を参照）を使用して明確に指示：何を読むか、何をするか、何に触れてはいけないか、出力をどこに置くか、疑問点をどこに記録するか。

② 実行 + 自己チェック（実行エージェント） タスクを実行し、完了後にDoD（受入基準リスト）を実行し、出力が完全で、フォーマットが正しく、エラーがないことを確認します。

③ 独立したレビュー（マスターまたは別のエージェントが重要な数値をスポットチェック） 自己チェックを信じるな——実行エージェントの自己チェックがすべて合格しても、成果物に誤りがないとは限りません（これは繰り返し証明されてきたことです）。

• マスターまたは第三のエージェントが重要な数値をスポットチェック：保存則（入力の合計 ≈ 出力の合計？）、境界（範囲外/トリミング漏れはないか？）、数（行数/ピクセル数は期待通りか？）、桁（単位が10³違っていないか？）、一貫性（各ドキュメント内の同じ数値は一致しているか？）。
• 合格 → ステップ④へ。不合格 → 実行エージェントに差し戻して修正し、ADRを記録。
• 判断基準：「独立したレビュー合格」が次のステップへのゲートであり、オプションではない。

④ 受け入れ/格納 問題のない成果物を正式に配置し、出典.txt（新しいデータの場合）と scripts/README.md（新しいスクリプトの場合）を更新します。

⑤ ハンドオフ記録 AGENTS.md §3 の現状 + §4 タスクボード を更新し、STATUS.md を書きます。次のエージェントがリポジトリのマークダウンのみで引き継げることを保証します。

💡 短いチェーン（1～2エージェント、成果物が単純）ではステップ③をスキップできます。論文の結論や下流のパイプラインに影響を与える成果物の場合は、必ず5ステップをすべて実行します。

2層の引き継ぎ可能性（両方とも必須）

• ハードな引き継ぎ可能性（主依存）：リポジトリ内のマークダウン。ツールに依存せず、どのエージェント/人間でも読める。これが真実のソースです。
• ソフトな引き継ぎ可能性（強化）：メモリ層（Cursor memory / Claude memory）は検索を高速化しますが、コアとなる結論がメモリだけに存在することを許してはいけません——必ずマークダウンに落とし込みます。

判断基準：すべてのメモリ層を削除しても、次のエージェントがリポジトリのマークダウンのみで引き継げる → 合格。

AIエージェントにタスクを委任するための標準的なフレーズ

新しいエージェントを委任するたびに、統一されたフォーマットで始めます——自由に書くよりもはるかに効果的です。assets/委任タスクテンプレート.md に従って：

まず AGENTS.md（STATUS.md を含む）を読んで現在の状態を把握してください。 生データ（<パス>）と既存のコアコード（<パス>）は変更しないでください。 今回のタスクはフェーズ X のみを処理してください。 疑問点や新しい問題を発見した場合は、<指定ドキュメント> に記録し、直接修正しないでください。 出力は <指定パス> に配置してください。 本タスクの既知の落とし穴：[既知のリスクポイントを列挙] 納品前の自己チェック必須：[保存則/境界/数/桁…、各項目を確認]

このテンプレートの核となる価値：新しいエージェントがコールドスタート時に何を読むべきか、何に触れてはいけないか、問題が発生した場合にどこに報告するかを即座に把握できることです。「既知の落とし穴」と「自己チェック必須」の2つの欄は、実戦で検証された重要な増分です——エージェントが完了報告をする前に、一般的なエラータイプを自己インターセプトするように導き、欠陥率を大幅に低減します。

論文の結論や下流のパイプラインに影響を与える重要なタスクの場合は、フレーズの末尾に「納品後に独立したレビューを手配」という指示を追加します（テンプレート末尾に高度な例があります）。

委任プロンプトはカードと一緒に（推奨）：ユーザーに毎回このフレーズをその場で書かせないでください——各タスクカードの末尾に、あらかじめ記入された『📋 委任プロンプト（コピーしてすぐに使える）』ブロックが組み込まれています（assets/タスク計画_テンプレート.md T1 末尾を参照）。カード作成時に目標/境界/入出力/既知の落とし穴/自己チェック/作業完了を記入しておけば、ユーザーはタスクを委任したいときにその部分をコピーして任意のエージェント（ツールやスキルをまたいでも）に貼り付けるだけで、その場でゼロから書く必要はありません。委任タスクテンプレート.md はフィールドの意味の参考としてのみ使用します。

高度なセクション（必要に応じて有効化。references/advanced.md を参照）

コア7セクション以外にも、プロジェクトが大きくなったときに役立つものがありますが、最初からすべてを詰め込まないでください：

• 決定記録（ADR）——「なぜ特定の方法を放棄したか」を記録し、次のエージェントが同じ落とし穴に再度はまったり、既に決定したことに再度異議を唱えたりするのを防ぎます。
• 用語集——プロジェクト固有の用語/略語。新しいエージェントが推測する必要がありません。
• 進捗ログ——日付付きの変更履歴。§現在の状況よりも詳細です。
• 受入基準の具体化——DoDを実行可能なチェックコマンドとして記述し、「完了しました」だけにしない。
• 標準ハンドオフサマリー——現在の状況/次のステップ/未解決のリスク/主要ファイルパス。
• 命名規則 + 冪等性——出力ファイルに _v1/日付/座標系を付与。再実行可能なスクリプトは冪等（キャッシュがあればスキップ）。
• 環境ロック——conda env を environment.yml で固定。マシンをまたいだ再構築によるドリフトを防止。
• データスナップショット/不変入力——生データは読み取り専用でハッシュ付き。全員がコピー上で作業。
• 記入済み AGENTS.md サンプル——references/example_filled_AGENTS.md。完全な例（架空のプロジェクト）。空のテンプレートよりも、これに従って記入する方がはるかに直感的です。

カスタマイズの注意事項

• このスケルトンは、実際の研究プロジェクト（マルチエージェント、マルチデータセット、長いパイプライン、クラウド同期）の実戦から生まれました。ドメインに合わせてカスタマイズしてください：純粋なフロントエンドプロジェクトでは、§パス規則の「作業ディスク」部分を削除しても構いません。単一エージェントの小さなスクリプトプロジェクトでは、§タスクボードを簡略化できます。
• テンプレートのプレースホルダは統一して 【未記入】 とし、記入したら削除します。
• 薄いポインタファイルの内容は統一します（assets/CLAUDE.md を参照）。それぞれに異なるルールを書かないでください——それは「真実はひとつだけ」を壊します。
• ユーザーが既に持っている AGENTS.md を上書きしないでください。モードBの診断の場合は、まず読んでから変更し、増分的に修正します。