Qiaomu Goal Meta Skill

Qiaomu Goal Meta Skill

把一个模糊任务，收敛成 Codex 可以持续执行、可以验证、知道何时停止和何时暂停的 /goal 指令。

Copyright (c) 向阳乔木 X: https://x.com/vista8 GitHub: https://github.com/joeseesun/

Operating Mode

Run as a production-lite meta skill.

Default assumptions:

• The user wants a paste-ready Codex /goal command, not a general prompt.
• The executable slash command stays /goal. Do not output /目标 as the command unless the user's environment explicitly documents that alias.
• The first goal block should be the best recommended executable version, not a half-filled template. Users often copy the first draft directly.
• For Chinese users, output Chinese content and Chinese field names by default while keeping the command prefix /goal.
• For Chinese users, include both 推荐执行版（中文，可直接复制） and Goal Draft (English-compatible) unless the user asks for one language only.
• If the task is still vague but low-risk, choose the best conservative defaults and continue. Ask only when the answer changes cost, risk, ownership, or product direction.
• If the domain is unfamiliar or specialized, create a discovery-first goal that makes the agent inspect authoritative project/docs/runtime evidence before implementation instead of inventing domain rules.
• If the missing detail is low-risk, make an explicit assumption and continue.
• Do not start the work described by the goal unless the user explicitly asks. This skill creates the goal instruction.
• Prefer concrete verification commands and artifacts over vague confidence phrases.
• Prefer narrow write boundaries and explicit forbidden paths over broad permission.
• Treat Stop when and Pause if as part of the same completion/blocking contract.

Workflow

1. Restate the task as an outcome, not an activity. 2. Classify the task using references/default-goal-strategy.md: familiar vs unknown domain, low vs high risk, new work vs existing project. 3. Choose best defaults for low-risk unknowns and write a one-sentence reason. 4. Identify missing information across the Goal contract:

• success criteria
• verification commands, artifacts, or evidence
• constraints that must not change
• allowed writes and forbidden paths
• iteration policy
• completion evidence
• blocked stop conditions, human decisions, or budget caps

5. If the task is under-specified, prefer numbered multiple-choice adjustments with defaults. Use references/interview-checklist.md. 6. For Chinese-first users, produce the Chinese recommended execution goal first, then an English-compatible mirror that preserves the same meaning and keeps English field labels. 7. Check the command against references/goal-command-playbook.md. 8. For file deliverables, run python3 scripts/lint_goal_command.py <file> before calling the goal done.

Output Contract

When enough information is known, output the best recommended command first. Do not leave placeholders in real output.

/goal Create a first-version local MVP for the requested task, inspect project-provided commands before changing code, implement the core user-visible workflow, and keep unrelated systems unchanged.
Verification: run the smallest project-provided checks, start the local app or relevant runtime, complete the core workflow once, and capture logs/screenshots or command output as evidence.
Constraints: do not add accounts, paid services, production changes, destructive operations, or unrelated features unless requested.
Boundaries: write only inside the new project directory or the directly related existing project files.
Iteration policy: implement one focused workflow at a time, rerun checks after meaningful changes, inspect logs before retrying, and make at most 3 focused improvement rounds before reporting remaining risks.
Stop when: the core workflow is proven by runtime evidence and checks pass or missing checks are explicitly reported.
Pause if: credentials, payments, production data, destructive changes, legal/medical/financial decisions, copyrighted assets, or unclear ownership is required.

For Chinese-first users, prefer this equivalent shape:

/goal 基于用户需求创建第一版本地 MVP，先读取项目已有命令和约束，实现核心用户可见流程，并避免改动无关系统。
验证：运行项目提供的最小相关检查，启动本地应用或对应运行环境，完整走通一次核心流程，并用日志、截图或命令输出作为证据。
约束：不加入账号、付费服务、生产变更、破坏性操作或无关功能，除非用户明确要求。
边界：只写入新项目目录，或只修改现有项目中与该功能直接相关的文件。
迭代策略：一次实现一个聚焦工作流，每次有意义改动后重跑检查，重试前先读日志，最多做 3 轮聚焦改进后报告剩余风险。
完成条件：核心流程有运行证据证明可用，检查通过或明确说明缺少配置。
暂停条件：需要凭证、付费、生产数据、破坏性操作、法律/医疗/金融判断、版权素材或所有权不清时暂停。

When the task is vague, output:

1. 推荐执行版（中文，可直接复制）: the best default /goal. 2. 默认选择理由: one concise sentence. 3. 可选调整: numbered choices with recommended defaults and short option labels. 4. 你可以直接回复: an example such as 按默认 or 1B 2A 3C. 5. Goal Draft (English-compatible): a faithful English-compatible mirror with English field labels.

