Putting Claude Code in a loop: /goal, /loop, and hooks

Loop engineering becomes interesting when it leaves theory behind. In Claude Code, you can ask a session to pursue a goal, rerun a prompt at regular intervals, or consult an evaluator before stopping.

These mechanisms look similar on screen: Claude answers, then another action starts. But they answer different questions. The first waits for a condition. The second waits for a clock. The third waits for a decision.

Three mechanisms, three triggers

This distinction is the starting point. Using /loop for a compilation goal is possible, but time is not the right signal. Using a hook for a simple periodic check is just as disproportionate.

/goal: continue until a condition is met

/goal is the mechanism closest to loop engineering. You give it a measurable success condition, and Claude keeps working without you having to type “continue” after every turn.

/goal all tests in test/auth pass,
lint exits 0,
and no other test file is modified

After each turn, a separate evaluation model checks whether the condition is satisfied. If it is not, the reason is sent back to Claude and another turn starts.

The condition should be written as something the conversation can demonstrate. The evaluator does not run commands or independently read your repository. Claude therefore needs to run the tests and make their results visible in the transcript.

A good condition usually contains:

• a measurable final state;
• the expected command or proof;
• constraints that must not be violated;
• a turn or time limit.

/goal npm test -- auth exits 0,
production files stay inside src/auth,
and stop after 12 turns maximum

Use /goal without an argument to see the loop status. Use /goal clear to remove it.

/loop: rerun a task on a schedule

/loop answers a different situation: an action should be repeated at regular intervals. It is useful for watching a deployment, checking a pull request, or following a long-running build.

/loop 5m check whether the deployment is finished and tell me what happened

Both the interval and the prompt are optional. The current documentation also allows Claude to choose the delay dynamically between checks:

/loop check CI and handle new review comments

The difference from /goal is simple: /loop is triggered by time, not by a failed condition. It is tied to the local session and is not a production scheduler. For overnight or durable work, use a scheduled task, GitHub Actions, or a dedicated routine instead.

The Stop hook: your own evaluator

A Stop hook runs whenever Claude finishes a response. It can run a deterministic script, ask a model for a decision, or, with an agent hook, inspect the repository and run commands before allowing Claude to stop.

Here is a simplified prompt hook:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "prompt",
            "prompt": "Check whether all tasks are complete.
If not, respond with {\"ok\": false, \"reason\": \"what remains to be done\"}."
          }
        ]
      }
    ]
  }
}

If the evaluator says the work is not finished, its reason becomes the next signal sent to Claude. For verification that really needs to read files or run tests, an agent hook is more appropriate than a simple prompt hook.

I would reserve hooks for cross-cutting rules: preventing premature stops, enforcing a security check, or protecting a branch. For a one-off task, /goal is easier to read and control.

Which mechanism should you choose?

• You want to reach a verifiable final state: use /goal.
• You want to check an external state regularly: use /loop.
• You want a rule at the end of every turn: use a Stop hook.
• You want work outside the session: use a scheduler or CI.

A sensible first workflow

For a feature in an application, I would start simply:

1. Write the goal and acceptance criteria in a work file.
2. Run /goal with a precise condition and a turn limit.
3. Ask Claude to show the validation commands and their results.
4. Read the evaluator’s reason when the loop continues.
5. Interrupt if the next step requires a product decision or a risky change.

Once this workflow is understood, add hooks. Not before. Orchestration complexity should solve a real problem, not merely make the system look more impressive.

The examples above follow the official /goal documentation, the /loop documentation, and the hooks guide.