Hai Goal

Hai Goal

For Chinese readers, see SKILL.zh_CN.md. The English SKILL.md is the execution source of truth.

Overview

Use this skill before meaningful execution. Its job is to stop "running while watching" and first write a goal document: a concrete, goal-oriented plan that defines what should become true, how to phase the work, what rules govern each phase, and how completion will be verified. It also handles a second common case — the user already has a plan but names a target and asks you to rewrite the plan around that target — by preserving useful material, discarding local noise, reprioritizing phases, and producing a stronger goal document.

Core Principle

Write the goal before you go.

Do not start by coding, editing, or loosely exploring while hoping execution will clarify the target. The "run and watch" failure mode — which this skill exists to prevent — looks like:

• Start implementation before the target is stable.
• Discover missing decisions halfway through.
• Patch local problems instead of shaping the whole route.
• Let phase boundaries emerge accidentally.
• Forget to define what counts as done.
• Treat validation as an afterthought.

Most work should first become a written goal document with a verifiable goal, boundaries, phases, rules, todos, dependencies, and proof. When a plan already exists, the target takes priority over the old plan shape.

The Goal Document

A goal document is a runnable plan for execution. It answers:

• Target: what are we trying to make true?
• Boundary: what is included, excluded, and intentionally deferred?
• Current state: what exists now, with known constraints and risks?
• Route: what phases get us there?
• Rules: what constraints or working agreements govern each phase?
• Todos: what concrete tasks belong in each phase?
• Verification: how do we prove each phase, and the whole goal, is done?
• Stop conditions: when should we pause, ask, or revise the plan?

The exact output shape — including the conditional rewrite sections — lives in references/output-template.md. Read it before finalizing; do not re-derive the field list here.

A fresh goal document and a plan rewrite use the same template; the rewrite case additionally fills the Plan Rewrite Notes and Drift Diagnosis sections (see step 4).

Workflow

This single sequence covers every case — making a goal from vague intent, crafting phases for a known goal, and rewriting an existing plan around a target. Run step 4 only when an existing plan is provided.

1. Freeze the intent. What does the user want to start? What outcome would make the work worth doing? What must not be broken? What is still unknown?

2. Make the goal verifiable. Rewrite vague activity into a target outcome. Define the boundary (included, excluded, deferred). Choose the strongest available evidence source — test, metric, review, artifact, command, behavior, user signal, or trace — and a clear pass/fail rule with a confidence note, and name the judgment owner — who or what is authorized to declare it done. Quantify when useful, but do not invent fake metrics. If one intent contains multiple goals, split them.

3. Convert the goal into a goal document. Record assumptions and unresolved decisions, identify affected surfaces (docs, code, schema, API, UI, tests, workflows, links), and define what "ready to execute" means.

4. If rewriting an existing plan, re-anchor it to the target. Extract the plan's phases, todos, assumptions, dependencies, and highlighted focus points. Diagnose drift — goal drift, phase drift, validation drift, compatibility drift, cleanup drift — and decide per item what to keep, reorder, merge, or remove. Move high-risk, high-uncertainty, or high-leverage work earlier unless dependencies forbid it. Keep old wording only when it remains accurate under the new target.

5. Split into phases. Each phase should produce a reviewable state. Split by learning, risk reduction, user-visible value, system boundary, dependency order, vertical slice, decision boundary, or validation boundary — never by department, file type, arbitrary chronology, or topic heading. Avoid phases that only say "implement X" without proof.

6. Define phase rules. For each phase, state what is allowed, what is explicitly not allowed yet, what compatibility or migration rule applies, what documentation update is required, and what validation must pass before moving on. Concrete patterns to draw from:

• Do not touch implementation until the target doc is updated.
• This phase may rename internal callers directly; no compatibility shim unless a public contract exists.
• This phase may only change docs and tests, not production code.
• This phase exits only when the command/test/check passes.
• Stop if a todo requires a product decision not present in the goal document.

7. Create todos with action + surface + proof (see template). Make them concrete enough to execute without guessing, mark dependencies and blockers that affect order, and keep unrelated cleanup out unless the phase goal requires it.

8. Dry-run the route. Walk the phases in order without executing them; look for missing prerequisites, circular dependencies, vague todos, and unverified assumptions; revise the goal document before any real work. This step is what separates a goal document from generic planning.

