research-project-memory

研究プロジェクトのメモリ

プロジェクトのメモリは、単一のメモファイルではなく、階層化されたシステムとして維持してください。このスキルは、研究プロジェクトで何を証明しようとしているのか、どのようなエビデンスがあるのか、どのようなリスクが残っているのか、次のアクションをどのコンポーネントが担当するのかを、エージェント間で共有するためのプロトコルを提供します。

次の場合にこのスキルを使用してください。

• リモート実行の状態を超えて、セッションをまたぐプロジェクトのメモリが必要な場合
• paper/、code/、worktrees、slides/、査読者シミュレーション、リバッタルにわたるメモリをユーザーが求めている場合
• 主張、実験、図、論文のセクション、査読者のリスク、アクションの整合性を保つ必要がある場合
• セッションによってプロジェクトの方向性、エビデンス、執筆内容、査読リスク、計画中の実験が大きく変わる場合
• 新しいエージェントセッションで、作業を始める前にコンテキストを読み込む必要がある場合
• ユーザーがメモリシステム、プロジェクト状態グラフ、主張／エビデンスボード、worktreeメモリ、または作業完了プロトコルを求めている場合

これは調整用のスキルです。remote-project-control、experiment-design-planner、conference-writing-adapter、paper-reviewer-simulator、rebuttal-strategistの代わりにはなりません。信頼できるプロジェクトの状態をどこに、どのように保存するかを、それらのスキルに示します。

スキルのディレクトリ構成

<installed-skill-dir>/
├── SKILL.md
├── references/
│   ├── closeout-protocol.md
│   ├── consistency-checks.md
│   ├── claim-lifecycle-protocol.md
│   ├── cross-module-handoff-contracts.md
│   ├── evidence-provenance-protocol.md
│   ├── memory-architecture.md
│   ├── object-schemas.md
│   ├── paper-source-visibility-protocol.md
│   ├── phase-dashboard-protocol.md
│   ├── toolchain-gates-protocol.md
│   └── writeback-protocol.md
└── templates/
    ├── component/
    │   ├── component-status.md
    │   ├── worktree-index.md
    │   └── worktree-status.md
    └── memory/
        ├── action-board.md
        ├── claim-board.md
        ├── component-index.yaml
        ├── current-status.md
        ├── decision-log.md
        ├── evidence-board.md
        ├── handoff-board.md
        ├── phase-dashboard.md
        ├── provenance-board.md
        ├── project.yaml
        ├── risk-board.md
        └── source-visibility-board.md

段階的な読み込み

• 必ずreferences/memory-architecture.md、references/object-schemas.md、references/writeback-protocol.mdを読んでください。
• 主張、エビデンス、プロジェクトのフェーズ、論文執筆、実験計画、レビュー、リバッタル、コンポーネント間の引き継ぎに関わる場合は、references/claim-lifecycle-protocol.md、references/evidence-provenance-protocol.md、references/phase-dashboard-protocol.md、references/cross-module-handoff-contracts.mdを読んでください。
• 論文のブランチ、Overleaf/GitHubの同期、共同研究者が参照できるソース、匿名投稿用のソース、arXiv、カメラレディ版のソースパッケージ、論文worktreeのクリーンアップに関わる場合は、references/paper-source-visibility-protocol.mdを読んでください。
• コード、論文、ドキュメント、Git、GitHub、リモート、リリース、アーティファクトの品質ゲートを設定、変更、確認する場合は、references/toolchain-gates-protocol.mdを読んでください。
• プロジェクトの状態を監査する、マイルストーンに備える、投稿する、執筆する、レビューする、またはリバッタルを行うよう求められた場合は、references/consistency-checks.mdを読んでください。
• 重要なセッションを終了する前、または意味のある作業の後にメモリを更新する前に、references/closeout-protocol.mdを読んでください。
• 不足しているメモリファイルの初期設定では、templates/を信頼できる情報源として使用してください。

基本原則

