goalify

Based on the spec or current work progress, first plan out the goal, then confirm with the user which stage the goal should run to, then based on the current Agent's capabilities start /goal, or output pasteable /goal text for the user to start. If there are questions, the goal is hard to clarify, or the user chooses a custom endpoint but does not clearly state the stop condition, ask the user before setting the goal.

Positioning

goalify isafter the requirements are already cleara tool used to drive long-horizon tasks — translating "what to do, where to read context from, where to stop" into a task description that can be driven by /goal and continuously self-driven.

Applicable：

• The spec / validation contract is complete (or the user has already made the goal clear in the conversation), and now it needs to "run for a while" to get results
• Changes span multiple steps / multiple files / multiple rounds of verify, and you want the agent not to interrupt the user at every step
• The user explicitly says "auto-run to completion / run to Ready / autopilot / self-driven"

Not applicable：

• Requirements are still in the clarification stage (Q+GUESS has not converged, the user is still reframing scope) → first go through spec-design
• One-off single-step tasks (one grep, one command, one line change) → just do it directly; goalify's plan + /goal overhead is not worth it
• The direction of change is not yet decided (the plan stage is incomplete) → first complete planning or architecture design, then wrap it into a goal as appropriate

Boundary with incremental-impl is：incremental-impl manages scale determination, splitting axes, slice granularity, and discipline within slices during the implementation stage; goalify manages wrapping an already-clear goal into a continuously executed task./goal The text should point to the spec package or current work progress, require the runtime to advance according to the auriga workflow, and call incremental-implas needed when actually entering the implementation stage; do not hard-code the slice plan in advance during the goalify stage.

Choosing goalify does not mean skipping plan

The user choosing goalify during the planning stage does not mean skipping plan. goalify only hands the work over to the self-driven /goal run; during that run there are no interactive prompts available — sothe planning method is decided by the agent itself: the agent judges on its own whether to use the built-in Plan,planning-with-files, or first run arch-design to produce an architecture design, and writes this planning responsibility into the /goal text. In other words, choosing goalify hands the decision of "how to plan, how to move forward" to the agent to complete self-driven, rather than canceling this decision.

Input sources

Prefer to get information from the spec package produced by spec-design ; look at both files:

• docs/specs/<topic>/spec.md — take the Why / What / Out of scope sections as the goal's purpose and boundaries
• docs/specs/<topic>/validation-contract.md — as the source of the goal's completion criteria;/goal the text only needs to point to this file and require item-by-item verification at runtime; do not expand and copy the VAL list into the input box

When there is no spec package, extract from the goal description in the user conversation + the current branch / commit history / PR description.

Output structure

Before generating or starting /goal , first organize the content according to the fixed structure below. The structure should be stable; the wording can be adjusted naturally according to the task:

• Goal in one sentence: State in one sentence the observable result this goal must accomplish.
• Sources of truth: List the spec, validation contract, issue, PR, current branch, or other repository sources of truth to be read; cite paths or numbers, and do not copy large blocks of body text.
• Execution constraints: Require progress according to the auriga workflow; create a branch from main, test first, and if necessary invoke during the implementation phase incremental-impl; if the runtime environment cannot directly start the goal, output paste-ready text.
• Endpoint conditions: State the endpoint selected by the user, and the specific conditions that must be met to reach that endpoint.
• Out-of-bounds stop rule: Make clear that phases after the endpoint are outside the scope of this goal; stop when the endpoint is reached and hand back to the user.
• handoff requirements: Finally, explain what was done this time, how the user should accept it, and what the user can do next; if the scope includes review, also explain the review findings, how they were handled, and the reasons for retaining any unhandled items.

Determine the endpoint phase

Before set goal, you must confirm with the user the endpoint of this goal—which phase of the auriga workflow it should advance to before stopping. Use AskUserQuestion / request_user_input to present options; common endpoints:

• Advance to PR Ready — validation complete + complete the five elements of the PR description + mark Ready for Review
• Advance to deep-review convergence — run review and fix in a loop: deep-review → fix blocking findings → commit → deep-review again, until all three are satisfied simultaneously: (1) the most recent round of deep-review reports 0 blocking findings; (2) all PR Checks pass; (3) there are no unresolved blocking review comments on the PR. non-blocking findings are still judged by severity, confidence, and change risk. There is no loop limit,/goal do not hard-code the number of rounds in the text
• Advance to merge — includes review and merge
• User-defined — the user defines the stopping condition themselves; if the stopping condition is not specific enough, ask for clarification before set goal

Make the endpoint selected by the user anexplicit termination conditionwritten into the /goal text: the goal stops when it reaches that phase and must not continue beyond it. If phases after the endpoint (review, merge, etc.) are not in scope, the goal text must state "stop here, hand back to the user."

If the goal endpoint is PR Ready or a later phase,spec-design / arch-design / planning-with-files design documents produced (spec.md、arch_design.md、findings.md、progress.md、task_plan.md , etc.) are by default archived to docs/worklog/worklog-<YYYY-MM-DD>-<branch-name>/—there are no interactive prompts during autonomous runs, so do not stop just to ask how to handle them. If you judge deletion or another disposition to be more appropriate, do not carry it out on your own; explain the reason in the handoff and hand it back to the user to decide.

The specified goal must finally give the user a handoff: explain what was done this time, how the user should accept it, and what the user can do next. If the goal scope includes review, also add the review findings, how they were handled, and the reasons for retaining any unhandled items.

How to start

/goal is the target execution mechanism; do not write one Agent's interaction method as a general rule:

• Claude Code: usually produces /goal text, which the user pastes into Claude Code's /goal command to start; the skill layer must not pretend it can directly dispatch Claude Code interface commands.
• Codex: If the current Codex environment exposes goal startup capability, the Agent can set up and start the goal on its own; if not exposed, it degrades to outputting /goal text for the user to start.

Must Not

• Must not hardcode the slicing plan in the /goal text. Slicing, scale determination, slicing axes, and granularity belong to the implementation-phase responsibilities of incremental-impl .
• Must not copy large portions of existing content from spec.md、validation-contract.md or the PR description into /goal. The repository is the source of truth;/goal only needs to point to these files and declare execution constraints.
• Must not predict which issues deep-review will find or write fix plans in advance./goal can only write the handling strategy: fix blocking findings, and judge non-blocking findings by severity, confidence, and change risk.

Examples

Good /goal text example:

目标一句话：修复 GitHub issue #139 并把相关 PR 推进到 deep-review 收敛。

事实来源：上下文以 docs/specs/<topic>/spec.md、docs/specs/<topic>/validation-contract.md 和 issue 正文为准；不要重复抄写这些文件。

执行约束：按 auriga workflow 推进：从 main 建分支，测试先行，必要时在实现阶段调用 incremental-impl 决定切片。

终点条件：终点是 deep-review 收敛：deep-review 报 0 blocking findings，所有 PR Check 通过，PR 上没有未解决的 blocking review comment。

越界停止规则：到达 deep-review 收敛后停止，不要继续合并。

handoff 要求：最后给用户 handoff，说明做了什么、验收方式、下一步建议；因为本 goal 包含 review，也要说明 review 发现、处理结果和未处理项的保留原因。

Bad /goal text example:

先做 slice 1 改 goalify 文档，再做 slice 2 改测试，再做 slice 3 开 PR。下面复制完整 spec、所有 VAL 表格和预估的 deep-review 问题清单……

The two problems with the bad example: it specifies slicing in advance during the goalify phase, and moves existing repository content into the input box, which both usurps incremental-impl 's responsibilities and wastes /goal 's limited input space.

Other rules

• If possible, proceed according to the auriga workflow