If the user writes in English, output only the English-compatible draft unless they ask for Chinese too.

Do not output long generic coaching unless the user asks for explanation.

Quality Bar

A strong goal:

• has one concrete outcome
• names exact checks or evidence
• protects unrelated files, user data, secrets, and default branches
• defines the write boundary
• tells the agent how to iterate after failures
• says when to stop because completion is proven
• says when to pause because a human decision, credential, account state, budget, or repeated blocker is required

Reject or revise a goal that:

• says only make it better, finish this, or fix bugs
• lacks verification
• lets the agent edit the whole machine or repo without reason
• asks for repeated retries without a new source of evidence
• has no pause condition for external auth, secrets, payments, destructive actions, or ambiguous product decisions
• leaves placeholders such as [Outcome] in user-facing executable drafts
• treats vague words such as 高级, 有质感, or professional as verification instead of translating them into screenshots, runtime checks, review criteria, or iteration rules

Reference Files

• references/goal-command-playbook.md: the core /goal template, when to use it, examples, and anti-patterns.
• references/default-goal-strategy.md: lazy-user defaults, unknown-domain discovery, risk classification, and direct-copy output rules.
• references/interview-checklist.md: question bank for turning vague tasks into strong goals.
• scripts/lint_goal_command.py: lightweight checker for required /goal labels and unresolved placeholders.

qiaomu-goal-meta-skill

你只想说一句“帮我做个 App”，但 Codex 真正需要的是一个能执行、能验证、知道边界、知道何时停下来的目标。

qiaomu-goal-meta-skill turns vague work into a copy-ready Codex /goal command with defaults, verification, boundaries, and pause conditions.

<p align="center"> <a href="https://github.com/joeseesun/qiaomu-goal-meta-skill/stargazers"><img alt="Stars" src="https://img.shields.io/github/stars/joeseesun/qiaomu-goal-meta-skill?style=for-the-badge&logo=github" /></a> <a href="https://github.com/joeseesun/qiaomu-goal-meta-skill/network/members"><img alt="Forks" src="https://img.shields.io/github/forks/joeseesun/qiaomu-goal-meta-skill?style=for-the-badge&logo=github" /></a> <a href="https://github.com/joeseesun/qiaomu-goal-meta-skill/issues"><img alt="Issues" src="https://img.shields.io/github/issues/joeseesun/qiaomu-goal-meta-skill?style=for-the-badge&logo=github" /></a> <a href="https://github.com/joeseesun/qiaomu-goal-meta-skill/commits/main"><img alt="Last commit" src="https://img.shields.io/github/last-commit/joeseesun/qiaomu-goal-meta-skill?style=for-the-badge&logo=git" /></a> <a href="LICENSE"><img alt="License" src="https://img.shields.io/badge/license-MIT-blue.svg?style=for-the-badge" /></a> </p>

中文 | English

npx skills add joeseesun/qiaomu-goal-meta-skill

为什么值得用

很多 agent 任务失败，不是因为模型不会写代码。

而是因为目标一开始就太松：

• “做得高级一点”
• “帮我开发一个 App”
• “修一下这个问题”
• “做个类似 GTA 的网页游戏”

这些话对人类有感觉，对 agent 却缺少几个关键东西：怎么验证、哪里不能碰、失败后怎么迭代、什么时候必须暂停。

这个 skill 的目标很简单：

让 Codex 在开工前拿到一份更像“任务合同”的 /goal。

它会默认给你一段可直接复制的推荐执行版，而不是让你先填表。

它会怎么帮你

1. 先给可直接复制的推荐版

中文用户默认先看到：

推荐执行版（中文，可直接复制）
/goal 开发一个第一版原创 GTA-like 网页游戏 MVP，用户可以在浏览器中进入一个俯视 2D 城市场景，控制角色步行、上车驾驶、完成一个简单任务，并看到基础状态反馈。
验证：如果已有项目，先读取项目脚本和运行方式；否则新建最小网页游戏项目，启动本地开发服务，在浏览器中完整走通一次进入游戏、移动角色、上车驾驶、触发任务、完成任务、查看状态反馈流程，并检查桌面和移动端布局与控制区无重叠。
约束：不使用 GTA、Rockstar 或任何真实游戏的名称、Logo、角色、地图、音乐、音效、美术素材或受版权保护内容；第一版不加入登录、后端、联机、付费 API、真实暴力血腥表现、复杂 AI 或营销落地页。
边界：如果新建项目，只写入新项目目录；如果在现有项目中工作，只修改与网页游戏画布、输入控制、游戏状态、样式和直接相关测试有关的文件。
迭代策略：先实现可玩的核心循环，再补任务、状态反馈和响应式控制；每次有意义改动后重跑项目检查并启动本地服务验证，遇到运行时或浏览器错误先读控制台日志；最多做 3 轮聚焦体验改进。
完成条件：本地游戏可运行，玩家能完成移动、驾驶、任务触发和任务完成的核心流程，项目检查通过或明确说明缺少配置，并且桌面和移动端验证无布局破损。
暂停条件：需要使用 GTA 官方 IP 或素材、真实版权素材授权、联机服务器、账号系统、支付、上架发布、复杂 3D 开放世界、真实暴力血腥表现或更完整游戏策划时暂停。

