How to Hand Off Night‑Shift Tasks to Claude Code: The Four Critical Loop Hand‑off Points

Four Hand‑off Points in a Claude Code Loop

Claude Code’s official blog introduces four Loop categories—turn‑based, goal‑based, time‑based and proactive. The author reframes them as four engineering hand‑off points that answer the question: At which step does a human step back, and what boundary does the system need to record?

检查怎么做 -> 做到哪算完 -> 什么时候再看 -> 能不能自己分派和收口

These correspond to Check , Stop , Wait and Responsibility Boundary actions.

Step 1 – Check

The first hand‑off is to hand over the manual verification steps that engineers normally perform before merging a PR. For a front‑end change this may include running targeted tests, linting, opening the app to verify UI changes, taking screenshots and scanning the console for regressions. The author recommends encoding this checklist as a Claude Skill so the agent does not have to infer the team’s verification habits each round.

---
name: verify-pr-change
description: Verify a PR change before reporting it complete.
---
# PR verification
For every PR‑related change:
1. Run the targeted tests for the touched area.
2. Run lint or typecheck if the repo provides one.
3. If UI changed, start the app, interact with the changed path, and save before/after screenshots.
4. Check browser console or service logs for new errors.
5. If any step fails, fix it and rerun the failed check.
6. Final output must include commands, exit codes, screenshots or logs, and remaining risks.

Storing the checklist as an asset ensures the loop has a solid foundation; otherwise the agent may finish a round without a clear standard of completion.

Step 2 – Goal (Stop Condition)

The second hand‑off defines when the loop should stop. This is expressed with a /goal command that lists concrete evidence and a braking rule. Example:

/goal 这个 PR 的 auth 相关测试全部通过，
lint 退出码为 0，
改动只限 src/auth 和 tests/auth，
最多 8 轮；
如果连续两轮没有新增证据，停下来说明阻塞原因。

The goal includes two essential parts:

Evidence – e.g., tests pass, lint exits with 0, diff stays within allowed paths.

Brake – e.g., max 8 rounds or two consecutive rounds without new evidence.

The official docs note that after each round a separate evaluation model checks whether the goal is met; it only sees what Claude has placed in the conversation, not the file system.

最后输出：
- 实际执行过的验证命令；
- 每条命令的退出码；
- 失败过哪些方案；
- 当前 diff 是否越界；
- 如果未完成，下一步需要人判断什么。

Explicitly exposing evidence prevents the loop from silently claiming success.

Step 3 – Loop (Waiting)

The third hand‑off determines the trigger timing. Tasks such as CI status, review comments or deployment state often do not change the core work but depend on external inputs. A /loop command can poll at a fixed interval or let Claude adapt the interval based on activity.

/loop 15m check CI and review comments for this PR.
Address low‑risk comments only.
For anything involving public API, auth logic, data migration, or production config, summarize the issue and wait for human review.

The author warns that treating /loop as “ask the model more often” can be costly; if events or logs can provide the needed signal, a loop is unnecessary.

Current conversation still active

Local environment still needed

External state may change

Human wants Claude to check back later

Because /loop runs in the current session, it is unsuitable for long‑running production tasks; those belong to /schedule, routines or external CI pipelines.

Step 4 – Schedule (Identity & Permissions)

When a task must survive beyond the current session or machine, the hand‑off moves to /schedule and routines. A routine stores the full configuration—prompt, repository, environment, connectors and triggers—and can be invoked by time, API or GitHub events. Crucially, the routine runs with the creator’s identity, so its permissions, connector list and network access are fixed at creation time.

Key questions the author raises for a routine:

Can it only create claude/ branches?

Which connectors are enabled?

Can it write to Slack, Linear, or only read?

What network domains are allowed?

Where are results stored for human review?

What happens on budget overrun, repeated failures, or insufficient evidence?

These concerns shift the problem from “dialogue quality” to “post‑grant execution behavior”.

Proactive Loop

The final layer is the proactive loop, which combines the previous primitives with dynamic workflows. The official example uses /schedule to collect user feedback, /goal to define completion, a Skill to record acceptance criteria, and dynamic JavaScript workflows to orchestrate multiple sub‑agents for classification, fixing and review. The author stresses that dynamic workflows can spawn many agents, increasing token consumption, conflict risk and the need for a reviewer or automated audit.

To keep the system safe, the author adds a hard rule: any loop that makes decisions must have an independent review step—human, reviewer‑agent, test suite, rule check, screenshot diff, budget threshold or whitelist.

First Night – A Conservative Path

For a pilot night‑shift run, the author suggests starting with a low‑risk PR that touches a single module, has existing tests, and whose review comments are purely mechanical. Even if Claude makes no changes, summarising CI status, review comments and risk points is valuable.

The recommended workflow:

Tag the PR with claude-watch so Claude knows to act.

Add a verification Skill (as shown earlier).

Define a /goal that limits changes to src/auth and tests/auth, requires auth tests and lint to pass, caps at 8 rounds, and stops after two rounds without new evidence.

Use /loop 15m check CI and review comments for this PR to poll while waiting.

After a stable period, draft a routine that only pushes claude/* branches, never merges, never touches production config, and leaves a draft PR or summary comment with commands, evidence, cost summary and unresolved risks.

When the night ends, the engineer should inspect the transcript, diff, command exit codes, scope of changes, failure paths and token cost. If any of these are unclear, the loop is not yet ready for hand‑off.

Practical Takeaways

The author’s conservative interpretation of Claude’s official Loop guide is:

First ensure the loop can produce clear evidence, be paused, be reviewed and be handed over.

Only then consider letting the agent run multiple rounds.

In short, successful night‑shift automation with Claude Code requires explicit hand‑off definitions, bounded authority, observable evidence and independent review at every decision point.