• メモリは調整のためのコンテキストであり、実行上の真実ではありません。
• 安定した主張、決定、リスク、コンポーネントの対応関係は、リポジトリのメモリに記録します。
• 変更中の Git の状態、キューの状態、実行中のジョブ、ファイルの存在など、変動する事実は再確認する必要があります。
• 主張はアイデアから最終確定または却下まで、明示的なライフサイクルをたどります。根拠のない主張を、論文の文章で暗黙のうちに使用しないでください。
• エビデンスには、論文に掲載する表、図、キャプション、結果文を、CSV、レポート、実行記録、引用、分析、アセットまで追跡できるだけの出所情報を保持する必要があります。
• 論文ソースの公開範囲は、最優先で扱うポリシーです。論文のブランチが Overleaf にリンクされている、または共著者から見える場合は、エージェント専用ではなく author-visible として扱います。
• プロジェクトのフェーズダッシュボードで全体のサイクルを把握し、詳細ボードでは引き続き、基盤となる主張、エビデンス、リスク、アクション、出所情報、引き継ぎの各オブジェクトを管理します。
• アイデア、手法、コード、論文、スライド、レビュー、反論、成果物、リリースの各モジュール間で作業を移す場合は、モジュール間の引き継ぎを明示してください。
• 重要な主張はすべて、エビデンス、論文内の掲載箇所、現在のリスクにリンクする必要があります。
• 査読者への対応や反論に関するリスクはすべて、アクション、リスクを受け入れる決定、または対象範囲外とする理由にリンクする必要があります。
• すべてのワークツリーには、目的と終了条件（マージ、続行、保留、破棄）が必要です。
• 論文のバージョン管理用ワークツリーには、対象の投稿先／リリース、投稿モード、テンプレート／スタイルの差異、ソースの公開範囲、クリーンアップ要件、コンパイルのワークフローも記録する必要があります。
• .agent/、AGENTS.md、CLAUDE.md、執筆メモリ、生の CSV、プロット用スクリプト、内部向けの結果ドキュメント、査読者対応の方針など、エージェント専用の論文関連データを、著者に公開するソース、投稿用ソース、arXiv 用ソース、カメラレディ版のソースに含めないでください。
• コンポーネント固有のメモリは集約情報であり、プロジェクトメモリの代替ではありません。code/docs/ops/current-status.md と code/docs/ops/decision-log.md にはコードの運用状態を記録できますが、コンポーネント間およびワークツリー間の調整内容は、引き続きルートの memory/ と各コンポーネントの .agent/ インデックスから確認できるようにしてください。
• ワークツリー間の状態は、memory/component-index.yaml のグローバルレジストリ、<component>/.agent/worktree-index.md のコンポーネント集約情報、各 <component-worktree>/.agent/worktree-status.md の個別ステータスという3つの階層で管理します。
• 設定済みの場合、GitHub Projects は、複数のコンポーネントリポジトリにまたがるイシュー、PR、ブロッカー、ロードマップ／ステータスを確認するための、共同作業者向けのクラウドボードです。ルートの memory/、コンポーネントの .agent/、ワークツリーのメモリに代わるものではありません。
• ツールチェーンのゲートは、プロジェクトポリシーの最優先事項です。デフォルトでは非変更チェックを優先し、変更を伴うフォーマット／修正コマンドは、要求された場合または必要な場合にのみ実行してください。また、どのチェックがコミット、プッシュ、投稿、リリース、成果物の引き継ぎの条件となるかを記録してください。
• 確実性を observed、user-stated、inferred、stale、needs-verification のいずれかで示します。
• 次のセッションに役立つ、最も具体的な階層にメモリを記録してください。

ステップ 1 - プロジェクトと既存のメモリを確認する

プロジェクトルートを検出します。

git rev-parse --show-toplevel 2>/dev/null || pwd

次に、メモリとして使われている可能性のあるファイルを確認します。

