to-goal

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

To Goal

生成执行目标

Compile existing planning and repository evidence into an execution goal. Do not implement, mutate the tracker, create a branch, or modify files.

将现有规划和仓库证据整理为执行目标。请勿进行实现操作、修改追踪器、创建分支或修改文件。

Source of truth

事实来源

Read

../goal-crafter/SKILL.md

only for compiled-handoff mode, Phase 2 harness formats, Phase 3's four self-checks, and Special Rules (never re-interview; one verifiable condition per checkbox). Skip Phase 1 and Examples. This skill owns context gathering, frontier selection, readiness checks, and execution handoff. Do not reopen decisions already made by

to-spec

to-tickets

, or

triage

仅在compiled-handoff模式下阅读

../goal-crafter/SKILL.md

，查看Phase 2的 harness 格式、Phase 3的四项自我检查以及特殊规则（绝不重新询问用户；每个复选框对应一个可验证条件）。跳过Phase 1和示例。本Skill负责上下文收集、前沿工单选择、就绪检查和执行交接。请勿重新讨论

to-spec

、

to-tickets

或

triage

已做出的决策。

Accepted inputs

接受的输入

Resolve one of:

no argument: inspect the configured tracker and select the current unblocked, agent-ready frontier ticket;
a ticket number or URL: read that ticket in full;
a parent spec issue: read the spec, sub-issues, and blocking graph, then select its current frontier;
a local spec or ticket path: read the complete file and any directly referenced local planning document (local tracker:
```
.scratch/<feature>/spec.md
```
and one file per ticket under
```
.scratch/<feature>/issues/<NN>-<slug>.md
```
);
```
--all <parent>
```
: generate one dependency-ordered cross-ticket goal.

Always read ticket comments. For a tracker parent, use native sub-issue and dependency relationships when available; otherwise use explicit blocker text. Do not infer that a ticket is ready merely from its label.

If no argument yields several frontier tickets, list them and ask the user to choose one. Do not silently combine them. If a requested ticket is blocked, report its blockers and do not generate an implementation goal.

For a spec with no tickets, generate a goal directly only when the entire work fits one fresh context window. If it is multi-session work, route it through

to-tickets

instead of bypassing the context boundary.

处理以下任意一种输入：

无参数：检查配置的追踪器，选择当前未阻塞、Agent就绪的前沿工单；
工单号或URL：完整阅读该工单；
父规范议题：阅读规范、子议题和阻塞关系图，然后选择其当前的前沿工单；
本地规范或工单路径：完整读取文件以及任何直接引用的本地规划文档（本地追踪器：
```
.scratch/<feature>/spec.md
```
和
```
.scratch/<feature>/issues/<NN>-<slug>.md
```
下每个工单对应一个文件）；
```
--all <parent>
```
：生成一个按依赖顺序排列的跨工单目标。

务必阅读工单评论。对于追踪器父项，若有原生子议题和依赖关系则使用该关系；否则使用明确的阻塞文本。请勿仅通过标签推断工单已就绪。

若无参数时出现多个前沿工单，请列出它们并让用户选择其一。请勿静默合并。若请求的工单被阻塞，仅报告阻塞因素，不生成实现目标。

对于无工单的规范，仅当全部工作可容纳在一个新上下文窗口中时，才直接生成目标。若为多会话工作，请将其路由至

to-tickets

，而非绕过上下文边界。

Gather current evidence

收集当前证据

Before drafting:

Read the complete source spec and selected ticket, including acceptance criteria and comments.
Inspect the repository instructions and relevant design vocabulary.
Inspect the current branch, HEAD, worktree status, recent commits, and diff. Record the pre-implementation HEAD as the code-review fixed point.
Compare current behavior and tests with every acceptance criterion.
Classify criteria as evidenced complete, demonstrably incomplete, or unverified. A commit message is not evidence.
Discover validation commands from the repository's own scripts, CI, documentation, and existing tests.
Preserve user-established permissions and workspace boundaries from the source context.

Keep this work read-only. Do not create status artifacts merely to build the goal.

起草前：

完整阅读源规范和选定工单，包括验收标准和评论。
查看仓库说明和相关设计术语。
查看当前分支、HEAD、工作区状态、最近提交和差异。将实现前的HEAD记录为代码审查的固定点。
将当前行为和测试与每个验收标准进行对比。
将标准分类为已验证完成、明确未完成或未验证。提交消息不算作证据。
从仓库自身的脚本、CI、文档和现有测试中发现验证命令。
保留源上下文中用户设定的权限和工作区边界。

