progress

进度

仅当用户明确调用 $progress 时，或已确立的持久目标契约要求在继续、恢复、压缩或交接时执行 $progress 恢复流程时，才运行此技能。不要从普通的规划请求中推断出后一种情况。将规划系统视为手动选择的项目记忆：在依赖它之前，先根据直接指令和仓库证据进行核对。在目标模式下，保持两种相互独立的事实：项目队列说明项目接下来应该做什么，而目标契约说明当前运行获准执行什么。

请求可以授权多个阶段。完成并验证每个阶段，然后通过此入口重新调度下一个获准的操作；执行前先恢复目标授权。仅规划阶段本身不会授予实施或交付权限。

解析工作系统

1. 阅读适用的 AGENTS.md 文件并检查 git 状态。
2. 选择文件前，先确定规划范围。使用用户指定的范围或索引。并行 worktree 工作期间，从并行 worktree 工作流中选择当前 worktree 的隔离命名空间。否则，使用普通的非限定命名空间。
3. 选择工作前，先对请求分类：
   • 明确指定 goal mode、提供了 Goal contract，或指定了命名的目标状态路径，则选择目标执行；
   • 继续、恢复、实施、交接、开始或完成当前工作，均会影响执行；
   • 在实施之前与用户讨论路线图、未来实施或拟议计划，则选择规划审查；
   • 仅定位、审计、记录、重排、安排或以其他方式编辑项目队列，属于项目平面工作；
   • 明确要求保持活动目标不变并开展单独的项目工作，则选择普通项目模式。不要仅凭笼统的继续请求推断出这一覆盖指令。
4. 检查已解析范围内约定的 goals/ 路径，查找符合架构的目标状态，而不是任意名为 goals 的项目文档。隐式恢复要求状态为 Status: active、Planning scope 匹配，并且 Original contract 块包含从 Outcome 到 Delivery 的所有必需字段，其中包括指向该文件的 Goal state 路径。若显式调用目标模式或指定路径时状态格式错误，则应停止处理；否则，调度时忽略不符合架构的文件。对于显式目标执行，或存在一个可恢复活动目标的、会影响执行的请求，启用目标覆盖层。对于仅涉及项目平面工作的请求以及明确要求单独工作的覆盖指令，保持关闭；这些路径可以让队列保持准确，但不能悄然启动目标工作。如果仅限规划的请求扩展为实施请求，则应在首次实施操作前重新调度。在目标模式下，选择候选工作前，先阅读目标契约和目标执行。
5. 在该范围内，如果现有索引符合工作队列模型，则使用该索引。普通工作优先使用 ROADMAP.md，并行工作优先使用范围限定的路线图。只有在 PLAN.md 明确指引项目工作时才使用它。如果仅存在独立的旧版进度文档，则报告这些文档需要先通过 organize 分支显式迁移，其他工作流才能使用。
6. 阅读选定的索引。在目标模式下，先恢复目标文件并检查其终止条件，再打开项目条目的内容。如果工作尚未完成，则选择目标状态中当前或下一个范围内的结果，根据契约和索引元数据对其分类，然后才读取工作流所需的允许范围内工作项文件。项目 Current 可以帮助定位或协调已纳入的结果，但不能用于选择结果。无需仅为确认某项位于范围之外而打开其链接。
7. 仅在核实重要状态声明所需的范围内检查近期历史、代码、测试或差异。将冲突视为需要报告或修复的过时信息，而不是文档施加的限制。

当项目的当前/下一个工作已确定（适用时，也分别确定目标的当前/下一个工作），并且已知文档与仓库状态之间的任何重要冲突时，解析即告完成。

将授权与项目顺序分开

• 路线图、Current 链接、有序计划、任务、分支、PR、评审发现或新编写的计划，都不会为活跃目标增加工作。
• 在目标模式下，每次开始新的计划、工作分支、PR、评审流程或可独立评审的成果之前，都要根据持久化的目标契约检查候选事项。
• 允许明确纳入的工作，以及完成纳入的条件所必需的最小范围工作。遵守有效契约中明确持久化的决策权限。记录有用的范围外工作，以便后续处理。对于该权限未涵盖的模糊工作或实质上扩大范围的工作，先征求确认。
• 满足最后一项纳入条件后，更新两个事实平面，完成目标，并在查看下一个项目事项之前返回。
• 如果无法准确恢复目标契约，则应采取保守做法。不要从项目队列推断范围，也不要根据零散的对话片段重构权限。

