Autopilot

Deliver the agreed scope: short plan → implement → review → repair if needed → verify → branch decision. Continue through routine steps without approval checkpoints. Stop for a material scope/architecture decision, a blocker, or the final branch choice. Use /tracer-implement when the user wants plan approval and an implementation report without finishing.

Scope and execution

Acceptance requirements and explicit user decisions are binding; planner-generated mechanisms are proposals. Prefer existing commands and libraries and simplify the approach without changing required behavior. Before adding custom parsing, a generic process runner, a permission evaluator, concurrency guarantees, or persisted recovery machinery not explicitly chosen by the user, explain the need and simpler alternative, then ask. Safe reruns alone do not imply concurrent execution or automatic crash recovery. Preserve agreed data/security safeguards.

Default to one implementation context for cohesive work, normally the controller. A new task, file, or commit is not a reason to spawn a fresh agent. Delegate only a named investigation or separable unit with a clear benefit, reuse its context for follow-ups, and keep dependent changes sequential. Helpers return evidence without spawning agents or extending the workflow.

1. Workspace and short plan

1. Inspect branch and working tree. Stay on an existing feature branch; follow /tracer-worktrees on main or master. Ask about detached HEAD or ambiguous ownership. Preserve unrelated work.
2. Ensure .tracer/ is ignored; commit a needed ignore rule before recording the base. Read .tracer/implement/progress.md before starting. For a fresh delivery, record scope and the immutable starting SHA. On resume, verify scope, base, commits, running workers, and reports against Git and recover the unfinished step. Ask about invalid or unexplained state rather than resetting the workflow.
3. Select focused checks for required behavior and material failure paths. Run relevant existing baseline tests when available; a new feature needs a failing acceptance test, not a full-repository baseline. Report unrelated failures without repairing them. Clarify failures that prevent assessing the change.
4. Write .tracer/implement/plan.md: goal, source, acceptance and safety limits, existing facilities to reuse, affected paths, and verification commands. Add ### Task N: <behavior> headings only to organize coherent implementation units. One task is valid. A few bullets per task suffice; code belongs in implementation, not the plan.
5. Show the approach, task order, delegation if any, and checks, then proceed. Explicitly surface new infrastructure or stronger safety guarantees for approval; an innocuous task name is not disclosure of a complex architecture.

Use focused testing by default. Full-suite runs and broad typechecks require repository policy, a user request, or a stated impact-based reason. Otherwise leave broad validation to CI or the user and report that limit.