<p align="center"> <img src="assets/to-goal-hero.png" alt="从模糊想法到已确认 Spec，再到隔离执行线程的工程工作流" width="100%"> </p>

<div align="center">

# Matt Skills with To-Goal

**把需求留在规划线程，把实现放进继承 Spec 的执行线程**

让规划线程专注于把事情想清楚，让执行线程专注于把事情做完。

[](https://github.com/mattpocock/skills) [](#安装) [](LICENSE)

`grill → spec ready → fork → execute → receipt`

[**▶ 在线故事版：别让一个线程从需求聊到代码写完**](https://verifiable-goal-weekly-share-public.pages.dev)

</div>

## 它解决什么问题

AI coding 任务常常从需求讨论一路聊到代码实现。线程越长，上下文越容易膨胀、压缩和变慢；但直接开新线程，又担心缺少需求背景和已经确认的决策。

这套技能把工作拆成两类线程，并用仓库里的持久化证据连接它们：

| 常见困境 | 这套流程的处理方式 | |---|---| | 方案讨论和代码实现挤在一个长线程里 | 规划线程停在 `SPEC READY`，fork 线程承担代码和测试日志 | | Fork 后又重新分析和改写一遍 Goal | `spec-executor` 直接执行继承的最终 Spec，并回传结构化 receipt | | 当前上下文太脏、无法可靠继承 | `to-goal` 把 ticket 和仓库证据压成干净的执行契约 | | 不同任务都使用同一档模型和推理强度 | goal 按风险推荐 Lightweight / Standard / Advanced 与推理强度 | | “做完了”依赖人的主观判断 | Goal 带完成标准，executor 回传逐项证据和外部操作状态 |

> **Fork 负责隔离后续上下文，Goal 负责压缩已有上下文。** 连续开发优先 fork；跨人、跨天、并行或上下文混乱时使用 `to-goal`。

## 30 秒看懂主流程

```mermaid flowchart LR idea["模糊想法"] --> grill["聊清楚<br/>/grill-me"] grill --> spec["封版共识<br/>/to-spec"] spec --> fork["Fork<br/>继承 SPEC READY"] fork --> execute["实施<br/>/spec-executor"] execute --> receipt["摘要回流<br/>EXECUTION RECEIPT"] spec -. "多分片 / 跨上下文" .-> goal["压缩契约<br/>/to-tickets + /to-goal"] goal --> execute

classDef source fill:#171717,color:#F7F3EA,stroke:#171717,stroke-width:2px; classDef plan fill:#F7F3EA,color:#171717,stroke:#171717,stroke-width:2px; classDef contract fill:#DCF23E,color:#171717,stroke:#171717,stroke-width:3px; classDef action fill:#F35B2A,color:#FFFFFF,stroke:#171717,stroke-width:2px;

class idea source; class grill,spec plan