---
description: 用 goal-driven 方法推动一个复杂任务持续执行，直到明确成功标准被满足
argument-hint: 建议填写任务目标；若同时给出成功标准更好
allowed-tools: ["Read", "Edit", "Bash", "Grep", "Glob"]
---

# /goal-driven — 目标驱动执行模式

使用 `lidangzzz/goal-driven` 的核心思想来推进复杂任务：先固定目标与成功标准，再持续执行和反复验收，直到标准真正满足。

适用场景：

- 长周期实现任务
- 高复杂度工程任务
- 可被明确验收的研究、实现、迁移、验证类工作

不适用场景：

- 纯脑暴
- 无法定义成功标准的模糊任务
- 很小的一次性修改

## 输入要求

若 `$ARGUMENTS` 只包含目标，没有成功标准，先补全一版可执行的成功标准再开始。

启动时先输出：

```md
Goal
- ...

Criteria for success
- ...

Plan
1. ...
2. ...
3. ...

Verification
- ...
```

## 执行规则

1. 先把任务固化为两个核心块：
   - `Goal`
   - `Criteria for success`

2. 成功标准必须尽量客观，可验证，可落地。
   优先写成：
   - 需要交付什么
   - 需要通过哪些测试或验证
   - 如何判断结果真的完成

3. 进入持续执行循环：
   - 完成一个阶段
   - 检查当前结果是否满足成功标准
   - 若未满足，明确剩余差距并继续推进

4. 任何“完成了”“差不多了”“已实现”之类的结论，都必须经过验证，不能直接接受。

5. 如果验证失败：
   - 明确指出哪条成功标准没满足
   - 继续工作，不要把阶段性进展误判为完成

6. 只有在以下情况之一才能停止：
   - 成功标准已满足
   - 用户明确要求停止

## 执行风格

- 重证据，轻口头判断
- 优先使用确定性工具证据：`rg`、`git diff --stat`、`git diff -- <path>`、测试、构建、lint、`curl`、数据库查询等能直接证明成功标准的方式
- 不把大段命令输出粘进回复；保留在工具调用里，回复只总结关键证据
- 重验收，轻自我感觉
- 优先用测试、日志、产物、对比结果来证明完成
- 对长期任务保持“未达标就继续”的节奏

## 简版模板

```md
Goal: [[[[[在此填写最终目标]]]]]

Criteria for success: [[[[[在此填写成功标准]]]]]

循环执行：
1. 推进任务
2. 检查是否满足成功标准
3. 若未满足，继续工作
4. 直到满足标准或用户明确停止
```