• memory/project.yaml
• memory/component-index.yaml
• memory/current-status.md
• memory/decision-log.md
• memory/claim-board.md
• memory/evidence-board.md
• memory/risk-board.md
• memory/action-board.md
• memory/provenance-board.md
• memory/handoff-board.md
• memory/phase-dashboard.md
• memory/source-visibility-board.md
• paper/.agent/
• paper/.agent/worktree-index.md
• code/.agent/
• code/.agent/worktree-index.md
• slides/.agent/
• reviewer/.agent/
• rebuttal/.agent/
• 設定済みの場合は、memory/project.yaml 内の GitHub Project の URL／番号
• 設定済みの場合は、memory/project.yaml 内のツールチェーンのゲート

プロジェクトで別のディレクトリ構成を使用している場合は、コンポーネントのパスを適宜調整しつつ、メモリの役割は同じにしてください。

ステップ 2 - 不足しているメモリを初期化する

ユーザーからメモリの初期化を依頼された場合、またはメモリが不足しておりタスクの実行に必要な場合は、テンプレートから必要最小限のファイルを作成します。

• templates/memory/project.yaml -> memory/project.yaml
• templates/memory/component-index.yaml -> memory/component-index.yaml
• templates/memory/current-status.md -> memory/current-status.md
• templates/memory/decision-log.md -> memory/decision-log.md
• templates/memory/claim-board.md -> memory/claim-board.md
• templates/memory/evidence-board.md -> memory/evidence-board.md
• templates/memory/risk-board.md -> memory/risk-board.md
• templates/memory/action-board.md -> memory/action-board.md
• templates/memory/provenance-board.md -> memory/provenance-board.md
• templates/memory/handoff-board.md -> memory/handoff-board.md
• templates/memory/phase-dashboard.md -> memory/phase-dashboard.md
• templates/memory/source-visibility-board.md -> memory/source-visibility-board.md
• templates/component/component-status.md -> <component>/.agent/<component>-status.md
• コンポーネントが worktree を使用する場合、templates/component/worktree-index.md -> <component>/.agent/worktree-index.md
• コードまたは論文の worktree に専用のメモリが必要な場合、templates/component/worktree-status.md -> <component-worktree>/.agent/worktree-status.md

安全に推測できない項目だけを尋ねます。

• プロジェクト名
• プロジェクトのルート
• コンポーネントのパス
• 現在の研究課題
• 現在の投稿先またはマイルストーン（該当する場合）
• ユーザーがクラウドボードとの連携を希望する場合は、GitHub Project のオーナー／タイトル／URL／番号
• メモリファイルをコミットするかどうか

ステップ 3 - 初期化の概要を作成する

本格的な作業に入る前に、以下を要約します。

• プロジェクト名とルート
• 現在の研究課題と位置付け
• 投稿先またはマイルストーン
• アクティブなコンポーネントとパス
• 現在の主張 ID
• 現在のエビデンス ID と最新の信頼できる結果
• 現在のフェーズとアクティブなゲート
• 対応が必要な来歴の不足事項と暫定的な結果
• 未完了のコンポーネント間ハンドオフ
• 論文ソースの公開範囲とクリーンアップの阻害要因
• 主なリスクと阻害要因
• アクティブなアクションと担当者
• 古くなっている、または不足しているメモリ
• 実行前に検証が必要な事実

概要は簡潔にまとめます。ユーザーから依頼がない限り、ボード全体を貼り付けないでください。

ステップ 4 - 適切なレイヤーに書き込む

references/writeback-protocol.md を読みます。

次のルーティングを使用します。

