research-project-memory

研究项目记忆

将项目记忆维护为分层系统，而不是扁平的笔记文件。此技能为 Agent 提供一套共享协议，用于记住研究项目要证明什么、现有哪些证据、还存在哪些风险，以及每项后续行动由哪个组件负责。

在以下情况下使用此技能：

• 项目需要超越远程执行状态的跨会话记忆
• 用户希望在 paper/、code/、工作树、slides/、审稿模拟或 rebuttal 之间保留记忆
• 需要让主张、实验、图表、论文部分、审稿风险和行动保持一致
• 某次会话实质性地改变了项目方向、证据、写作、审稿风险或计划实验
• 新的 Agent 会话需要在采取行动前获取初始上下文
• 用户要求提供记忆系统、项目状态图、主张/证据看板、工作树记忆或收尾协议

这是一项协调技能。它不取代 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。
• 涉及主张、证据、项目阶段、论文写作、实验规划、审稿、rebuttal 或跨组件交接时，阅读 references/claim-lifecycle-protocol.md、references/evidence-provenance-protocol.md、references/phase-dashboard-protocol.md 和 references/cross-module-handoff-contracts.md。
• 涉及论文分支、Overleaf/GitHub 同步、协作者可见的源文件、匿名投稿源文件、arXiv、camera-ready 源文件包或论文工作树清理时，阅读 references/paper-source-visibility-protocol.md。
• 配置、更改或检查代码、论文、文档、Git、GitHub、远程、发布或制品质量门禁时，阅读 references/toolchain-gates-protocol.md。
• 要求审计项目状态、准备里程碑、投稿、写作、审稿或 rebuttal 时，阅读 references/consistency-checks.md。
• 在结束重要会话或完成有意义的工作后更新记忆之前，阅读 references/closeout-protocol.md。
• 初始化缺失的记忆文件时，以 templates/ 为准。

核心原则

• 记忆是协作上下文，不是执行事实。
• 稳定的主张、决策、风险和组件映射应记录在仓库记忆中。
• 脏 Git 状态、队列状态、活动作业和文件是否存在等易变事实必须重新核实。
• 主张应通过明确的生命周期从想法推进到最终定稿或删减；不要让论文文字悄然采用缺乏依据的主张。
• 证据必须保留足够的来源信息，以便将面向论文的表格、图、图注和结果语句追溯到 CSV、报告、运行记录、引用、分析或素材。
• 论文源文件的可见性是一项首要策略。如果论文分支已关联 Overleaf 或对合作者可见，应将其视为 author-visible，而非 Agent 私有。
• 项目阶段仪表板提供全局周期视图；详细看板仍负责底层的主张、证据、风险、行动、来源信息和交接对象。
• 工作在想法、方法、代码、论文、幻灯片、评审、答辩、制品或发布模块之间流转时，应明确记录跨模块交接。
• 每项重要主张都应关联证据、论文位置和当前风险。
• 每项评审或答辩风险都应关联一项行动、接受该风险的决策，或说明其不在范围内的理由。
• 每个工作树都应有明确用途和退出条件：合并、继续、搁置或终止。
• 论文版本工作树还应记录目标会议／发布版本、投稿模式、模板／样式差异、源文件可见性、清理要求和编译工作流。
• .agent/、AGENTS.md、CLAUDE.md、写作记忆、原始 CSV、绘图脚本、内部结果文档和评审策略等 Agent 私有论文状态，不得包含在作者可见、投稿、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 中的叶节点状态。
• 配置后，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
• 当组件使用工作树时，templates/component/worktree-index.md -> <component>/.agent/worktree-index.md
• 当代码或论文工作树需要独立记忆时，templates/component/worktree-status.md -> <component-worktree>/.agent/worktree-status.md

只询问无法安全推断的字段：

• 项目名称
• 项目根目录
• 组件路径
• 当前研究问题
• 当前目标投稿 venue 或里程碑（如有）
• 如果用户需要集成云端看板，询问 GitHub Project 的所有者、标题、URL 和编号
• 是否应提交记忆文件

步骤 3 - 构建初始化摘要

在开展实质性工作之前，总结：

• 项目名称和根目录
• 当前研究问题和定位
• 目标投稿 venue 或里程碑
• 活跃组件及其路径
• 当前 claim ID
• 当前 evidence ID 和最新可靠结果
• 当前阶段和活跃关卡
• 活跃的来源溯源缺口和暂定结果
• 尚未解决的跨模块交接事项
• 论文源文件的可见性范围和清理阻碍
• 主要风险和阻碍
• 活跃任务和负责人
• 过期或缺失的记忆
• 行动之前必须核实的事实