此工作仅为只读操作。请勿仅为构建目标而创建状态工件。

Select scope

选择范围

Default to exactly one frontier ticket. The generated goal must fit one fresh context window and must not attract work from downstream blocked tickets.

For

--all

preserve the complete dependency order;
distinguish the current frontier from future work;
carry forward partially completed work without treating it as done;
warn that the goal requires a persistent harness capable of context renewal;
never present
```
--all
```
as the normal Matt workflow.

默认仅选择一个前沿工单。生成的目标必须能容纳在一个新上下文窗口中，且不得涉及下游阻塞工单的工作。

对于

--all

：

保留完整的依赖顺序；
区分当前前沿工单与未来工作；
延续部分完成的工作，但不将其视为已完成；
警告该目标需要能够更新上下文的持久化harness；
切勿将
```
--all
```
作为常规Matt工作流程呈现。

Recommend execution capacity

Readiness checklist

就绪检查清单

This list is for this compiler; do not put it in the paste block.

Required propositions — tick every item before drafting. If any of these is unchecked, stop and do not invent a goal.

<readiness-checklist>

Source is agent-ready: every required product decision and completion condition is in the evidence. If not, stop, name what is missing, and do not reopen a planning interview.
Ticket is unblocked. If blocked, report the blockers only; do not generate an implementation goal.
Exactly one frontier. If several, list them and ask the user to choose; do not silently combine them.
Pre-implementation HEAD recorded as the code-review fixed point.
Every acceptance criterion classified: evidenced complete / demonstrably incomplete / unverified.
Validation commands discovered from the repository's scripts, CI, documentation, or existing tests.
Permissions and workspace boundaries from the source context preserved.
Every completion criterion independently decidable (
```
goal-crafter
```
Phase 3: no "looks good").

</readiness-checklist>

Conditional prohibitions — satisfied by default on the single-ticket path. Do not tick them; an unchecked item here is not a stop.

If this run is not
```
--all
```
: skip. If it is
```
--all
```
: the user asked for it explicitly, and the goal is labeled cross-context.
Spec with no tickets: compile a goal only when the entire work fits one fresh context window; otherwise route through
```
to-tickets
```
.

此清单供本编译器使用，请勿放入粘贴块。

必填项 — 起草前需勾选所有项目。若有任何一项未勾选，请停止操作，不要生成目标。

<readiness-checklist>

源已就绪：所有必要的产品决策和完成条件均已包含在证据中。若未满足，请停止操作，说明缺失内容，且不要重新开启规划访谈。
工单未被阻塞。若被阻塞，仅报告阻塞因素；不生成实现目标。
仅有一个前沿工单。若有多个，请列出并让用户选择；请勿静默合并。
已记录实现前的HEAD作为代码审查固定点。
所有验收标准均已分类：已验证完成 / 明确未完成 / 未验证。
已从仓库脚本、CI、文档或现有测试中发现验证命令。
已保留源上下文中的权限和工作区边界。
每个完成条件均可独立判定（
```
goal-crafter
```
Phase 3：无“看起来不错”的模糊表述）。

</readiness-checklist>

条件禁令 — 在单工单路径下默认满足。无需勾选；此处未勾选的项目并非终止信号。

若本次运行未使用
```
--all
```
：跳过。若使用了
```
--all
```
：用户已明确请求，且目标已标记为跨上下文。
无工单的规范：仅当全部工作可容纳在一个新上下文窗口中时才生成目标；否则路由至
```
to-tickets
```
。

Goal template

目标模板

Required fields must be filled. Conditional fields appear only when they apply. Use the harness envelope from

goal-crafter

Phase 2. When the harness is not explicit, infer it from the invocation context; if that is impossible, emit this generic block so it can be pasted into a fresh coding-agent session. Current state, Execution order, and the prefilled constraints stay required even when the harness names fewer sections.

Unless the source context explicitly overrides a default constraint, keep that line verbatim. When it does override, rewrite that line and name the source.

If current implementation is partial, put verified finished work in Current state and every remaining gap in Completion criteria. Never hide a known gap or tell the next agent to redo verified work.

Inherit every ticket criterion without changing product decisions. Do not relist evidenced-complete work as to-do.

<goal-template>

必填字段必须填写。条件字段仅在适用时出现。使用

goal-crafter

Phase 2的harness信封。若harness未明确指定，从调用上下文推断；若无法推断，输出此通用块以便粘贴到新的编码Agent会话中。即使harness指定的部分更少，当前状态、执行顺序和预填充约束仍为必填项。

