cursor-memory-curator

Cursor Memory Curator

目标

将 Cursor 持久上下文视为由用户拥有的 Agent 状态进行审查：揭示过时、不安全、重复、被忽略、冲突或放置不当的规则；提出更合适的存放位置；并通过一份明确的契约处理审查、规划、持久化和清理。

范围仅限 Cursor Project Rules、旧版 .cursorrules、AGENTS.md、User Rules、Team Rules，以及由用户维护的 Cursor memory-bank 产物。不要将其视为 Codex 记忆整理工具。

适用场景

• 用于审查、放置、规划或清理描述中列出的 Cursor 持久化内容。
• 当这些内容过时、冲突、敏感、被忽略、范围过宽，或导致 Cursor 忘记或重复使用旧指导时使用。

不适用场景

• 不用于 Codex 记忆、普通文档，或不涉及 Cursor 持久上下文的通用提示词工作。
• 审查请求必须保持只读。User Rules 和 Team Rules 必须由用户手动处理，除非涉及有文档记录的文件型产物或明确获批的导出路径。

工作流选择

按以下固定顺序展示全部八种工作流；当意图明确时可精简展示。根据用户要求的结果和交付方式推荐匹配的路径；对于未说明意图的调用，推荐 review-chat 并请用户选择：

工作流	交付内容与结果
plan-run-cleanup-file	一条记录：审查、获批计划、备份、清理和验证。
review-chat	聊天：只读审查和建议。
review-file	一条记录：只读审查和建议。
cleanup-chat	聊天和备份：审查、高置信度原子清理和验证。
cleanup-file	一条记录和备份：审查、高置信度原子清理和验证。
plan-cleanup-chat	聊天：审查和获批计划；不执行清理。
plan-cleanup-file	一条记录：审查和获批计划；不执行清理。
plan-run-cleanup-chat	聊天和备份：审查、获批计划、清理和验证。

根据意图选择路径，而不是添加 auto 工作流：

• 直接审查默认选择 review-chat；明确要求持久化时选择 review-file。
• 明确要求清理但未指定交付方式时，选择 plan-run-cleanup-file。
• 如果直接请求明确，可在交付方式和执行意图都清楚时选择其他匹配路径。
• 由 Agent 主动启动时，只能选择相关的只读路径。仅当现有任务已要求持久化时才使用 review-file；绝不可推断用户授权了清理。
• 对于未说明意图的调用、相互冲突的线索，或对审查还是清理、聊天还是文件、是否执行、目标路径或修改权限存在歧义的情况，展示表格并请用户选择。
• 只有当用户已要求清理明确指定的 Cursor 上下文范围时，才可选择会执行修改的路径。

在实质性检查之前，只披露一次完整且有限的选项，并说明 Selected、Reason、目标路径、写入范围、预期产物、受保护状态、Plan 模式能力，以及尚待批准的事项。复用任务中已确定的事实和明确授权；将已知字段合并成简短说明。若选择明确，说明后继续。若存在歧义，则在盘点之前停下，只询问尚未解决的选择。不要重复展示选择器，也不要再次询问用户已经明确的选择。

选择工作流并不代表用户授权删除整个文件、破坏性恢复、编辑 User/Team 设置、执行付费或外部操作、部署、发布或扩大范围。

要检查的输入

• 确定仓库，以及仅适用的 .cursor/rules、.cursorrules、AGENTS.md、提供的 User/Team Rule 导出内容和提供的 memory-bank 路径。
• 仅在需要核实有争议的说法时，检查当前仓库证据。
• 仅在相关决策确实需要时，加载以下放置、分类、冲突和安全编辑参考资料。生成报告或计划时，加载相应的报告或计划资源。

工作流

每条路径都必须针对明确请求的范围，执行同等质量的审查，然后才能进行规划或清理。针对某个文件或说法的请求，并不授权检查整个存储库：应使用定向读取，而不是全根目录清点或扫描命令；仅在解决范围内的冲突时，才查阅其他证据。交付方式不得降低审查质量：

1. 确定所选路径、目标仓库和上下文路径（如适用），以及受保护状态。

2. 清点 Cursor 上下文，但不要输出其内容：

   node scripts/inventory-cursor-context.mjs --repo .
   

   如需指定 memory-bank 资源，请添加 --memory-bank PATH。需要结构化证据时，使用 --json。

3. 查找敏感、过时、范围过广、已忽略、旧版、本地或易发生冲突的规则时，运行脱敏风险扫描器：

   node scripts/scan-cursor-context-risks.mjs --repo . --json
   

   退出代码 1 表示发现问题，并非扫描失败。请概述数量及信号最强的脱敏发现，而不要粘贴完整内容。