编写时保持计划连贯

每当任何 progress 工作流创建计划，或对其预期成果、行为、架构、兼容性、迁移、推出或验收条件进行实质性修改时，都要先阅读 终态规划，并在编写前应用其中的要求。重构已确定的目标，清除历史遗留内容，保留真实义务及其退出条件，并在同一次操作中写出一份连贯的计划。不要要求用户在编辑后单独运行评审命令或再次发起请求。

如果只是常规更新证据、刷新下一步行动、调整队列顺序、变更生命周期状态或修正错字，且不改变计划的最终状态，则不适用此门槛。适用时，只询问用户指令和仓库证据都无法解决的关键产品决策或外部契约决策。遵守所选工作流现有的修改权限和目标权限；连贯性评审不会扩大可编辑或可实施的范围。

每个范围仅保留一个工作队列

• 让每个索引保持精简：包含一个 Current 槽位、一个有序的 Plans 队列，以及一个无序的 Tasks 池。
• 对于常规工作，将索引保存在 ROADMAP.md，将已排期工作保存在 plans/<stable-slug>.md，将未排期工作保存在 tasks/<stable-slug>.md。如果已有 todo/ 或 todos/ 目录，则将其作为任务池保留，不要再创建一套重复约定。
• 在并发 worktree 工作期间，为每个并发编辑的 worktree 分配不同的路线图以及不同的计划和任务子目录。遵循并行 worktree 工作流中的命名和归属规则。
• 仅在所选索引中持久化计划顺序。不要在文件名和事项文件中使用序号。
• 在一个范围内，每个活跃事项只能列出一次：当前、排队中或待处理。事项位于 Current 时，在不再处于当前状态前，不应出现在原列表中。
• 每个事项文件都应作为其 Outcome、Current state 和 Next action 的事实来源。只有在有助于后续继续处理时，才添加范围、检查清单、决策或验证信息。
• 完成事项时，在该事项文件中记录结果，从活跃索引中移除该事项，并将未列出的文件保留为简要历史记录。

选择工作流

目标执行是一层条件式授权，而不是项目工作管理的替代方案。目标模式处于启用状态时，如果请求涉及审查、修改或实现项目工作，除目标资源外，还要从下方选择并阅读且仅阅读一个主要工作流。如果请求仅涉及初始化、恢复、修订或完成目标状态，则目标工作流已足够。

• 组织工作 — 初始化系统；记录、开始、重新排序、安排、取消安排或完成事项。
• 了解工作 — 报告当前、下一步、受阻或过期的工作，不修改仓库。
• 简述计划工作 — 说明接下来要做什么，以及计划是如何编写的，以便用户判断其是否符合自己的意图；指出重要的审查备注，并且只应用获得明确批准的计划变更。
• 继续工作 — 选择并实现一个实质性且连贯的工作切片，同时将对应事项保持为当前事项。
• 交接工作 — 将当前会话整理成持久化事项和下一步行动，不进行实现。

当用户实际在协调多个 git 工作树时，也要阅读并行工作树。不要在常规运行中纳入这一例外。

有条理地结束

结束会修改内容的工作流之前，请验证每个已触及索引中的所有路径均存在、每个活动事项在其范围内恰好出现一次、计划编号连续，并且每个已触及事项都说明了有依据的当前状态和明确的下一步行动。对于每个新建或实质性修订的计划，还要验证所写目标已通过最终状态规划关卡，无需再调用后续审查。在并行工作期间，还要验证当前工作树只更改了自己的规划命名空间。不要将对话记录和常规会话日志写入文件。在目标模式下，还要验证原始约定保持不变，除非有明确记录的修订；状态仅指示范围内的下一步工作；完成工作不会启动项目队列中的下一事项。报告已更改的规划文件、执行的验证，以及范围内的下一步行动、完成情况或阻碍。