| name | wf-plan |
| description | 产品/架构方案:还不确定是否值得做,先评估价值、范围和可行性。
仅当用户显式输入 /wf-plan 时使用;不要因“产品方案、架构方案、方案讨论、值不值得做”等自然语言自动触发。
|
产品 / 架构方案通道。
状态行规则:在本工作流执行期间,每次回复开头输出一行:
> wf-plan · 步骤 N/4
N 为当前正在执行的步骤编号。
切换与退出规则:
- 收到超出当前范围的独立任务请求时,先宣告「wf-[name] 已暂停/切换,原因:[一句话]」,再处理新请求,不得静默切换
- 用户调用
/wf-finish 显式关闭;调用其他 /wf-* 命令时自动切换
适用于想法尚不确定、需要先判断是否值得做或如何收敛范围的任务。
强制依赖清单
不得用普通方案讨论替代第 1 步的拷问式确认。
required_steps:
alignment:
- grilling-style-confirmation
Codex App 交互规则
- 有选项的地方,优先使用 Codex App 提供的 UI 交互工具(如
request_user_input 或当前宿主暴露的等价工具)。
- 只有 UI 交互工具不可用时,才退化为文本选项;文本选项必须短且明确。
- 完成方案评估后,必须展示推荐路径和备选项,再询问是否进入
/wf-small 或 /wf-complex。
启动自检
开始执行时必须先展示或内部完成以下自检,并在首条进展中说明依赖状态:
- 当前工作流:
wf-plan
- 第一步:拷问式确认(一次一问,达成共识前不得进入产品/工程梳理)
- 下一步:结合共识做产品视角梳理
执行以下步骤:
- 拷问式确认(决策导向):一次只问一个问题,聚焦"值不值得做"背后的关键分支——
目标用户是谁、不做的代价、最小验证方式、明显的可行性风险点。每题给出你的推荐答案,
供用户确认或修正。不生成独立文档,不触发完整设计管线。达成共识前不得进入下一步,
不得因"看起来已经想清楚"跳过。
- 结合第 1 步的共识,从产品视角梳理:值得做?用户价值?替代方案?更小路径?
- 对照
risk_triggers 输出建议路径:不做 / /wf-quick / /wf-small / /wf-complex / /wf-debug。
- 完成后询问:「决定做了吗?用哪个 workflow 继续?」
收尾审计
完成前必须输出执行审计:
wf-plan:已执行
- 拷问式确认:列出关键问题与用户回复要点
- 推荐路径:列出推荐进入
/wf-small、/wf-complex 或暂不实现的理由