goal-draft

# /goal-draft — write a Goal the verifier can judge

You are already inside the loaded `goal-draft` skill — do not call the `skill` tool to invoke it again; start with Step 0.

You are drafting the text for `/goal set`. You are NOT doing the work the goal describes. Do not edit files, do not run the checks, do not start on the task. The only deliverable is the objective text and the `/goal set` line the user can run.

## How Goals are judged (why the format below matters)

An active Goal is re-fed to the model every turn, and its completion is judged by an independent verifier that sees ONLY transcript evidence:

- Visible assistant output and tool results count as evidence. The objective itself, user prompts, and hidden reasoning do not.
- `delivered_output` evidence proves only that text was printed. It cannot prove that tests passed, files changed, or remote state changed — those need a tool result in the transcript (an `external_fact`).
- A claim that the user confirmed, chose, or approved something needs a real user message as evidence; otherwise the completion proposal is rejected.
- Vague, subjective, or open-ended conditions never accumulate enough evidence; the loop then runs until a limit is hit.

So a good objective makes the agent PRODUCE evidence: run the named check and paste the decisive output line.

## Step 0 — should this be a Goal at all?

Say no, briefly, when the request is a normal one-shot task, needs a design or product judgement call, or has no way to be checked from the agent's own output. Offer to just do it, or to write a plan instead. A goal that cannot be checked is a prompt, not a goal.

## Step 1 — check the active Goal

Call `get_goal`. If a Goal is active, ask whether to edit it (same goal, tighter wording → `/goal edit`) or replace it (`/goal set`). Never draft a second concurrent goal.

## Step 2 — ground the draft in the workspace

Before asking anything, verify what you can with `read_file`, `glob`, and `grep_search`: that named files and packages exist, and what the real check commands are (`package.json` scripts, `Makefile`, CI workflow, test config). Use those exact commands in "Done when". Never invent paths, IDs, or commands; write `<TODO: …>` for anything you cannot confirm.

## Step 3 — at most one round of questions

Ask with `ask_user_question`, 1–3 questions in one call, each with options and a recommended default. Ask only when the answer changes the check, the scope, or the budget. Typical questions:

- Which check defines success: a test command, a build, a metric threshold, a file or state assertion?
- Which environment: local, CI, staging?
- What is off limits: which files, which actions (push, delete, publish)?
- How long to try before stopping as blocked?

Rules for the questions:

- Never ask what you could find out by reading the workspace.
- Batch them into one `ask_user_question` call; do not drip one per turn.
- Only ask things only the user can answer: what counts as done, what is off limits, how long to try.
- If you cannot find a concrete way to verify the outcome, you MUST ask, offering 2–3 candidate checks. Do not skip this and do not invent one.

If you cannot ask (headless, or a client without prompts), take the recommended default and mark it `[ASSUMPTION]` in Context.

## Step 4 — draft the objective

Use exactly these labels, in this order. Keep the whole objective on one line when you hand it over — the `/goal` parser joins lines with spaces, so number items instead of relying on newlines. Body text follows the user's language; labels stay English so the verifier can match them.

```text
Outcome: <one sentence: what is true when done>
Done when: 1) <command> exits 0 and its output shows <…> (paste that line); 2) <file/state assertion provable via read or grep>; 3) …
Must not: <files not to touch; tests/thresholds not to weaken; irreversible actions not to take>
Budget: stop as blocked after <N> turns (default 20) or <M> minutes without measurable progress
On block: propose blocked with the exact blocker and the decision a human must make; never claim completion without evidence for every Done-when item
Context: <only facts the agent cannot derive: paths, branch, environment, earlier decisions>
```

Rules of thumb:

- One Outcome. Several outcomes = several goals, or a checklist file plus a single "every item in `<file>` is checked" goal.
- Every Done-when item is binary, and at least one is tool-observable (a command with an exit code or output line, a file that exists, a grep that matches).
- Prefer "the smallest safe change in `<scope>`" over open-ended refactors.
- Put anything that must not change on the way into Must not — this is what stops the loop from deleting a failing test to "pass".
- Keep it short: everything the agent can derive from the workspace stays out. Aim for under ~1200 characters.

### Weak → strong

| Weak                          | Strong                                                                                                                                                                                                                                                                                                                                                                                           |
| ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| make checkout faster          | Outcome: checkout API p95 is below 250 ms on the documented slow path. Done when: 1) `npm run bench:checkout` exits 0 and prints a p95 below 250 (paste the line); 2) `npm test` exits 0. Must not: change the benchmark, skip tests, touch fil