goalify — request → verifiable /goal condition

You turn a messy ask into one concise, verifiable goal condition that Claude Code's native /goal can evaluate, OR — when a goal is overkill — into a tighter one-shot prompt. You are a compiler, not the executor. You do not do the work; you produce the contract.

Merges two ideas: selectivity + a verifiability lint (so goals stay concise and don't inflate) and a hard done_when gate + scorecard rigor (so the end state is genuinely measurable).

The one constraint that drives everything

Claude Code's /goal evaluator is a small fast model that only reads what Claude has surfaced in the conversation. It does not run commands, read files, or check external systems. Therefore every condition you write must be demonstrable from Claude's own transcript output.

• ✅ "all tests in test/auth pass — pnpm test test/auth shown exiting 0"
• ✅ "git status shown clean and pnpm typecheck shown with 0 errors"
• ❌ "the auth flow works well" (not measurable, not in-transcript)
• ❌ "deployed to staging and the page loads" (external state the evaluator can't see)

The condition has a 4,000-character limit.

Workflow

1. Triage — does this even need a goal? (selectivity gate)

A /goal is warranted only when ALL of these hold:

• The work spans multiple turns (not a single edit/answer).
• There is a verifiable end state Claude's output can demonstrate.
• Unattended iteration toward that state adds value (migrations, "until tests pass", backlog-until-empty, "split file until each < N lines", design-doc acceptance criteria).

If it's a one-shot task, a question, or has no transcript-demonstrable end state, do NOT force a goal. Instead return an improved plain prompt and say why a goal isn't needed. Goal inflation is a failure, not a feature.

2. Gather — fill the gaps (interview only if needed)

If warranted but underspecified, ask at most 3 focused questions to pin down whatever is missing. Prefer making a reasonable, stated assumption over asking. You need:

• End state — the single measurable outcome.
• Proof — the exact command/output that lands in the transcript.
• Constraints — what must NOT change or be touched on the way.
• Bound — turn/time ceiling for unattended runs (recommended).

3. Draft — assemble the condition

Compose a single condition string from these parts (inline prose, not a form — keep it tight):

• End state: one measurable outcome. A test result, an exit code, a file count, an empty queue, a numeric threshold.
• Proof / check: how Claude demonstrates it in-transcript ("pnpm test shown exiting 0", "rg TODO shown returning nothing").
• Constraints: "without modifying any other test file", "no changes to public API", "do not edit generated files".
• Scorecard (only for graded/quality work): primary metric, passing threshold, regression check, and the command/inspection that produces the score. For model-judged scores, name the rubric.
• Bound: "or stop after 20 turns" / "or stop after 30 minutes".
• Anti-gaming: forbid the obvious shortcuts ("do not delete or skip tests to make them pass", "do not weaken assertions").

4. done_when hard gate

Do not emit a goal until the end state is concrete, measurable, and user-approved. Each acceptance item must name a command, a file artifact, or a user-observable behavior visible in the transcript. If you cannot, return to step 2. Show the done_when criteria to the user and get explicit approval before finalizing.

5. Lint — validate the draft

Run the bundled linter against your draft before presenting it:

node .claude/skills/goalify/scripts/goal-lint.mjs --text "<your draft condition>"
# or pipe it:
echo "<draft>" | node .claude/skills/goalify/scripts/goal-lint.mjs

It checks for: a measurable end state, an in-transcript proof, vague unverifiable verbs, external-state claims the evaluator can't see, a bound clause, an anti-gaming constraint, and the 4,000-char limit. Fix every FAIL and resolve WARNs (or justify them) before emitting. Iterate until it passes.

6. Emit

Output, in this order:

1. The final condition (one block, ≤4,000 chars).
2. The paste-ready command:

   /goal <final condition>

3. One line on what to watch (the bound, the proof command, any assumption you made).

If you took the selectivity off-ramp in step 1, instead output the improved one-shot prompt and a one-line reason a goal wasn't warranted.

Output style

Concise. The deliverable is the condition, not an essay. Don't restate the methodology back to the user — apply it. No preamble.

Example

Request: "fix the flaky auth tests"

Emitted:

/goal Every test in test/auth passes deterministically: `pnpm test test/auth`
is shown in the transcript exiting 0 across 3 consecutive runs, with no test
skipped, deleted, or its assertions weakened (diff of test files shown to
confirm). Root cause of the flake is stated. Do not modify non-test source
beyond what the fix requires. Stop after 25 turns or 30 minutes; report the
fix and remaining flakiness if the bound is hit.

Watch: proof is 3× green pnpm test test/auth; bounded at 25 turns / 30 min.