• プロジェクト全体の識別情報、投稿先、コンポーネントのパス、メモリポリシー -> memory/project.yaml
• GitHub Project ボードのオーナー、URL、番号、スコープ、同期ポリシー -> memory/project.yaml
• ツールチェーンのゲートポリシーとデフォルトコマンド -> memory/project.yaml
• 現在の重点、アクティブなマイルストーン、次回セッションの開始点 -> memory/current-status.md
• 永続的なプロジェクト上の決定事項とその理由 -> memory/decision-log.md
• 論文の主張とそのステータス -> memory/claim-board.md
• 主張を裏付ける実験、分析、証明、引用、図 -> memory/evidence-board.md
• 生データの結果、CSV、レポート、アセット、キャプション、文章のトレーサビリティ -> memory/provenance-board.md
• 査読者、新規性、ベースライン、執筆、実行、反論に関するリスク -> memory/risk-board.md
• 具体的な次のタスクと担当者 -> memory/action-board.md
• プロジェクトのフェーズ、アクティブなゲート、準備状況、次のフェーズへの移行条件 -> memory/phase-dashboard.md
• コンポーネント間の生成側／利用側のペイロードと受け入れチェック -> memory/handoff-board.md
• 論文ソースの公開範囲レベル、対象読者、同期先、許可／禁止ファイル、クリーンアップゲート -> memory/source-visibility-board.md
• コンポーネント固有の状態 -> <component>/.agent/<component>-status.md
• グローバルな worktree レジストリとルートパス -> memory/component-index.yaml
• コンポーネント内の worktree 間のロールアップ -> <component>/.agent/worktree-index.md
• コード worktree の目的、または論文のバージョンポリシーと終了条件 -> <worktree>/.agent/worktree-status.md

迷った場合は、プロジェクトレイヤーには簡潔な参照先を書き、詳細はコンポーネントレイヤーに記録します。

Step 5 - Claim-Evidence-Risk-Action グラフを維持する

references/object-schemas.md を読みます。 クレームまたはエビデンス項目が変更されたときは、references/claim-lifecycle-protocol.md と references/evidence-provenance-protocol.md を読みます。

安定した ID を使用します。

• CLM-###：クレーム
• EVD-###：エビデンス項目
• EXP-###：実験または実行ファミリー
• FIG-###：図または表
• PRV-###：ソースデータまたは分析からエビデンス／アセット／文章への来歴リンク
• RSK-###：リスク
• ACT-###：アクション
• DEC-###：決定
• WTR-###：ワークツリー
• REV-###：レビューまたは反論の課題
• HND-###：モジュール間の引き継ぎ
• VIS-###：論文ソースの可視性の範囲またはポリシー
• GATE-###：ツールチェーンのゲートまたは必須のプロジェクトチェック

主要な更新では、リンクを維持してください。

CLM-001 -> supported_by EVD-003 -> traced_by PRV-002 -> visualized_by FIG-002 -> threatened_by RSK-004 -> resolved_by ACT-007

孤立したオブジェクトを作らないでください。エビデンスのないクレームには、planned、evidence-needed、provisional、または cut のいずれかを指定します。

Step 6 - フェーズと引き継ぎの状態を維持する

references/phase-dashboard-protocol.md と references/cross-module-handoff-contracts.md を読みます。

プロジェクトが主要なフェーズゲートを通過、またはそこから後退した場合は、memory/phase-dashboard.md を更新します。主要なフェーズゲートには、アイデアの検証、位置付け、手法の設計、実装、実験の設計、エビデンスの作成、論文アセットの構築、執筆、内部レビュー、投稿、反論、カメラレディ、アーティファクトのリリース、保守があります。

あるモジュールが別のモジュールで使用するペイロードを生成した場合は、memory/handoff-board.md を更新します。たとえば、手法の設計から実験の設計、実験レポートから論文アセットビルダー、エビデンスギャップマイナーから実験の設計、結果アセットビルダーから図表レビュー、執筆メモリからセクションライター、レビュワーシミュレーターからエビデンスボード、反論ストラテジストから実験／執筆担当、カメラレディの最終調整担当からアーティファクト／リリースへの引き継ぎなどがあります。

各引き継ぎには、生成元、受け取り先、ペイロード、ソースパス、期待される出力、受け入れチェック、陳腐化のトリガー、関連オブジェクト、ステータスを記載します。

Step 7 - 論文ソースの可視性を維持する

references/paper-source-visibility-protocol.md を読みます。

次の場合は、memory/source-visibility-board.md を更新します。