用户可以直接复制这一段执行。

2. 再给一句默认理由

默认选择理由：先做原创俯视 2D MVP，因为它能最快验证“城市移动、驾驶、任务”核心乐趣，同时避开版权和 3D 开放世界的高成本。

这句理由很短，但能让你知道 skill 为什么这么选。

3. 给懒人选择题

可选调整
1. 项目形态：A 新建本地网页游戏 MVP（默认） / B 改现有项目 / C 先做可交互原型
2. 画面形式：A 俯视 2D（默认） / B 像素风 2D / C Three.js 3D
3. 第一版范围：A 步行+驾驶+一个任务（默认） / B 加警戒/追逐系统 / C 加多任务和商店
4. 验证方式：A 本地浏览器桌面+移动检查（默认） / B 加自动化测试 / C 部署后线上验证

你可以直接回复：按默认，或回复类似 1A 2B 3B 4A。

不用写长句，回选项就能继续收敛。

4. 同时给英文兼容镜像

英文版字段保留 Verification、Constraints、Boundaries、Iteration policy、Stop when、Pause if，方便复制到偏英文的 agent 环境或团队文档。

什么时候用

适合：

• 开发一个网站、App、游戏、Chrome 插件、自动化脚本
• 修 bug、做重构、加测试、跑发布
• 设计一个 UI 或产品原型
• 创建、整理、发布 agent skill
• 做多步骤研究或文档交付
• 把一句模糊需求变成可执行任务

不适合：

• 一句话翻译
• 简单改写
• 一行 shell 输出
• 不需要持续执行和验证的小任务

安装

npx skills add joeseesun/qiaomu-goal-meta-skill

安装后确认：

test -f ~/.agents/skills/qiaomu-goal-meta-skill/SKILL.md

你可以这样说

• “用 qiaomu-goal-meta-skill 帮我把这个需求写成 Codex /goal。”
• “我要开发一个 iOS 提词器，帮我写 goal。”
• “我要做一个 GTA 网页游戏，帮我写一个安全可执行的 goal。”
• “这个任务太模糊，先给推荐执行版，再给我几个可选调整。”
• “帮我把修 bug 的任务写成带验证和暂停条件的 goal。”
• “给这个发布任务写一个不能直接乱推主分支的 goal。”
• “这个是医疗/金融/版权相关任务，帮我写发现优先的 goal。”

工作方式

flowchart LR
  A["用户的模糊需求"] --> B["选择保守默认值"]
  B --> C["生成推荐执行版 /goal"]
  C --> D["补验证、约束、边界"]
  D --> E["补迭代、完成、暂停条件"]
  E --> F["给编号可选调整"]
  F --> G["给英文兼容镜像"]

内置原则

默认先推进

低风险不确定性，不拦用户填表。

它会做明确假设，给最佳默认方案。

高风险才暂停

遇到这些情况会写进 暂停条件：

• 凭证、账号、支付
• 生产数据、破坏性操作
• 法律、医疗、金融判断
• 版权素材、官方授权
• 上架发布、真实部署
• 所有权或产品方向不清

陌生领域先发现

meta skill 不假装懂所有专业领域。

如果任务涉及医疗、金融、合规、复杂专业数据，它会生成“发现优先”的 goal：

/goal 创建一个安全的医疗影像标注工具第一版，先读取工作区内的项目文档、样例数据说明和可用脚本，再实现最小可验证标注流程。
验证：识别并读取项目文档、样例数据说明、现有脚本或官方参考资料；运行最小相关检查；用样例数据完整走通一次导入、标注、保存、重新打开流程，并以日志、截图或导出文件作为证据。
约束：不编造医学结论、合规声明、数据语义或诊断用途；不处理生产患者数据；不改变未理解的数据格式。
边界：只修改第一版标注流程直接需要的界面、状态和样例数据处理文件；不触碰生产配置、凭证或无关模块。
迭代策略：先完成发现阶段并列出工作假设，再实现一个聚焦切片；每次失败后基于日志或文档调整，最多做 3 轮聚焦改进。
完成条件：样例数据下的最小标注流程有运行证据证明可用，检查通过或明确说明缺少配置，未解决的领域问题被列出。
暂停条件：需要医疗判断、合规审批、真实患者数据、外部付费服务、生产部署或破坏性数据迁移时暂停。

