context-drift

Context Drift

使用此技能可审查或修复存储库中承载关键信息的上下文文件之间的偏差，同时不丢失细节，也不模糊它们各自的职责边界。

如果此技能已加载，而本轮其余内容中没有任何由人撰写的任务文本——包括唯一的其他内容只是自动生成的系统或工具通知（例如诊断或上下文消息）——不要因此认定无事可做。仅加载此技能本身就是请求。请立即依据本文档中的默认设置，对当前存储库开始第 1 阶段。不要等待，不要只确认技能已可用，也不要询问要处理什么。

权限模型

此技能是协调器，并非决定各文件应包含哪些内容的最终权威。

在判断偏差之前，请预先调用或加载相关文件的所属技能。应以这些技能自身的职责分离规则、针对特定文件的防护措施以及文档归属逻辑为准，判断哪些内容应放在哪里。此技能负责协调跨文件比较、无损迁移计划和审批流程。不应自行判断文件归属，再到最后才引入所属技能。

如果两个所属技能给出的方向不同，请将这一冲突呈现给用户，而不要在此处自行裁决。

规范归属模型

在将任何内容认定为冗余、位置不当或过时之前，请先使用此归属模型作为路由图。它是指向各归属技能的快速索引，不能替代这些技能的判断。

文件	核心问题	此处应包含的内容	重要性	配套技能
openspec/config.yaml	这个项目是什么？	项目 DNA、技术栈事实、结构默认值、制品规则	关键	accelint-onboard-openspec
ARCHITECTURE.md	这个系统是如何构建的？	系统结构、组件、部署、数据流、技术拓扑	重要	accelint-architecture-doc
AGENTS.md / CLAUDE.md	Agent 在此处应如何行动？	Agent 工作流、审批边界、沟通规则、特定于仓库的工作规范	关键	accelint-onboard-agents
CONSTRAINTS.md	为什么有些选择不可妥协？	外部约束：合规、安全、利益相关方、供应商、托管、范围边界	重要	constraints-extractor
EPISTEMIC-MAP.md	我们有多确定？	已验证事实、未解决问题、假设、推断出的风险	重要	epistemic-mapper
JARGON.md	这些术语是什么意思？	词汇表条目、缩写、内部术语、简要定义	辅助	jargon-extractor
README.md	人类如何开始使用？	面向人类的入门信息、安装／运行／使用基础、面向外部的项目介绍	重要	accelint-readme-writer

在一个文件中简短地指向另一个文件，通常是恰当的。完整重复内容通常不是。例如，AGENTS.md 可以要求 Agent 在开展部署工作前阅读 ARCHITECTURE.md，但部署拓扑本身应归入 ARCHITECTURE.md，而不是 AGENTS.md。

JARGON.md 与这组文件中的其他文件作用不同：它唯一的任务是简短、精炼地定义项目各处使用的术语——就像词典条目，而不是解释。因此，JARGON.md 与其他文件存在一些内容重叠是预期情况，并不代表内容偏移。其他规范文件可以在完整阐释某个术语有助于完成自身职责时，对其进行深入说明——ARCHITECTURE.md 完整呈现某项内容的技术图景，而 JARGON.md 仅用一行定义它，这不算重复，正如详细参考资料和词汇表释义各有不同作用。约束针对的是 JARGON.md，而非其他文件：JARGON.md 必须保持简洁。如果某个 JARGON.md 条目不再是简短定义，而开始包含与实际归属该细节的规范文件同等深度的内容，这才是需要修正的偏移——修正方式是缩短 JARGON.md 条目（也可以指向完整内容所在的位置），而不是删减其他文件。

绝对不要做这些事

