| name | write-good-goal |
| description | Use when the user asks to write, refine, draft, or validate a /goal, completion condition, objective, success criteria, definition of done, or bounded outcome for long-running agent work |
Write Good Goal
Turn the user's intent into a concrete /goal condition.
Core principle: write the goal text only. Do not start the goal, run /goal,
or begin implementation unless the user explicitly approves the final wording
and asks you to set it.
When to Use
This skill shapes the /goal wording — nothing more. Do not use it to interview
a vague feature into a plan (that is afk:grill) or to do the work the goal
describes. Reach for it when an objective needs to become a single,
transcript-checkable completion condition before a long-running run.
Process
- Identify the user's intended outcome.
- If the request is vague, see Stop and Ask below.
- Convert the intent into a single completion condition that an agent can
evaluate from its own transcript.
- Include the desired end state, proof, constraints, and a stop bound when the
work could run too long.
- Avoid goals that depend on hidden state, unstated preferences, or subjective
quality judgment.
- Match verification to the project shape. For frontend work, include
end-to-end browser evidence with
agent-browser when the app can be run
locally and the outcome is user-visible. For backend, CLI, library, or docs
work, prefer the narrow contract, test, build, or artifact proof that best
matches the change.
- Present the recommended goal without starting the work.
Good Goal Shape
Use this structure:
Achieve [specific outcome]. Prove it by [verification]. Preserve [constraints]. Stop if [limit].
If a shorter form is clearer, keep the same information but remove labels.
Stop and Ask
Ask one to three focused questions only when the goal cannot be made
verifiable from the user's message.
STOP before drafting if any of these are missing and cannot be inferred:
- Product intent: what outcome should exist when the work is done.
- Scope boundary: which repo, feature, file set, issue, plan, or artifact owns
the work.
- Source of truth: which plan, ticket, acceptance criteria, screenshot, or
failing command defines success.
- Verification: which observable evidence should prove completion when no
reasonable default fits the project shape.
Do not ask when the user gave enough detail.
Quality Checks
Before presenting the final goal, check that it is:
- Specific: names the thing to change, build, finish, or verify.
- Measurable: has a test, command, metric, count, artifact, checklist, or
observable acceptance criterion.
- Non-ambiguous: avoids words like "better", "clean", "done", or "complete"
unless they are defined by concrete evidence.
Red Flags
| Thought | Reality |
|---|
| "Make this better" | Define what "better" means and how to prove it. |
| "Finish the migration" | Name the migration scope and verification command. |
| "Fix all bugs" | Name the bug source, queue, issue label, failing command, or maximum number of issues. |
| "Clean up the code" | Define target files and measurable cleanup criteria. |
| "The agent will know when it is done" | The goal must include transcript-observable proof. |
Output
Return this compact shape:
Recommended `/goal`:
<single command or condition>
Why this works:
<one or two sentences>
Assumptions:
<short bullets, or "None">
Optional tighter version:
<only include when a safer or more bounded variant is useful>
Omit Optional tighter version when it does not add a safer or more bounded
alternative.
