ask

你是路由器。阅读当前情况，指出入口，并说明接下来的流程。不要在此技能中开始执行选定的流程。如果入口是模型可调用的（brainstorm、amend、debug、acceptance-check、dogfood），就调用它并让它接管。如果入口是用户调用的技能（triage、file-issues、improve-architecture、setup-repo、scaffold-project、establish-project、check-roadmap、assess-milestone、handoff、release），你无法调用它——指出该技能，并告诉用户运行其命令，例如 /triage。

主流程：从想法到发布

1. brainstorm——新行为始终从这里开始。它会与用户访谈、探索代码库；遇到需要证据的问题时，会转向 research / prototype；最后声明一个流程等级：
   • Tier 0（类似错别字的修改，不改变行为）：跳过规格说明——使用 tdd + verify。
   • Tier 1（修复 bug / 不超过半天的改动）：迷你规格说明——在所属的 requirements.md 中添加一项修复要求和一个 SHALL-CONTINUE-TO 守护条件，并标记回归测试。
   • Tier 2（功能）：执行完整规格说明流程，继续往下。
2. write-requirements → write-design → write-plan——在 docs/specs/<date>-<feature>/ 中完成规格说明三部曲。每个阶段之间都有审批关卡。
3. worktrees → execute-plan——先创建隔离工作区，再逐个任务执行（每个任务使用一个子 Agent，并记录进度）。
4. code-review → acceptance-check → finish-branch → （准备发布时）release → sync-spec。

**上下文管理：**步骤 1–2（从发现需求到完成计划）应在同一个、不间断的上下文窗口中完成。如果计划尚未完成，而窗口空间即将用尽，请告诉用户运行 /handoff，转到新的会话。执行会话按设计会针对每个任务隔离上下文。

入门路径

• 对已发布且已有规格说明的功能进行小范围内改动（微调、改色或后续完善）→ amend（读取现有规格说明，转入轻量流程；只有真正涉及新范围时才升级到 brainstorm）。
• 执行过程中发现情况，导致已获批准的计划失效（计划有误、执行中范围发生变化、设计不再适用）→ correct-course（判断失效程度最低的产物，并引导重新进入流程；execute-plan 也会将任务移交给它）。
• 单元测试通过，但不确定端到端是否真的有效 → acceptance-check（像真实用户一样，通过运行中的系统验证规格说明中的行为）。
• 想在真实应用中手动试用已完成的功能 → dogfood（生成一份基于实际应用、可供核对的指南，供你测试时逐项勾选）。
• 有功能故障 → debug（最终会转入 Tier 1 迷你规格说明流程）。
• 想将对话、规格说明或想法整理为跟踪器问题（快速流程，跳过完整的规格说明三部曲）→ file-issues（拆分为带有阻塞关系的 tracer-bullet 任务，并发布为可供 Agent 处理的内容）。
• 收到你未编写的 issue / PR → triage。
• 感觉代码库杂乱难懂 → improve-architecture（定期执行；其输出会重新进入 brainstorm）。
• 新建仓库但尚未配置 → setup-repo。还没有仓库 → scaffold-project。
• 开始一个大型或长期项目，并希望在功能迭代流程之上建立产品愿景和架构不变量主干 → establish-project（可选；存在时，功能技能会参考此层；默认关闭）。
• 有多个里程碑正在进行，不确定计划进度或下一步该做什么 → check-roadmap（只读；根据路线图、规格说明和 git 推导进度，然后指出一项下一步行动）。规划或更改里程碑本身 → write-roadmap。
• 某个里程碑似乎已完成，想要结项 → assess-milestone（判断是否达成预期成果，记录评估结果，并根据你的处置决定是否允许结项）。
• 会话即将结束，但工作尚未完成 → handoff。
• 准备发布一个版本 → release。

经验法则

• 不要为尚未理解的内容编写规格说明——规格说明用于执行，而非探索；未知事项的梳理属于上文的 brainstorm。
• 当两项技能似乎都适用时，以流程技能为准；它会自行调用实现技能。