• 在确定内容的归属位置之前，绝对不要删除内容。 如果某句话要从一个文件中移出，就将其移至规范归属文件、替换为简短指引，或保留原文。
• 绝不要为了方便迁移，就把详细陈述改成含糊的摘要。 “无损”意味着操作层面的含义得以保留，细节程度也大致相同。
• 绝不要仅仅因为两个文件提到了同一概念，就称其为冗余。 一条指向 CONSTRAINTS.md 的行为规则，与重述约束本身并不是一回事。
• 绝不要因为两个章节以不同细节层次涉及同一主题，就将其归为重复内容。 为快速了解而编写的简短摘要，与用于完整技术参考的全面说明，即使描述的是同一个子系统，也不是相同的信息；精选示例并非详尽表格的重复，概念图也不是结构图的重复。在认定内容完全重复或换种说法重复之前，请指出两个文件中在信息上确实等价、且其中一处变更会导致另一处过时的具体段落，而不是仅指出主题相近的内容。README.md 是最容易被误判的文件，因为压缩并预览其他文件中的内容本就是它的职责，并非内容漂移的迹象。
• 绝不要默认将 JARGON.md 与其他文件的内容重叠视为重复，也绝不要认定问题出在其他地方的详细解释上。 JARGON.md 唯一的职责是集中提供简洁的术语定义，因此，其他文件提及其中定义的术语——即使根据自身职责需要对该术语进行完整详细的解释——也是正常的，不属于内容漂移。限制恰恰相反：JARGON.md 本身必须保持简洁。如果 JARGON.md 中的条目与其他文件中的解释内容逐渐趋同，就把 JARGON.md 中的条目精简为简短定义；不要缩短实际负责提供详细内容的文件。
• 当相关所有者技能能够给出答案时，绝不要仅凭此技能决定文件归属。 先加载所有者技能，并以其标准为准。
• 绝不要通过此技能直接编辑来实施已获批准的更改，即使更改看起来只是机械操作。 每项已接受的提案都应通过相关所有者技能执行。
• 当用户要求逐项审批提案时，绝不要未经审核就批量应用整个清理流程。 逐项展示每个拟议更改，然后等待接受、拒绝或讨论。
• 绝不要临时凭空指定新的规范归属位置。 只能将内容移至现有文件所承担的用途范围内，或者明确说明缺少合适的目标文件。
• 绝不要默默扩大审计范围。 如果用户指定了五个文件，第一轮就只检查这五个文件，除非明确需要检查其他文件，并说明原因。
• 绝不要让方便程度凌驾于文档归属之上。 内容的正确归属位置应由相关所有者技能决定，而不是取决于把句子留在哪里最省事。
• 绝不要把“默认审计并实施”当作可以绕过第 6 阶段关卡、直接写入文件的许可。 这个默认设置决定的是你是否要在列出问题后继续制定更改计划，并不意味着无需展示差异预览并获得明确接受就可以写入更改计划。如果没有人可以回应接受、拒绝或讨论，就停在关卡处；不要代替对方自行批准。

审查前，应用默认设置

不要向用户询问以下问题。检查用户是否已针对每项给出答案；如果没有，则采用默认设置并继续。

1. 仅审查，还是审查并应用？
   • 如果用户表示类似“目前只需验证”，则在列出问题后停止。
   • 默认：审查并应用。此处的“应用”是指：列出问题后，继续执行第 5 阶段的变更计划和第 6 阶段的差异预览。这并不意味着在第 6 阶段的接受／拒绝／讨论关卡得到答复前就写入文件——该关卡不可跳过，且不取决于用户是否要求逐项讲解。
2. 精确范围，还是默认的规范文件集？
   • 如果用户指定了具体文件，则仅审查这些文件。
   • 默认文件集：AGENTS.md、CLAUDE.md、ARCHITECTURE.md、CONSTRAINTS.md、JARGON.md、EPISTEMIC-MAP.md、README.md、openspec/config.yaml。
3. 仅进行无损移动，还是也进行更广泛的清理？
   • 如果用户要求更广泛的清理，则照办。
   • 默认：仅进行无损移动。
4. 仅报告缺失的目标文档，还是也创建／刷新？
   • 如果用户明确要求创建或刷新缺失的文档，则照办。
   • 默认：先报告，获批后再创建。

对于用户未回答的任何问题，说明你将采用的默认设置，让用户在工作开始前知晓这些假设。

工作流程

按顺序执行以下阶段。

第 1 阶段：确定范围并阅读实际来源

1. 根据上述默认设置确定范围内的文件，并应用用户已明确给出的任何范围。继续处理前，不要暂停询问用户是否确认此列表。
2. 在判断内容是否重叠前，完整阅读每个范围内的文件。
3. 如果 AGENTS.md 和 CLAUDE.md 均存在，则先确定其中一个是否为指向另一个的指针存根，再将它们视为独立来源。
4. 如果某个文件缺失，不要仅因此就认定存在偏差。只有当其他文件包含明显属于该缺失文件的内容时，才需考虑此情况。
5. 说明你正在审查的文件集。

第 2 阶段：使用子 Agent 执行文档归属技能审查

如果可以使用子 Agent，这是首要的重点环节。

针对范围内的每个文件，按文档归属者／文件配对启动一个子 Agent。每个子 Agent 应：

