Ghostbots.art

Guide 06 · Workflow

Overnight batch, one morning overview

Several agents work on separate branches while you are away. In the morning you read one overview and decide what goes into main.

Related:
Ghostbots wing
Builds on:
Guide 02 · Plan, review, implement
Checked against the source:
Nov 4, 2026
Tools:
Git 2.52 · OMP 18.14.1 · Orca 1.4.248 (optional)

What it is for

Some tasks do not need you at every step: several pages, guides or fixes that do not depend on each other. Here the evening ends with a batch of such tasks, each on its own branch in its own worktree, and agents work on them through the night. In the morning, one agent has merged the branches into an integration branch and written one overview: what is done, what is verified and what you need to decide. Nothing reaches main, the remote or production until you say so.

Each task in the batch still goes through plan, review, implement from guide 02, or gets a short brief if the change is small. This guide covers what sits around several tasks at once. There are four roles:

What you need

We have not tested other agent CLIs with this workflow. If agent sessions are new to you, start with the basics guide.

Steps

  1. You: settle the request before you leave

    Write down what you want in your own words. Answer the choices that would block the night before you go. In one of our batches, that was whether a demo agent should call a real model or give scripted answers. Everything else comes back as questions in the morning.

  2. Control session: write the batch contract

    One shared file that every session reads first. It holds your request word for word, the state of the repo with its commit, the labels for claims, the one folder each branch may write to, the files only integration changes, what nobody does tonight, the checks each branch runs and the shape of the report. Each branch runs its own local server, so each gets its own port.

    illustrative
    # Batch contract: night of Nov 4
Read this first. It applies to every session in the batch.

Request, word for word: "prepare a few guides tonight"
Repo: main = origin/main = a1b2c3d.
Labels on claims: VERIFIED (source), INFERRED, UNVERIFIED.

Branch             Only folder it may write    Port
night/hooks        site/guides/hooks/          8105
night/skills       site/guides/skills/         8106
night/integration  everything                  8109

Only integration changes: site/index.html, site/guides/index.html.
A link to another branch's page may 404 on your branch.
Nobody pushes, merges into main or deploys.
Stage files by name. Temporary files go to one scratch folder per branch.
Checks: static checks, HTTP status, browser at 1440 and 390 px.
Report: branch and hash, actual check output, verified locally /
against the real boundary / unverified, questions for the owner.

    In one night batch, four branches with separate folders went into the integration branch without a conflict.

  3. Control session: one short brief per branch

    Each brief points to the contract and adds the goal, what is out of scope and the claims it relies on. Each claim is marked verified (with its source), inferred or unverified. In one of our runs, workers used the labels to check inferred claims before building on them and corrected two. Send the agent a one-line pointer to the brief, as in guide 02.

    illustrative
    # PLAN: night/hooks
Read the batch contract first: briefs/night-11-04/contract.md

Goal: a guide to hook types, one tested example for each.
Out of scope: other folders, shared files, push, deploy.

Claims:
- main is a1b2c3d, same as origin/main.   VERIFIED (git rev-parse)
- The site has no build step.              VERIFIED (no package.json)
- Readers know what a git hook is.         INFERRED
- Hook X can block a tool call.            UNVERIFIED, check the docs

Return decisions this brief does not settle as
question, recommendation, impact.
Last line of your report: PLAN DONE: path to the prompt

  4. Control session: one worktree per branch, all from the same base

    Every branch, the integration branch too, starts from the same commit. Keep a small table of branch, worktree, session and phase, and update it when a phase changes.

    real commands · branch names and paths are illustrative
    git fetch origin
git worktree add --no-track -b night/hooks ../night-hooks origin/main
git worktree add --no-track -b night/skills ../night-skills origin/main
git worktree add --no-track -b night/integration ../night-integration origin/main

    Without --no-track, Git 2.52 set each new branch to track origin/main in our test.

  5. Worker: report in a fixed shape

    Each worker writes its report to a file in the reports folder: branch and hash, files, the actual output of each check, what is verified locally, what is verified against the real boundary (the live service, the real API) and what is not verified, and its questions as question, recommendation and impact. While they work, workers do not touch shared files such as the changelog or the roadmap; they return a report. Entries in shared files come only once the branch's work is done. The control session ends a worker's session as soon as it is no longer needed.

  6. Integration agent: merge, link, check, write the overview

    A separate agent in the integration worktree does this, not the control session. First it checks that each branch stayed in its folder. Then it merges the branches in the order the contract gives and stops on any conflict that is not mechanical. It adds the links between new pages that the contract kept for integration and runs the checks again on the merged result. A branch you have not decided on gets only a trial merge, which touches no working tree.

    real commands · branch names and paths are illustrative
    # Files a branch changed outside its folder. Expect no output.
git diff --name-only origin/main...night/hooks -- . ':(exclude)site/guides/hooks/'

# In the integration worktree, in the contract's order.
git merge --no-ff -m "merge night/hooks" night/hooks
git merge --no-ff -m "merge night/skills" night/skills

# Trial merge of an undecided branch. Exit status 1 means a conflict.
git merge-tree --write-tree --name-only night/integration night/palette

    Last, it writes the overview and commits it on the integration branch: one section per branch, then the decisions grouped by topic, each with a recommendation.

    illustrative
    # Morning overview, Nov 4
Integration: night/integration (e4f5a6b). Nothing pushed or deployed.
Checked locally only. Nothing against the live site.

## night/hooks (b7c8d9e, merged)
Brings: /guides/hooks/, three hook types, one example each
Verified: examples run in a scratch repo; 1440 and 390 px, no errors
Not verified: Safari, Firefox

## night/palette (f0a1b2c, not merged)
Trial merge on top of integration: clean, changes index.html only

## Decisions
1. Publish lessons from our own incidents?
   Recommendation: yes, in general terms, without repo names.
   Impact if no: the "watch out" sections keep only rules.

  7. You: decide in the morning

    Read the overview, answer the decisions and say what goes into main. In our setup the control session then merges the integration branch in the repo's main checkout and pushes. Deploying is a separate decision. Small follow-ups go to one session as short briefs. Every change to the integration branch makes earlier trial merges stale, so run them again.

How to check it works

  1. git worktree list shows one worktree per branch and one for integration.
  2. The scope check from step 6 prints nothing for every branch.
  3. git log --oneline origin/main..night/integration includes one merge per branch and the overview commit.
  4. Before your decision, git fetch origin and then git rev-parse origin/main still print the commit named in the contract: nothing reached the remote overnight.
  5. The overview has a section for every branch with what is verified and what is not, and every decision has a recommendation and an impact.

What to watch out for

Sources

← All guides