模糊词不删除，翻译成验证

“高级”“有质感”“专业”“像官网”不是坏词。

坏的是把它们当完成标准。

这个 skill 会把它们变成：

• 设计方向
• 截图检查
• 层级、间距、字体、可读性
• 最多 3 轮聚焦视觉改进

本地质量检查

这个仓库带了一个轻量 linter：

python3 ~/.agents/skills/qiaomu-goal-meta-skill/scripts/lint_goal_command.py goal.txt

它会拦住：

• /目标 这种不可执行前缀
• [Outcome]、TODO、待定 这类占位符
• make sure it works
• 随便改
• edit anything
• keep trying
• 缺少具体证据的验证条件

前置要求

• [ ] 已安装支持 Agent Skills 的运行环境，例如 Codex、Claude Code 或兼容工具。
• [ ] 已安装 Node.js 和 npx，用于执行 npx skills add。
• [ ] 运行环境能读取 ~/.agents/skills。

Troubleshooting

边界

• 这个 skill 只创建 /goal 指令，不默认执行目标本身。
• 它不会替用户绕过版权、账号、支付、生产数据或合规判断。
• 它不会把陌生领域的专业规则编造成“事实”。
• 它默认生成 MVP 级目标；完整产品策略、商业化、部署和发布需要明确要求。

License

MIT

Copyright (c) 向阳乔木 X: https://x.com/vista8 GitHub: https://github.com/joeseesun/

<a name="english"></a>

English

qiaomu-goal-meta-skill turns vague work into a copy-ready Codex /goal command.

It is built for people who do not want to fill out a planning form.

It chooses conservative defaults, explains them in one sentence, gives numbered options when a choice really matters, and mirrors the final goal with English-compatible field labels.

Install:

npx skills add joeseesun/qiaomu-goal-meta-skill

Use it like this:

• "Use qiaomu-goal-meta-skill to turn this vague app idea into a Codex goal."
• "Write a goal for an iOS teleprompter MVP."
• "Write a safe goal for a GTA-like browser game without copyrighted IP."
• "This domain is unfamiliar. Make the goal discovery-first."

It produces goals with:

• outcome
• verification evidence
• constraints
• write boundaries
• iteration policy
• stop conditions
• pause conditions

It intentionally avoids:

• placeholders in executable drafts
• vague verification like "make sure it works"
• broad permissions like "edit anything"
• infinite retry language like "keep trying"
• unsafe scope expansion into auth, payment, production data, copyrighted assets, or regulated decisions

Author:

Copyright (c) 向阳乔木 X: https://x.com/vista8 GitHub: https://github.com/joeseesun/

Default Goal Strategy

Generate goals that can be copied directly.

The skill should not rely on knowing every domain. Reliability comes from conservative defaults, authoritative context discovery, concrete verification, bounded iteration, and high-risk pause rules.

Output Priority

For Chinese users, output in this order:

1. 推荐执行版（中文，可直接复制） 2. 默认选择理由 3. 可选调整 4. 你可以直接回复 5. Goal Draft (English-compatible)

Do not put a half-filled template before the recommended executable goal. Users often copy the first block directly.

Default-First Rule

If the user gives a vague task and the uncertainty is low-risk, choose the best default and move forward.

Good defaults:

• new app/site/tool: local MVP first
• existing repo: inspect project scripts, docs, and conventions first
• no deployment request: local runtime verification only
• no auth request: no login, backend, cloud sync, paid API, or account system
• no design system request: follow existing style; if new project, choose a restrained usable interface
• no test command known: discover package scripts, Makefile, CI config, Xcode schemes, or project docs before inventing commands
• no advanced feature request: implement the smallest complete user-visible workflow

Always add one short reason:

默认选择理由：先做本地 MVP，因为它能最快验证核心体验，同时避免账号、后端和发布流程拖慢第一版。

Lazy-User Choices

Ask with numbered choices only when a decision materially changes cost, risk, or direction.

可选调整
1. 项目形态：A 新建本地 MVP（默认） / B 改现有项目 / C 先做原型
2. 范围：A 核心流程（默认） / B 加常见增强 / C 做完整产品
3. 验证：A 本地运行检查（默认） / B 真机或线上检查 / C 发布前检查

你可以直接回复：按默认，或回复类似 1B 2A 3C。

Keep choices short. Do not ask a long open-ended questionnaire.

Unknown Domain Strategy

