End-of-run commit, push, and PR updates

If someone’s agent keeps committing and pushing at the end of every chat — or updating an open pull request — that is intentional house policy, not a runaway loop.

The rule (short)

When an agent run changes files in an owned repo, it closes the run with logical commits, a push, and (when a PR is in play) PR updates — unless you said not to commit or push.

Portable source: general/end-of-run.md in the agent-rules repo. Skills: push-code, git-commit, draft-pr.

Why we do it

Easier to reason about than chat memory

Chat threads are a poor system of record. At the end of a day you should not have to reopen old conversations to remember what still needs committing, pushing, or opening as a PR.

Standing end-of-run close-out makes git and the remote the source of truth. The last reply in a chat corresponds to a synced tree on GitHub (or your forge).

Two machines at once

Many of us develop on laptop and desktop in the same week — sometimes the same day. When every productive chat ends with push:

  • The other machine can git pull and continue without guessing which chat last touched the repo.

  • You are not carrying uncommitted work across sleep, travel, or a different IDE session.

  • Hive-watch and normal git workflows see the same HEAD on both boxes.

Contributors and review in pull requests

For org-owned work, changes should land in pull requests where review happens — not as a pile of local-only edits tied to one chat session.

End-of-run push keeps the PR branch current. Iteration is later commits and PR updates, not “wait until the demo feels done” (see Demos + push workflow).

Auditing updates on GitHub

GitHub records each push to a PR branch:

  • The Commits tab lists every commit on the branch.

  • The PR timeline shows when new commits arrived.

  • Reviewers can inspect individual commit diffs and compare how the PR changed between pushes.

You do not lose history when an agent pushes several times across chats — each push adds reviewable commits (normal git push, not force-push to shared branches).

When it does not apply

  • You explicitly said not to commit or not to push.

  • Secrets are present — stop and warn; never commit them.

  • Push would require force to main/master, or there is no upstream — report instead of forcing.

  • Read-only / ask mode where the harness forbids writes.

  • Parallel worker leaves in a multitask / multi-subagent / harness swarm wave — those nodes commit locally and defer push to the coordinator after the wave (cuts remote CI rebuild storms). Detail: general/parallel-git-closeout.md.

Parallel waves (deferred push)

Standing end-of-run push still applies to the session, not to every concurrent Task leaf.

  • Workers — GIT_CLOSEOUT=commit-only / coordinator-batch: commit only unless that worker needs the remote now to validate.

  • Parent / coordinator — after workers finish, one batched push-code per affected repo.

  • Briefing — parents must put the close-out line in the worker prompt and omit standing “push before final reply” text. Cursor often copies always-on rules into subagents; without an explicit omit, every leaf pushes and CI queues pile up.

DevCentr harness stores gitCloseout on each node and injects a system addendum on spawn so inherited push authorization cannot silently win. Variable: GIT_CLOSEOUT in $CODE_ROOT/harness.md.

Related