4. 解析会影响 Cursor 行为的 .mdc 前置元数据字段：description、globs 和 alwaysApply。

5. 将 .cursor/rules 下的纯 .md 文件标记为 Cursor Project Rules 元数据所忽略的文件，并建议转换为 .mdc 或移至 AGENTS.md。

6. 除非存在当前有文档记载的文件系统路径，否则将 User Rules 和 Team Rules 视为设置证据或用户提供的导出内容。

7. 分段读取上下文文件，并对敏感值进行脱敏。

8. 每行提取一个原子性说法。分类前拆分复合规则。

9. 仅根据核实争议所需的仓库文件，验证有争议的说法。如果优先级不明确，请加载 references/conflict-resolution.md。

10. 为每条原子性说法指定且仅指定一个主要分类：KEEP、KEEP BUT REWRITE、MOVE TO CURSOR PROJECT RULE、MOVE TO AGENTS.md、MOVE TO REPO DOCS、MOVE TO CURSOR USER RULES、MOVE TO CURSOR TEAM RULES、MOVE TO SKILL、MOVE TO CONFIG、DELETE 或 ASK USER。

11. 将高风险条目标记为仅供参考的上下文：stale、duplicated、too-broad、too-specific、repo-specific、workflow、config、sensitive、conflicting、ignored、legacy 或 useful。

12. 为每条内容添加置信度（high、medium 或 low）以及建议操作。

13. 先完成完整审查，再进行规划或编辑。交付路径不得降低审查质量，也不得扩大请求范围。

路由执行

• review-chat：在聊天中返回审查结果，不创建持久化整理报告。
• review-file：持久化单条整理记录，不更改任何上下文。
• cleanup-chat：仅从已完成的审查中提取高置信度的原子操作，为每个要更改的文件创建备份，然后执行操作，重新读取已更改的部分，并在聊天中报告验证结果。不创建持久化整理报告。
• cleanup-file：在修改前创建整理记录；若持久化失败，则停止。然后备份确切的文件，仅执行高置信度的原子操作，并在同一条记录中补全执行和验证信息。
• plan-cleanup-chat 和 plan-cleanup-file：进入 Plan 生命周期，与用户敲定清理计划，获批后停止，不更改 Cursor 上下文。
• plan-run-cleanup-chat 和 plan-run-cleanup-file：进入 Plan 生命周期，敲定并获批完整清理计划，重新检查状态，退出 Plan 模式，备份确切的文件，仅执行未更改的计划，并进行验证。计划获批后，不要再询问笼统的清理问题。

直接清理（cleanup-chat 或 cleanup-file）仅限于对现有、可编辑且由运行时管理的 Cursor 上下文执行高置信度的原子编辑、移动或条目删除。以下内容均应暂缓：删除整个文件、新建上下文文件、配置、User Rules、Team Rules、AGENTS.md、仓库文档、技能、不确定的 memory-bank 架构、中低置信度更改，以及任何范围扩展。只有当获批计划明确列出每个目标位置、写入路径、备份、回滚方式和单独的审批边界时，计划执行路由才可进行范围更广的整理更改。除非某个有文档记录且可编辑的导出项明确在范围内，否则 User Rules 和 Team Rules 仍需手动处理。

Plan 生命周期

在每条路由上都要遵守当前激活或请求启用的原生 Plan 模式，以及实际写入权限：Plan 模式激活或权限未知时，不得写入报告、备份或清理内容。无需手动切换模式，即可继续只读规划。对于 plan-* 路由或尚未解决的重要问题，请阅读 references/plan-lifecycle.md。复用未更改的审批；仅退出模式不代表已获批，未获答复的问题不授予任何权限。写入前重新检查状态，仅在有实质性变更时重新确认。仅规划路由绝不授权清理。

不要在此整理工作流中调用 cursor-spec-interviewer。如果发现的问题需要制定范围更广的持久规则、仓库规范，或尚未解决的产品决策，请先完成所选整理路由，再将访谈工具作为单独的后续事项提出。

文件交付约定

文件路由必须恰好持久化一条脱敏的整理记录。优先使用仓库中已有的原生报告位置；否则使用 <repo>/.agent-reports/cursor-memory-curation/<UTC timestamp>-<selection-id>.md。创建新路径时不得覆盖已有文件，并将所有路由输出保存在该记录中。

记录包含 Review、Plan、Execution Receipt、Deferred Work、Backup 和 Verification。对于路由不执行的阶段，使用 not applicable 并说明原因。对于 cleanup-file 和 plan-run-cleanup-file，必须在修改前创建记录；持久化失败时不得执行清理。聊天路由不创建报告文件。备份目录始终是必需的安全产物，不计作整理报告。