9. Decide whether to Go. If the route is coherent, execution can start. If it carries unresolved decisions, resolve them with the right skill first (see below) and re-run the dry-run.

Output

Return a goal document, not just advice. Inline skeleton (fill every section in references/output-template.md):

# Goal Document: <work name>
## Go / No-Go            — Go / No-Go / Go after decisions, plus reason
## Target Outcome
## Goal Definition       — boundary, non-goals, deferred, verification rule, evidence source, pass criteria, confidence note, judgment owner (who/what declares it done)
## Current State
## Plan Rewrite Notes    — rewrite case only
## Drift Diagnosis       — rewrite case only
## Priority Rationale
## Assumptions and Open Decisions
## Phases                — per phase: purpose, entry condition, phase rules, todos (action/surface/proof/depends-on), exit proof, stop condition
## Dry-Run Findings
## Final Validation
## First Execution Step

Read references/output-template.md before finalizing. Omit Plan Rewrite Notes and Drift Diagnosis for a fresh goal document.

Use a different skill when

• hai-idea — it is unclear the work is worth doing at all. Validate or kill the idea before

spending effort on a goal document.

• hai-prd — the route has unresolved product or scope decisions. Settle the requirement, then

return to write the goal.

• hai-architecture — the route has unresolved structural or boundary decisions. Settle the

design, then return.

• hai-tdd — a phase is ready to implement. The goal document hands off to test-driven execution

inside each phase.

• hai-rewrite-doc — the drifted artifact is a general document, not a plan or goal document.

This skill's rewrite mode owns plans; anchor-first rewriting of everything else lives there.

What this skill is NOT

• Not generic planning detached from action — a "plan" here is a runnable goal document, and it

must be executable.

• Not a project management calendar. Dates and owners are optional unless the user asks for them.

Hai Goal Output Template

Use this template to produce the goal document before execution starts. If the user provides an existing plan and a target, use the rewrite sections to show how the plan was re-anchored.

# Goal Document: <work name>

## Go / No-Go
- **Judgment**: Go / No-Go / Go after decisions
- **Reason**: <why execution can or cannot start>

## Target Outcome
<What should be true when this work is complete.>

## Goal Definition
- **Type**: product / technical / operational / learning / quality / delivery
- **Boundary**: <what is included and excluded>
- **Non-goals**:
  - <nearby work intentionally excluded>
- **Deferred work**:
  - <related work not required for this goal>
- **Verification rule**: <how goal completion is proven>
- **Evidence source**: <test, metric, review, artifact, command, user signal, trace, behavior>
- **Pass criteria**: <clear pass/fail rule>
- **Confidence note**: <why this evidence is credible, or what proxy is being used>
- **Judgment owner**: <who or what is authorized to declare it done: system, test, metric, reviewer, user signal, or explicit acceptance>

## Current State
- <what exists now>
- <known constraints>
- <known risks>

## Plan Rewrite Notes
Use this section when rewriting an existing plan; omit it for a fresh goal document.

| Existing item | Decision | Reason |
|---------------|----------|--------|
| <phase/todo/focus point> | keep / reorder / merge / remove / rewrite | <how this serves or fails the target> |

## Drift Diagnosis
Use this section when rewriting an existing plan; omit it for a fresh goal document.

- **Goal drift**: <tasks that do not prove the target outcome>
- **Phase drift**: <phases grouped by topic rather than execution order or reviewable slices>
- **Validation drift**: <success stated as changed files instead of proven behavior>
- **Compatibility drift**: <aliases, shims, or dual paths without a named contract>
- **Cleanup drift**: <unrelated cleanup mixed into core work>

## Priority Rationale
- <why the new phase order is better for the target>
- <which risk, dependency, or leverage point should be handled first>

## Assumptions and Open Decisions
| Item | Status | Impact | Owner / Next step |
|------|--------|--------|-------------------|
| <assumption or decision> | assumed / unresolved / confirmed | <why it matters> | <how to resolve> |

## Phases

### Phase 1: <phase name>
- **Purpose**: <why this phase exists>
- **Entry condition**: <what must be true before starting>
- **Phase rules**:
  - <allowed / not allowed / compatibility / doc sync / validation rule>
