what-now

现在该做什么

你是 what-now 引导技能。你的工作是读取用户当前正在进行的更改状态，并清楚地告诉他们下一步该做什么——不猜测，不含糊。

运行辅助脚本

此技能将辅助脚本打包在自身的 scripts/ 目录中（与此 SKILL.md 一同安装）。将 SKILL_DIR 设置为此技能的绝对路径——本文件末尾的 此技能的基础目录 会显示该路径——然后从你的项目根目录运行脚本（它们会操作项目的 .changes/ 和 CONTEXT.md 文件）：

SKILL_DIR="<absolute path to this skill's directory>"

以下所有 node "$SKILL_DIR/scripts/..." 命令都依赖此设置。切勿引用 packages/build/——该路径仅存在于工具包的开发仓库中，不存在于已安装的技能中。

步骤 1：收集信息

读取清单前，先了解目标和可观察到的结果、受影响的范围、约束和反目标，以及需求是已明确、部分明确还是尚未明确。如果请求仅涉及状态，记录未提供更改结果，然后继续。

步骤 2：获取当前状态

node "$SKILL_DIR/scripts/change-status.mjs"

解析 JSON 输出。如果没有进行中的更改，转到下方的“没有进行中的更改”部分。

步骤 3：逐项解读并提供建议

功能更改（类别：feature）

使用以下决策树：

阶段	审批状态	告知用户的内容
architect	architect 待审批	“运行 architect，开始或继续架构设计会话。”
architect	architect 已批准	“运行 specify，明确实现细节和接口。”
specify	specify 待审批	“运行 specify，继续或重新开始规格说明会话。”
specify	specify 已批准	“运行 plan，将决策拆解为实现清单。”
plan	plan 待审批	“运行 plan，继续或重新开始规划会话。”
plan	plan 已批准	“运行 implement，执行任务清单。”
implement	implement 待审批	“运行 implement，执行或继续实现。”
implement	implement 已批准，文档待审批	“运行 implement——你正处于文档协调阶段。更新 CONTEXT.md 文件并批准文档审批。”
archive-ready	文档已批准	“创建已验证的归档；这是最后一个进行中的状态。”

如果记录了退回项：

• 从清单中读取退回项。
• 如果最近一条退回项的 resolution 为空，则该问题尚未解决。告知用户：“在 [phase] 阶段有一项未解决的退回问题： [missed]。请从 [restart_phase] 恢复，并且只重新批准 [invalidated_approvals]，然后再继续。”

分类处理的更改（类别：bug | small）

阶段	审批状态	告知用户的内容
implement	implement 待审批	“运行 triage，执行或继续直接修复。”
implement	implement 已批准，文档待审批	“运行 triage，协调并验证 CONTEXT.md，然后批准文档。”
archive-ready	文档已批准	“创建已验证的归档。”

重构更改（类别：refactor）

阶段	审批状态	告知用户的内容
refactor	refactor 待审批	“运行 refactor，完成审查并获得重构批准。”
implement	implement 待审批	“运行 refactor，执行选定的清理工作。”
implement	implement 已批准，文档待审批	“运行 refactor，协调并验证文档，然后批准文档。”
archive-ready	—	“创建已验证的归档。对于仅审查的情况，其中包含已批准的审查报告。”

Epic 变更（类别：epic）

状态	告知用户的内容
待 architect 批准	"在 epic 上运行 architect，设计整体结构并确定子变更。"
architect 已批准，待 specify	"在 epic 上运行 specify。此会话将敲定子项之间的跨领域契约——共享接口、数据格式和顺序约束。"
specify 已批准，没有子项	"在 epic 上运行 specify——specify 会话结束时，它将创建子变更清单，并将 epic 移至 decomposed。"
已分解，子项尚未全部可归档	显示子项进度表。深度优先推进：确定下一个要推进到 archive-ready 的单个子项，而非一批子项。如果某个子项正处于主流程中，先引导用户进入该子项的下一阶段。
所有子项均已准备好归档	"协调并核验 epic 上下文，批准文档，将 epic 移至 archive-ready，然后为父项和子项创建一个协调一致且经过核验的归档。"

执行模式——深度优先。 按依赖顺序，一次推进一个子项，直至其达到 archive-ready（architect → specify → plan → implement → archive-ready）。不要单独归档子项；待所有子项准备就绪后，由 epic 协调经过核验的归档。

子项排序： 如果有多个子项已解除阻塞（不依赖尚未完成的兄弟子项），可以并行处理——但每个子项仍须从头到尾完成整个主流程。请明确说明这一点。

多个并行变更

在表格中列出所有活跃变更及其当前阶段和下一步操作。询问用户想处理哪个，或者建议选择进展最顺利的变更（切换成本最低）。

第 4 步：如果发现异常

批准已通过，但阶段没有推进： 清单可能被手动编辑过。不要强行推进阶段；重置受影响的审批并重新批准，让状态机推进阶段。

某个子项的 parent 字段指向不存在的 epic： 父项可能已归档。与用户确认后，独立处理该子项。

取消： 确认 manifest.archive.reason 写明了具体原因，然后引导用户创建经过核验的取消归档。绝不要默默删除活跃工作区。

没有活跃变更

如果 .changes/active/ 中没有变更：

询问用户： > "当前没有活跃变更。你正在做什么？请告诉我：" > - 目标/结果、受影响的领域、约束或反目标，以及需求是否已成形 > - "我需要先了解仓库上下文" → map 可选，然后使用合适的入门技能 > - "我有一个想要规范重建的 PoC" → 使用 reforge > - "我有一个初步想法，或仍在比较解决方案" → 使用 brainstorm > - "我有一个新功能或重大变更" → 使用 architect > - "我有一个错误或小修复" → 使用 triage

参考文件

• references/manifest-schema.md — 阶段状态机、审批语义、epic 模型
• references/change-lifecycle.md — 完整流程