define-goal

Define Goal

Help the user turn a fuzzy intention into a single, verifiable completion condition for the native /goal skill — by asking, not assuming.

This skill runs a short, structured interview with AskUserQuestion, drafts a candidate condition plus a short task brief, refines them with the user in a tight loop, saves the result to a file, and then offers to run /goal <condition>.

What the native /goal actually is (read this first)

/goal is not a "do this project" command. It is an autonomous run-until control built into Claude Code:

• /goal <condition> — sets a success condition. Claude then works autonomously and keeps going until the condition is met (Goal achieved) or it determines the condition cannot be achieved (Goal could not be achieved).
• /goal — shows status (Goal active / No goal set).
• /goal clear — stops early / clears the active goal.
• The goal persists and is restored on resume.
• /goal requires a trusted workspace and hooks enabled (it won't run if disableAllHooks / allowManagedHooksOnly is set).

Because /goal loops until the condition flips true, the single most important deliverable of this skill is a condition that is observable and unambiguously checkable — Claude must be able to tell, on its own, the moment it's done. Vague conditions cause /goal to run forever or stop too early.

When to use

• The user wants to kick off an autonomous /goal run but their target is fuzzy.
• The user asks what their /goal condition should be, or to refine one.
• A previous /goal run looped without converging or stopped prematurely because the condition was vague — redefine it.

When NOT to use

• The condition is already crisp and checkable — just help them run /goal <condition>.
• The task is a one-off you should simply do now (no autonomous loop needed).

Core principle

Ask, reflect, draft, show, repeat. Never invent requirements the user hasn't confirmed. Drive every clarification through AskUserQuestion. The goal of the interview is to be able to write a condition that Claude itself can verify is true or false at any moment.

Process

1. Capture the seed

Read the invocation args and recent conversation. Restate, in one sentence, what the user seems to want /goal to accomplish, and confirm. If there's nothing to go on, ask one open question to get the seed.

2. Clarify through structured questions (AskUserQuestion)

Use AskUserQuestion. Group related questions into rounds (up to 4 per call). For each question give a short header (≤12 chars), a clear question, and 2–4 concrete options with helpful descriptions (the tool always adds "Other" and free-text, so don't add your own). Use multiSelect: true when options aren't mutually exclusive, and put a recommended default first labelled "(Recommended)".

Cover these dimensions (skip what's already answered; infer the obvious and show it back as an assumption rather than asking):

1. Outcome — what state of the world means "done"?
2. Verifiable signal — how will Claude know the condition is met? A passing test, a command exit code, a file existing/containing X, an HTTP 200, a metric threshold, a checklist all ticked. Push hard here — this becomes the condition.
3. Scope / boundaries — what's in, and what's explicitly out.
4. Constraints & guardrails — must / must-not, tech, style, files to avoid.
5. Give-up criteria — what makes the goal unachievable so /goal should stop and report rather than loop (e.g. "if it needs prod credentials, stop").
6. Context & resources — repos, paths, commands, docs the loop will need.

Run one round at a time; reflect on the answers before the next round. Stop when you can write a condition the agent can self-check. Two to four rounds is typical.

3. Draft the condition + brief

Produce two things:

• The condition — one crisp sentence stating the observable, checkable success state. This is the literal /goal argument. Prefer concrete checks:
  • Weak: "the API works"
  • Strong: "pytest -q exits 0 and curl -s localhost:8000/health returns {\"status\":\"ok\"}"
• The brief — short supporting context (task, constraints, give-up criteria, resources) that helps the autonomous loop pursue the condition well.

Mark anything you inferred with (assumption) so the user can correct it.

4. Review & refine loop

Show the condition and brief, then use AskUserQuestion to ask if it's ready:

• "Looks good — finalize (Recommended)"
• "Sharpen the condition / make it more checkable"
• "Adjust scope or guardrails"
• "Adjust give-up criteria"

Apply only the requested change and show it again. Loop until the user finalizes. Keep tightening the condition toward something binary and self-verifiable.

5. Finalize & write to file

On finalize:

1. Derive a short kebab-case slug from the outcome (e.g. green-ci).
2. Create ./.goal/ in the current working directory if needed.
3. Write the brief + condition to ./.goal/<slug>.md using the template below. If the file exists, confirm overwrite or add a numeric suffix.
4. Print the saved path, the full brief, and the exact /goal <condition> command back to the user.

6. Hand off to /goal

Use AskUserQuestion:

• "Run /goal <condition> now (Recommended)" — invoke the native /goal skill with the finalized condition.
• "I'll run it myself later" — show the exact command and the saved file path.
• "Keep refining" — return to the refine loop.

Before launching, sanity-check the prerequisites: the workspace must be trusted and hooks enabled, or /goal will refuse. If they aren't, tell the user what to fix (accept the trust dialog on restart; ensure hooks aren't disabled).

Saved file template

# Goal: <one-line outcome>

## Condition (the /goal argument)
> <single, observable, self-checkable success condition>

Run it with:
`/goal <single, observable, self-checkable success condition>`

## Brief
<2–4 sentences: what to do to reach the condition.>

## Verification
<Exactly how the condition is checked — the command, file, endpoint, or metric
that flips it true.>

## Guardrails
- <must / must-not, files to avoid, style constraints>

## Give up if
- <conditions that make this unachievable; /goal should stop and report>

## Context & resources
- <repos, paths, commands, docs the loop needs>

## Assumptions
- (assumption) <anything inferred; correct me if wrong>

Tips

• A great /goal condition is binary and machine-checkable. If you can't describe how Claude would verify it without a human, keep refining.
• Bake the check into the condition itself (the command/exit code/response), not just a description of the desired state.
• Always define give-up criteria — without them an impossible goal loops.
• Favor fewer, sharper questions. Each round should make the condition crisper.
• Reflect the user's own words back in the brief.