Claude Code /goal: From Prompting to Goal-Driven Engineering

The hard part of delegating a coding task to an AI agent isn't getting it started. It's knowing when the work is actually finished and making sure it can prove it.

Most coding-agent workflows still follow a relatively manual interaction pattern:

Describe a task.
Let the agent investigate and implement it.
Review the result.
Identify what is missing.
Send another prompt.

This works well for interactive development, but it introduces a coordination bottleneck for larger tasks. The agent can execute commands, modify files, run tests, and inspect results, but the developer still has to drive the process forward.

Claude Code's /goal introduces a different execution model: goal-driven iteration.

Instead of treating each model response as the end of a task, you define a completion condition. Claude continues working across multiple turns until the condition is satisfied, judged impossible, or the workflow encounters an error that requires intervention.

The important shift is from specifying the next action to defining the expected end state.

What Claude Code `/goal` actually does

The /goal command establishes a completion condition for the current Claude Code session.

When you activate it, Claude starts working on the goal immediately. At the end of each turn, a separate evaluator model assesses whether the stated condition has been satisfied.

The evaluator can return three outcomes:

Not yet met: Claude continues working and uses the evaluator's feedback to guide the next turn.
Met: The goal is considered achieved and the loop terminates.
Impossible: The evaluator determines that the condition cannot be satisfied, and Claude clears the goal.

Certain unrecoverable errors also require the goal to be cleared so the developer can address the underlying problem.

Conceptually, the execution loop looks like this:

Goal → Execute → Evaluate → Continue or Stop

This is more than a longer conversation. The completion condition becomes part of the session's execution lifecycle.

An important implementation detail is that the evaluator is not an independent test runner. It evaluates the condition against the conversation and the evidence Claude has surfaced. It does not independently execute commands or inspect repository files.

That distinction matters. Claude still needs to run the relevant tests, inspect the output, and report the results. The evaluator judges whether the available evidence demonstrates completion.

The quality of the loop therefore depends heavily on the quality of the verification process.

The difference between a task and a goal

A conventional prompt usually describes an activity:

"Refactor the billing service."

That leaves several questions unanswered:

What exactly should change?
Which interfaces must remain compatible?
Which tests must pass?
What constitutes complete coverage?
When should the agent stop?

A goal should describe an observable end state.

For example, a billing-service migration could have these completion criteria:

All relevant modules have been migrated.
Existing public interfaces remain compatible.
The unit and integration test suites pass.
Type checking and linting complete successfully.
No legacy implementation remains in the target scope.
No unrelated modules have been modified.

This gives the agent a concrete target and a way to demonstrate progress. You should structure most engineering goals around three elements:

Expected outcome - Describe what should exist or be true when the work is finished.
Verification - Specify which commands, tests, or checks establish that the expected outcome has been reached.
Constraints - Define what must not change, which areas are in scope, and what limitations apply to the execution.

This is particularly important for tasks that span multiple modules or require several implementation and verification cycles.

The control loop is more important than the prompt

There is an interesting distinction between autonomous execution and reliable autonomous execution.

An agent can continue making changes without human intervention and still produce an incorrect result.

For example, a successful build does not establish that business behavior has been preserved. A passing unit test suite does not establish that integration behavior is correct. A clean linter does not establish that an implementation meets the original requirements.

The control loop needs feedback that is relevant to the actual task. For software development, this usually means combining:

Unit and integration tests.
Static analysis and type checking.
Build and compilation results.
API or contract validation.
Regression tests.
Git-based checks to identify unintended changes.
Browser or end-to-end verification for user-facing features.

The more observable the result, the easier it is for the agent to evaluate its own progress.

For deterministic requirements, I would go a step further and use scripts, CI checks, or Claude Code Stop hooks. These can enforce conditions that should not depend solely on a model's interpretation of terminal output. This leads to an important engineering principle:

Use the model to make decisions and deterministic checks to enforce requirements wherever possible.

The evaluator helps manage continuation. It should not replace a proper test and validation strategy.

`/goal` does not automatically mean unrestricted autonomy

Another important distinction is between the execution loop and tool permissions.

Claude Code's /goal controls whether the agent continues working across turns. It does not automatically grant permission to execute every command or modify every file.

