Skip to Content
ConceptsAutonomous Completion

Autonomous Completion

Finishing a task involves a predictable sequence of chores — commit, document, close the ticket, save a marker. None of them require judgment once the work is verified, yet each traditionally needs a human prompt. Autonomous Completion eliminates those prompts: when implementation is verified complete, Navigator runs the finish protocol on its own, without waiting for “please commit” or “close the ticket.”

The principle

Navigator expects full autonomy over deterministic workflows. A four-prompt finish sequence is four interruptions that add nothing — the outcome is the same whether you ask or not. So Claude executes the protocol automatically and reserves your attention for decisions that actually need it.

The protocol

Each step exists for a reason:

  1. Simplify — clarity pass over the code you just changed, so cleanup happens while the work is fresh rather than never. See nav-simplify.
  2. Commit (conventional format) — captures the change as an atomic, well-described unit for history and review.
  3. Archive the task doc — moves the implementation plan out of active context so it stops consuming tokens but stays available.
  4. Close the ticket (if a PM tool is configured) — keeps the tracker in sync with reality automatically.
  5. Write a context marker — preserves intent and decisions so a future session can resume without re-deriving them.
  6. Suggest compact — offers to clear context once the sub-task is done, so the next task starts clean. See nav-compact.

Exception cases

The protocol pauses and asks first in three situations, each a place where acting blind would be worse than interrupting:

  • Secrets in uncommitted files — committing automatically could leak credentials into history, which is hard to undo.
  • Multiple unrelated tasks touched — one autonomous commit would conflate changes that belong in separate, reviewable units.
  • Tests failing or implementation incomplete — “complete” is a precondition for the protocol; if it isn’t met, finishing is premature.

These are the right gates because they’re exactly the cases where the deterministic assumption — “this is done and safe to ship” — no longer holds.

How it’s enforced

Through v6 the finish protocol was a prose instruction Claude was asked to follow. As of v7 it’s backed by the hook runtime: the stop_state op records completion indicators on every Stop event, derived from observable turn evidence — git tree clean, tests ran green, docs touched, marker created, ticket closed, code simplified — not from the model’s own claim of being done.

When indicators show unfinished work (the turn mutated the codebase but the chores didn’t happen) and no exit signal is present, the stop_completion op can force one continuation so the protocol actually runs, capped by stop_completion.max_continues. This gate ships off (stop_completion.continue_enabled: false) and is always off under PILOT_EXECUTOR — enforcement is opt-in.

How it connects

In Loop Mode, an explicit exit signal is what declares the work complete, and that signal triggers the finish protocol — the loop and the completion sequence share one definition of done, evaluated on the same Stop event. The simplify step is the same clarity pass Loop Mode runs in its VERIFY phase, so completion and iteration stay consistent whether or not you’re looping.

Codebase ResearchOverview