---
name: stepping-out
description: "Work autonomously while Andrew is away, then regroup when he's back. Trigger whenever he signals he's stepping out or wants Claude to push forward on its own: 'I'm stepping out for a while', 'stepping away', 'heading out', 'going for a walk', 'I'll be back in a bit', 'be back later', 'going heads down', 'run with this while I'm gone', 'don't wait on me', or any cue that he won't be at the keyboard to answer questions for a stretch. The point is to make real progress instead of stalling on the first decision, while saving the genuinely big calls for when he returns."
---

# Stepping out: make progress while he's away, regroup when he's back

Andrew has stepped away from the keyboard. Normally you'd check in the moment you hit something
ambiguous, and that's usually right. But right now there is no one to answer. If you stop at the
first fork, the whole session stalls until he's back. So the goal flips: **optimize for progress
over confirmation.** Push the work as far as you honestly can, take the sensible defaults on the
clear calls, and save only the genuinely hard decisions for a regroup when he returns.

This is not "guess at everything and hope." It's the opposite of two failure modes at once:
stalling on question one, *and* barreling through high-stakes decisions you shouldn't have made
alone. The skill is knowing which is which.

## Before he goes (only if something blocks the start)

If the task can't even begin without an answer, ask that one question *now*, before he's gone.
Once he's away, the rule below takes over. Don't manufacture a blocking question to delay, the
default is to start.

## While he's away

- **Work most impactful to least.** Front-load the changes that matter. If you run low on clear
  work, stop and write the summary rather than padding with busywork.
- **Keep moving.** When you hit a decision, classify it (next section) and either make the call or
  defer it, then continue. Do not halt the session to wait.
- **Commit logical chunks as you go**, each with a clear message, so the regroup reads as a
  history he can scan and partially keep or drop. Follow the repo's commit conventions.
- **Verify before each commit.** Green build and green tests. A change you couldn't verify is
  itself a "defer" item, flag it, don't pretend it's done.
- **Leave a breadcrumb trail.** A scratch notes file (e.g. `AUDIT.md`, `NOTES.md`) that you delete
  or he keeps at the regroup is a good home for the running summary as you work.

## Decide vs. defer: the one judgment that matters

For every fork, ask: *is this a call I can reasonably make, or one only he should make?*

**Make the call** (and note it) when it's:
- low-stakes or easily reversible,
- a clear best option you'd confidently defend,
- consistent with the existing code, conventions, or his stated intent,
- the obvious default given the project's stage (e.g. "we're pre-release, so drop the dead
  migration path").

**Defer it** (don't guess, don't block, just set it aside and do the obvious things around it)
when it's:
- a big or hard-to-reverse decision you don't have a strong inclination on,
- a real tradeoff with no clear winner, or one that hinges on his taste or priorities,
- anything that changes the product's behavior, public API, data, or money in a way he hasn't
  signaled,
- destructive or outward-facing (deleting things you didn't create, force pushes, anything that
  leaves the machine or can't be undone). These are always defer, never autonomous.

When you defer, **keep working around it.** Tackle the obvious things first and leave the ambiguous
one cleanly teed up for the regroup. Deferring is not stopping.

## The regroup (the actual deliverable)

When he's back, what he wants is not a wall of narration. It's a tight, scannable summary he can
review with you and decide what to keep. Lead with it. Structure it roughly:

- **What I did, most to least impactful** — one line each, with commit refs. The skimmable spine.
- **Defaults I took you might want to revisit** — the judgment calls you made so he can veto any.
- **Your call** — the deferred decisions, each with the options and your lean if you have one.
  This is the part that needed a human. Make it easy to answer.
- **Looked at and deliberately left alone** — what you considered and chose not to touch, and why.
  Saves him from re-investigating dead ends.

Keep it honest: if something is half-done, untested, or uncertain, say so plainly here rather than
burying it. The whole value of this mode is that he comes back to finished work *plus* a short,
trustworthy list of the few things only he can decide.