Goal Mode Ops

Operate Claude Code /goal as a session-scoped completion-condition loop. Use this skill to decide whether /goal is the right mechanism, write an evaluator-friendly condition, set continuation and stop boundaries, and close with evidence that the goal ended for the right reason. [DOC]

Treat /goal as a Claude Code feature whose exact availability depends on the installed version, workspace trust, hooks settings, and provider configuration. Verify local state when the answer depends on it. If current state cannot be checked, state coverage_gap instead of assuming the command is available. [DOC][CONFIG]

Supporting files:

• references/claude-code-goal-behavior.md - Canonical behavior, requirements, status, clear, resume, non-interactive use, and evaluator mechanics. [DOC]
• references/continuation-mechanism-matrix.md - Decision matrix for /goal, /loop, Stop hooks, auto mode, and scheduling. [DOC][INFERENCIA]
• references/failure-modes-and-stop-rules.md - Stuck-loop patterns, false completion risks, and manual stop rules. [INFERENCIA]
• assets/goal-condition-checklist.md - Checklist for writing measurable completion conditions. [CONFIG]
• assets/goal-safety-gates.md - Preflight and runtime gates for autonomous continuation. [CONFIG]
• assets/goal-stop-condition-matrix.md - Normal, manual, bounded, and unsafe stop conditions. [CONFIG]
• scripts/check.sh - Deterministic package check for required terms, assets, evals, and fixtures. [CONFIG]

Inputs Expected

• Claude Code route: interactive session, non-interactive claude -p, desktop, or Remote Control.
• Desired end state, validation command, evidence artifact, queue boundary, or acceptance criteria.
• Safety limits: turn cap, time cap, token/budget cap, file ownership, approval boundaries, and destructive-action exclusions.
• Local constraints: Claude Code version, workspace trust, hooks settings, provider/model config, and whether auto mode is allowed.
• Current goal state if diagnosing: /goal status, transcript reason, latest tool results, changed files, and validation output.

Outputs Expected

• A /goal <condition> string or a recommendation not to use /goal.
• A mechanism decision: /goal, /loop, Stop hook, auto mode, schedule, or ordinary single turn.
• Explicit completion proof: command exit code, test result, artifact count, issue queue state, or transcript evidence.
• Explicit continuation boundary: when Claude should keep going, ask, clear, or stop.
• Safety packet with requirements, gates, stop conditions, and any coverage_gap.

Procedure

1. Verify Fit

Use /goal only when the task has one measurable end state and can be proven from evidence Claude surfaces in the conversation. Prefer it for migrations, refactors, test repairs, acceptance-criteria implementation, backlog draining, file-splitting budgets, and other substantial work where completion can be judged after each turn. [DOC]

Avoid /goal for vague exploration, brainstorming, open-ended research, subjective polish, tasks requiring fresh human judgment after every step, destructive operations without approval, or goals whose evidence is hidden from the transcript. Use a normal prompt, plan mode, Stop hook, /loop, or scheduling instead. [DOC][INFERENCIA]

2. Check Requirements

Confirm the local command can run before relying on it. Check Claude Code version when possible; /goal requires Claude Code v2.1.139 or later. Confirm workspace trust for interactive use. Inspect settings for disableAllHooks and allowManagedHooksOnly when /goal is unavailable, because /goal is implemented through the hooks system. [DOC][CONFIG]

If non-interactive mode is requested, use claude -p "/goal ..." and treat Ctrl+C as the manual interruption path. If resuming, note that an active goal can restore with --resume or --continue, while achieved or cleared goals do not restore. [DOC]

3. Write The Completion Condition

Write the condition as a state the evaluator can verify from transcript evidence. Include:

• one measurable end state;
• the validation check Claude must run or surface;
• constraints that must remain true during the work;
• a turn, time, or budget stop clause for bounded autonomy.

Prefer: /goal all tests in test/auth pass with npm test -- test/auth exiting 0, no production files outside src/auth are modified, or stop after 12 turns and report blockers. Avoid: /goal make auth better. [DOC]

4. Run The Loop Deliberately

