Goal crafter

Skill tt-a1i/matt-skills-with-to-goal/skills/goal-crafter

Planning → verifiable goals → fresh-session implementation for AI coding agents. Based on mattpocock/skills v1.1.

Install

npx -y skills add tt-a1i/matt-skills-with-to-goal --skill goal-crafter

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

26 days oldThe repository was created 26 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
18 stars18 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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.

SKILL.md

7.6 KB, as published. Nobody here has run it

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:

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:

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:

Can an agent read the completion criteria and unambiguously decide "done" vs "not done"?
Is every criterion observable without human judgment? (No "looks good", "feels right")
Are the constraints specific enough to prevent scope creep?
Is the context sufficient for the agent to start working without asking "where" or "how"?

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

Example 1: Code review automation

User: "帮我写个 goal，自动审查 PR"

Clarified:

Task: 审查当前分支相对于 main 的所有改动
Where: hive-private 仓库
Done: 输出一份审查报告，列出所有 P0/P1 问题，每个问题标注文件和行号
Constraints: 只读，不改文件
Agent: Claude Code

Output:

Goal: 审查当前分支相对于 origin/main 的 diff

Completion criteria:
- [ ] 已读取完整的 git diff
- [ ] 已检查安全漏洞（SQL 注入、XSS、密钥泄露）
- [ ] 已检查逻辑错误（空指针、竞态条件、边界条件）
- [ ] 已检查代码规范（命名、结构、重复代码）
- [ ] 输出审查报告，每个问题标注：严重度 + 文件:行号 + 问题描述 + 修复建议

Constraints:
- 只读，不修改任何文件
- 只关注当前分支的改动，不审查已有代码

Context:
- 项目背景：Hive 是本地多 Agent 协作 runtime
- 设计 spec：docs/superpowers/spec.md

Example 2: UI redesign

User: "帮我写个 goal，重做这个页面"