write-good-goal

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

1. Identify the user's intended outcome.
2. If the request is vague, see Stop and Ask below.
3. Convert the intent into a single completion condition that an agent can evaluate from its own transcript.
4. Include the desired end state, proof, constraints, and a stop bound when the work could run too long.
5. Avoid goals that depend on hidden state, unstated preferences, or subjective quality judgment.
6. 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.
7. 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.