---
name: generic-goal-driven
description: '长周期任务的目标驱动流程：把中心思想、步骤清单、进度指针、改动日志和验收指南存成文件，换 session 也能接着做；每步做完等用户说“通过”；中途可以加或改需求。只在用户明确输入 /generic-goal-driven 时使用，日常任务不要用。关键词：长任务、goal-driven、续接、换 session、防失忆、TODO 清单、中心思想、进度指针、开发日志、验收指南、需求变更。'
argument-hint: '新目标的描述，或“继续”'
disable-model-invocation: true
type: workflow
specificTo: generic
---

# Goal-Driven：长任务不失忆

用文件记住一个大任务。先定中心思想，再拆成小步，一步一步做、自验、交给用户验收。换了 session 或隔了几天，读文件就能接上。

## 使用时机

- 用户认为任务大、会跨很多天或多个 session，并明确输入了 `/generic-goal-driven`。
- 用户说“继续”：接着做已有的目标。
- 做的过程中用户加了需求或改了需求。

## 不要用

- 一个 session 能做完的任务。日常任务直接开一个任务（技能 `harness-my-task`）。
- 用户没有明确要求。你觉得任务很长时，只能建议用户启用，不能自己启动。
- 目标文件不是每个任务都要有。没有目标时，不要补建。

## 文件

放在 `.workspace/goals/<id>/`（git 忽略）。`<id>` 用短英文名，例如 `ledger-migration`。你直接读写这些文件。模板在 [templates/](templates/)。

| 文件 | 放什么 | 多久改一次 |
| --- | --- | --- |
| `GOAL.md` | 中心思想：目标、原则、范围、不做什么、整体验收；“已定的事”；末尾是变更记录 | 需求或决定变了才改 |
| `TODO.md` | 步骤清单：每步有状态、验收标准、反馈记录 | 每步开工、交棒、通过时改 |
| `NOW.md` | 进度指针：现在在哪一步、下一步做什么、用哪个任务 | 每次动手前后都改 |
| `LOG.md` | 改动日志：每个通过的步骤改了什么，以前怎样、现在怎样。只往上加，不改旧条目 | 每步通过时加一条 |
| `accept/<步骤号>.md` | 验收指南：复杂步骤才写，一步一步告诉用户怎么测 | 交棒时写，用户反馈后补 |

状态只有五个：`待做`、`做中`、`已交棒`（等用户验收）、`已通过`、`已取消`。

## 开始新目标

1. 目标有不清楚的地方，先用技能 `generic-grill-me` 问用户。
2. 建目录，按模板写 `GOAL.md`、`TODO.md`、`NOW.md`、`LOG.md`。步骤要小：一个 session 内能做完，用户能单独验收。
3. 给用户文件的链接，让用户在编辑器里看。用户确认前不开始第 1 步。

## 每一步的循环