When the task touches an unfamiliar or specialized domain, do not invent domain-specific rules. Generate a discovery-first goal.

Use this pattern:

/goal Create a safe first version of [task] by first inspecting authoritative context, then implementing the smallest verified workflow.
Verification: identify and inspect project docs, existing scripts, sample data, domain notes, or official references available in the workspace; run the smallest relevant checks; complete one representative workflow with logs, screenshots, exported artifacts, or command output as evidence.
Constraints: do not invent domain rules, compliance claims, data semantics, or user-facing promises that are not supported by the inspected context.
Boundaries: edit only the files directly required for the first workflow; keep unrelated modules, production data, credentials, and public contracts unchanged.
Iteration policy: complete a discovery pass first, state working assumptions, implement one focused slice, rerun checks, and use new evidence rather than repeated retries after failures.
Stop when: the first workflow works under documented assumptions and evidence proves the result; unresolved domain questions are listed clearly.
Pause if: required domain authority, legal/medical/financial judgment, compliance approval, production data, paid services, or destructive actions are required.

This keeps the goal useful without pretending the meta skill knows the domain.

Risk Classification

Low risk: local prototype, local UI, local docs, toy data, isolated scripts, non-destructive formatting, generated examples.

Medium risk: existing repo changes, public UI copy, migrations in development, shared config, external APIs with test credentials, browser extensions, mobile builds.

High risk: production data, payments, credentials, destructive deletion, legal/medical/financial advice, compliance, privacy-sensitive user data, copyrighted assets, App Store or store submission, live deployment, account ownership, official authorization claims.

Behavior:

• Low risk: choose defaults and generate a copy-ready goal.
• Medium risk: choose defaults, add explicit boundaries and pause conditions.
• High risk: either ask a numbered decision or generate a discovery-only goal that pauses before the risky action.

Vague Words

Do not ban vague direction words. Translate them into iteration and verification.

Example:

设计方向：克制、专业、有留白，避免模板感和营销页风格。
验证：用桌面和移动端截图检查首屏身份、信息层级、文字可读性、核心入口和布局重叠。
迭代策略：基于截图做最多 3 轮聚焦视觉改进，优先调整层级、间距、字体、素材处理和控件密度。

The vague words guide taste. The verification proves whether the result is acceptable.

Iteration Defaults

Use bounded autonomy:

迭代策略：先实现可运行第一版，再基于构建结果、运行日志和截图做最多 3 轮聚焦改进；同一错误连续失败 2 次后必须换证据来源。

Do not write keep trying or until it looks good.

Finalization Rule

After the user answers choices, output 最终可复制 /goal and keep the response mostly to one code block. Do not repeat the full explanation unless asked.

Goal Command Playbook

What This Skill Produces

This skill produces a Codex /goal command.

For Chinese users, the body of the goal can be fully Chinese, but the slash command should still start with /goal. Do not use /目标 as the executable command unless the current Codex client explicitly supports that alias.

A normal prompt tells the agent what to do now. A goal defines a durable operating contract: what outcome matters, how completion is proven, what must not change, where work may happen, how to iterate, when to stop, and when to pause.

Default stance: give the best copy-ready goal first. If the user is vague and the missing details are low-risk, choose conservative defaults and include one short reason instead of making the user fill out a form.

Use /goal for work that benefits from persistence:

• coding, debugging, refactoring, release, or deployment work
• UI or product changes that need verification
• multi-step research or document production
• repo cleanup, migration, or packaging
• any task where "done" must be proven with commands, artifacts, screenshots, logs, or external state

Do not force /goal for:

• one-line answers
• simple rewrites or translations
• quick shell outputs
• tasks whose success is obvious without agent persistence

Plan-To-Goal Interview Template

Use this when the user has a vague task and wants the agent to help write the goal:

/plan Help me turn this vague task into a strong Codex goal.
Interview me for missing success criteria, verification commands, constraints, boundaries, iteration policy, and blocked stop conditions.
Then draft a final `/goal ...` command.

Canonical Goal Template

/goal [Outcome].
Verification: [commands/artifacts/evidence].
Constraints: [what must not change].
Boundaries: [allowed writes / forbidden paths].
Iteration policy: [one focused change, rerun checks, log progress].
Stop when: [evidence proves completion].
Pause if: [blocked conditions / human decisions / budget cap].

中文友好模板

给中文用户时，推荐默认输出这一版。注意：开头仍然是 /goal，不是 /目标。

