Pre-Goal: Turn a Vague Task into a Long-Running Goal Prompt
Overview
A goal run succeeds or fails on how precisely "done" (the Definition of Done) is defined. A vague definition forces the AI to guess what "good" means → it wraps up in three minutes with output the user never wanted. This skill guides the user to nail down five elements before launching /goal.
The Iron Law
Never skip the interview and generate the goal prompt for the user.
The task the user brings is necessarily vague ("make it better", "make it prettier") — that is exactly why they came to you. Filling in the details yourself = you defining their Definition of Done = output they will not be satisfied with.
No exceptions:
- Do not skip because "the task looks simple"
- Do not skip because "there is enough information in context"
- Do not write a full prompt first and then ask "want any changes?" — the order is confirm first, assemble second
Process
- Gather clues: Read the user's task description. Mine the codebase and conversation history for usable facts (existing test commands, performance tools, directory layout) to use as proposal material.
- Propose + confirm, element by element: For each of the five elements below, draft 1–3 concrete proposals based on the clues, then use AskUserQuestion to let the user pick or revise. Never throw open-ended questions at a blank page — you propose, the user corrects.
- Branch for subjective tasks: If the Outcome is a matter of taste (beautiful, usable, polished, engaging), plain-text criteria cannot be verified. The Verification element must produce a rubric → follow the six-step SOP in references/rubric-sop.md.
- Assemble: Once all five elements are confirmed, compose the goal prompt using the template below and show it to the user.
- Deliver: After the user approves, output the final prompt and remind them to paste it into
/goal. Do not launch /goal yourself.
The Five Elements — Quality Bar
| Element |
Question it answers |
Quality bar |
Bad → Good |
| Outcome |
What state counts as done? |
Observable, with numbers or a decidable boundary |
"Make search better" → "Search first-paint response p95 ≤ 300ms; queries with up to 2 typos still match" |
| Verification |
How is completion proven? |
A command/tool/rubric the agent can run by itself |
"Tests pass" → "npm run test:search all green, and the k6 script measures p95 ≤ 300ms" |
| Constraints |
What must NOT be done? |
Named no-go zones: file scope, forbidden actions |
"Don't break things" → "Only touch src/search/** and its tests; no new dependencies; no API schema changes" |
| Iteration Policy |
What must each round leave behind? |
Per round: what changed, verification result (data), next most promising direction |
None → "Append to NOTES.md at the end of every round" |
| Error Handling |
When should it stop and report instead of looping? |
Explicit stop conditions + report format (what was tried / where it is stuck / what is needed) |
"Deal with problems as they come" → "Verification tool won't run, or same error for 3 consecutive rounds → stop and report" |
Fast Path (when the user is in a hurry)
When the user does not want to answer item by item, you may compress the questions, but you may not guess on the user's behalf. Rules:
- Outcome, Verification, and Constraints must come from the user — these three carry the user's taste and intent; guessing them is always wrong. Compress them into a single AskUserQuestion (multiple questions) asked all at once.
- Iteration Policy and Error Handling may fall back to standard defaults, but mark them in the final prompt so the user can confirm at a glance:
- Iteration Policy default: append to
NOTES.md each round: what changed / verification result / next direction
- Error Handling default: verification tool won't run, same problem for 3 consecutive rounds with no progress, or all known approaches exhausted without reaching the target → stop and report what was tried / where it is stuck / what is needed
Goal Prompt Template
# Goal
<one-sentence done state (Outcome)>
## Definition of Done
- <verifiable condition 1>
- <verifiable condition 2>
## Verification
<command/tool to verify each round; for subjective tasks, attach the rubric and scoring method>
## Constraints
- May touch: <scope>
- Must not touch: <no-go zones>
- <other forbidden actions>
## Iteration Policy
Keep iterating until the Definition of Done is met. At the end of every round, append to <NOTES.md>:
1. What this round changed
2. Verification result (concrete data / score)
3. The next most promising direction to try
## Stop Conditions
On any of the following, stop and report "what was tried, where it is stuck, what information is needed to continue":
- <verification tool won't run>
- <same problem for N consecutive rounds with no progress>
- <all known approaches exhausted without reaching the target>
Common Mistakes
| Mistake |
Consequence |
Fix |
| Generating the prompt without interviewing |
AI defines the DoD itself; output misses expectations |
Propose, then confirm each of the five elements |
| Verification written as "ensure quality" |
The reviewer has nothing to score against; self-grades always pass |
Objective tasks get runnable commands; subjective tasks get a rubric |
| A linear phase plan instead of an iteration loop |
One pass and done; never iterates to the target |
Frame as a loop: "keep going until the Outcome is met" |
| No stop conditions |
Infinite loop burning tokens, or stuck and guessing blindly |
At least one "stop after N rounds without progress" |
| Rubric written as abstract adjectives ("stay original") |
The reviewer cannot detect violations |
Name concrete banned examples, and diversify them to avoid overfitting |
Red Flags — Stop When You Catch Yourself Thinking
- "This task is clear enough, no need to ask" → Clear to you is not clear, period. Propose and let the user confirm.
- "I'll draft a full version first, it's faster for them to edit" → Dump a whole prompt at once and the user will just say "fine". Confirm element by element.
- "Verification can be figured out during the run" → A goal without verification criteria always wraps up early.
1---2name: pre-goal3description: Use when the user is about to launch /goal (or any long-running autonomous agent task) and the task is still vaguely defined, mentions "pre-goal" / "define the goal" / "write a goal prompt", or complains that a previous /goal run drifted off course, wrapped up too early, or produced unsatisfying results. Guides the user to pin down the definition of done before launching.4---56# Pre-Goal: Turn a Vague Task into a Long-Running Goal Prompt78## Overview910A goal run succeeds or fails on how precisely "done" (the Definition of Done) is defined. A vague definition forces the AI to guess what "good" means → it wraps up in three minutes with output the user never wanted. This skill guides the user to nail down five elements before launching `/goal`.1112## The Iron Law1314**Never skip the interview and generate the goal prompt for the user.**1516The task the user brings is necessarily vague ("make it better", "make it prettier") — that is exactly why they came to you. Filling in the details yourself = you defining their Definition of Done = output they will not be satisfied with.1718**No exceptions:**19- Do not skip because "the task looks simple"20- Do not skip because "there is enough information in context"21- Do not write a full prompt first and then ask "want any changes?" — the order is confirm first, assemble second2223## Process24251. **Gather clues**: Read the user's task description. Mine the codebase and conversation history for usable facts (existing test commands, performance tools, directory layout) to use as proposal material.262. **Propose + confirm, element by element**: For each of the five elements below, draft 1–3 **concrete proposals** based on the clues, then use AskUserQuestion to let the user pick or revise. Never throw open-ended questions at a blank page — you propose, the user corrects.273. **Branch for subjective tasks**: If the Outcome is a matter of taste (beautiful, usable, polished, engaging), plain-text criteria cannot be verified. The Verification element must produce a rubric → follow the six-step SOP in [references/rubric-sop.md](references/rubric-sop.md).284. **Assemble**: Once all five elements are confirmed, compose the goal prompt using the template below and show it to the user.295. **Deliver**: After the user approves, output the final prompt and remind them to paste it into `/goal`. **Do not launch /goal yourself.**3031## The Five Elements — Quality Bar3233| Element | Question it answers | Quality bar | Bad → Good |34|---|---|---|---|35| **Outcome** | What state counts as done? | Observable, with numbers or a decidable boundary | "Make search better" → "Search first-paint response p95 ≤ 300ms; queries with up to 2 typos still match" |36| **Verification** | How is completion proven? | A command/tool/rubric the agent can run by itself | "Tests pass" → "`npm run test:search` all green, and the k6 script measures p95 ≤ 300ms" |37| **Constraints** | What must NOT be done? | Named no-go zones: file scope, forbidden actions | "Don't break things" → "Only touch `src/search/**` and its tests; no new dependencies; no API schema changes" |38| **Iteration Policy** | What must each round leave behind? | Per round: what changed, verification result (data), next most promising direction | None → "Append to `NOTES.md` at the end of every round" |39| **Error Handling** | When should it stop and report instead of looping? | Explicit stop conditions + report format (what was tried / where it is stuck / what is needed) | "Deal with problems as they come" → "Verification tool won't run, or same error for 3 consecutive rounds → stop and report" |4041## Fast Path (when the user is in a hurry)4243When the user does not want to answer item by item, **you may compress the questions, but you may not guess on the user's behalf**. Rules:4445- **Outcome, Verification, and Constraints must come from the user** — these three carry the user's taste and intent; guessing them is always wrong. Compress them into a single AskUserQuestion (multiple questions) asked all at once.46- **Iteration Policy and Error Handling may fall back to standard defaults**, but mark them in the final prompt so the user can confirm at a glance:47 - Iteration Policy default: append to `NOTES.md` each round: what changed / verification result / next direction48 - Error Handling default: verification tool won't run, same problem for 3 consecutive rounds with no progress, or all known approaches exhausted without reaching the target → stop and report what was tried / where it is stuck / what is needed4950## Goal Prompt Template5152```markdown53# Goal54<one-sentence done state (Outcome)>5556## Definition of Done57- <verifiable condition 1>58- <verifiable condition 2>5960## Verification61<command/tool to verify each round; for subjective tasks, attach the rubric and scoring method>6263## Constraints64- May touch: <scope>65- Must not touch: <no-go zones>66- <other forbidden actions>6768## Iteration Policy69Keep iterating until the Definition of Done is met. At the end of every round, append to <NOTES.md>:701. What this round changed712. Verification result (concrete data / score)723. The next most promising direction to try7374## Stop Conditions75On any of the following, stop and report "what was tried, where it is stuck, what information is needed to continue":76- <verification tool won't run>77- <same problem for N consecutive rounds with no progress>78- <all known approaches exhausted without reaching the target>79```8081## Common Mistakes8283| Mistake | Consequence | Fix |84|---|---|---|85| Generating the prompt without interviewing | AI defines the DoD itself; output misses expectations | Propose, then confirm each of the five elements |86| Verification written as "ensure quality" | The reviewer has nothing to score against; self-grades always pass | Objective tasks get runnable commands; subjective tasks get a rubric |87| A linear phase plan instead of an iteration loop | One pass and done; never iterates to the target | Frame as a loop: "keep going until the Outcome is met" |88| No stop conditions | Infinite loop burning tokens, or stuck and guessing blindly | At least one "stop after N rounds without progress" |89| Rubric written as abstract adjectives ("stay original") | The reviewer cannot detect violations | Name concrete banned examples, and diversify them to avoid overfitting |9091## Red Flags — Stop When You Catch Yourself Thinking9293- "This task is clear enough, no need to ask" → Clear to you is not clear, period. Propose and let the user confirm.94- "I'll draft a full version first, it's faster for them to edit" → Dump a whole prompt at once and the user will just say "fine". Confirm element by element.95- "Verification can be figured out during the run" → A goal without verification criteria always wraps up early.
chenwei791129