开始使用 / 02

快速开始

三件事：普通任务是什么表现、怎么点名工作流，以及到底什么才算批准。

1 · 清晰任务直接描述

安装插件并开启新会话之后，常规任务照常描述即可。基础工程规则已经生效：模型会检查项目规则和相关代码、保护无关改动、只问会实质改变结果的问题，并在声称完成之前运行范围匹配的验证。

给 formatDisplayName 增加可选 middleName；空白值忽略。保留现有导出，添加最小验证，不要提交。

把工作流 token 和需求一起发送，建议放在第一行。之后这个工作流会接管整个任务，而不只是那一条消息。

$engineering-flow:develop
实现订单批量导出。复用现有权限和查询能力，添加聚焦测试并同步权威文档。不要提交。

环境	格式
Codex CLI	`$engineering-flow:<workflow>`
Claude Code	`/engineering-flow:<workflow>`

Develop 一定会先给出检查点——目标、验收行为、范围外、假设和方案边界——然后停下，哪怕需求本来就很清楚。只有你在检查点之后发出的行动语言才批准实施；初始请求、回答澄清问题、"明白了"都不算。

按上述方案执行。

需求记录的状态依次是 Draft → Accepted → Implemented，被新文档替代时可标记 Superseded。

回答、批准、纠正和补漏都留在同一个任务里，不必重复输入 token。原验收行为的遗漏会直接重新进入实施；新增或改变范围则只对齐增量，并再次等待批准。无关的新任务不会继承旧工作流。

现象	处理方式
终端提示 `$engineering-flow:develop: command not found`	Token 应发送到 Codex 对话，而不是系统终端。
安装后看不出变化	确认插件已安装并启用，然后关闭旧会话重新启动。
启动时没有欢迎提示	正常。Core 在后台加载，不要求显示横幅。
工作流没有触发	使用完整、准确的 token，建议放在请求第一行。
更新后仍是旧行为	刷新 marketplace、重装插件并开启新会话。