| name | goal-crafter |
| description | Craft verifiable, tight goal prompts for AI coding agents (Claude Code /goal, Codex Automations, Pi), either from a standalone task interview or from an already-approved to-goal handoff. Use when the user says "给我一个 goal 提示词", "帮我写个 goal", "设置一个自动化任务", "我想让 agent 自动做 X", or asks to turn a task into a self-running loop. Ensures every goal has a checkable completion criterion so the agent knows when it's done.
|
Goal Crafter
Turn a vague task into a verifiable goal that an AI agent can run unattended.
Leading principle: A goal without a checkable completion criterion is just a wish. The agent must be able to answer "Am I done?" without asking a human.
Invocation modes
Choose the mode before following the process:
- Standalone mode: the user brings a vague task or directly asks for a goal. Run Phase 1 and clarify the task one question at a time.
- Compiled-handoff mode: an upstream skill such as
to-goal invokes this skill after to-spec, to-tickets, or triage. The approved spec, selected ticket, tracker evidence, and repository state supply the answers. Do not interview the user again. Apply only this skill's verifiability rules and target-harness formatting.
In compiled-handoff mode, if a required product decision or completion condition is genuinely absent from the sources, report that the source is not agent-ready and name the missing evidence. Do not reopen the planning interview from inside goal compilation.
Process
Phase 1 — Clarify the task
Run this phase only in standalone mode. In compiled-handoff mode, extract the five answers from the upstream evidence without asking questions.
Ask the user, one question at a time, in this shape (standalone interview only — keep compiled-handoff mode emoji-free):
❓ **QN** - **<short title>**
<body>
💡 <your recommended answer, when you have one>
Walk these five in order:
-
What exactly should the agent do?
Get the task in one sentence. If it's vague ("优化代码", "改进 UI"), push for specifics.
-
Where does it run?
Which project / repo / workspace? Is there a specific branch or file area?
-
What does DONE look like?
This is the most important question. Push for observable, machine-checkable conditions:
| ❌ Vague (bad) | ✅ Verifiable (good) |
|---|
| "代码质量提高" | "tsc --noEmit 0 errors + eslint 0 warnings" |
| "UI 更好看" | "页面在 375px / 768px / 1440px 三个断点下视觉一致，无溢出" |
| "修复所有 bug" | "npm test 全部通过，且 git diff 只包含修复相关改动" |
| "写好文档" | "README.md 包含安装/使用/API 三个章节，每个章节有代码示例" |
| "性能优化" | "Lighthouse Performance 分数 ≥ 90，LCP < 2.5s" |
-
Any constraints?
Don't touch certain files? Must use specific tools? Budget limit? Time limit?
-
What agent / harness?
Claude Code (/goal), Codex (Automations), Pi, or generic?
Phase 1 complete when you have answers to all 5 questions. If the user can't answer #3, help them brainstorm verifiable conditions — this is the most common failure point.
Phase 2 — Draft the goal
Write the goal in the target agent's format. Follow these rules:
The three shapes below are the formats this skill deliberately maintains for the harnesses it is most often pointed at. They are a snapshot, not a standard: when the target harness documents a different shape, follow the harness and treat the block here as the fallback. Any harness not listed uses the generic block.
For Claude Code /goal:
Goal: [one-line task description]
Completion criteria:
- [ ] [checkable condition 1]
- [ ] [checkable condition 2]
- [ ] [checkable condition 3]
Constraints:
- [file/area restrictions]
- [tool/approach restrictions]
- [budget/time limits]
Context:
- [key files to read first]
- [relevant docs/specs]
- [related issues/PRs]
For Codex Automations:
Task: [one-line description]
Frequency: [once / on push / on schedule]
Verification: [checkable condition]
Workspace: [project path]
For Pi / generic:
任务：[一句话]
完成标准：
- [ ] [可验证条件 1]
- [ ] [可验证条件 2]
限制：[约束条件]
Phase 3 — Verify the goal
Before presenting the final goal, self-check:
If any check fails in standalone mode, go back to Phase 1 and ask the user to clarify that specific point. In compiled-handoff mode, report the source as not agent-ready and name the missing evidence instead of asking a new planning question.
Phase 4 — Deliver
In standalone mode, present the final goal and end with:
🎯 把这个 goal 粘贴到 [agent 名称] 里，它就会自己跑到完成。如果中途卡住，告诉我哪条完成标准没达到，我帮你调。
In compiled-handoff mode, the upstream skill owns the delivery wrapper. Return the goal in the requested harness format without adding this standalone closing line.
Examples
下面两个示例里的仓库名、目录结构和文件路径都是占位符，不代表任何真实项目的约定。真正产出的 goal 必须写目标仓库当前的真实路径，不要照抄这里的形状。
Example 1: Code review automation
User: "帮我写个 goal，自动审查 PR"
Clarified:
- Task: 审查当前分支相对于 main 的所有改动
- Where: 当前工作仓库
- Done: 输出一份审查报告，列出所有 P0/P1 问题，每个问题标注文件和行号
- Constraints: 只读，不改文件
- Agent: Claude Code
Output:
Goal: 审查当前分支相对于 origin/main 的 diff
Completion criteria:
- [ ] 已读取完整的 git diff
- [ ] 已检查安全漏洞（SQL 注入、XSS、密钥泄露）
- [ ] 已检查逻辑错误（空指针、竞态条件、边界条件）
- [ ] 已检查代码规范（命名、结构、重复代码）
- [ ] 输出审查报告，每个问题标注：严重度 + 文件:行号 + 问题描述 + 修复建议
Constraints:
- 只读，不修改任何文件
- 只关注当前分支的改动，不审查已有代码
Context:
- 项目背景：<一句话说明这个仓库是什么>
- 设计 spec：<仓库内的设计文档>
Example 2: UI redesign
User: "帮我写个 goal，重做这个页面"
Clarified:
- Task: 用 shadcn 组件库重做目标页面
- Done: 页面在 3 个断点下视觉一致，所有交互有 hover/focus/active 状态，通过 tsc 类型检查
- Constraints: 不改变现有 API 接口，使用项目已有的 Tailwind 配置
- Agent: Claude Code
Output:
Goal: 用 shadcn/ui 组件库重做目标页面
Completion criteria:
- [ ] 所有组件替换为 shadcn/ui 等价组件
- [ ] 页面在 375px / 768px / 1440px 断点下无溢出、无错位
- [ ] 所有可交互元素有 hover、focus、active 状态
- [ ] `tsc --noEmit` 0 errors
- [ ] 页面加载后无 console error
Constraints:
- 不修改 API 客户端目录下的任何文件
- 使用项目已有的 Tailwind 主题配置
- 不引入新的 npm 依赖（shadcn 除外）
Context:
- 当前页面：<页面组件文件>
- UI 组件：<组件库入口文件>
- 样式：<全局样式入口>
Special Rules
- Never skip Phase 1 question #3 in standalone mode. If the user can't define "done", the goal will fail. Help them brainstorm.
- Never re-interview in compiled-handoff mode.
to-spec, to-tickets, or triage already owns clarification and product decisions; missing evidence means the source is not agent-ready.
- One verifiable condition per checkbox. Don't combine multiple conditions into one line.
- Constraints are your friend. They prevent the agent from "optimizing" unrelated files or introducing breaking changes.
- If the task is too large for one goal, suggest breaking it into 2-3 smaller goals with clear handoffs.
- For research/analysis goals (no code changes), the completion criterion is "output a report with specific sections".
