把他加入agents.md即可~~~或者为了节省上下文您可以自定义skill
在v1版本上进行了一些优化，提高了可用性
=============================================
Goal Mode 工作流
当处于 goal mode，或用户 prompt 包含 /goal 时，必须进入本流程。
在当前涉及到的 project 下创建新的目录：
goal-[num]/
input.md
plan.md
tasks.md
编号递增，不得覆盖已有目录。
如果目前没有 project，你需要新建。
input.md：完整保存用户原始输入，逐字保留，不得改写。plan.md：分析需求、上下文、风险、执行方案、验证方式、回滚方案，以及必要的默认假设。tasks.md：把 plan 拆成小任务，每个 task 必须可独立验证。每三个 task 需要一次大型全面检查-debug循环，确保没有 bug 和问题，你需要在文件中标出。task越小越好，对于中等项目推荐10个左右，大项目和小项目可适当更改，但是越多越好
在完成以上文件前，不得修改代码。
你还需要使用内置的工具来注册此任务，保证客户端识别正确
第一轮会话只能初始化 goal，然后结束此会话。客户端会继续开启下一个会话，这时候你再开始 task1。
当goal未标记为完成，并且你停止输出的时候，客户端会自动推进。你必须保证每一轮都停止，然后让客户端自动推进。
第一轮结束时，只输出：
GOAL_INIT_DONE
然后停止输出。
每次上下文压缩后，或每个新会话开始时，你必须全量读取这三个文件，以防止上下文模糊：
goal-[num]/input.md
goal-[num]/plan.md
goal-[num]/tasks.md
对于每个会话，都要先列出小 todo，并且注册。只执行 tasks.md 中第一个未完成 task。
每次只执行一个 task。
每次你想要结束 task 的时候，你必须思考：
“你对当前实现 100% 有信心吗？”
如果没有，请找出所有可能的漏洞和提高的方案，提出合适的修复方案，然后不断重复这个循环，直到你对新实现在事实上达到足够高的信心为止。
不得只口头声称 100% 有信心。必须基于实际检查、测试、diff、日志、类型检查、构建结果或其他可验证证据。
然后你需要提交代码，若有代码修改。
然后你需要在 tasks.md 中把任务标记为完成，并且写上你干的事情、验证结果、剩余风险和下一步。你在 tasks.md 中需要预留空位用来记录这些内容。
然后你需要向用户简单汇报，并且停止输出。
每轮 task 结束时，只简单进行汇报，然后客户端会自动推进
goal 模式中，你处于无人值守状态，禁止：
- 抢夺 Windows 焦点
- 重启本机
- 向用户提出问题，这会暂停任务
- 让网络链路不工作
- 在初始化 goal 文件前修改代码
- 一轮执行多个 task
- 擅自扩大任务范围
- 擅自删除重要数据
- 擅自修改生产配置、密钥、认证、支付等高风险内容
- 等
遇到不确定信息时，禁止向用户提问。你需要做合理默认假设，把假设写入 plan.md 或 tasks.md，然后继续执行不依赖该不确定信息的部分。
每完成三个 task，必须进行一次大型全面检查-debug循环，检查：
- 需求是否偏离
- 代码是否有 bug
- 类型检查是否通过
- 构建是否通过
- 测试是否通过
- UI/UX 是否正常
- 安全性是否有问题
- 数据是否一致
- 是否需要回滚方案
- 文档是否同步
- 等
检查结果必须写入 tasks.md。
全部 task 完成后，你需要进行最后的最大的 review，全面从 C 端、代码、安全性、数据一致性、权限、错误处理、测试、构建、文档、回滚等角度分析项目，并且进行修缮和测试，直到没有已知高风险问题为止。
然后把 goal 标记为完成。
最后向用户简短说明和报告，此时你停止输出，客户端不会继续推进，这代表任务最终完成
1 个帖子 - 1 位参与者