What’s the Difference Between Claude Code’s /loop and /goal Commands? An Interview‑Style Deep Dive

What Is Loop Engineering?

Loop Engineering is the practice of designing a sustainable feedback loop around an AI agent so that it repeatedly acts under explicit goals, tools, context, verification signals, and stop conditions until the task succeeds, fails, or requires human hand‑off.

Key engineering dimensions include:

Trigger : who or what starts the loop (manual command, schedule, CI failure, PR creation, issue update, message event).

Goal : the state that counts as completion (all tests pass, CI green, coverage threshold, screenshot matches, or a draft for human review).

Context : files, rules, history, tool results, and project conventions the agent sees each round.

Action : what the agent can do (modify code, run tests, query GitHub, read logs, open PRs, or only give suggestions).

Observation : how the agent knows a step succeeded (test output, lint, type check, screenshot, review comment, log summary).

State : recording what was tried, where it failed, and next steps in an external file, issue, Linear card, or database.

Stop : conditions for exiting, handing over to a human, or aborting due to budget or iteration limits.

What Older Concepts Does It Reuse?

Agent Loop / ReAct

Agent Loop has existed for a long time: an agent reads the current context, lets the LLM decide the next step, calls a tool or outputs an answer, writes the tool result back into the context, and repeats until a stop condition is met. ReAct follows the same reasoning‑acting alternating pattern.

Workflow / Graph / Loop

In workflow graphs a loop is simply a back‑edge, e.g., "draft → review → reject → modify → review". A reliable loop must define a continue condition, an exit condition, and safety boundaries (max iterations, timeout, token budget, degradation strategy).

Context Engineering

When loops run for a long time the context can bloat, slowing the model and causing it to lose track of earlier information. Proper context engineering decides each round which permanent project rules (e.g., AGENTS.md, CLAUDE.md) and which on‑demand materials (relevant files, test output, issue description) to load, which tool results to summarize, and when to compress or offload history.

Harness Engineering

Harness treats an agent as Model + Harness: the model does reasoning and generation, while the harness provides the execution environment, tools, feedback, sandbox, permissions, observation, and recovery. Loop Engineering sits on top of the harness, scheduling when to invoke the harness and where to store state.

Skills

Skills capture reusable knowledge that would otherwise be re‑prompted each round. By writing a SKILL.md that describes the workflow, boundaries, commands, and failure handling, the agent can load the skill once instead of re‑explaining the same rules every iteration.

MCP (Model‑Connector‑Platform)

MCP abstracts tool integration so that agents can uniformly discover and invoke connectors for GitHub, CI, Sentry, Linear, databases, Slack, etc. It does not make the model smarter but provides a stable bridge to external services, requiring additional safeguards such as permission checks, audit logs, rate limits, and human confirmation for high‑risk actions.

What’s Actually New?

The novelty is not the loop itself—TDD, CI, ReAct, and workflow graphs already contain loops—but the shift of focus from writing a single prompt to engineering the surrounding system that decides who generates the prompt, when, with what context, and how the result is verified.

Claude Code’s /loop and /goal Commands

/loop

solves the "check again later" problem. It repeatedly runs a prompt in the current session, optionally at a fixed interval (e.g., every 5 minutes) or letting Claude decide the next wait time based on observations.

/loop 5m "Check deployment status and report current state"
/loop 30m /code-review
/loop "Monitor PR CI and review comments; delay if no changes"

/goal

solves the "has the objective been achieved" problem. You provide a verifiable completion condition; after each round a small model evaluates whether the evidence satisfies the condition. If not, the loop continues.

/goal auth module all unit tests pass, only modify src/auth and tests/auth, run npm test -- tests/auth, exit code 0, max 5 rounds, stop after 2 identical failures and report
/goal migrate src/legacy components, npm run build succeeds, git diff only contains src/legacy and related tests

In practice, /loop is suited for periodic checks (deployment health, PR babysitting), while /goal fits deterministic tasks (run tests until they pass, migrate code until coverage reaches a target).

Loop Categories

Time‑driven Loop : triggered every N minutes/days; typical for PR babysitting, CI checks, log inspection; uses /loop, Codex Automations, cron.

