# Goal Setter

> 把模糊诉求收敛成另一个 AI 能自主执行且可验收的 goal contract（scope / non-goals / success criteria / verification / stop conditions）。本 skill 只写目标契约，**绝不替用户执行任务**。触发硬条件：这份 goal 是要交给别人跑的——subagent、Codex、另一个 AI 会话或另一个人。用于写 goal、优化 goal、改 handoff prompt，或把"今天做完、尽量优化、帮我研究并执行"这类请求变成执行方不会乱猜、不会越界的任务契约。不适用于：自己团队的需求管理和版本拆解（用 issue-pool——它产出的是给人开工的 task，不是给 AI 的契约）、界面设计探索（用 design-exploration）、PRD/验收标准/测试用例文档（用 prd-test-writer）、框架计划和版本路线（用 issue-pool）、以及用户其实是想让你**直接把这件事做了**的情况——那就直接做，不要走本 skill 把活变成一份文档。

- Skill: `yunshu0909/goal-setter` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds add yunshu0909/goal-setter`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yunshu0909/goal-setter/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: yunshu0909 (https://skillmd.com/u/yunshu0909)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/yunshu0909/goal-setter

---


# Goal Setter

目标是把用户的真实诉求变成另一个 AI 可以直接执行的 goal contract。不要替用户执行任务；只负责收敛目标、边界、验收和停止条件。

核心判断：好 goal 不是更长，而是让执行 agent 少猜、少越界、可证明完成。

## 工作流

### 1. 先理解诉求和环境

先读取用户给出的路径、材料、仓库上下文、现有文档或对话事实。不要问能从环境发现的问题。

快速判断任务类型：

- 低风险：信息整理、小范围代码修改、明确测试命令、无账号/生产/隐私/外部成本。
- 高风险：生产、部署、真实账号、付费 API、密钥、隐私数据、线上配置、不可逆操作。
- 弱验证：周报、研究、SEO、增长、PRD、内容总结、策略建议、没有天然测试命令的任务。
- 探索型：用户还不确定目标，只描述了模糊愿望或问题。

如果用户给了时间词，如“今天”“明天”“尽快”“先上一版”，把它转成明确交付边界和验收时间点，不要保留模糊表达。

### 2. 推荐式追问

每轮最多问 1-3 个高影响问题。优先问会改变 scope、权限、验收或停止条件的问题。

提问规则：

- 给出推荐默认，不把空白选择丢给用户。
- 用户说“你定”“都行”时，采用保守默认，并在最终 goal 的 Assumptions 中写明。
- 不问实现细节能从代码或材料中发现的问题。
- 不为低风险任务过度追问；能安全默认就直接产出。

常见高影响问题：

- 最终交付物是什么：代码改动、报告、PRD、测试结果、上线方案，还是可复制 prompt。
- AI 是否允许改文件、跑测试、联网、调用真实账号、部署或使用付费 API。
- 什么证据算完成：测试通过、截图、diff、报告、数据表、人工确认项。
- 哪些事情明确不做：上线、真 key、真实用户数据、范围外重构、商业承诺。

### 3. 按风险选择输出形态

低风险任务用短格式：

```markdown
Goal:
Scope:
Done When:
Verification:
```

标准或高风险任务用完整格式：

```markdown
Objective:
Context:
Scope:
Non-goals:
Autonomy & Permissions:
Constraints:
Success Criteria:
Verification Evidence:
Stop Conditions:
Deliverables:
Assumptions:
```

不要机械套完整模板。只有当风险、模糊度或验收难度需要时才展开。

### 4. 写 goal contract

最终输出必须能直接复制给另一个 AI 执行。使用命令式、具体、可验收的语言。

必须写清：

- 本轮要完成什么。
- 本轮不做什么。
- AI 能自主做哪些动作。
- 哪些动作必须停下来问用户。
- 完成后要交付什么证据。

避免这些坏写法：

- “尽量优化”“研究一下然后执行”“效果好一点”“上线一版看看结果”。
- 没有路径、没有范围、没有验收、没有权限边界。
- 把用户价值判断和 AI 执行细节混在一起。

## 高风险任务规则

如果涉及生产、部署、真实账号、真实 key、付费 API、用户数据、财务、法律、医疗或不可逆操作，必须在 goal 中写明：

- 不使用真实密钥、真实用户数据或真实付费 API，除非用户明确授权。
- 不部署、不改生产、不改真实配置，除非用户明确授权。
- 可以使用隔离副本、mock、fixture、dry-run、测试账号或本地环境。
- 遇到账号、权限、密钥、生产配置、数据删除、外部费用或合规风险时停止并询问用户。
- 验收证据必须避免泄露密钥、token、隐私数据和内部凭据。

## 弱验证任务规则

如果任务没有天然测试命令，必须补足事实和验收规则：

- 标明事实来源：会议、任务、风险、文档、代码、用户材料、网页来源等。
- 不编造未提供的成果、数字、负责人、日期、承诺或外部结论。
- 模糊信息必须进入“待确认”或明确标为假设。
- 输出必须包含可检查证据，如来源标注、覆盖清单、对照表、审阅 checklist 或验收标准。

## 交付格式

默认先给最终 goal，再给极短说明。不要输出长篇过程分析。

推荐结构：

```markdown
下面是可以直接交给 AI 执行的 goal：

[goal contract]

我采用的默认假设：
- ...
```

如果用户明确要求“只要 goal”，只输出 goal contract。

如果用户要求比较多个版本，输出：

- 一句话版。
- 结构化版。
- 推荐使用哪一个和原因。