Create Goal

Design a well-formed goal for a long-running Claude Code session. Produces docs/goals/<slug>.md and a short stop-hook condition string ready for /goal.

Modelled on the grill interview pattern — one question at a time, always with a recommended answer — but oriented toward eliciting a new goal rather than interrogating an existing artifact.

When to invoke

• User is starting a substantial multi-hour or multi-day Claude Code session.
• User says "create a goal", "set a session goal", "help me define my goal", or /create-goal.
• Before invoking /goal <condition> — to ensure the condition is well-formed and provable from the conversation transcript.

Background — the /goal stop hook

/goal <condition> sets a session-scoped stop hook. After every turn, a fast evaluator model (Haiku) reads the conversation transcript and checks whether the condition holds. If yes, the goal auto-clears and the session returns control to the user. If no, the evaluator's reason is fed back to Claude as guidance and the next turn begins. The condition is evaluated from the transcript alone — it cannot read external state unless Claude has already surfaced it in conversation.

Procedure

1. Welcome + slug. Greet the user and state what you are doing in one sentence. If $1 is supplied, use it as the goal slug. Otherwise ask for a short descriptive name (kebab-case, ≤6 words, e.g. add-auth-flow).
2. Read context before interviewing. Before asking any question, read:
   • memory/constitution.md (governing principles)
   • Any in-flight specs/<slug>/workflow-state.md (active stage + intent). If multiple specs are active, list them and ask the user which one is the target. If none are active, skip this read.
   • CLAUDE.md and AGENTS.md (tech stack, project conventions) Anything you can answer from these, answer yourself and confirm with the user rather than asking blind.

3. Interview — one question at a time, in this order. For each question: state your recommended answer with one-sentence reasoning; wait for the user's answer; record it before moving on.

   a. Objective — "What outcome should exist at the end of this session that doesn't exist today?" (Free text. Recommend the most specific intent you can infer from project context.)

   b. Scope — "Which parts of the codebase or system are in play?" (Recommend the narrowest scope that achieves the objective.)

   c. Verification method — "What command or check will prove the session is done?" (Examples: npm test, git status is clean, gh pr list --state open | grep <slug>. The evaluator reads the transcript — Claude must run this check and report the output. Recommend the most concrete, runnable check available in the project.)

   d. Success criteria — "List 2–4 specific outcomes that together signal the session succeeded." (Recommend deriving directly from objective + verification method.)

   e. Constraints — "Are there hard constraints? (files to never modify, must-use branch, time box, etc.)" (Recommend "none beyond project conventions" unless context reveals specific limits.)

   f. Out-of-scope — "What related work is explicitly excluded?" (Recommend "anything not directly advancing the objective".)

   g. Known unknowns — "What will you need to discover or decide mid-session?" (Recommend "none identified" if objective is clear; surface real gaps if context reveals them.)

   h. Session horizon — "Is this one session or multiple sittings? When should Claude stop and report rather than continue?" (Recommend "single session; stop after 20 turns or when verification passes".)

   i. Permitted autonomy — "What can Claude do without asking? What always needs approval?" (Recommend "Claude may edit files and run tests freely; opening PRs or destructive operations require approval".)

   j. Condition string. Propose a ≤2-sentence stop-hook condition based on all answers. Apply quality criteria below. Ask the user to confirm or refine before proceeding.

4. Write the goal file.
   • Slugify the goal name to kebab-case (lowercase, alphanumerics and hyphens only).
   • docs/goals/ is pre-seeded in the template. If absent, stop and report — do not attempt to recreate it.
   • Check docs/goals/<slug>.md does not already exist. If it does, propose <slug>-2.md; if that also exists, ask the user for a new slug.
   • Copy templates/goal-template.md to docs/goals/<slug>.md.
   • Fill in all frontmatter fields and all body sections from the interview answers.
   • Keep the file under 200 lines — prune self-evident content ruthlessly.
   • Hand-off note: If an active specs/<slug>/workflow-state.md was found in step 2, append a dated one-line entry to its ## Hand-off notes section: YYYY-MM-DD (create-goal): created session goal docs/goals/<slug>.md.
5. Report.

   Created goal: <title>
     path:      docs/goals/<slug>.md
     condition: "<the confirmed condition string>"
   
   To activate this goal:
     /goal <paste condition string here>

   For multi-session goals, remind the user to append a dated entry to the ## Session log section at the end of each sitting: YYYY-MM-DD: <decision or constraint discovered>.
6. Offer to activate. Ask: "Should I activate this goal now with /goal <condition>?" Do NOT invoke /goal without explicit user confirmation. Activating a stop hook changes session state; the user must choose.

Goal quality criteria

A well-formed stop-hook condition:

• Is ≤2 sentences.
• Names a concrete, verifiable outcome ("npm test exits 0 and git status is clean").
• Can be proven from the conversation transcript — Claude must have run the check and reported the output.
• Stacks multi-part checks with AND ("all tests pass AND PR is open AND lint is clean").
• Includes an optional turn or time bound ("or stop after 20 turns") when the session horizon is long.
• Avoids vague language:
  • ✗ "everything works"
  • ✗ "the feature is finished"
  • ✓ "npm test exits 0, git status is clean, and a PR is open on GitHub for this branch"
  • ✓ "all acceptance criteria in docs/goals/<slug>.md are checked off and npm run verify exits 0"

Rules

• One question per turn. Never batch questions.
• Always state your recommended answer. The user should be able to say "yes" and move on.
• Read codebase before asking — never ask a question you can answer from project context.
• Use AskUserQuestion for enum choices (session type, autonomy level options). Plain conversational questions for free text.
• Do not activate /goal automatically. The stop hook changes session state; the user must choose.
• Do not overwrite an existing goal file. Propose a variant slug.
• Keep the goal file under 200 lines — ruthlessly prune self-evident content.

When not to invoke

• The user already has a running /goal with a well-formed condition. Don't re-elicit.
• The user has an existing goal file in docs/goals/ that is still relevant — offer to activate it with /goal <condition> rather than re-running the interview.
• The session is short and tactical (a quick fix, a one-off query). /create-goal is for substantial, multi-step work.
• You are already inside a stage agent's prescribed flow that owns the conversation.