Delegate approved work

When you'd do this

• The design is settled and the remaining work is mechanical: apply the same change to several modules, finish the tests, update the consumers of an API you have already changed.
• You have a meeting, a review or lunch coming up, and an approved plan with tasks still open.
• A change spans several repositories and you want each part to run with its own test command, in order, without confirming each step.
• You lead a team and want agents to make progress on agreed work while keeping every change reviewable before it is committed.
• Work is split across teammates and you want to see who is running what, in which repository, before you start your part.

Before you start

• CodeZero installed in VS Code with Claude Code, Codex, GitHub Copilot or Cursor as the agent, signed in to your organisation, with the relevant repositories indexed.
• The repositories the plan will edit checked out locally on the branch you want the work on, with dependencies installed so the verification commands can actually run. CodeZero offers to clone a repository when a plan needs one that is missing.
• A clean or deliberately staged working tree. Coffee Mode leaves its changes in the working tree, so starting from a clean tree makes the diff you review on your return exactly the agent's work.
• Vörr is not needed to delegate work. It is useful before and after, from Claude, ChatGPT or another MCP assistant, for production context such as errors, CI results or a deploy feed. It takes no part in running the plan. ChatGPT needs a paid plan with Developer mode turned on.

Operations

Delegating is a sequence: choose how the request is handled, get the plan into a state that needs no further decisions, approve it, run it, and review what came back. The operations below follow that order, then cover runs that stop early, work shared across a team, and work that should not be delegated at all.

Choose the mode for the request

1. Look at the mode chip in the CodeZero session header. Pick by how much review the work needs, not by how large it looks.
2. Auto, the default, decides whether planning is needed. It keeps a request direct only when the change is tightly scoped, touches little code, adds no new configuration or API surface and needs no design decision. Each edit or command is still shown for confirmation.
3. Planned sends every change through a plan. Source files and commands are blocked until the plan is reviewed and approved, so the agent can only investigate before then.
4. Normal creates no plan. The agent proposes edits and commands and you confirm each one.
5. In Auto, prefix a single message with /plan to force planning for it, or /quick to force a direct change.

Only plan-based work can be delegated. If you expect to step away, use Planned or /plan from the start rather than converting a long Normal session afterwards.

Get the plan into a delegable state

1. Describe the change. In Planned or Auto, CodeZero investigates the existing implementation before proposing anything, using the organisation index for repositories that are not checked out.
2. Answer every clarification question. CodeZero asks when the code cannot answer a product or implementation decision rather than planning around an assumption. An open question is also what stops Coffee Mode from starting.
3. Check that the plan names every repository it will edit. Edits there go ahead; an edit in a repository the plan does not name asks you first while you are at the keyboard.
4. Check the phases and tasks: each task should be one coherent change, with dependencies where one genuinely cannot start before another.
5. Check the verification commands. After approval these are the only commands that run without asking, so they should be commands the repository actually has (its package scripts, Makefile or CI config), scoped to what the change touches.

A delegable plan leaves the agent nothing to decide: the approach, the repositories, the order of tasks and what "done" means are all written down. If you would expect the agent to ask you something halfway through, that question belongs in the plan now.

Approve the plan

1. Open the plan in Tasks. It shows warnings, phases and the exact commands it allows.
2. Read it as you would read a design note from a colleague: the goal, the approach, the repositories, the tasks and the checks.
3. Approve it yourself. The agent cannot approve its own plan.
4. If something is wrong, ask for a revision rather than approving and correcting later. A revised plan is reviewed again before anything runs.

Approval is the unit of permission. It opens write access to the plan's repositories and allows the declared commands; it does not allow anything else.

Run one task, or Run all

1. To stay involved, run an individual task from Tasks and review its result before starting the next. This suits the first task of an unfamiliar change, where you want to check the pattern before it is repeated.
2. To work through the rest in order, use Run all. Tasks tracks pending, in-progress, completed and blocked work and respects the dependencies between them.
3. While you are at the keyboard, the declared verification commands run without asking. Any other command still asks for your confirmation, and an edit outside the plan's repositories asks first.

A good result for each task is the change, the verification command it ran with its real output, and the task marked complete with that evidence. A task marked complete with no command output deserves a second look.

Hand it to Coffee Mode

1. Check the two preconditions on the current tab: the plan is approved, and every clarification question for it is answered. Coffee Mode will not start otherwise, and tells you which condition is missing.
2. Turn Coffee Mode on with the coffee icon. CodeZero notes how many tasks are outstanding and what it will and will not do.
3. Step away. Click the coffee icon again to end the break early.

What happens while you are away