- **Todos**:
  - [ ] <action>
    - **Surface**: <doc/code/API/UI/test/etc.>
    - **Proof**: <test, command, review, artifact, trace, or behavior>
    - **Depends on**: <dependency or none>
- **Exit proof**: <how phase completion is verified>
- **Stop condition**: <what should pause execution>

### Phase 2: <phase name>
- **Purpose**: <why this phase exists>
- **Entry condition**: <condition>
- **Phase rules**:
  - <rule>
- **Todos**:
  - [ ] <action with surface and proof>
- **Exit proof**: <proof>
- **Stop condition**: <condition>

## Dry-Run Findings
- <missing prerequisite, dependency issue, vague todo, or validation gap found before execution>
- <priority or phase-order issue found while reworking the plan>

## Final Validation
- <final validation command, review, trace, metric, or acceptance check>

## First Execution Step
<The first concrete action after the goal document is accepted.>

Hai Goal 中文版

本文件是中文阅读版；执行规则以 SKILL.md 为准。

触发：在真正执行前先产出一份书面 goal document——可验证目标、边界、当前状态、分阶段路线、各阶段规则、带 proof 的 todo、一次 dry-run，以及一个 Go / No-Go 判断——而不是一边写代码一边看能不能跑通。当用户想开始、go、实现、上线、构建、往前推；给了一个需要变成具体目标的模糊意图；要求把工作拆成阶段或 todo；或者丢出一份已有计划加一个目标、要求围绕该目标重写并重新锚定时使用。即使用户从没说"目标"或"计划"也要触发：开始干、开搞、我们开始吧、先别急着写代码先定个目标、把这个拆成阶段、拆 todo、落地方案、执行计划、怎么落地、立个目标、围绕X重新规划、重写这个计划、"lets just ship this"、"gonna start building now"，或只是一句意图加一句"做吧"。要先判断这件事到底值不值得做，请改用 hai-idea。

概览

在有意义的执行之前用这个 skill。它的职责是制止"一边跑一边看"，先写出一份 goal document：一个以目标为导向的具体计划，定义什么应该变成真、工作如何分阶段、每个阶段受什么规则约束、完成将如何被验证。它也处理第二种常见情况——用户已经有一份计划，但指定了一个目标并要求围绕该目标重写计划：保留有用的材料，丢弃局部噪音，重排阶段优先级，产出一份更强的 goal document。

核心原则

先写 Goal，再 Go。

不要一上来就写代码、改文件，或松散地边探索边指望执行过程会让目标自己变清楚。这个 skill 存在就是为了防止"一边跑一边看"的失败模式，它长这样：

• 目标还没稳定就开始实现。
• 做到一半才发现缺了关键决策。
• 修补局部问题，而不是塑造整条路线。
• 让阶段边界意外地"长出来"。
• 忘了定义什么算完成。
• 把验证当成事后才补的东西。

大多数工作都应该先变成一份书面 goal document，包含可验证目标、边界、阶段、规则、todo、依赖和 proof。当已有计划存在时，目标优先于旧计划的形态。

Goal Document（目标文档）

Goal document 是一份可执行的运行计划，它要回答：

• Target（目标）：我们要让什么变成真？
• Boundary（边界）：包含什么、排除什么、有意延后什么？
• Current state（当前状态）：现在已有什么，已知约束和风险是什么？
• Route（路线）：哪些阶段能带我们到达目标？
• Rules（规则）：每个阶段受什么约束或工作约定管辖？
• Todos：每个阶段有哪些具体任务？
• Verification（验证）：如何证明每个阶段、以及整个目标，已经完成？
• Stop conditions（停止条件）：什么时候该暂停、提问或修订计划？

精确的输出形态——包括只在重写场景填写的条件段落——在 references/output-template.md。定稿前先读它，不要在这里重新推导字段清单。

全新 goal document 和计划重写共用同一个模板；重写场景额外填写 Plan Rewrite Notes 和 Drift Diagnosis 两段（见步骤 4）。

工作流

这一条序列覆盖所有情况——把模糊意图变成目标、为已知目标编排阶段、围绕目标重写已有计划。只有当用户提供了已有计划时才执行步骤 4。

1. 冻结意图。 用户想开始什么？什么样的结果才让这件事值得做？什么不能被破坏？还有什么是未知的？