For unattended execution, /goal can be combined with Claude Code's Auto mode, which handles tool approvals within the configured permission model.

These are separate concerns:

/goal determines whether more work is required.
Auto mode determines how tool approvals are handled.
Skills and hooks provide reusable workflows and lifecycle controls.
Scripts and CI provide deterministic validation.

Combining these primitives is considerably more useful than relying on a single large prompt.

There is also a practical cost consideration. Every additional turn involves more model activity, and the evaluator introduces additional usage. Claude Code exposes goal status, evaluated turns, token consumption, and the evaluator's latest reasoning through /goal without arguments.

Goals should therefore have explicit time or turn boundaries. A condition can include a stopping clause, such as stopping after a specified number of turns.

This prevents an agent from spending an unreasonable amount of time attempting to satisfy an ambiguous or fundamentally unachievable condition.

The GitHub Copilot alternative: Autopilot

GitHub Copilot offers a closely related workflow through Autopilot mode, available in GitHub Copilot CLI and the Copilot app. In Copilot CLI, you can activate it through the /autopilot command or switch modes using Shift+Tab.

Autopilot allows Copilot to work through successive model interactions without waiting for another prompt after every step. It can:

Implement changes across multiple files.
Execute commands and run tests.
Evaluate the results.
Modify its implementation based on failures.
Continue iterating until it determines the task is complete or reaches an execution limit.

For complex tasks, GitHub also supports a plan-first workflow. You can begin in Plan mode, review the proposed implementation, and then move into Autopilot execution.

This is a useful pattern because it separates two different engineering activities: deciding how the change should be implemented and allowing the agent to execute that plan.

How does it compare with Claude Code?

The two approaches solve a similar orchestration problem, but they should not be treated as identical implementations.

Claude Code /goal

Establishes an explicit completion condition.
Uses a separate evaluator model after each turn.
Provides feedback when the condition is not yet met.
Supports explicit turn or time boundaries.
Evaluates completion based on evidence surfaced in the conversation.

GitHub Copilot Autopilot

Enables autonomous continuation through successive model interactions.
Supports implementation, testing, and iterative correction.
Can be combined with Plan mode.
Provides configurable continuation and AI-credit limits.
Separates autonomy from tool permissions.

One additional feature is worth distinguishing: Copilot's /delegate sends work to the Copilot cloud agent. Unlike local CLI Autopilot, the task runs remotely, creates a branch, and can produce a draft pull request while you continue working elsewhere.

That is a different form of delegation, rather than a direct equivalent of Claude's /goal evaluation loop.

The practical comparison is therefore:

Claude /goal is particularly interesting when the completion condition itself is central to the workflow.
Copilot Autopilot provides a comparable iterative execution experience within the GitHub Copilot ecosystem.
Copilot /delegate is useful when the work should move into a remote background workflow.

When should you use these workflows?

Not every coding task benefits from autonomous execution. For short, well-understood changes, an interactive session is usually more efficient. There is little value in introducing additional evaluation cycles when the task can be completed and reviewed in one turn.

Goal-driven execution becomes more useful when:

The implementation spans multiple files or components.
The task requires several rounds of testing and correction.
There is a clear acceptance criteria set.
Progress can be measured through executable checks.
The work can continue without frequent architectural decisions from a developer.

It is less appropriate for open-ended exploration, ambiguous requirements, or tasks where important decisions require human judgment throughout the process.

In those cases, a better workflow is to use the agent interactively to clarify the problem, develop a plan, and establish acceptance criteria before enabling autonomous execution.

Human review remains necessary regardless of which tool performs the work. The final diff, test results, and unintended side effects still need engineering review.

The engineering takeaway

The evolution of coding agents is not simply about making models better at writing code. It is also about improving the systems that orchestrate them. A useful autonomous workflow needs a clearly defined target, reliable feedback, bounded execution, and an explicit stopping condition.

Claude Code /goal makes this control-loop approach available directly within a coding session. GitHub Copilot Autopilot offers a comparable way to reduce manual orchestration during multi-step development tasks.

Both are useful steps toward a more autonomous development workflow, but autonomy alone is not the measure of success.

The real objective is to reduce manual coordination without reducing engineering confidence in the result.