research-project-memory

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Research Project Memory

研究项目内存系统

Maintain project memory as a layered system, not a flat notes file. This skill gives agents a shared protocol for remembering what a research project is trying to prove, what evidence exists, what risks remain, and which component owns each next action.

Use this skill when:

a project needs cross-session memory beyond remote execution state
the user wants memory across
```
paper/
```
,
```
code/
```
, worktrees,
```
slides/
```
, reviewer simulation, or rebuttal
claims, experiments, figures, paper sections, reviewer risks, and actions need to stay aligned
a session materially changes project direction, evidence, writing, review risks, or planned experiments
a new agent session needs bootstrap context before acting
the user asks for a memory system, project state graph, claim/evidence board, worktree memory, or closeout protocol

This is a coordination skill. It does not replace

remote-project-control

experiment-design-planner

conference-writing-adapter

paper-reviewer-simulator

, or

rebuttal-strategist

; it tells them where and how to persist trusted project state.

为项目内存采用分层系统而非扁平笔记文件。此技能为Agent提供一套共享协议，用于记录研究项目试图证明的内容、已有的证据、剩余的风险以及每个后续行动对应的负责组件。

在以下场景使用此技能：

项目需要超越远程执行状态的跨会话内存
用户希望在
```
paper/
```
、
```
code/
```
、worktrees、
```
slides/
```
、评审模拟或反驳回复之间共享内存
需要确保论点、实验、图表、论文章节、评审风险与行动保持一致
某会话显著改变了项目方向、证据、撰写内容、评审风险或计划中的实验
新的Agent会话需要启动上下文才能开展工作
用户要求建立内存系统、项目状态图、论点/证据看板、worktree内存或收尾协议

这是一项协调类技能。它不会替代

remote-project-control

、

experiment-design-planner

、

conference-writing-adapter

、

paper-reviewer-simulator

或

rebuttal-strategist

；而是告知这些技能应在何处以及如何持久化可信的项目状态。

Skill Directory Layout

技能目录结构

text

<installed-skill-dir>/
├── SKILL.md
├── references/
│   ├── closeout-protocol.md
│   ├── consistency-checks.md
│   ├── memory-architecture.md
│   ├── object-schemas.md
│   └── writeback-protocol.md
└── templates/
    ├── component/
    │   ├── component-status.md
    │   └── worktree-status.md
    └── memory/
        ├── action-board.md
        ├── claim-board.md
        ├── component-index.yaml
        ├── current-status.md
        ├── decision-log.md
        ├── evidence-board.md
        ├── project.yaml
        └── risk-board.md

text

<installed-skill-dir>/
├── SKILL.md
├── references/
│   ├── closeout-protocol.md
│   ├── consistency-checks.md
│   ├── memory-architecture.md
│   ├── object-schemas.md
│   └── writeback-protocol.md
└── templates/
    ├── component/
    │   ├── component-status.md
    │   └── worktree-status.md
    └── memory/
        ├── action-board.md
        ├── claim-board.md
        ├── component-index.yaml
        ├── current-status.md
        ├── decision-log.md
        ├── evidence-board.md
        ├── project.yaml
        └── risk-board.md

Progressive Loading

渐进式加载

Always read

references/memory-architecture.md

references/object-schemas.md

, and

references/writeback-protocol.md

Read
```
references/consistency-checks.md
```
when asked to audit project state, prepare a milestone, submit, write, review, or rebut.
Read
```
references/closeout-protocol.md
```
before ending a substantial session or updating memory after meaningful work.
Use
```
templates/
```
as the source of truth when bootstrapping missing memory files.

务必阅读

references/memory-architecture.md

、

references/object-schemas.md

和

references/writeback-protocol.md

。

当需要审计项目状态、准备里程碑、提交、撰写、评审或反驳时，阅读
```
references/consistency-checks.md
```
。
在结束重要会话或完成有意义的工作后更新内存之前，阅读
```
references/closeout-protocol.md
```
。
当启动缺失的内存文件时，以
```
templates/
```
作为事实来源。

Core Principles

核心原则