保持摘要简洁。除非用户要求，否则不要粘贴整个看板内容。

步骤 4 - 写入正确的层级

阅读 references/writeback-protocol.md。

按以下规则确定写入位置：

• 整个项目的身份信息、目标投稿 venue、组件路径、记忆策略 -> 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
• 审稿人、新颖性、基线、写作、执行和 rebuttal 风险 -> 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
• 全局工作树登记信息和根路径 -> memory/component-index.yaml
• 组件本地的跨工作树汇总 -> <component>/.agent/worktree-index.md
• 代码工作树用途，或论文版本策略和退出条件 -> <worktree>/.agent/worktree-status.md

如不确定，在项目层写入简短索引，并将详细信息写入组件层。

步骤 5——维护主张—证据—风险—行动图谱

阅读 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。

步骤 6——维护阶段和交接状态

阅读 references/phase-dashboard-protocol.md 和 references/cross-module-handoff-contracts.md。

当项目跨越或退回某个重大阶段门槛时，更新 memory/phase-dashboard.md：创意验证、定位、方法设计、实现、实验设计、证据产出、论文资产构建、撰写、内部评审、投稿、反驳、定稿、工件发布或维护。

当一个模块产出另一个模块应消费的内容时，更新 memory/handoff-board.md，例如从方法设计到实验设计、从实验报告到论文资产构建器、从证据缺口挖掘器到实验设计、从结果资产构建器到图表评审、从写作记忆到章节撰写器、从评审模拟器到证据看板、从反驳策略制定者到实验／撰写人员，或从定稿处理器到工件／发布。

每项交接都应注明产出方、消费方、内容、源路径、预期输出、验收检查、过时触发条件、关联对象和状态。

步骤 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。

步骤 8——运行一致性检查

审查记忆时，阅读 references/consistency-checks.md。

检查以下问题：

• 论文主张没有证据支持
• 证据没有对应的主张或论文位置
• 证据、表格、图、图注或结果正文没有溯源信息
• 评审风险没有对应行动
• 反驳承诺没有对应的论文／代码跟进
• 跨模块交接已就绪但尚未被消费、受阻却没有对应行动，或已过时
• 源文件可见性范围包含被禁止的 Agent／私有文件
• 阶段看板门槛与当前的主张／证据／溯源／风险／行动／交接看板相矛盾
• 工作树没有退出条件
• 工作树未列入全局注册表或组件工作树索引
• 撰写中仍在使用过时结果
• 幻灯片与论文状态相矛盾
• 将易变状态记录为稳定事实

将不一致之处报告为项目风险或行动。

步骤 9 - 结束会话

阅读 references/closeout-protocol.md。

结束重要会话前，请更新：

• memory/current-status.md
• 如果当前阶段或关卡发生变化，则更新 memory/phase-dashboard.md
• 任何发生变更的主张／证据／来源追溯／风险／行动／交接看板
• 如果某个结果、素材、说明文字、表格、图或结果语句的来源或验证状态发生变化，则更新 memory/provenance-board.md
• 如果某个模块产出、使用、阻塞或使某项交接失效，则更新 memory/handoff-board.md
• 如果论文分支、工作树、Overleaf 分支、投稿源文件或公开源文件包的可见性或清理状态发生变化，则更新 memory/source-visibility-board.md
• 相关组件状态文件
• 如果代码分支方向或论文版本策略发生变化，则更新工作树状态文件
• 如果新增、关闭、搁置、合并或终止了工作树，则更新组件工作树索引和 memory/component-index.yaml
• 如果做出了长期有效的决策，则更新 memory/decision-log.md

结束会话时应说明：发生了什么变化、哪些内容可信、哪些内容已过时、下一个 Agent 应验证什么，以及下一项具体行动是什么。

最终检查

完成前，请确认：

• 稳定事实与易变事实已分开
• 新主张已链接到证据，或标记为 evidence-needed、provisional、parked 或 cut
• 新证据已链接到主张、组件和源文件路径
• 新证据附有来源追溯信息，或有行动项说明缺少哪些来源追溯信息
• 如果项目已脱离初始状态，则当前阶段和下一个关卡清晰可见
• 活跃的跨模块交接均包含生产方、消费方、验收检查和过时触发条件
• 可见的论文源文件界面均设有可见性层级、允许／禁止的文件策略、清理关卡和最新审计状态
• 新风险已关联到行动项或接受风险的决策
• 工作树记忆包含用途和退出条件
• 活跃工作树同时出现在根注册表和相关组件的工作树索引中
• current-status 为下一次会话提供明确的起点
• 除非用户明确要求，否则共享记忆中不写入私有本地路径或凭据