spec-loop-plan-task

在执行前，使用此技能选择规划形式并制定任务计划。

除非此文件已加载到当前会话上下文中，否则请完整阅读。存在 AGENTS.md 等项目指令时，请遵循这些指令。

如果这些规则已在上下文中，请保留一份简短摘要；只有在摘要缺失或用户表示规则已更改时才重新阅读。

核心规则

• 工作从 PLAN 阶段开始。
• PLAN 阶段只能更改规划材料。
• Spec Loop 任务是经过规划、需审批，并且可供审查的工作单元。
• 非平凡的实现工作必须有任务。
• 只有在调查工作需要明确规划、单独跟踪或产出可审查成果时，才需要为其创建任务。
• 开始 EXECUTION 需要用户明确批准。只有在当前任务已准备就绪，且指令明确指向该任务时，implement、investigate、go ahead、proceed 或 apply 等指令才算批准。如果是否已准备就绪或指令指向不明确，请询问。
• 只有用户可以覆盖这些规则。

如果 AGENTS.md 与这些规则冲突，请停止并询问用户。 如果助手停止或暂停，请说明原因。

如果用户明确要求使用规划表单、规划流程或分节式任务格式，除非用户明确同意，否则不要简化。 实现工作获得执行批准后，请遵循 spec-loop-implementation-flow/SKILL.md。 调查工作获得执行批准后，只执行获批的调查。将最终结果记录在任务文件的 Findings 中，或仅在聊天中进行的任务的 Scope 中。完成任何必需的 Test specification 检查，然后按照所选表单的规则，将任务或子任务提交审查或移至 review。

首先进行分类

将每项工作归为以下类别之一：

• 独立文档工作；
• 轻微实现工作；
• 非平凡实现工作；或
• 调查工作。

如果添加或扩展覆盖范围是独立的工作，可以单独建立测试类任务。

符合以下任一条件时，将实现工作视为非平凡工作：

• 涉及多个文件，且不是直接的机械式编辑；
• 编辑前需要研究或探索；
• 涉及多个模块、包或插件；
• 会更改公开或共享 API；
• 需要有针对性的测试设计或超出机械式编辑范围的验证；或
• 存在多个可行的实现路径。

调查工作是指研究、试验、原型设计、编目、验证或类似的证据收集工作，其产出是知识或可审查的材料，而非产品变更。只有当调查本身需要明确规划、单独跟踪或产出可审查成果时，才需要为其创建任务。常规的规划研究应在 PLAN 阶段进行，并纳入当前任务或聊天状态。调查工作不得交付产品、测试、构建、配置、运行时或与之相结合的文档变更；这些范围应规划为实现工作。

规划形式选择

默认使用任务文件。使用更轻量的形式必须符合相关规则并获得用户许可。

完成初步分类后，请阅读并遵循 planning-form-selection-guidance.md。

基于当前优先级的多项文件工作详细规划

如果规划形式选择为 task file with subtasks 或 multiple task files / backlog items，请先只澄清整个工作的范围、动机及合理的粗略拆分。然后使用 spec-loop-plan-work-breakdown/SKILL.md，确定当前任务，或在使用子任务时确定当前子任务，并概述后续的轻量级任务或子任务。仅对当前任务进行完整澄清和详细规划；如果使用子任务，则仅对当前子任务及任何必需的共享背景进行完整澄清和详细规划。

阶段模型

阶段：

• PLAN = 任务的研究、设计/规范、测试规范和调查规划。
• EXECUTION = 已获批准的任务工作。对于实现工作，这 意味着实现变更及其配套更新。
• DONE = 已验证并接受。

规则：

• 工作从 PLAN 开始，每项工作完成后返回 PLAN，除非 用户另有说明；
• 在 PLAN 阶段，仅当命令用于研究或验证，且不会更改规划 产物以外的仓库内容时，才可以使用这些命令；
• 对行为、测试、构建或配置、依赖项、打包、运行时资源或 配套文档的任何实现变更都属于 EXECUTION，且需要用户明确指示；
• 除非用户允许同时进行规划和执行，否则各阶段互斥。

除非用户或项目指示另有规定，独立文档工作不属于此阶段模型。

强制澄清关卡

在创建或修订任务或当前子任务的规划内容之前，按照 spec-loop-clarify-task/SKILL.md 中的重要未决决策定义，执行澄清技能要求的强制决策筛查。

主动应用此关卡；不要等用户提出澄清要求。

对于基于文件的多项工作，此关卡需应用两次：

• 在粗略拆分之前，仅针对整体工作的范围、动机、 规划形式选择，以及任务或子任务的边界、顺序、 可发布性或连贯性；
• 确定当前任务后——或者对于基于子任务的工作， 确定当前子任务后——在起草可用于实现的设计或测试 规范之前，对当前任务完整应用此关卡；若是子任务， 则对当前子任务及任何必要的共享上下文完整应用。

对于子任务，仅对当前子任务及必要的任务级上下文应用此关卡。未来子任务成为当前子任务时，再对其应用。