/goal [目标结果]。
验证：[命令 / 产物 / 截图 / 日志 / 外部证据]。
约束：[不能改变的行为、接口、数据、风格或分支规则]。
边界：[允许写入的位置 / 禁止触碰的路径或系统]。
迭代策略：[一次只做一个聚焦改动，重跑检查，基于日志调整]。
完成条件：[哪些证据证明可以停止]。
暂停条件：[需要人工决定、凭证、外部权限、预算或破坏性操作的情况]。

也可以使用双语字段，适合要兼顾中文可读性和英文模板兼容性的场景：

/goal [目标结果]。
Verification（验证）：[命令 / 产物 / 截图 / 日志 / 外部证据]。
Constraints（约束）：[不能改变的行为、接口、数据、风格或分支规则]。
Boundaries（边界）：[允许写入的位置 / 禁止触碰的路径或系统]。
Iteration policy（迭代策略）：[一次只做一个聚焦改动，重跑检查，基于日志调整]。
Stop when（完成条件）：[哪些证据证明可以停止]。
Pause if（暂停条件）：[需要人工决定、凭证、外部权限、预算或破坏性操作的情况]。

双语草案策略

当用户使用中文、任务还在收敛中，默认先给可直接复制的推荐版，再给英文兼容镜像：

1. 推荐执行版（中文，可直接复制）：给用户直接复制，字段名用中文。 2. Goal Draft (English-compatible)：给 Codex、团队文档或偏英文工具链复制使用，字段名用英文。

两份草案必须语义一致，不能一份扩大范围、一份缩小范围。英文版是兼容镜像，不是重新发挥。

如果用户明确说“只要中文版”或“只要英文版”，遵从用户要求。

推荐执行版（中文，可直接复制）
/goal 基于用户需求创建第一版本地 MVP，先读取项目已有命令和约束，实现核心用户可见流程，并避免改动无关系统。
验证：运行项目提供的最小相关检查，启动本地应用或对应运行环境，完整走通一次核心流程，并用日志、截图或命令输出作为证据。
约束：不加入账号、付费服务、生产变更、破坏性操作或无关功能，除非用户明确要求。
边界：只写入新项目目录，或只修改现有项目中与该功能直接相关的文件。
迭代策略：一次实现一个聚焦工作流，每次有意义改动后重跑检查，重试前先读日志，最多做 3 轮聚焦改进后报告剩余风险。
完成条件：核心流程有运行证据证明可用，检查通过或明确说明缺少配置。
暂停条件：需要凭证、付费、生产数据、破坏性操作、法律/医疗/金融判断、版权素材或所有权不清时暂停。

默认选择理由：先做本地 MVP，因为它能最快验证核心体验，同时避免账号、后端和发布流程拖慢第一版。

可选调整
1. 项目形态：A 新建本地 MVP（默认） / B 改现有项目 / C 先做原型
2. 范围：A 核心流程（默认） / B 加常见增强 / C 做完整产品
3. 验证：A 本地运行检查（默认） / B 真机或线上检查 / C 发布前检查

你可以直接回复：按默认，或回复类似 1B 2A 3C。

Goal Draft (English-compatible)
/goal Create a first-version local MVP for the requested task, inspect project-provided commands before changing code, implement the core user-visible workflow, and keep unrelated systems unchanged.
Verification: run the smallest project-provided checks, start the local app or relevant runtime, complete the core workflow once, and capture logs/screenshots or command output as evidence.
Constraints: do not add accounts, paid services, production changes, destructive operations, or unrelated features unless requested.
Boundaries: write only inside the new project directory or the directly related existing project files.
Iteration policy: implement one focused workflow at a time, rerun checks after meaningful changes, inspect logs before retrying, and make at most 3 focused improvement rounds before reporting remaining risks.
Stop when: the core workflow is proven by runtime evidence and checks pass or missing checks are explicitly reported.
Pause if: credentials, payments, production data, destructive changes, legal/medical/financial decisions, copyrighted assets, or unclear ownership is required.

The six practical elements are:

中文对应：

Drafting Rules

• Write the outcome as a result, not as "work on X".
• Put exact commands in Verification when the repo exposes them.
• If exact commands are unknown, make discovery part of the goal: read package scripts, Makefile, CI config, Xcode schemes, project docs, or local runbooks first.
• Put artifacts in Verification when commands are not enough: changed files, screenshots, exported PDFs, published URL, GitHub PR, logs, or API response.
• Put "what must not change" in Constraints, not in Boundaries.
• Put filesystem and repo permissions in Boundaries.
• In Iteration policy, require a new source of evidence after repeated failures.
• In Stop when, define proof, not a feeling.
• In Pause if, include anything that needs human judgment or external permission.
• If the domain is unfamiliar or specialized, do not invent domain rules. Require an initial discovery pass over authoritative project docs, sample data, official references, or user-provided material.
• Allow model taste and implementation judgment inside the boundary, but do not allow scope expansion or weaker verification.