Event‑driven Loop : triggered by CI failure, issue creation, PR update; used for fault triage, comment handling; implemented via GitHub Actions, webhooks, Claude Code channels.

Goal‑driven Loop : after each round checks whether the goal is satisfied; used for fixing tests, migrating APIs, increasing coverage; uses /goal, stop hooks, Agent SDK.

Human‑approval Loop : pauses for manual confirmation before high‑risk actions such as production config changes or permission updates.

Concrete CI‑Triage Loop Example

Trigger: every weekday at 9 am or on CI failure.

Input: read the latest CI failure, related PR, recent commit, and failure logs.

Context: load AGENTS.md and the ci‑triage skill, limiting file access to the failing module.

Action: analyze the failure reason (environment glitch, flaky test, regression, dependency issue).

Verification: if reproducible locally, run a minimal test suite; otherwise retain evidence.

State: write conclusions to TODO.md, a GitHub issue, or a Linear card.

Output: generate a short report tagging "auto‑fixable", "needs owner", or "sporadic".

Stop: never modify code, never merge, and abort after three consecutive retries.

After the first stable version, low‑risk automatic fixes can be added (e.g., formatting errors, dependency version bumps) with additional safeguards such as isolated worktrees, whitelist‑based file changes, and mandatory test verification before opening a draft PR.

When to Use Loops

CI failure triage – clear logs, test results, and deterministic pass/fail signals.

Dependency upgrades – isolated branch, test‑driven verification.

Coverage improvement – quantifiable target (e.g., raise module coverage from 62 % to 75 %).

Documentation sync – update user or API docs based on recent diffs, with human review.

Large‑scale mechanical migrations – CommonJS→ESM, API replacements, formatting fixes.

PR/Issue triage – read, classify, summarize, and prioritize.

Avoid loops for vague goals (e.g., "make the product better"), weak verification (agent self‑declares success), high‑impact changes (production DB writes, permission changes), or projects lacking tests, logs, or rollback mechanisms.

Common Pitfalls

Vague Goals

Goals like "optimize the project" lead to endless iteration. A robust goal must specify the exact condition, verification command, iteration limit, and failure‑stop rule.

/goal "auth module all unit tests pass, only modify src/auth and tests/auth; after each change run npm test -- tests/auth and show exit code; max 5 rounds; stop after 2 identical failures and report"

Agent Self‑Evaluation

Relying on the same agent to both act and judge completion is risky. Use a maker‑checker pattern: one agent implements, another validates, or rely on hard signals such as test exit codes, lint results, screenshots, or explicit human approval.

Cost Overruns

Loops can quickly consume tokens because each iteration reads files, runs tools, and writes back state. Encode budget constraints in the design: max iterations, max tool calls, daily token/price caps, and early‑stop on repeated identical failures.

Over‑Permissive Rights

Unrestricted write access lets a loop corrupt production data, push unwanted changes, or send unauthorized messages. Separate read‑only and write permissions, require human confirmation for high‑risk actions, and audit all connector usage.

Safety Levels (L0–L4)

L0 – Read‑only Summary : agent reads logs, issues, generates a report; human decides adoption.

L1 – Local Reproduction : agent runs specified tests and locates failures; human decides whether to fix.

L2 – Draft Fix : agent edits code in an isolated worktree and runs tests; human reviews the diff.

L3 – PR Creation : agent pushes a branch, writes PR description; human reviews and merges.

L4 – Automatic Merge : after policy approval the PR merges automatically; only exceptions are handled manually.

Most teams find value at L1/L2; L4 should be delayed until the task is low‑risk, fully test‑covered, and has a reliable rollback path.

Conclusion

Loop Engineering is essentially a repackaging of many existing ideas—Agent Loop, ReAct, workflow graphs, context engineering, harnesses, skills, MCP, and CI—but it forces engineers to think beyond the next prompt and design the surrounding system that governs triggers, context, verification, and brakes. Properly defined goals, tools, observations, and stop conditions turn repetitive manual work into reliable automation while keeping the loop safe and cost‑effective.