plan-feature-scaffold

规划功能 — 搭建脚手架（内部）

将已设计的功能转化为项目完整的规划产物集，做好按阶段执行的准备。仅填写 SPEC 的工程部分——产品部分（目标、背景、范围、能力闭环）已经存在，并且在此技能运行前已标记为 designed（plan-feature 的重定向门禁可确保这一点）。仅限文档——绝不编写代码。

适用时机

• 当某个功能的产品部分已标记为 designed 时，plan-feature 路由器会调用此技能——该功能可能来自 design-feature、plan-feature-from-issue，或已确定范围的 slug/SPEC。此技能将填写 docs/features/<NN>-<slug>/SPEC.md 的工程部分及文件夹中的其余内容，然后更新路线图。

不用于定义产品（由 design-feature 负责）、编写代码（由 execute-phase 负责），也不用于决定是否构建（由 plan-feature 路由器／triage-issue 负责）。

步骤 0 — 探索项目（始终先执行）

遵循 Agent 指南中的工作流约定和文档映射，然后阅读此技能所需的内容：功能 SPEC 模板、路线图（编号／顺序／依赖关系）、1–2 个近期功能文件夹以供参考其产物集，以及文档映射所指向的架构／领域文档。若没有模板或路线图，则退回参考 Agent 指南，并说明所作假设。

渐进式加载 — 仅在探索后搭建脚手架

参考资料白名单恰好只有一个路径。完成步骤 0 后，阅读并执行完整的脚手架流程。该流程负责产品部分门禁、产物扩展、路线图转换、重新读取和固定的完成报告。阶段契约负责 8 项检查的阶段 lint，以及规范化的阶段指纹。

此资源具有规范效力，且与本文件仅隔一跳。若资源缺失，则停止；绝不可凭记忆重构阶段或收尾措辞。

验证契约负责 ACCEPTANCE.md 架构、验证阶梯和防止弱化的规则。在工程计划完成后、登记为 planned 前，使用该契约。

研究与参考追踪（规划阶段）

• 有条件的网络研究。 仅当有明确范围的问题（ROWS.md Q1–Q5）无法通过仓库证据解答时，才进行规划阶段研究：在输出阶段前，恰好执行一次网络检索，并将返回内容作为证据行（URL 和访问日期）固定下来。仓库能够解答的问题绝不再次检索。
• 强制参考追踪。 通过符号／引用搜索定位受影响的代码——环境支持时使用 LSP/serena，否则使用 grep——并且必须依据搜索结果推导影响范围，不能依赖模型记忆：新增或修改的代码可能破坏调用方，计划必须列出这些调用方。

护栏

• 仅限文档。不得修改源代码、迁移或依赖项。
• 遵循架构：遵守分层规则（内层不得导入外层），以及文档映射中的任何领域／i18n/SEO/a11y 规则。
• 架构不变量。 规划预检负责读取规范化的仓库状态，并为整个计划作出唯一的最终架构分类；在此使用其结果。若缺少该预检，则兼容此情况：在工程部分记录 n/a: no project invariants declared。对于每项适用规则，都要在 ### Architecture impact 中记录其 ID、仓库证据，以及 preserves | violates | introduces | changes 分类。只有 preserves 才能生成阶段；其他分类都必须停止，并通过项目指定的权威方明确作出架构决策——且只能在完整计划形成之后，绝不可转化为阶段任务，也不可从产品部分推断。
• 在编写前指出冲突（编号冲突、依赖循环、范围重叠），不要等到编写后。
• 其他方面遵循项目的工作流约定（分支／PR、文档语言）。

与其他技能的关系

由 plan-feature 路由器调用（在 design-feature / plan-feature-from-issue 设计完产品部分后，或直接用于已完成设计的限定 slug/SPEC）。随后交接给 execute-phase 执行 P1；audit-docs 可随时进行审查。

完成条件

• docs/features/<NN>-<slug>/ 已创建，包含 SPEC 的工程部分、 ACCEPTANCE.md 和所有已填写的扩展规划文档——产品部分保持 design-feature / plan-feature-from-issue 编写时的原样。
• 路线图已列出该功能，且编号、顺序和依赖关系均正确，状态为 planned（此技能负责将 defined 更新为 planned）—— 写入后重新读取并确认，而非仅凭已运行该技能就认定完成。
• 未更改任何代码；未决问题已记录在 decisions.md 中。