Strong Examples

Bug Fix

/goal Fix the checkout discount bug so percentage coupons apply once per order and fixed-value coupons still stack with gift-card credit.
Verification: run the repo's checkout unit tests, add or update a regression test for percentage coupons, and run the smallest relevant lint/typecheck command from package scripts.
Constraints: do not change public coupon API names, database schema, gift-card behavior, or unrelated checkout UI copy.
Boundaries: edit only checkout pricing logic, coupon tests, and directly required fixtures; do not touch payment provider configuration or migration files.
Iteration policy: make one focused change at a time, rerun the failing check after each change, and inspect test output before changing strategy.
Stop when: the regression test fails before the fix, passes after the fix, and the relevant lint/typecheck command passes.
Pause if: payment credentials, production data, a schema migration, or a product decision about stacking rules is required.

UI Polish

/goal Make the editor toolbar usable on mobile without horizontal overflow or overlapping controls.
Verification: run the configured frontend checks, open the local app, capture desktop and mobile screenshots, and confirm no text/control overlap in the toolbar.
Constraints: preserve existing editor commands, keyboard shortcuts, saved document format, and visual identity.
Boundaries: edit only toolbar layout/components/styles and directly related tests; do not redesign the editor shell or change document serialization.
Iteration policy: adjust one layout issue at a time, rerun checks, and use screenshots to compare before/after.
Stop when: checks pass and screenshots show the toolbar fits at desktop and mobile widths with all primary controls accessible.
Pause if: the design requires removing a primary command, adding a new design system dependency, or changing product navigation.

Skill Creation

/goal Create a local agent skill named qiaomu-example-skill that packages the provided workflow into a reusable SKILL.md, README.md, agents/interface.yaml, references, and a lightweight validation script.
Verification: inspect the generated files, run YAML/JSON syntax checks if present, run the validation script on a sample output, and confirm the skill directory exists under ~/.agents/skills/qiaomu-example-skill.
Constraints: keep the skill concise, Chinese-first when appropriate, and include 向阳乔木 copyright/contact metadata; do not publish to GitHub unless explicitly requested.
Boundaries: write only under ~/.agents/skills/qiaomu-example-skill and any explicitly requested temporary verification files; do not modify existing unrelated skills.
Iteration policy: create the minimal package first, validate structure, then add only references or scripts that improve reliability.
Stop when: all required files exist, validation passes, and the README explains usage, boundaries, and local checks.
Pause if: the workflow requires private credentials, external publishing, unclear ownership, or a naming change from the user.

Anti-Patterns

Weak:

/goal Improve the app.

Better:

/goal Reduce the dashboard's first-screen clutter so a returning user can see today's key metrics and complete the primary action without scrolling.
Verification: run frontend checks, open the local app, capture desktop and mobile screenshots, and verify no text overlap or hidden primary action.
Constraints: keep existing data sources, routing, auth flow, and analytics events unchanged.
Boundaries: edit only dashboard view components, layout styles, and directly related tests.
Iteration policy: change one visual/workflow issue at a time, rerun checks, and compare screenshots after each meaningful layout change.
Stop when: checks pass and screenshots show the key metrics plus primary action in the first viewport on desktop and mobile.
Pause if: new product priorities, new analytics events, or backend API changes are required.

Avoid:

• verification like make sure it works
• boundaries like edit whatever is needed
• iteration like keep trying
• stop conditions like when it seems good
• pause conditions omitted for auth, payment, destructive operations, or private data

Goal Interview Checklist

Ask only the questions needed to write a safe and testable goal. If an answer can be inferred with low risk, state the assumption and move on.

Prefer numbered choices with defaults over open-ended questions. The user should be able to reply with 按默认 or 1B 2A 3C.

Fast Interview

Use these choices for a very vague but low-risk task:

1. 项目形态：A 新建本地 MVP（默认） / B 改现有项目 / C 先做原型 2. 范围：A 核心流程（默认） / B 加常见增强 / C 做完整产品 3. 验证：A 本地运行检查（默认） / B 真机或线上检查 / C 发布前检查

你可以直接回复：按默认，或回复类似 1B 2A 3C。

Use open-ended questions only when choices would hide an important decision.

Targeted Questions

Outcome

• Is the desired result a code change, a document, a published artifact, a clean repo state, a deployment, or a verified diagnosis?
• Who is the user or reviewer of the final result?
• Is a "first version" acceptable, or does the task require production-ready completeness?

Verification

• Are there project-provided commands: package.json scripts, Makefile targets, scripts/, CI config, Xcode schemes, pytest markers, or deployment checks?
• Does the task need live verification: browser screenshot, mobile viewport, API call, GitHub PR status, published URL, or exported file?
• Should the agent add or update tests, or only run existing checks?

