--- name: align-plan description: 通过代码调查和每轮 1–3 个问题对齐工程目标，纠正错误假设，维护当前决策，并经用户确认生成供新会话执行的计划。适用于需要先讨论需求、改造边界和实现取舍的任务；本 skill 不实施代码。 --- # 对齐目标并生成计划 产出一份新会话仅凭它和代码库就能实施的计划。调查服务于当前目标；不要把访谈变成遍历所有可能性的设计会议。 ## 资产位置 1. 先读取项目约束、Git 状态和项目根目录的 `.agent/MEMORY.md`。优先采用用户本次明确指定的资产目录，否则复用 MEMORY 中的 `讨论资产目录`；已有会话中明确指定的位置也有效，不重复询问。 2. 没有位置时，在首轮 1–3 个问题中询问外部资产根目录。等待期间可只读调查，不自行选择目录或把讨论写进项目代码目录。 3. 用户给出位置后，解析为绝对路径，确认不在当前代码库内；若用户明确要求例外，遵从其选择。确认目录可用后记录到 MEMORY，保留其中其他内容。区分系统资产根目录与本次计划目录；只指定计划目录时保留已知根目录，未知则询问，不把计划目录当根目录或推断其父目录。不可写或路径失效时说明具体问题，请用户提供可用位置，不静默回退。 4. MEMORY 只保存必要定位信息，例如： ```markdown --- 系统: 项目或系统名称 时间: YYYY-MM-DD 目标: 保存讨论资产位置 --- ## 讨论资产 - 讨论资产目录：/用户指定的系统资产根目录 ``` 写入前检查 MEMORY 是否被 Git 跟踪；已跟踪则说明与“不提交本地记忆”的冲突，先解决冲突，不自行取消跟踪。未跟踪时在 `git rev-parse --git-path info/exclude` 指向的本地排除文件中幂等加入 `/.agent/MEMORY.md`，不改共享 `.gitignore`。非 Git 项目仍保留本地记忆，并说明当前无法设置 Git 排除。 5. 严格使用用户指定目录作为资产根目录，可直接在其中建立 `<日期-计划主题>/`，不再插入项目名、系统名等中间目录。若用户已指定本次计划目录，直接使用，不再次嵌套。恢复同一计划时复用已有目录；新计划名称冲突时只调整计划目录名，不覆盖其他计划。核心文件为 `current.md` 和确认后生成的 `plan-v1.md`；后续确认版本另存，不覆盖旧批准版本。 每份生成资产（当前决策、计划、实施记录及其他讨论文档，包括 MEMORY）顶部使用下方模板中的 YAML frontmatter，按顺序包含 `系统`、`时间`、`目标`，不使用 HTML 注释。系统填写项目或系统名称，目标用一句话概括该资产对应的目标；无法确定的字段留空，不编造。时间采用用户当地的 `YYYY-MM-DD` 日期，表示该资产所依据决策的日期；尚无确认决策的草稿先记创建日期，正文仍标记待确认。确认或新决策改变当前资产内容时更新日期；纯排版、补证据或执行进度更新不改变决策日期。已批准计划保留原日期，新版本记录新确认日期；实施记录使用其所依据的计划决策日期。字段值包含 YAML 特殊字符时使用引号，保证元数据可解析。 宿主限制写入时，遵从限制，在对话中维护当前状态并明确尚未落盘；不要把未保存资产说成已保存。资产维护是规划阶段唯一的写入范围，不能开始项目实现。 ## 跨计划系统约束 确定资产根目录后，先读取 `<资产根目录>/CONTEXT.md`，再针对当前目标调查代码。新会话及上下文恢复时同样读取，不通过遍历历史计划恢复系统约束。文档不能替代对本次相关代码的核实。默认一个根目录对应一个系统；已有 CONTEXT 属于其他系统时先澄清，不混写或另建项目层级。 - 没有 CONTEXT 时可继续调查，在首次有已确认的长期约束时创建，不扫描历史计划补齐、不凭推测编写。 - 用户确认长期业务决策、业务约束或设计约束后立即更新，不等整份计划结束。未确认建议、假设和当前任务的问题留在 `current.md`。 - 正文按“业务约束”和“设计约束”组织；每条记录约束、适用范围、简短原因及状态。无需实施即可成立的规则标为“当前有效”；依赖尚未完成改造的规则标为“已确认待生效”，可附对应计划位置。 - 待生效的新规则不替代当前有效规则。新决策与现有约束冲突时，展示差异和影响，由用户确认保留、修订或替代；决策真正生效后再移除失效规则，避免并存矛盾。 - CONTEXT 自身必须可独立理解，不放聊天、任务清单、详细代码、测试日志或完整决策历史。仅保留当前需要的约束与原因，不能把局部实现偏好提升为系统规则。 - 顶部沿用 `系统`、`时间`、`目标` YAML 元数据；目标为“保存系统长期有效的业务与设计约束”。时间记录最近一次确认系统决策的日期，仅更新生效状态时不改日期。 ## 调查与问答 - 先读相关代码、调用链、现有测试与项目约束，再提出问题。需要外部证据时，针对影响当前决策的开源实现或官方资料查证，记录链接、版本或提交以及相关结论；不进行无边界的生态调研。无法查证的内容标记为待验证。 - 每轮提问共 1–3 个，只问影响目标、验收或实现选择的问题。能从环境查明的事实自己查。需要先前答案的问题留到下一轮；不要用一个问题包装大量独立子问题。 - 提问前给出必要的调查结论；存在真实取舍时给出简短选项、推荐及原因。使用宿主的提问工具（若可用），否则直接提问；不依赖特定工具，不使用装饰性 emoji。 - 对用户的判断区分事实、假设与偏好。事实有误时指出冲突证据、影响和替代建议；证据不足则说明不确定性。尊重明确的偏好，不为反驳而反驳，也不把用户提出的想法自动视作已批准方案。 - 优先复用现有能力、标准库和平台机制，选择满足已确认目标的最小实现。不用“简化”省略用户要求或必要的正确性保障。 - 新想法先核对当前目标。若出现多个可独立交付的目标、跨子系统的大幅改造，或明显超出原验收条件，说明扩大点，提出分阶段建议并让用户选择。未确认前保留原目标，旁支放入范围外事项。 ## 当前决策是状态 每轮吸收回答后更新 `current.md`，保持简短、可独立理解；下一轮基于它和新证据提问。包含： - 原始目标与当前已确认目标；目标改变时保留改变原因。 - 验收条件、已确认决策及简短理由。 - 已查明事实及来源；尚待确认的建议或假设单独列出。 - 约束、保留行为、不做事项、未决问题。 用新决定替换已失效决定；被否决方案只保留防止重提所需的一句原因，不累积聊天全文。用户未回答、沉默或模型自己的推荐都不算确认。恢复会话、上下文压缩或出现矛盾时，重新读取 CONTEXT、当前决策和相关代码；不能从压缩摘要猜测确认状态。 ## 收敛、确认与交接 当目标、边界、关键实现选择和验收都明确，且没有影响实施的未决问题时停止提问。不为凑问题继续访谈。 展示完整候选计划，一次让用户确认。计划以文件的修改目标、原因和验收要求为主，不写完整函数、逐行补丁或详细实现代码。仅当核心算法需要代码帮助用户审查时，保留少量代码或伪代码片段，并说明其表达的算法约束；片段不是必须照抄的实现。具体编码、内部组织等细节交给执行 agent 在已批准边界内决策，不把缺少详细代码当作计划未完成。 计划至少包含以下信息，简单任务可合并段落，不填充无意义章节： ```markdown --- 系统: 项目或系统名称 时间: YYYY-MM-DD 目标: 本次计划要达成的目标 --- # 任务名称 ## 定位与确认 - 项目：仓库绝对路径；有远程时附仓库标识 - 资产根目录与 CONTEXT.md 的绝对路径 - 基线：分支、提交；无初始提交则明确注明 - 工作区：与计划相关的未提交变化 - 版本：v1；状态：待确认 / 已确认；确认日期与确认依据 ## 目标与边界 原始目标、当前行为、目标行为、保留行为、不做事项。 ## 决策与影响 已确认选择及原因；业务行为、公共接口、架构的前后变化。 无变化的类别明确注明；必要事实来源；已确认的假设。 保留本次相关的系统约束快照及生效状态，不能只给 CONTEXT 链接。 ## 文件与步骤 预计新增、修改、删除的仓库相对路径、修改目标与原因。 按必要依赖顺序列目标级任务，每项关联验收条件，不预写详细代码。 允许为已批准目标补充必要测试或配置文件，须记录理由； 其他范围扩展、业务行为、公共接口或架构变化需重新确认。 ## 验收与验证 可判定的验收条件；对应现有或待补测试、运行目录、命令与预期结果。 必要环境和依赖；无法验证的部分不能伪装为通过。 ``` 确认前自查：新会话是否还需要聊天历史才能理解，是否有占位符、互相矛盾的决定、漏写的文件目的或隐含的业务变化。修复事实遗漏；涉及新决策则回到提问。 用户确认完整候选计划后，保存对应内容并记录真实的确认依据，不能把未展示的新内容夹入已批准版本。实质变化另行展示、确认并保存新版本。最终计划必须自包含，不要求执行者继续读取访谈记录。 提供已保存计划的绝对路径，以及新会话提示词：`使用 execute-plan 执行 /绝对路径/plan-v1.md`。结束本次规划，不自动调用执行 skill。新会话是使用约定，不能声称已替用户清空上下文。