1. **开工前**：`TODO.md` 该步改成 `做中`；`NOW.md` 写明第几步、用哪个任务。要落盘的步骤，一步开一个任务（技能 `harness-my-task`）。
2. **做**：照任务的规则做。
3. **自验**：跑能跑的检查。结果写下来，不要只说“应该没问题”。
4. **收尾**：先 promote（如需要），再 `task close`。这是“步骤边界”，见下面的 gate 说明。
5. **交棒**：
   - `TODO.md` 该步改成 `已交棒`，写自验结果。
   - 验收按 [验收指南](#验收指南) 写：简单步骤在 `TODO.md` 写一行；复杂步骤写 `accept/<步骤号>.md`，在 `TODO.md` 放链接。
   - `NOW.md` 写“等用户验收”。在对话里告诉用户，然后停下。
6. **用户反馈**：
   - 有问题：写进该步的“反馈记录”（有验收指南的，也写进指南的“反馈记录”），状态改成 `做中`，回到第 2 步。
   - 用户说“通过”：按下面顺序写，再停下等用户说开始。
     1. `LOG.md` 加一条（见 [LOG.md 怎么写](#logmd-怎么写)）。
     2. `TODO.md` 该步改成 `已通过` 并写日期。
     3. `NOW.md` 指向下一步，并把这一步的细节删掉（见 [NOW.md 保持短](#nowmd-保持短)）。
     4. 说下一步要不要开任务、开哪一种。

## 验收指南

- **简单步骤**（一个文件、一个命令就能看出对不对）：在 `TODO.md` 的“验收标准”写一行：看哪里，预期是什么。
- **复杂步骤**（要多个操作、多个 prompt、跨文件看结果）：写 `accept/<步骤号>.md`，按 [templates/ACCEPT.md](templates/ACCEPT.md) 的固定节写：目的、前置、步骤、看哪里、预期、自验结果、反馈记录。
- 每个步骤只测一件事。步骤要按顺序编号，每步写清“做什么”和“预期”。
- 命令和 prompt 写成能直接复制的样子。不要让用户去猜。
- 能在磁盘上看的结果（日志、文件、`git diff`），就让用户看文件，由你读。不要让用户复制大段输出回来。
- 能用便宜的做法就用：最小的任务、最小的文件。
- 你已经验过的写进“自验结果”；你验不了的（要用户的环境、账号、真实界面），明说，让用户来测。

## LOG.md 怎么写

每个步骤通过时加一条，新的写在最上面。只写已经完成并通过的改动，不写计划和猜测。

```markdown
### <yyyy-mm-dd>｜第 <n> 步：<名称>

- **改了什么**：<文件、命令、行为，给链接；不要贴代码>
- **以前**：<一句话>
- **现在**：<一句话>
- **验收**：<TODO 的哪一行，或 accept 的哪个文件>
```

- 返工步骤也记一条，写明返工的是哪一步。
- 已写的条目不改。写错了，加一条更正。
- 目标整体完成后，用户可以把 `LOG.md` 交给技能 `generic-populate-development-log` 的格式整理，由用户决定。

## NOW.md 保持短

`NOW.md` 只是指针，新 session 第一个读它。

- 只写当前一步和下一步。已通过的步骤细节删掉，细节在 `LOG.md` 和 `TODO.md`。
- 不放环境说明、历史、已完成的清单。
- “卡点和遗留问题”最多 5 条。解决了就删，并在 `LOG.md` 对应条目里提一句。放不下的，说明该开一个新步骤。
- 超过一屏，就是写多了。先删再写。

## 改需求和续接

- 用户加、改或删需求时，按 [references/change.md](references/change.md) 做。
- 新 session 输入“继续”时，按 [references/resume.md](references/resume.md) 做。

## 写文件和 gate

接着任务的会话（`task close` 之前），gate 不许写 `.workspace/goals/` 下的文件（含 `LOG.md`、`accept/`）。所以：

- 开工前先把 `NOW.md` 写好，再开任务。
- 做完先 `task close`，再写 `TODO.md`、`NOW.md`、`LOG.md`、验收指南。
- 任务进行中用户提了新需求：先在对话里记下，到步骤边界再写进文件。用户要立刻存下，就先 `task close`（之后 `task open` 能接回来）。
- 写入被拒绝时，不要用终端命令绕过。照拒绝理由里的下一步做。

## Gotchas

- **只有用户本人在对话里说“通过”，才能标 `已通过`。** 没回应、“差不多”、“还行”都不算，再问一次。你自己宣布通过会让后面所有步骤建在没验收的东西上。
- **不要一次做多步。** 一步交棒后停下，等用户验收，再开下一步。
- **不要改写已通过的步骤和已写的日志。** 它受到需求变更影响时，加一个新步骤（返工）。步骤编号不复用，取消的步骤留着并写原因。
- **记录和磁盘不一致时，以磁盘为准。** 修正记录，并告诉用户。不要照着旧记录继续做。
- **`GOAL.md` 和 `NOW.md` 各保持在一屏左右。** 续接时每次都要读，太长会浪费上下文。旧细节往 `LOG.md` 挪，不要堆在这两个文件里。
- **不要把知识库内容或业务数据抄进目标文件。** 只放指针和结论。
- **本 Skill 不改变权限。** 它只管记录和流程。

## 故障处理

| 问题 | 处理方式 |
| --- | --- |
| 写 `TODO.md`、`NOW.md`、`LOG.md` 被拒绝 | 任务还没关。先 `task close`，再写 |
| 找不到 `.workspace/goals/<id>/` | 问用户目标名。不要新建一个顶替 |
| 目录下有多个目标，不知道接哪个 | 列出各目标的 `NOW.md` 第一行，让用户选 |
| `NOW.md` 写“做中”，但磁盘上没有对应成果 | 当作该步没做。告诉用户，从这一步重新开始 |
| `TODO.md` 写“已通过”，但 `LOG.md` 没有对应条目 | 补一条，写明是补记，并告诉用户 |