用途
what-now 是 agent-toolkit 流水线中的“定位”技能（orientation skill）。当用户不确定在 agent-toolkit 流水线中下一步该做什么时，该技能负责读取用户当前活跃变更的状态，并清晰告知下一步操作，避免猜测和歧义。
主要能力
- 读取所有活跃变更清单（active change manifests），解读当前状态。
- 根据变更类别和阶段/审批状态，给出明确的下一步指令。
- 处理多种变更类别：feature（功能）、bug/small（缺陷/小改动，归为 triage）、refactor（重构）、epic（史诗级变更）。
- 支持多个并发变更的列表展示与选择建议。
- 识别并处理异常情况，如审批已通过但阶段未推进、子变更的 parent 指向不存在的 epic、取消操作等。
- 在没有活跃变更时，引导用户选择合适的入口技能（reforge、brainstorm、architect、triage）。
使用方式
该技能捆绑了辅助脚本，位于其自身的 scripts/ 目录中（与 SKILL.md 一同安装）。使用前需设置 SKILL_DIR 为该技能目录的绝对路径，然后从项目根目录运行脚本（脚本操作项目的 .changes/ 和 CONTEXT.md 文件）：
SKILL_DIR="<absolute path to this skill's directory>"
所有 node "$SKILL_DIR/scripts/..." 命令都依赖此设置。切勿引用 packages/build/，该路径仅存在于工具包的开发仓库中，安装后的技能中不存在。
步骤 1：信息收集（Intake）
在读取清单之前，获取目标与可观察结果、受影响区域、约束与反目标，以及需求是否已形成、部分形成或未形成。如果请求仅为状态查询，则记录未提供变更结果并继续。
步骤 2：获取当前状态
node "$SKILL_DIR/scripts/change-status.mjs"
解析 JSON 输出。如果没有活跃变更，转到下方“无活跃变更”部分。
步骤 3：对每个活跃变更进行解读和建议
功能变更（class: feature）
使用以下决策树：
| 阶段 | 审批状态 | 告知用户 |
|---|---|---|
| architect | architect pending | “运行 architect 以开始或继续架构设计会话。” |
| architect | architect approved | “运行 specify 以确定实现细节和接口。” |
| specify | specify pending | “运行 specify 以继续或重新开始规格说明会话。” |
| specify | specify approved | “运行 plan 将决策分解为实施清单。” |
| plan | plan pending | “运行 plan 以继续或重新开始规划会话。” |
| plan | plan approved | “运行 implement 以执行任务清单。” |
| implement | implement pending | “运行 implement 以执行或继续实施。” |
| implement | implement approved, docs pending | “运行 implement——你正处于文档协调阶段。更新 CONTEXT.md 文件并批准文档审批。” |
| archive-ready | docs approved | “创建已验证归档；这是最后一个活跃状态。” |
如果记录了 kickback（回退）：
- 从清单中读取 kickback 条目。
- 如果最近的 kickback 的 resolution 为空，则未解决。告知用户：“在 [phase] 中存在未解决的 kickback：[missed]。在 [restart_phase] 恢复，并在继续之前仅重新批准 [invalidated_approvals]。”
分诊变更（class: bug | small）
| 阶段 | 审批状态 | 告知用户 |
|---|---|---|
| implement | implement pending | “运行 triage 以执行或继续直接修复。” |
| implement | implement approved, docs pending | “运行 triage 以协调并验证 CONTEXT.md，然后批准文档。” |
| archive-ready | docs approved | “创建已验证归档。” |
重构变更（class: refactor）
| 阶段 | 审批状态 | 告知用户 |
|---|---|---|
| refactor | refactor pending | “运行 refactor 以完成审计并获得重构批准。” |
| implement | implement pending | “运行 refactor 以执行选定的清理。” |
| implement | implement approved, docs pending | “运行 refactor 以协调并验证文档，然后批准文档。” |
| archive-ready | — | “创建已验证归档。对于仅审计的情况，它包含已批准的审计报告。” |
史诗变更（class: epic）
| 状态 | 告知用户 |
|---|---|
| architect approval pending | “在 epic 上运行 architect 以设计整体形态并识别子变更。” |
| architect approved, specify pending | “在 epic 上运行 specify。此会话确定子变更之间的横切契约——共享接口、数据格式和排序约束。” |
| specify approved, no children | “在 epic 上运行 specify——当 specify 会话结束时，它将创建子变更清单并将 epic 移至 decomposed。” |
| decomposed, children not all archive-ready | 显示子进度表。按深度优先工作：确定下一个要带到 archive-ready 的单个子变更，而不是一批。如果某个子变更处于中间阶段，先指向该子变更的下一阶段。 |
| all children 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 — 完整流水线
适用场景
- 在 agent-toolkit 流水线中不确定下一步该做什么时。
- 需要查看所有活跃变更的当前阶段和下一步操作时。
- 处理多个并发变更、需要选择优先处理哪一个时。
- 遇到审批状态与阶段不一致、kickback 未解决等异常情况时。
- 没有活跃变更、需要选择合适入口技能时。
限制
- 该技能依赖 agent-toolkit 的 .changes/ 和 CONTEXT.md 文件结构，以及捆绑的辅助脚本。
- 需要正确设置 SKILL_DIR 环境变量，且不能引用 packages/build/ 路径。
- 具体安装方式、收费、价格、平台支持等信息暂未提供。