如果澄清发现未解决的阻塞问题，需要开展 ADR 工作或单独调查工作，则在继续受阻的任务规划之前，先安排这些工作。

如果后续起草时出现重要未决决策，立即停止并先行澄清。

规划内容

对所选形式使用相应的任务格式。涵盖范围、最终决策、研究、 约束、设计、评审预期和验证。此要求适用于实现任务和调查任务。

使用 common-task-guidance.md 中的共享任务指南。

在起草或修订 Test specification 之前，遵循 spec-loop-write-readable-tests/SKILL.md 中的测试指南。

针对不同规划形式的处理方式

仅聊天

使用此规划形式时：

• 完整阅读 chat-only-path-guidance.md；并且
• 与 common-task-guidance.md 一起遵循该指南。

如果仅在聊天中保留持久状态变得不安全，请在继续之前切换到任务文件规划形式。

任务文件

使用此规划形式时：

• 完整阅读 task-file-path-guidance.md；
• 将其与 common-task-guidance.md 一起使用；
• 在 EXECUTION 开始之前创建或更新活动任务文件；并且
• 如果项目指示未指定任务目录，则默认使用 tasks/。

对于 task file with subtasks 或 multiple task files / backlog items， 应用上述规则：仅完整规划当前任务；若使用子任务，则完整规划当前子任务及必要的共享上下文。

对于基于任务文件的工作，在请求执行批准之前，使用 spec-loop-prepare-execution-approval/SKILL.md。

ADR 路由

对于仅涉及 ADR 的工作，使用 spec-loop-write-adr/SKILL.md 了解 ADR 的位置、命名、 结构和更新规则。

如果任务规划或已接受的调查结论表明需要作出持久的架构或策略决策，请通过 spec-loop-write-adr/SKILL.md 安排 ADR 工作。 不要把 ADR 工作隐藏在澄清工作中。

如果 ADR 工作属于更大范围的实现变更，请将其纳入该任务，并在 EXECUTION 期间使用 spec-loop-write-adr/SKILL.md。

持续维护的项目文档

持续维护的项目文档记录当前项目事实：规范、 API 契约、架构和运维文档、项目术语表以及当前 ADR。历史文档、归档文档和 临时文档不在此列。

Spec Loop 不要求项目必须有持续维护的项目文档。 如果不存在此类文档，不要仅为满足本策略而创建文档或 Living Project Documents 列表。

项目列表

拥有多份持续维护的项目文档的项目，应维护一个名为 Living Project Documents 的列表作为入口：

• 使用已加载的项目说明文件中的现有列表；否则 使用根目录下的 README.md；
• 通过路径、角色和范围，让条目标明单份文档或文档集合；
• 将包含该列表的文件视为隐式条目；并且
• 如果存在多个列表，请询问应使用哪一个。

将此列表作为相关 Research 的起点。如果当前工作提及或依赖未列出的持续维护文档，请询问如何处理。 如果项目有多份持续维护的文档但没有列表，请在根目录下的 README.md 中创建默认列表前询问用户。

项目术语表属于持续维护的项目文档。即使不存在列表，也要搜索 glossary.adoc 和 glossary.md。如果现有术语表未列入涵盖其他持续维护文档的列表，请询问如何处理。 如果术语表是唯一的持续维护文档，请使用它，并在受到影响时更新它，无需创建列表。

持续维护项目文档的操作本身并不要求创建任务。 将所需操作纳入与实现相同的增量中。对于基于任务的工作，在 Research（仅聊天工作则在 Scope）中记录检查，并在 Design 中列出操作。对于 taskless 实现或独立文档工作，应一并完成这些操作，并在最终回复中列出每项操作及其生成的文件，或注明 None affected。任务内容请参阅 common-task-guidance.md。

术语表策略

将 glossary.adoc 和 glossary.md 视为项目术语表文件。 如果两者都存在，请在更新任一文件前询问哪一个是权威版本。

对于 Spec Loop AsciiDoc 术语表，请使用 spec-loop-write-glossary/SKILL.md。 对于其他术语表格式，请遵循项目格式。

现有项目术语表是高于单项任务和代码的共享领域语言来源。若没有术语表，则在创建项目术语表之前，使用 Research 和现有代码库作为依据。

项目术语表是否存在，不决定任务或子任务是否需要任务 Glossary。它只决定任务词汇和任务术语表变更要与哪个共享来源进行比较。

当经批准的工作更改、澄清或实现共享领域术语时，请在任务文件的独立部分或仅聊天工作的 Scope 中记录所需的任务 Glossary 内容。如果现有项目术语表受到影响，请在同一增量中规划其更新。创建、更新或取代项目术语表属于持续维护项目文档的工作。只有在用户、项目说明或任务计划批准后，才能创建或取代术语表。

当任务或子任务需要 Scenario 或 Glossary 时，请阅读 scenario-and-glossary-guidance.md 并遵循其中的说明。任务 Glossary 内容是规划产物；项目术语表的操作仅在 EXECUTION 期间进行。

Related skills

Use spec-loop-setup-doc-rendering/SKILL.md for rendering setup.