1. 加载相关归属技能
2. 完整阅读分配给它的文件
3. 根据归属技能自身的文档归属和护栏逻辑判断该文件
4. 仅返回简洁、结构化的发现，而非冗长的过程记录

至少对每个受审查文件执行一次归属技能审查。如果某个文件也可能是移动内容的目标，则还应在审查过程中纳入该目标文件对应的归属技能。

将这些归属技能子 Agent 视为以下事项的权威来源：

• 各文档应包含哪些内容
• 如何区分正确的指针行为与不当重复
• 无损移动后必须保留的细节程度
• 移动的内容应放在目标文档的哪个位置

仅使用上方的路由映射来决定启动哪项归属技能。不要用此技能的摘要表代替归属技能本身的判断。

保持父级上下文精简。每个审查子 Agent 只需返回父级后续阶段实际需要的信息：

• 问题 ID 或本地发现 ID
• 当前文件和位置
• 疑似偏差类型
• 建议的规范归属位置
• 简短的证据摘录
• 简短说明指出相关发现背后的归属技能规则或边界
• 任何不确定性，或与其他可能相关的归属技能之间的冲突

不要仅为了重新整理相同的发现而启动第二轮汇总子 Agent。在父级上下文中合并精简的发现集。

如果无法使用子 Agent，则以内联方式调用或加载归属技能，但仍须遵守相同原则：先咨询归属技能，再判断偏差，并且仅保留精简的发现以供后续使用。

阶段 3：检测偏移类型

根据各所有者技能的判断，在提出任何编辑建议之前，对每个问题进行分类。

偏移类型	含义	典型修复方式
完全重复	相同信息出现在两个位置，且用途相同	保留规范版本，将另一处替换为指针，或在迁移完成后删除
改写式重复	相同观点以略有不同的措辞重复出现	合并为一条规范表述，只在其他位置保留会影响行为的指针
内容位置错误	某条说明位于错误的文档层级	将其移至正确文件，并视情况留下简短指针
冲突	两个文件对同一事实给出了不兼容的版本	明确列出两者，不要擅自选择；编辑前先询问或核实
缺少目标文件的候选内容	一个文件包含某些内容，但正确的目标文件尚不存在	报告此问题，并询问是否创建或刷新缺失的规范文件
缺少指针	某个文件应指向另一份规范文档，而不是重述其内容	添加指针，而不是重复源材料

在将任何内容标记为完全重复或改写式重复之前，先并排引用各文件中重叠的段落。如果其中一份是精简的概览摘要（示例更少、图示更简单、统计数字为汇总值），而另一份是其概述的完整参考资料，则这不属于重复——涉及同一子系统，不代表承载了相同信息。只有当两处内容需要同步变更时，才应将其归类为重复。

阶段 4：先给出仅核验的发现

如果用户要求仅核验，请在此处停止。

以简洁的条目列表报告问题，并包含以下字段：

• 问题 ID
• 当前位置
• 建议的规范归属位置（依据相关所有者技能）
• 偏移类型
• 偏移原因
• 确切摘录或范围明确的摘要

此阶段应以描述为主，不要提出修改建议。请明确指出，当前内容位置违反了哪条所有者技能边界或规则。

阶段 5：将发现转化为无损变更计划

对每个问题，将基于所有者技能得出的发现转化为具体迁移方案。

使用以下结构：

提案	操作	来源	目标	无损检查
P1	移动 / 合并 / 添加指针 / 不变更	源文件 + 章节	目标文件 + 章节	说明变更后相同细节将保留在哪里

对于每项删除或精简，都要明确说明保留的内容将存放在哪里。如果无法指出该目标位置，则此变更方案尚未实现无损。

阶段 6：逐项审阅提案并提供差异预览

每种模式下的每项提案都必须经过此阶段，无论默认采用审计还是应用模式，也无论用户是否明确要求逐项审阅。任何提案都不能从发现直接跳到文件编辑。如果用户要求逐项审阅，这也正是应采用的节奏——一次审阅一项提案，并在进入下一项之前等待决定。

如果本轮无人可以回应以下提示（例如，调用该技能时没有附带任何后续任务文本），则展示提案及其差异预览，以“接受 / 拒绝 / 讨论”的提示结尾，并在此处停止。不得将沉默或无人回应视为接受。

对于每项提案：

1. 用一段话说明理由。
2. 展示每个受影响文件的 Git 差异样式预览。
3. 以直接提示结尾：接受 / 拒绝 / 讨论。
4. 等待回应后再进入下一项提案。

