The five-point check before a long agent run
Repo and branch, scope, open decisions, hard limits, how to split PRs, plus sane defaults for whatever nobody specified.
"I'm going to sleep. I want to see the site live tomorrow."
Eight seconds after I sent that, Claude Code replied. Its first line was:
OK, go to sleep, check the results in the morning. I'll finish this on my own with the following defaults:
Then four items: which repo and branch, what's in scope, which actions count as authorized, and which decisions it would leave for me to make in the morning.
That opening is something I require in my rules file. My global CLAUDE.md (the rules file Claude Code reads at the start of every session) has a rule that says, roughly: at the start of a long task, check five points; for anything the user didn't specify, use the defaults, and state which defaults you're using in the very first sentence.
Why at the start, not the end
When people hand off a long task, they usually say one sentence. "I want to see the site live tomorrow" doesn't say which repo, whether merging the PR is OK, or whether settings beyond the site itself can be touched. The agent has to fill those gaps either way. The only question is whether it fills them quietly or out in the open.
Fill them quietly, and you find out how it read your request when you see the results the next day. If it got it wrong, a whole night of work is wasted. Fill them in the open, and the person hasn't gone far yet. One look, one sentence, and it's fixed.
One line in that night's opening:
Authorization: deploying Pages to production and merging the PR are both covered by what you asked. Apart from pdd.bot itself, no other domains or Cloudflare settings will be touched.
All I'd said was that I wanted to see the site live. I never said it could merge the PR. That line was its reading of my sentence, written out, and the second half drew a hard line: this site only, nothing else.
What each of the five covers
The first is repo and branch. The rule says: if none was specified and the current repo doesn't match, ask first. Don't guess and run.
I've been burned here. My company's main repo is often shared by several Claude sessions at once. One time in September, another session switched branches between two of my commands, and my commit landed on local main. I only noticed when gh pr create said "No commits between main and …". After that, every task got its own git worktree (a second working copy of the same repo, with its own branch). Writing out the repo and branch at the start at least makes that kind of mix-up surface sooner.
The second is scope: do only what was named; note anything out of scope and report it, don't expand on your own. The worst outcome of a long task isn't unfinished work. It's extra work, waking up to twice as much to review as you asked for.
The third is decisions left for a human. User-facing copy, billing and pricing, blocking or restricting users, deleting data: go with the recommended option, but list each one separately in the wrap-up report. There's a lot to say about this, so it has its own essay: The veto list: the agent decides, a human can overrule.
The fourth is hard limits: without explicit authorization, no merging PRs, no deploying to production, no writing to the production database. Where authorization was given, stay within it.
That "stay within it" has a story too. One night in September I gave an overnight task one-time authorization for the whole chain: audit, open PRs, merge, deploy to the test environment. The next day, for a small daytime change, the agent opened the PR and merged it too. I told it: "I asked you to open a PR, not merge it. Fine this time, but remember next time." One authorization covers one task and doesn't carry over. Unless that's written down, an agent easily treats last time's permission as the new normal.
The fifth is PR granularity: split by risk, so changes to model behavior, billing, or data structures each get their own PR. That night's opening said "the new site is the only change, so I won't split it." Not splitting is fine. What matters is that it said why.
Defaults matter more than questions
The five points aren't five questions for the agent to ask before starting. You're going to bed; nobody would answer.
What does the work is the second half: use the defaults for anything unspecified, and say so in the first sentence. The defaults in the rules are decisions I made for myself ahead of time. The opening statement is the agent telling me which defaults apply this time. The next morning's wrap-up then has a yardstick: compare it with the opening, and you can see whether anything went out of bounds.
The one exception is the first point. When the repo or branch doesn't match, ask. A night of work in the wrong repo is worse than a night of waiting.
A version to copy
Paste this into your global or project CLAUDE.md (Codex reads AGENTS.md):
## Starting a long task
For long tasks (the user is away and wants you to finish on your own),
check five points first. Use the defaults for anything unspecified, and
state which defaults you're using in your first sentence:
1. Repo and branch: if unspecified and they don't match, ask first;
don't guess and run
2. Scope: do only what was named; report out-of-scope issues instead
of expanding on your own
3. Open decisions: user-facing copy, billing, restricting users,
deleting data: go with the recommended option, then list them under
"open to veto" in the wrap-up report
4. Hard limits: without explicit authorization, don't merge PRs, deploy
to production, or write to the production database; authorization
covers this task only and doesn't carry over
5. PR granularity: split by risk; model behavior, billing, and data
structure changes each get their own PR
The next morning's report opened with "Good morning, pdd.bot is live," followed by 5 decisions open to my veto. The opening the night before had said that's how it would be delivered.