# Goal Definition

> 通过与用户分轮交互，把模糊、复杂或长期任务转化为证据驱动的 Goal 合同；在用户要求定义、澄清、审查、改写 Goal，或任务涉及远程运行、实验、调试、多阶段交付、截止时间与领导汇报时使用。输出可证明的验收标准、交付物、预算、权限、停止与升级条件，并强制绑定 $goal-execution；不要用于直接执行已经确认的 Goal。

- Skill: `kirrito-k423/goal-definition` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add kirrito-k423/goal-definition`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kirrito-k423/goal-definition/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Kirrito-k423 (https://skillmd.com/u/kirrito-k423)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/kirrito-k423/goal-definition

---


# Goal 定义

把 Goal 当作用户与执行者之间的**任务合同**，不要把它写成一句愿望或“持续尝试直到成功”的循环指令。先收敛成功定义和工程边界，再允许进入执行。

## 基本原则

1. **先复述已知信息，再提问。** 不重复询问用户已经给出的内容，也不询问可通过只读检查直接获得的事实。
2. **每轮只问 1–3 个会改变方案的问题。** 同时给出推荐默认值、影响和不回答时的处理方式。
3. **尽早展示草案。** 从第一轮起维护 `DRAFT`，让用户修改具体条款，而不是接受连续审问。
4. **区分事实、假设、未知量和决策。** 不把推测写成事实，不用虚假的精确数字掩盖不确定性。
5. **验收必须可举证。** “跑通”“效果好”“问题解决”不是完整标准；必须写明可观察条件和证据位置。
6. **持续交付。** 最终目标未达成时，仍应能交付已完成代码、最小复现、日志、调查结论、文档和决策包。
7. **不替用户扩大权限。** 外部发信、推送代码、创建 PR、变更生产环境、删除数据或产生显著费用等动作必须在 Goal 中明确授权。
8. **不擅自缩小成功标准。** 任何范围、指标或交付期限变化都作为变更请求交给用户确认。

## 交互流程

### 1. 建立任务画像

从用户上下文和只读环境中提取：

- 业务背景、期望终态和截止时间；
- 仓库、基线提交、环境、硬件和数据；
- 已完成工作、现有证据、已知故障和未知量；
- 预期交付件、汇报对象与频率；
- 时间、算力、费用、重试和版本切换预算；
- 允许与禁止的动作、需要审批的边界。

将缺口分成两类：

- **关键缺口**：不同答案会改变目标、验收、风险、权限或成本，必须由用户确认。
- **非阻塞缺口**：可以给出保守默认值，但必须列在“待确认假设”中。

### 2. 分轮澄清

优先按以下顺序提问：

1. **终态与证据**：什么结果才算完成，谁来验收，用什么证据证明？
2. **范围与交付**：哪些必须做、明确不做，代码、脚本、文档、报告分别交付到哪里？
3. **时限与预算**：截止时间、算力、费用、高成本实验次数和重试上限是什么？
4. **环境与基线**：仓库/提交、机器、软件栈、数据、凭证和已知成功基线是什么？
5. **权限与升级**：是否允许提交/推送/建 PR/改远端环境，阻塞时谁能做资源或范围决策？
6. **汇报节奏**：多久同步一次，领导最关心哪些信息，何时必须生成交接包？

当用户明确授权“按最佳判断补全”时，采用推荐默认值并明确标注，不要继续追问非关键问题。涉及不可逆动作、外部影响或明显费用的关键缺口不得自行假设。

### 3. 生成 Goal 草案

生成最终合同前，必须读取 [Goal 合同模板](references/goal-contract-template.md)。在仓库任务中，默认将合同保存为：

```text
goal_process/<goal-id>/GOAL.md
```

若用户只要求聊天内草案，则在回复中完整给出，不擅自写文件。

草案至少包含：

- 元数据、目标陈述、成功后的业务价值；
- 范围、非目标、环境基线；
- 已知事实、待验证假设和关键未知量；
- 带编号的验收标准及证据要求；
- 带路径或目标位置的交付物；
- 里程碑及各自退出条件；
- 时间、算力、费用、重试、版本切换和高成本实验预算；
- 允许动作、禁止动作和需审批动作；
- 过程归档目录、汇报频率和汇报对象；
- 停止、回滚、阻塞和升级条件；
- 条件化 ETA 与最晚决策点；
- 强制执行技能 `$goal-execution`。

### 4. 执行就绪审查

只有同时满足下列条件，才将状态从 `DRAFT` 改为 `READY`：

- 目标和非目标无实质冲突；
- 每个验收项都有可获得的证据；
- 每个必需交付件都有载体或目标位置；
- 环境、权限和预算足以开始第一个里程碑；
- 高风险动作具有审批人或明确禁令；
- 到期、物理不可行和外部依赖阻塞时有停止/升级路径；
- 用户确认关键条款，或明确授权采用已列出的默认值；
- Goal 明确绑定 `$goal-execution`。

不满足时输出：

1. 当前 `DRAFT`；
2. 阻止 `READY` 的最小问题集；
3. 推荐答案及其代价；
4. 当前仍可安全进行的只读调查。

不要用低风险细节拖延就绪，也不要为了尽快开始而跳过关键门禁。

### 5. 完成确认

向用户展示一屏摘要：

- 一句话目标；
- 验收标准；
- 交付物；
- 截止时间和预算；
- 最大风险；
- 允许/禁止动作；
- 首个里程碑；
- 停止/升级条件。

获得确认后，将状态改为 `READY`。明确说明执行时必须携带 `$goal-execution`；本技能到此结束，不直接开展实现或实验。

## Goal 变更

执行中出现范围、验收、截止时间、资源或权限变化时：

1. 保留原条款；
2. 记录变更原因和证据；
3. 标出对进度、成本、风险和已有交付的影响；
4. 生成待用户确认的变更项；
5. 未确认前继续遵循原 Goal，无法继续则进入升级，不静默改写。