除非源上下文明确覆盖默认约束，否则保留该行原文。若有覆盖，请重写该行并注明来源。

若当前实现为部分完成，将已验证的完成工作放入当前状态，将所有剩余缺口放入完成标准。切勿隐藏已知缺口或指示下一个Agent重做已验证的工作。

继承所有工单标准，不修改产品决策。请勿将已验证完成的工作重新列为待办事项。

Goal

目标

<单工单范围的成果>

Current state

当前状态

Branch:
HEAD (review fixed point):
Dirty / untracked files to protect:
Evidenced complete:
Known gaps:
Existing failures:

分支：
HEAD（审查固定点）：
需保护的未提交/未追踪文件：
已验证完成：
已知缺口：
现有失败项：

Execution order

执行顺序

<选定工单的最短依赖路径>

Completion criteria

完成标准

<ticket criterion>
Ran the smallest applicable validation:
```
<command>
```
Ran the applicable code-review flow against the recorded pre-implementation fixed point
Commit only after all selected-ticket criteria pass and the source context or user authorizes a commit
Workspace is clean except for this ticket's changes (unrelated dirty or untracked files untouched)

<工单标准>
运行最小适用验证：
```
<command>
```
针对记录的实现前固定点运行适用的代码审查流程
仅在所有选定工单标准通过且源上下文或用户授权提交后再提交
工作区除本工单的变更外保持干净（不修改无关的未提交/未追踪文件）

Constraints

约束条件

do not push, open a pull request, merge, close issues, or edit tracker state
do not modify unrelated dirty or untracked files
do not implement downstream tickets early
use the pre-agreed test seam and test behavior rather than implementation details
always run the smallest applicable validation during development
require broad or full validation only when repository gates demand it, the user explicitly requests it, or the change affects core logic, security, data consistency, concurrency, or a known bug regression
for low-risk non-behavioral work, allow tests to be skipped only when there is no relevant test seam or non-test validation is sufficient; still require the smallest applicable validation, and require the execution report to state why tests were skipped and identify any residual risk
run the applicable code-review flow against the recorded pre-implementation fixed point before committing
commit only after all selected-ticket criteria pass and the source context or user authorizes a commit
Validation breadth: smallest | full Reason:

请勿推送、开启拉取请求、合并、关闭议题或修改追踪器状态
请勿修改无关的未提交/未追踪文件
请勿提前实现下游工单
使用预先约定的测试接缝和测试行为，而非实现细节
开发期间始终运行最小适用验证
仅当仓库要求、用户明确请求，或变更影响核心逻辑、安全、数据一致性、并发处理或已知bug回归时，才要求进行全面验证
对于低风险非行为类工作，仅当无相关测试接缝或非测试验证足够时，才允许跳过测试；仍需运行最小适用验证，且执行报告需说明跳过测试的原因并识别任何剩余风险
提交前针对记录的实现前固定点运行适用的代码审查流程
仅在所有选定工单标准通过且源上下文或用户授权提交后再提交
验证范围：最小 | 全面理由：

Context

上下文

Source ticket / spec:
Design docs:
Agreed test seam:
Inspect first (commands / files):

</goal-template>

源工单/规范：
设计文档：
约定的测试接缝：
优先检查（命令/文件）：

</goal-template>

Deliver

交付内容

Output only:

the ticked Readiness checklist — not part of the paste block;
the filled goal template, copy-pasteable;
the filled Session recommendation.

<session-recommendation>

Session: fresh | persistent goal loop
Capability: Lightweight | Standard | Advanced
Intensity: Low | Medium | High
Reason: <one sentence from observed task risk and complexity>
Optional model mapping: <only when the target harness and its model choices are known>

</session-recommendation>

Recommend a fresh session that directly executes the goal after

to-tickets

triage

. The ticket, spec, branch, and recorded fixed point carry the context; do not send the fresh session back through an interview or create a handoff document unless essential context exists only in the conversation and was never published.

For

--all

, explicitly label the goal as cross-context and recommend a persistent goal loop. For a single frontier ticket, recommend a normal fresh implementation or goal-loop session. If the harness automatically invokes

/implement

, the goal remains the execution contract and

/implement

must not re-interview or restate it. Keep the recommendation portable: for example, say

Advanced + High

for an authorization migration with concurrency invariants, not

use Model X

unless Model X is known to be available.

仅输出：

已勾选的就绪检查清单 — 不属于粘贴块；
已填写的目标模板，可直接复制粘贴；
已填写的会话推荐。