请使用如下预览格式：

--- AGENTS.md
- Deployment topology: API runs in ECS behind ALB, worker runs on Fargate...
+ Read `ARCHITECTURE.md` before changing deployment-related code.

--- ARCHITECTURE.md
+ Deployment topology: API runs in ECS behind ALB, worker runs on Fargate...

如果提案只添加指针，则仅展示该文件。如果提案会变更三个文件，则将三者的预览一并展示，以便用户确认迁移确实无损。

Stage 7：使用子 Agent 执行应用阶段

有子 Agent 可用时，这是第二个主要使用它们的环节。

只有在 Stage 6 中确实接受了提案后，Stage 7 才会开始；绝不能仅仅因为“审计并应用”就直接进入 Stage 7。即使改动看起来只是机械操作，也不要通过此技能直接编辑来应用已接受的提案。

对于每个受影响的文件，启动相应的所有者技能子 Agent，并向它提供已批准的提案、需要保留的确切内容，以及其他文件中所需的指针或移除行为。由所有者技能子 Agent 决定如何在其自身的规范文档中落实改动，同时保持已批准的范围。

如果某项提案影响多个文件，就为该提案启动所需的所有相关所有者技能子 Agent。确保它们之间同步落实已接受的改动，不要让任何一个子 Agent 暗中扩大已批准的范围。

不要在审批循环与文件所有者应用子 Agent 之间插入额外的提案整形或应用规约子 Agent。用户批准提案后，应直接从父级审批状态进入相关的所有者技能应用子 Agent。

如果没有子 Agent 可用，则内联调用所有者技能，并仍须遵守以下规则：由所有者技能应用改动，而非由协调者自行处理。

示例：

Invoke the accelint-onboard-agents skill.

Apply the approved change below to AGENTS.md only.
Remove the architecture detail from AGENTS.md, keep a short behavior-level pointer, and preserve the original meaning without widening scope.

Invoke the accelint-architecture-doc skill.

Add the approved deployment-detail block into ARCHITECTURE.md at the correct architectural section. Preserve the existing structure and keep the imported detail at the same level of specificity.

使用此路由表：

• AGENTS.md / CLAUDE.md → accelint-onboard-agents
• openspec/config.yaml → accelint-onboard-openspec
• ARCHITECTURE.md → accelint-architecture-doc
• CONSTRAINTS.md → constraints-extractor
• EPISTEMIC-MAP.md → epistemic-mapper
• JARGON.md → jargon-extractor
• README.md → accelint-readme-writer

Stage 8：总结已更改的内容及仍需关注的事项

应用已批准的改动后，报告：

• 哪些提案已接受、已拒绝或仍未解决
• 哪些文件发生了更改
• 仍未解决的偏差问题
• 是否仍需创建缺失的规范文件

输出模式

选择最符合请求的精简模式。

1. 审计模式

用户说“检查”“验证”“审计”或“列出问题”时使用。

输出：

• 范围内的文件列表
• 仅列出问题
• 不做编辑

2. 变更计划模式

用户希望获得逐项列出的“将 X 从 Y 移至 Z”指南时使用。

输出：

• 问题列表
• 提案表
• 暂不编辑

3. 交互式应用模式

用户希望逐项批准变更时使用。

输出：

• 逐项提供提案差异预览
• 接受／拒绝／讨论循环
• 仅应用已批准的提案

重要说明

• 在任务开始阶段就加载相关所有者技能，不要等到发现问题后才加载。
• 仅在有子 Agent 可用时，在两个环节使用它们：所有者技能审查阶段和所有者技能应用阶段。
• 将 Stage 3 至 Stage 6 保留在父级上下文中，避免技能通过不必要的规约或提案子 Agent 反复传递同一批发现数据。
• 此技能负责协调跨文档比较与审批；它不能取代所有者技能对特定文件的判断。
• 如果某个文件只需改变读者行为，优先使用指针而非重复内容。
• 优先采用最小有效改动。不要借跨文档偏差检查之名进行大范围重写。
• 如果两个文件对同一事实存在分歧，应将其视为需要解决的冲突，而非清理机会。
• 如果用户指定了子集，例如 AGENTS.md、ARCHITECTURE.md 和 openspec/config.yaml，则保持相同的推理模型，但仅审计该子集。
• 如果用户要求改动必须无损，即使措辞有所变化，也要保留相同的操作细节。