显式指定 --backup-root 时，必须同时指定稳定且非敏感的 --backup-root-alias；文件路由必须持久化脚本报告的可移植存储定位符以及 /backup-manifest.json。确切的绝对备份路径和清单路径只能在非持久化的聊天中报告，绝不能写入仓库产物。

安全规则

• 如果路由尚未明确，不要检查；只有在所选路由和用户请求授权清理确切目标范围时，才允许修改。
• 绝不悄悄删除、改写、截断或移动 Cursor 上下文文件。
• 在获批编辑前备份每个确切文件，并报告备份路径。
• 不要输出完整的密钥、令牌、凭据、客户数据、私人标识符或敏感个人数据。
• 如果发现类似密钥的数据，请在输出中遮盖其值，尽可能指出文件和行号，建议将其移除；如果是真实凭据，还应建议轮换。
• 如果记忆库架构不明确，不要直接编辑。应在当前记录或聊天结果中说明暂不处理。
• 不要根据仅限聊天的摘要编辑 User Rules 或 Team Rules；应改为提供手动操作建议。
• 不要将特定于仓库的假设应用到全局。仓库规则应优先参照 AGENTS.md、Cursor Project Rules 或仓库文档。
• 不要运行大范围破坏性命令。

参考资料

仅在需要时阅读：

• 文件放置与分类：references/context-surface-anatomy.md、references/classification-rubric.md。
• 冲突与安全修改：references/conflict-resolution.md、references/safe-editing-procedure.md。
• 示例与输出产物：references/example-review-report.md、assets/review-report-template.md、assets/cleanup-plan-template.md。

脚本

仅在需要时使用。所有脚本均为非交互式脚本，仅使用 Node.js 标准库，并支持 --help。

node scripts/inventory-cursor-context.mjs [--repo PATH] [--memory-bank PATH] [--json]
node scripts/scan-cursor-context-risks.mjs [--repo PATH] [--memory-bank PATH] [--json] [--max-findings N]
node scripts/backup-cursor-context.mjs [--repo PATH] [--memory-bank PATH] [--backup-root PATH --backup-root-alias NAME] [--include PATH ...]

• 清单生成是只读的。扫描器为只读工具，默认会遮盖内容，限制发现项数量；发现问题时以退出码 1 结束，而非表示执行失败。
• backup-cursor-context.mjs 会创建一个不会覆盖现有文件的备份，以及 backup-manifest.json，但不会编辑源文件。未遮盖的备份内容和清单必须保存在 Git 工作树之外。预检会拒绝不安全的根目录和路径中的所有符号链接组件；任何遍历错误都会在创建根目录前导致失败。编辑时请使用精确的 --include 路径；不指定任何路径则保留旧版发现行为。调用该脚本前，请阅读 references/safe-editing-procedure.md，了解根目录安全、预检、清单核对和恢复方法。

输出格式

使用上述工作流公告；仅报告尚未解决的审批关卡。

生成报告前，加载并遵循 assets/review-report-template.md，将其作为规范的标题和字段约定。文件路由会将该完整模板复制到一条整理记录中；聊天路由仅在聊天中呈现适用部分，不创建报告文件。填写所有适用字段；跳过的阶段应注明 not applicable 并说明原因，同时遮盖敏感值。

编辑前，完成审查表和决策表。编辑后，在同一条记录中填写回执，包括清单核对和未匹配路径、新路径（created-no-preimage）及回滚、备份模式和清单路径、备份完整性结果，以及以下行格式：| Changed path | Backup destination | Bytes | SHA-256 | Verification |。

完成标准

• 根据明确授权或已解决的歧义，选择了八种规范工作流之一；绝不根据 Agent 激活状态推断用户授权了清理。
• 已盘点适用的上下文和 .mdc 元数据，或报告其缺失；User/Team Rules 仅作为证据或经批准的导出内容保留，不会被悄悄编辑。
• 每条原子化声明都具有一项分类、风险标签、置信度和操作；适用时还应提供更高优先级的冲突证据。
• 始终遵守计划边界和直接清理边界。
• 聊天或文件交付符合规范模板约定；每项获授权的编辑都有精确文件备份、清单核对、重新读取和完整性结果。

失败模式

• 缺少可用界面或设置导出：报告不可用的内容，并在需要时提供手动添加用户规则／团队规则的建议。
• .cursor/rules 下的普通 .md 文件或未知的 memory-bank 架构：标记并暂缓处理，不要擅自编辑；适用时建议转换为 .mdc，或移至 AGENTS.md。
• 敏感或冲突的内容：进行脱敏；注明位置和优先级更高的来源；建议移除或轮换，或将其归类为重写、移动、删除或交由用户决定。
• 持久化、备份或已批准状态的重新检查失败：在修改前（或进一步修改前）停止，报告失败，并在发现偏差后返回规划阶段。