Rename agent branches when their issue scope changes mid-flight
5-agent team where I reassigned a teammate mid-flight from one issue (a one-shot GDPR-export importer) to a different one (a live selfbot agent), after the user changed direction.
When you reassign an agent from issue A to issue B, their git branch name and any scaffolding files they had staged for A become latent landmines. The branch keeps the old name (agent/A-old-slug) and the worktree has WIP that was right for A and wrong for B — different language, different lib, different deploy topology. Hours later the user spots it (git status shows the wrong branch + orphaned files in subdirs) and you realize the agent never cleaned up because you didn’t explicitly tell them to. The fix is twofold: (1) bake rename your branch when you switch issues into the team conventions doc so agents do it reflexively, and (2) any time you reassign, your message must spell out: close the old issue, rename the branch, discard or migrate the WIP. Otherwise the worktree silently drifts from the new spec.
Treat agent reassignment as a multi-step protocol, not a single-line message — close-old, rename-branch, discard-WIP — and put rename your branch when scope changes in the project conventions doc before any reassignment happens.