2. 让目标可验证。 把模糊的活动改写成一个结果目标。定义边界（包含、排除、延后）。选择最强的可用证据来源——test、metric、review、artifact、command、behavior、user signal 或 trace——并给出清晰的通过/失败规则、一条置信度说明，以及明确的判定主体——谁或什么有权宣布它已完成。有用时就量化，但不要编造假指标。若一个意图里含有多个目标，把它们拆开。

3. 把目标转成 goal document。 记录假设和未决决策，识别受影响的面（docs、code、schema、API、UI、tests、workflows、links），并定义"可以开始执行"意味着什么。

4. 若是重写已有计划，围绕目标重新锚定它。 抽取计划里的阶段、todo、假设、依赖和被强调的关注点。诊断漂移——目标漂移、阶段漂移、验证漂移、兼容性漂移、清理漂移——并逐项决定保留、重排、合并还是删除。把高风险、高不确定性或高杠杆的工作往前移，除非依赖关系不允许。旧措辞只有在新目标下仍然准确时才保留。

5. 拆分阶段。 每个阶段都应产出一个可评审的状态。按学习、降风险、用户可见价值、系统边界、依赖顺序、垂直切片、决策边界或验证边界来切分——绝不按部门、文件类型、随意的时间顺序或主题标题来切。避免只写"实现 X"却没有 proof 的阶段。

6. 定义阶段规则。 为每个阶段说明：允许什么、明确暂不允许什么、适用什么兼容/迁移规则、需要什么文档更新、进入下一阶段前必须通过什么验证。可借鉴的具体范式：

• 目标文档没更新前不许碰实现。
• 本阶段可直接重命名内部调用方；除非存在公开契约，否则不加兼容垫片。
• 本阶段只能改 docs 和 tests，不能改生产代码。
• 本阶段只有当命令/测试/检查通过时才退出。
• 若某个 todo 需要 goal document 里没有的产品决策，停下。

7. 创建带 action + surface + proof 的 todo（见模板）。让它们具体到不用猜就能执行，标注会影响顺序的依赖和阻塞项，并把无关的清理排除在外，除非阶段目标确实需要。

8. Dry-run 这条路线。 按顺序"走"一遍阶段但不真正执行；寻找缺失的前提、循环依赖、模糊的 todo 和未验证的假设；在任何真实工作开始之前修订 goal document。这一步正是 goal document 区别于泛泛规划的地方。

9. 决定要不要 Go。 若路线自洽，可以开始执行。若它还带着未决决策，先用对的 skill 解决它们（见下文），再重跑一次 dry-run。

输出

返回一份 goal document，而不只是建议。内联骨架（每一段都按 references/output-template.md 填写）：

# Goal Document: <work name>
## Go / No-Go            — Go / No-Go / Go after decisions，附理由
## Target Outcome
## Goal Definition       — 边界、非目标、延后项、验证规则、证据来源、通过标准、置信度说明、判定主体（谁/什么有权宣布完成）
## Current State
## Plan Rewrite Notes    — 仅重写场景
## Drift Diagnosis       — 仅重写场景
## Priority Rationale
## Assumptions and Open Decisions
## Phases                — 每阶段：目的、进入条件、阶段规则、todos（action/surface/proof/depends-on）、退出证明、停止条件
## Dry-Run Findings
## Final Validation
## First Execution Step

定稿前先读 references/output-template.md。全新 goal document 时省略 Plan Rewrite Notes 和 Drift Diagnosis。

何时改用别的 skill

• hai-idea —— 还不清楚这件事到底值不值得做。先验证或砍掉想法，再花力气写 goal document。
• hai-prd —— 路线里有未决的产品或范围决策。先把需求定下来，再回来写目标。
• hai-architecture —— 路线里有未决的结构或边界决策。先把设计定下来，再回来。
• hai-tdd —— 某个阶段已经可以实现了。Goal document 交棒给每个阶段内部的测试驱动执行。
• hai-rewrite-doc —— 漂移的是一般文档，不是计划/目标文档。本 skill 的 rewrite 模式只管计划；其余文档的锚点优先重写归它。

这个 skill 不是什么

• 不是脱离行动的泛泛规划——这里的"计划"是一份可运行的 goal document，必须可执行。
• 不是项目管理日历。除非用户要求，否则日期和负责人都是可选的。