Memory is coordination context, not execution truth.
Stable claims, decisions, risks, and component mappings belong in repo memory.
Volatile facts such as dirty git state, queue state, active jobs, and file existence must be re-verified.
Every important claim should link to evidence, a paper location, and current risks.
Every reviewer or rebuttal risk should link to an action, a decision to accept the risk, or a reason it is out of scope.
Every worktree should have a purpose and an exit condition: merge, continue, park, or kill.

Mark certainty:

observed

user-stated

inferred

stale

, or

needs-verification

Write memory at the most specific layer that will help the next session.

内存是协调上下文，而非执行事实。
稳定的论点、决策、风险和组件映射应存入仓库内存。
易变事实（如未提交的git状态、队列状态、活跃任务和文件存在性）必须重新验证。
每个重要的论点都应关联到证据、论文位置和当前风险。
每个评审或反驳风险都应关联到一项行动、接受风险的决策或超出范围的理由。
每个worktree都应有明确的目标和退出条件：合并、继续、搁置或终止。
标记确定性：
```
observed
```
（已观察）、
```
user-stated
```
（用户指定）、
```
inferred
```
（推断）、
```
stale
```
（过时）或
```
needs-verification
```
（需验证）。
在最具体的层级写入内存，以便为下一会话提供帮助。

Step 1 - Locate the Project and Existing Memory

步骤1 - 定位项目及现有内存

Detect the project root:

bash

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

Then inspect likely memory files:

```
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
```
```
paper/.agent/
```
```
code/.agent/
```
```
slides/.agent/
```
```
reviewer/.agent/
```
```
rebuttal/.agent/
```

If the project uses another layout, adapt the component paths but keep the same memory roles.

检测项目根目录：

