Mention Uncommitted Changes Before Starting New Work

Rule

When the working tree has uncommitted changes and the agent is about to start something else, mention them. Name what’s there, whether it should be committed first, stashed, or discarded. Never silently leave work in limbo while pivoting to a new task.

Why

Uncommitted work is invisible to anyone but the current session — and even the current session loses track if the pivot is large enough. When the operator asks for new work, they expect the agent to either complete the prior work or explicitly hand it off. A silent pivot leaves both pieces of work in a half-state: the prior work has no PR, no commit, no record; the new work proceeds against a working tree that has unexplained modifications. Disclosing the state takes one sentence and prevents the whole class of “what was I doing again?” recovery.

Applies To

In-platform coworkers running multi-step operations, external coding agents handling user prompts, and humans context-switching mid-task. Applies when the user pivots to a new request and the working tree has unstaged or staged changes from the prior request.

How To Apply

Before starting a new task, run git status --short. If there are uncommitted changes, mention them in the response: “Working tree has uncommitted changes in . Should I commit them first, stash, or discard?" Then proceed based on the answer. When the operator's new request is a continuation of the prior work (e.g., "OK, do that next"), no disclosure is needed — the uncommitted state is in scope.

Decision Dimensions

Examples

Sources

(Rendered from the sources: frontmatter by WikiSourceCitations.)