After each turn, expect the /goal evaluator to read the condition and conversation, return yes or no, and provide a short reason. A no decision starts another turn and gives that reason to Claude as guidance. A yes decision clears the active goal and records achievement in the transcript. The evaluator does not run tools or read files independently, so require Claude to surface command output and artifact evidence before claiming completion. [DOC]

Use auto mode only to reduce per-tool approvals inside each turn. Do not treat auto mode as a continuation mechanism; it approves tool calls but does not start a new turn. Use /loop for time-interval repetition. Use a Stop hook for reusable or deterministic post-turn logic across sessions. Use /goal for one session-scoped completion condition. [DOC]

Quality Criteria

• The recommended mechanism is justified against /goal, /loop, Stop hooks, auto mode, and scheduling.
• The condition is specific, measurable, transcript-verifiable, and bounded.
• The plan states how completion will be proven and what evidence must appear in the transcript.
• Safety gates cover version, trust, hooks settings, permissions, destructive actions, and budget limits.
• Stop conditions include success, manual clear, bounded stop, impossible condition, repeated failure, and user interruption.
• The output distinguishes task completion from loop continuation.
• Any unverified live command behavior is marked as coverage_gap.

Edge Cases

• Unverifiable condition: rewrite the condition around a command, file, artifact, or queue state that Claude can surface.
• Over-broad condition: split into one /goal per measurable end state or use a checklist with a bounded stop clause.
• Stuck loop: run /goal for status, inspect the evaluator reason, narrow the condition, add a stop clause, or /goal clear.
• False completion risk: require direct evidence in the transcript before accepting the evaluator's yes reason.
• Hooks disabled: do not promise /goal; report the settings blocker and use a non-goal workflow.
• Auto mode confusion: explain that auto mode handles tool approvals inside a turn, not turn-to-turn continuation.
• Persistent session confusion: active goals can resume, but achieved or cleared goals do not restore.
• Dangerous scope: stop before destructive, credential, production, payment, or external-send actions unless explicit approval exists.

Assumptions and Limits

• Current Claude Code behavior must be verified from official docs or the local CLI (command-line interface) before making version-sensitive claims.
• The evaluator is model-based, so it is useful for transcript-visible completion but not a substitute for deterministic tests.
• /goal keeps one current session moving; it is not a durable scheduler, project manager, or cross-session governance system.
• Provider, model, token, and policy settings may change evaluator availability or cost.

Related Skills

Unified with the verified metadata.relations frontmatter (each skill confirmed present in the plugin tree):

• scheduled-task-ops
• dynamic-workflow-forge
• agent-creator
• katas-deterministic-agent-loop
• worktree-isolation
• workflow-forge

Evidence Requirements

• Cite official Claude Code documentation when explaining command semantics.
• Cite local config or command output when claiming the current workspace can run /goal.
• Mark policy or operational recommendations as [INFERENCIA] unless directly backed by docs or config.
• Surface all validation results that the evaluator needs to judge completion.

Update-Safety Notes

• Do not enable auto mode, edit hooks, clear active goals, or start non-interactive long-running goals without explicit user intent.
• Do not hide unresolved blockers behind an evaluator yes result.
• Use assets/goal-safety-gates.md and assets/goal-stop-condition-matrix.md before proposing unattended continuation.

Contract

• Aceptación: /goal con condición de completitud verificable y gates de continuación seguros. [EXPLICIT]
• Límites: slash command sin tool en sesión — referencia, no verificable/testeable in-session. [EXPLICIT]
• Casos borde: loop atascado sin condición medible → no converge; usar Stop hook. [EXPLICIT]
• Supuestos: comportamiento de /goal por docs [DOC]. [SUPUESTO]
• Trade-off: autonomía vs control — toda continuación necesita gate explícito. [EXPLICIT]

Packet

Capas del packet, cargables bajo demanda (disciplina ICM: una capa por vez, nunca todas juntas): references/ guías de profundidad (cargar UNA por etapa) · knowledge/ cuerpo de conocimiento · prompts/ prompts listos · examples/ salida de ejemplo · agents/ subagentes del packet · templates/ plantilla de output · scripts/ automatización local · assets/ recursos estáticos.