• CodeZero works through the remaining approved tasks in order.
• Normal edits and recoverable commands proceed without asking. Edits stay within the organisation's repositories checked out on this machine, on the branch the plan is working on; anything outside them is refused.
• If a question comes up during execution, the agent chooses the safest option and records the decision for you to review.
• When every task is complete, it runs the verification commands the plan declared and reports what they said. A failing command is reported as a failure, not retried until it passes or left out.
• It writes a summary: tasks completed and still open, how many edits and commands were allowed without asking, how many questions were answered for you, and any commands it refused.

The hard boundaries

These limits do not depend on how the plan was written or on what the agent decides mid-run: a branch switch or destructive command is refused, and the refusal is counted in the summary. For teams, this is what makes unattended runs reviewable: the only output is uncommitted changes in the organisation's checkouts on this machine (the plan's repositories on the plan's branch, other checkouts on whatever branch they are on), plus a record of what the agent chose on its own.

Come back and review

1. Read the Coffee Mode summary first: how the run ended, tasks completed and still open, and any refused commands.
2. Read the agent's report of the decisions it made on its own. Each one is a place where it chose the safest option without you; check that it is the option you would have chosen.
3. Open Git Tree. The working-tree row collects everything uncommitted; review each changed file's diff in each repository the plan touched.
4. Re-run the checks yourself if you want to see them pass in front of you, or run anything the plan did not declare, such as a full build or an end-to-end suite.
5. Commit and push yourself, from Git Tree or your usual tools, once you are satisfied. Split the work into several commits if the tasks were independent.

A good review ends with you understanding every changed file, agreeing with every recorded decision, and having seen the declared verification pass. If any of those is not true, the work is not finished just because the tasks are marked complete.

When the run stopped early

1. Read how the summary says the run ended: finished, ended by you, stopped on an error, or stopped because the agent kept finishing with tasks still open. In the last case it waits for you rather than going round again.
2. For a blocked task, open it in Tasks and read why. Common causes: a failing verification command the agent could not fix within the plan, a missing dependency, or a task that turned out to need a decision the plan did not make.
3. For a refused command, decide whether it was needed. If it was a destructive or history-changing operation, run it yourself after checking it. If it was an ordinary command the plan should have declared, revise the plan to include it.
4. If the plan itself was wrong, ask for a revision, answer any new questions and approve again. The completed tasks and their changes stay in the working tree.
5. Start Run all or Coffee Mode again for what remains.

Split work across teammates

1. Agree the split in the plan: one plan per person or one plan with tasks attributed to each repository, so each part has a clear owner.
2. In Tasks, show work started by other people on your team alongside your own and work from your other CodeZero tabs, so you can see what is already running before you start.
3. Use the per-repository attribution in Tasks to avoid two runs editing the same repository at once, and the dependencies to order work that crosses people.
4. When a teammate's part lands, pull it, then run your dependent tasks.

Coffee Mode works only on the approved plan on the current tab. It does not pick up a teammate's tasks.

Use Vörr before and after, not during

1. Before planning, ask Vörr in Claude, ChatGPT or another MCP assistant for the production facts the plan should rest on: the errors a fix should address, the failing CI run, or which services call an endpoint according to live traces.
2. Bring those findings into the CodeZero request yourself. CodeZero does not call Vörr, and Vörr does not run inside CodeZero.
3. After you have committed, pushed and deployed, ask Vörr whether the change had the intended effect: the deploy in the organisation-wide feed, error rates compared with an earlier window, release health.

Decide when not to delegate

• Open design questions. If the plan cannot be written without a decision nobody has made, the agent will pick the safest option and you will review a guess. Settle the decision first.
• Destructive or irreversible data migrations. Coffee Mode refuses destructive operations, and a migration that drops or rewrites data should be run by a person who has checked a backup.
• Changes to production systems. Delegated work changes code in a working tree; applying infrastructure changes, rotating credentials or running scripts against production belongs with a person and your normal release process.
• Work whose verification cannot run locally. If the only real check is an end-to-end suite in a shared environment, an unattended run cannot tell you whether the change works.
• Exploratory debugging, where the next step depends on what the last one found. Use Normal or Auto with confirmations.

Without CodeZero

Claude Code can already work unattended. It has its own permission modes, an allow-list and deny-list of tools and commands you configure per project or user, a plan mode that keeps it read-only until you accept a plan, and settings that skip permission prompts entirely. With a well-tuned allow-list it can edit, test and iterate for a long time without you. The difference is where the boundary is defined and what it is tied to.

ChatGPT or Claude chat can help write and critique a plan but cannot execute it against your checkout. None of this makes CodeZero's agent more capable at the coding itself; the agent is the same Claude Code, Codex, GitHub Copilot or Cursor. What changes is the boundary around it.

With CodeZero

Modes that match the review needed

Auto, Planned and Normal, with /plan and /quick overrides for a single request.

A plan as the permission

Repositories, phases and verification commands written down, approved by a person and never by the agent.

Bounded execution