Constraints

• What public behavior, file format, API contract, schema, or UX should stay unchanged?
• Are secrets, credentials, production data, user content, or private notes in scope?
• Is direct push to default branch forbidden?

Boundaries

• Which directories are allowed?
• Which files, generated artifacts, caches, or unrelated modules must not be touched?
• Are docs, tests, mocks, or fixtures allowed?

Iteration Policy

• Should the agent make one focused change and rerun checks after each change?
• After repeated failures, should it inspect logs, search docs, reduce to a minimal repro, or pause?
• Is there a budget cap for attempts, time, or tokens?

Stop And Pause

• What evidence proves completion strongly enough to stop?
• What blocker requires the user: login, 2FA, paid service, destructive deletion, legal/medical/financial decision, account ownership, or product direction?
• Should partial success be reported with remaining manual steps, or should the agent continue until the full outcome is proven?

Interview Output Shape

Recommended Executable Goal
/goal Create a first-version local MVP for the requested task, inspect project-provided commands before changing code, implement the core user-visible workflow, and keep unrelated systems unchanged.
Verification: run the smallest project-provided checks, start the local app or relevant runtime, complete the core workflow once, and capture logs/screenshots or command output as evidence.
Constraints: do not add accounts, paid services, production changes, destructive operations, or unrelated features unless requested.
Boundaries: write only inside the new project directory or the directly related existing project files.
Iteration policy: implement one focused workflow at a time, rerun checks after meaningful changes, inspect logs before retrying, and make at most 3 focused improvement rounds before reporting remaining risks.
Stop when: the core workflow is proven by runtime evidence and checks pass or missing checks are explicitly reported.
Pause if: credentials, payments, production data, destructive changes, legal/medical/financial decisions, copyrighted assets, or unclear ownership is required.

Default Reason
- [one concise reason]

Optional Adjustments
1. [decision]: A [recommended] / B [alternative] / C [higher-cost option]

You can reply
- Use defaults, or reply like 1B 2A 3C.

中文输出形状

中文用户优先用这一版。命令前缀仍然写 /goal，不要写 /目标。默认先给中文推荐执行版，再给英文兼容版，除非用户明确只要一种语言。

推荐执行版（中文，可直接复制）
/goal 基于用户需求创建第一版本地 MVP，先读取项目已有命令和约束，实现核心用户可见流程，并避免改动无关系统。
验证：运行项目提供的最小相关检查，启动本地应用或对应运行环境，完整走通一次核心流程，并用日志、截图或命令输出作为证据。
约束：不加入账号、付费服务、生产变更、破坏性操作或无关功能，除非用户明确要求。
边界：只写入新项目目录，或只修改现有项目中与该功能直接相关的文件。
迭代策略：一次实现一个聚焦工作流，每次有意义改动后重跑检查，重试前先读日志，最多做 3 轮聚焦改进后报告剩余风险。
完成条件：核心流程有运行证据证明可用，检查通过或明确说明缺少配置。
暂停条件：需要凭证、付费、生产数据、破坏性操作、法律/医疗/金融判断、版权素材或所有权不清时暂停。

默认选择理由：[一句话说明为什么这些默认选项成本最低、风险最稳或最能验证核心价值。]

可选调整
1. 项目形态：A 新建本地 MVP（默认） / B 改现有项目 / C 先做原型
2. 范围：A 核心流程（默认） / B 加常见增强 / C 做完整产品
3. 验证：A 本地运行检查（默认） / B 真机或线上检查 / C 发布前检查

你可以直接回复：按默认，或回复类似 1B 2A 3C。

Goal Draft (English-compatible)
/goal Create a first-version local MVP for the requested task, inspect project-provided commands before changing code, implement the core user-visible workflow, and keep unrelated systems unchanged.
Verification: run the smallest project-provided checks, start the local app or relevant runtime, complete the core workflow once, and capture logs/screenshots or command output as evidence.
Constraints: do not add accounts, paid services, production changes, destructive operations, or unrelated features unless requested.
Boundaries: write only inside the new project directory or the directly related existing project files.
Iteration policy: implement one focused workflow at a time, rerun checks after meaningful changes, inspect logs before retrying, and make at most 3 focused improvement rounds before reporting remaining risks.
Stop when: the core workflow is proven by runtime evidence and checks pass or missing checks are explicitly reported.
Pause if: credentials, payments, production data, destructive changes, legal/medical/financial decisions, copyrighted assets, or unclear ownership is required.

Keep the interview short. The goal is to reduce ambiguity, not make the user fill out a form.