bash

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
```
```
paper/.agent/
```
```
code/.agent/
```
```
slides/.agent/
```
```
reviewer/.agent/
```
```
rebuttal/.agent/
```

如果项目采用其他结构，调整组件路径但保留相同的内存角色。

Step 2 - Bootstrap Missing Memory

步骤2 - 启动缺失的内存

If the user asks to initialize memory, or if memory is missing and the task depends on it, create the minimum useful files from templates:

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/component/component-status.md

<component>/.agent/<component>-status.md

templates/component/worktree-status.md

<code-worktree>/.agent/worktree-status.md

when a worktree needs its own memory

Ask only for fields that cannot be inferred safely:

project name
project root
component paths
current research question
current target venue or milestone, if any
whether memory files should be committed

如果用户要求初始化内存，或内存缺失且任务依赖于它，则从模板创建最基本的有用文件：

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/component/component-status.md

<component>/.agent/<component>-status.md

当worktree需要独立内存时，

templates/component/worktree-status.md

<code-worktree>/.agent/worktree-status.md

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

项目名称
项目根目录
组件路径
当前研究问题
当前目标会议或里程碑（如有）
是否应提交内存文件

Step 3 - Build the Bootstrap Summary

步骤3 - 生成启动摘要

Before substantial work, summarize:

project name and root
current research question and positioning
target venue or milestone
active components and paths
current claim IDs
current evidence IDs and latest reliable result
top risks and blockers
active actions and owners
stale or missing memory
facts that must be verified before acting

Keep the summary compact. Do not paste entire boards unless the user asks.

在开展重要工作前，总结以下内容：

项目名称和根目录
当前研究问题与定位
目标会议或里程碑
活跃组件及路径
当前论点ID
当前证据ID及最新可靠结果
主要风险与障碍
活跃行动及负责人
过时或缺失的内存
开展工作前必须验证的事实

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

Step 4 - Write to the Right Layer

步骤4 - 写入正确层级

Read

references/writeback-protocol.md

Use this routing:

whole-project identity, target venue, component paths, memory policy ->
```
memory/project.yaml
```
current focus, active milestone, next session entry point ->
```
memory/current-status.md
```
durable project decisions and why ->
```
memory/decision-log.md
```
paper claims and their status ->
```
memory/claim-board.md
```
experiments, analyses, proofs, citations, and figures that support claims ->
```
memory/evidence-board.md
```
reviewer, novelty, baseline, writing, execution, and rebuttal risks ->
```
memory/risk-board.md
```
concrete next tasks and owners ->
```
memory/action-board.md
```

component-specific state ->

<component>/.agent/<component>-status.md

code worktree purpose and exit condition ->
```
<worktree>/.agent/worktree-status.md
```

When in doubt, write a short pointer at the project layer and details in the component layer.

阅读

references/writeback-protocol.md

。

采用以下路由规则：

整个项目的标识、目标会议、组件路径、内存策略 ->
```
memory/project.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
```

组件特定状态 ->

<component>/.agent/<component>-status.md

code worktree的目标和退出条件 ->
```
<worktree>/.agent/worktree-status.md
```

如有疑问，在项目层级写入简短指针，在组件层级写入详细内容。

Step 5 - Maintain the Claim-Evidence-Risk-Action Graph

步骤5 - 维护论点-证据-风险-行动图谱

Read

references/object-schemas.md

Use stable IDs:

```
CLM-###
```
: claim
```
EVD-###
```
: evidence item
```
EXP-###
```
: experiment or run family
```
FIG-###
```
: figure or table
```
RSK-###
```
: risk
```
ACT-###
```
: action
```
DEC-###
```
: decision
```
WTR-###
```
: worktree
```
REV-###
```
: review or rebuttal issue

Every major update should preserve links:

text

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

Avoid orphan objects. If a claim has no evidence, mark it as

planned

unsupported

, or

cut

阅读

references/object-schemas.md

。

使用稳定ID：

```
CLM-###
```
: 论点
```
EVD-###
```
: 证据项
```
EXP-###
```
: 实验或运行系列
```
FIG-###
```
: 图表或表格
```
RSK-###
```
: 风险
```
ACT-###
```
: 行动
```
DEC-###
```
: 决策
```
WTR-###
```
: worktree
```
REV-###
```
: 评审或反驳问题

每次重大更新都应保留关联：

text

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

避免孤立对象。如果论点没有证据，标记为

planned

（计划中）、

unsupported

（无支持）或

cut

（已取消）。

Step 6 - Run Consistency Checks

步骤6 - 运行一致性检查

Read

references/consistency-checks.md

when auditing memory.

Check for:

paper claims without evidence
evidence without a claim or paper location
reviewer risks without actions
rebuttal promises without paper/code follow-up
worktrees without exit condition
stale results still used in writing
slides that contradict paper status
volatile state recorded as stable truth

Report mismatches as project risks or actions.

审计内存时阅读

references/consistency-checks.md

。

检查以下内容：

无证据支持的论文论点
未关联论点或论文位置的证据
未关联行动的评审风险
未跟进论文/代码修改的反驳承诺
无退出条件的worktrees
撰写中仍在使用的过时结果
与论文状态矛盾的幻灯片
被记录为稳定事实的易变状态

将不匹配项报告为项目风险或行动。

Step 7 - Close Out the Session

步骤7 - 会话收尾

Read

references/closeout-protocol.md

Before ending a substantial session, update:

```
memory/current-status.md
```
any changed claim/evidence/risk/action board
relevant component status file
worktree status file if code branch direction changed
```
memory/decision-log.md
```
if a durable decision was made

Closeout should answer: what changed, what is trustworthy, what is stale, what should the next agent verify, and what is the next concrete action.

阅读

references/closeout-protocol.md

。

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

```
memory/current-status.md
```
任何已修改的论点/证据/风险/行动看板
相关组件状态文件
如果代码分支方向改变，更新worktree状态文件
如果做出了持久决策，更新
```
memory/decision-log.md
```

收尾应回答：哪些内容发生了变化，哪些内容可信，哪些内容已过时，下一个Agent应验证哪些内容，以及下一个具体行动是什么。

Final Sanity Check

最终合理性检查

Before finalizing:

stable and volatile facts are separated
new claims link to evidence or are marked unsupported
new evidence links to a claim, component, and source path
new risks link to actions or accepted-risk decisions
worktree memory has a purpose and exit condition
current-status gives the next session a clear starting point
no private local path or credential is written into shared memory unless the user explicitly wants it

完成前检查：

稳定事实与易变事实已区分
新论点已关联证据或标记为无支持
新证据已关联论点、组件和源路径
新风险已关联行动或接受风险的决策
worktree内存有明确目标和退出条件
当前状态为下一会话提供了清晰的起点
除非用户明确要求，否则共享内存中未写入私有本地路径或凭据