项目卡在阶段之间、线索太多不知下一步做什么时…

当项目停滞、处于阶段切换、作者问「接下来做什么」或同时开着太多条有效线索时，用只读方式读当前状态，返回一个最省力且最能解除约束的下一步动作，而不是一份菜单。

适用场景

解决思路

1. 读取实时循环状态：plan gates、re0-memo 反模式、priority notes、最近的 git/文件变更、QA 证据，以及当前工作流阶段。
2. 定位项目在循环中的位置：FRAME、BUILD、DRIVE、RE0-MEMO、HATE、RE0-WORK、BUILD AGAIN 或 SHIP。
3. 诊断卡壳（blank-out）原因：打开的线索太多、线索丢失、阻塞点未被命名、闭环疲劳、回避那件难的一步，或该阶段其实已经完成。
4. 只返回一个行动：能清除最多障碍的最省力动作。它可以指出该由人触发的正确技能、需要的外部输入、第一个要试探的钉子，或已经到期的阶段转换。
5. 按固定格式表述：你在哪里、下一步最佳行动、为什么是现在、何时算完成。
6. 只给一个行动，不要给清单。
7. 基于状态而非泛泛而谈：必须引用驱动这次选择的 gate、文档、证据或文件状态。
8. 返回那个被回避的动作，而不是轻松的忙碌工作。
9. 如果没有外部真相进入，下一步行动就是获取外部输入，而不是再跑一轮内部循环。
10. 如果 gate 已经满足，行动就是进入下一阶段或发布，而不是再加一个表面。
11. 对项目保持只读：nba 只给建议，不执行。
12. 不要自动调用仅限用户使用的技能；当某个用户专属技能是下一步时，明确告诉人类去触发它。
13. 收尾前校验：建议必须引用它所读取的状态。
14. 收尾前校验：恰好只有一个下一步行动。
15. 收尾前校验：该行动有清晰、可观察的「何时算完成」。
16. 收尾前校验：读者能看出为什么这个行动优于其他可见选项。

适用边界 · 注意事项

• 需要真正执行动作（改代码、跑命令、发版）时——本技能只读、只建议、不执行。
• 缺少可读状态时（没有 plan gate、没有 git/文件变更、没有 QA 证据），无法做到基于状态判断。
• 当卡壳的真正原因是需要人的决策或外部信息输入，而你无法识别或获取该外部输入时。