Edits in the plan's repositories must be on the plan's branch; edits in other organisation checkouts are allowed on whatever branch they are on; anything outside is refused; outside Coffee Mode, only declared verification commands run without asking.

Run one, Run all or Coffee Mode

Step through tasks, run them in order, or let CodeZero finish them unattended with recorded decisions.

A fixed boundary while away

No commits, pushes, branch switches, history rewrites or merges, publishing or destructive operations.

Review in one place

The summary, the recorded decisions and the working-tree diff in Git Tree.

Team view

Teammates' tasks and per-repository attribution in Tasks.

Vörr adds production context before and after a delegated run, from your assistant. It is not part of the run.

Worked example: a logger migration over lunch

The repositories, files, counts and output below are examples, not output from a real run.

A developer needs to move the orders service and its worker from a legacy logger to the shared structured logger. The pattern is agreed; the work is forty-odd call sites across two repositories. She starts in Planned mode and describes the change. CodeZero asks two questions: should debug-level calls be kept or dropped, and should the worker's custom log prefix become a structured field? She answers "keep" and "field: component".

Plan: migrate orders to the shared structured logger (illustrative)
Repositories: frigga-example/orders-api, frigga-example/orders-worker
Phase 1  orders-api
  Task 1  replace legacy logger in src/http (12 call sites)
  Task 2  replace legacy logger in src/domain (19 call sites)
Phase 2  orders-worker
  Task 3  replace legacy logger, prefix -> component field (11 call sites)
  Task 4  remove legacy logger dependency from both package.json files
Verification
  orders-api     npm test   npm run lint
  orders-worker  npm test
Questions: 2 asked, 2 answered

She runs task 1 on its own and reviews the diff, which follows the pattern she wanted. She then starts Coffee Mode and goes to lunch.

Coffee mode finished after 38 min. (illustrative)
  4 tasks completed, 0 still open
  57 edits and 9 commands allowed without asking
  1 question answered for you
  1 command refused
Nothing was committed or pushed: the work is in the working tree on the plan's branch.

Verification
  orders-api     npm test       212 passed
  orders-api     npm run lint   0 problems
  orders-worker  npm test       64 passed
Decisions made on my own
  src/domain/audit.ts logs a raw object; kept it as a structured field 'payload'
  rather than stringifying it (safest: no information lost).
Refused
  git checkout main (to compare test results): refused, branches are not switched while you are away.

Conclusion: the migration is complete and the declared checks pass. Review: she reads the recorded decision and agrees with it, opens Git Tree, reads the diff in both repositories, and notices the payload field could carry customer email addresses. She asks CodeZero for every place audit payloads are built, adds a redaction step herself, re-runs the tests, and commits in two commits, one per repository. Follow-ups: after the deploy, she asks Vörr whether log volume or error rate for orders-api changed against the previous day, per source, and adds a plan for the remaining services that still use the legacy logger.

Verify and follow up

• Summary: check how the run ended, the tasks still open and any refused commands before reading the diff.
• Decisions: read every decision the agent recorded, and treat each as a review comment you have to resolve.
• Diff: review the working tree in Git Tree for every repository the plan named, and for any other organisation repository checked out on this machine.
• Verification: read the actual output of the declared commands. A task marked complete is a claim; the command output is the evidence.
• Your own checks: run anything the plan did not declare, such as a full build or a slower suite, before you commit.
• Commit and push yourself. After deploying, use Vörr if you want production evidence that the change behaved as intended.
• Next: carry anything the run surfaced, such as call sites outside the plan's repositories, into a new plan rather than widening this one after the fact.

Limits

• Coffee Mode finishes approved work; it does not decide what the work is. It will not start without an approved plan and answered questions, and it will not invent new tasks.
• Questions that arise mid-run are answered with the safest option, which is not always the right one. The quality of an unattended run depends on how completely the plan was clarified.
• Verification is only as good as the declared commands. If the plan declares only unit tests, an integration break will not show up until you run something broader.
• Changes are never committed or pushed for you, so delegated work is not finished until a person reviews and commits it.
• The agent's coding ability is that of the agent you use with CodeZero. The plan and the boundary change what it may do, not how well it writes code.
• Edits in the plan's repositories must be on the plan's branch; edits in other organisation checkouts are allowed on whatever branch they are on; anything outside is refused. A run cannot switch branches; that needs you.
• Vörr is not involved in execution and cannot change code, run commands or act on your systems. It is read-only towards your systems.

Related

• Build a feature
• Ship a cross-repository change
• Refactor or upgrade safely
• Write and run tests
• Review a pull request
• Keep context across the team
• CodeZero: Choose an execution mode
• CodeZero: Use Coffee Mode
• CodeZero: Work with Git visually
• CodeZero: Work across repositories
• Vörr: Ask Vörr about your system