• 論文ブランチまたはワークツリーが Overleaf/GitHub にリンクされた場合
• paper/main が非公開ではなく、共同編集者に表示されるものとして扱われる場合
• 学会、匿名投稿、arXiv、カメラレディ、または出版社向けのソースワークツリーが作成された場合
• 論文アセットが非公開の生成元から、可視のソースへ移動した場合
• 可視ソース内に .agent/、AGENTS.md、CLAUDE.md、生の CSV、内部ドキュメント、プロットスクリプト、非公開パス、レビュワーメモ、または来歴ファイルが見つかった場合

可視性の階層には、agent-private、author-visible、anonymous-submission、public-preprint、camera-ready-public、publisher-artifact を使用します。

Step 8 - 整合性チェックを実行する

メモリを監査するときは、references/consistency-checks.md を読みます。

次の点を確認します。

• エビデンスのない論文のクレーム
• クレームまたは論文内の掲載箇所がないエビデンス
• 来歴のないエビデンス、表、図、キャプション、結果の文章
• アクションが設定されていないレビュワーのリスク
• 論文またはコードでのフォローアップがない反論時の約束
• 使用可能な状態だが未使用、アクションなしでブロック中、または陳腐化したモジュール間の引き継ぎ
• 禁止されたエージェント／非公開ファイルを含むソース可視範囲
• 現在のクレーム／エビデンス／来歴／リスク／アクション／引き継ぎボードと矛盾するフェーズダッシュボードのゲート
• 終了条件のないワークツリー
• グローバルレジストリまたはコンポーネントのワークツリーインデックスに登録されていないワークツリー
• 執筆で引き続き使用されている古い結果
• 論文のステータスと矛盾するスライド
• 変動しやすい状態が安定した事実として記録されている箇所

不一致は、プロジェクトのリスクまたはアクションとして報告します。

ステップ 9 - セッションを締めくくる

references/closeout-protocol.md を読みます。

重要なセッションを終える前に、以下を更新します。

• memory/current-status.md
• アクティブなフェーズまたはゲートが変わった場合は memory/phase-dashboard.md
• 変更された claim／evidence／provenance／risk／action／handoff ボード
• 結果、アセット、キャプション、表、図、または結果を述べる文のソースや検証状況が変わった場合は memory/provenance-board.md
• モジュールがハンドオフを生成、消費、ブロック、または無効化した場合は memory/handoff-board.md
• 論文のブランチ、worktree、Overleaf ブランチ、投稿用ソース、または公開ソースパッケージの公開範囲やクリーンアップ状況が変わった場合は memory/source-visibility-board.md
• 該当するコンポーネントのステータスファイル
• コードブランチの方針または論文のバージョンポリシーが変わった場合は worktree のステータスファイル
• worktree が追加、終了、保留、マージ、または破棄された場合は、コンポーネントの worktree インデックスと memory/component-index.yaml
• 永続的な決定を行った場合は memory/decision-log.md

締めくくりでは、次の点を明らかにします。何が変わったか、何が信頼できるか、何が古くなっているか、次のエージェントが何を検証すべきか、次に取るべき具体的なアクションは何か。

最終確認

最終確定の前に、以下を確認します。

• 安定した事実と変動する事実が分けられている
• 新しい claim は evidence にリンクされているか、evidence-needed、provisional、parked、または cut として明示されている
• 新しい evidence は claim、コンポーネント、ソースパスにリンクされている
• 新しい evidence には provenance があるか、不足している provenance を説明する action がある
• プロジェクトが初期状態ではない場合、アクティブなフェーズと次のゲートが確認できる
• アクティブなモジュール間ハンドオフには、生成元、受け取り先、受け入れ確認、陳腐化のトリガーがある
• 外部から確認可能な論文ソースには、公開範囲、許可／禁止ファイルのポリシー、クリーンアップのゲート、最新の監査状況が設定されている
• 新しいリスクは、アクションまたは受容済みリスクの決定にリンクされている
• worktree のメモリには、目的と終了条件が記載されている
• アクティブな worktree は、ルートレジストリと該当するコンポーネントの worktree インデックスの両方に記載されている
• current-status に、次のセッションを開始するための明確な情報が記載されている
• ユーザーが明示的に希望していない限り、共有メモリに非公開のローカルパスや認証情報が記載されていない