Re-running agents

There is no separate “resume” command in autoducks. If a run was interrupted, produced something you want to change, or you just want another pass with more feedback — you re-issue the same comment on the same issue. This page explains why that’s always safe, what each stage actually does the second time, and how to steer the result.

The core idea

Every agent, LLM or bash, is stateless between runs: it recomputes what to do entirely from what’s currently visible in the issue tracker (ITS) and git — labels, the issue body’s design and tactical zones, comments, merged PRs, and branches. Nothing is cached in the workflow, and nothing lives outside the repo and the tracker. Re-running is therefore not a special “retry mode” — it’s the same code path the first run took, just observing different state.

This is what makes re-running the intended mechanism for three different situations:

• Resuming an interrupted or failed run (a max_turns cutoff, a merge conflict, a transient infra error — see When things fail). For a max_turns cutoff specifically, re-run with turns=<n> (e.g. /execute turns=<n>) to resume the preserved branch and raise the turn budget that caused the cutoff.
• Refining an earlier result (the design needs another pass, the plan needs a task added or dropped).
• Correcting course after reviewing what an agent produced, before the next stage locks it in.

Per-stage: what a second run does

Stage	What a second run does	How to steer it
Architect	Judges the maturity of the current body: a raw/thin body is authored from scratch, a mature one is revised — structure, decisions, and wording are kept where sound; gaps are filled and loose prose is structured. If a tactical zone is present, it is stripped (with a warning comment) rather than preserved — the design changed, so the old plan is treated as stale and re-planning is left to the Engineer. Re-classifies Feature/Bug each time. Refused outright once delivery has started — see Locked once delivery starts.	Edit the issue body before re-running.
Engineer	If Tactics:done is already set, this is revision mode: existing tasks referenced by their real issue number are preserved (number, comment history, assignees); tasks omitted from the revised plan are closed as “superseded by revised plan”; new tasks get fresh Tn placeholders. The design zone above the tactical zone is read-only and untouched. Refused outright once delivery has started — see Locked once delivery starts.	Leave a comment before re-running, or edit the design (see How to steer a re-run).
Maestro	Fully idempotent: recomputes wave state from merged task PRs, reuses the existing pipeline branch and draft PR, and dispatches only the next eligible wave. Never re-dispatches a task that already has an open or merged PR (one of the duplicate-dispatch guards).	Nothing to steer — it’s pure bash. Re-issue /quack execute, or let the next task-PR merge re-trigger it automatically.
Developer	The idempotency guard skips quietly if any PR — open or merged — already claims the task. Otherwise it resumes on top of the existing task branch (including a preserved WIP: branch from a max_turns cutoff) rather than starting over.	Edit the task’s acceptance criteria before re-running; for a failed run, /quack fix resumes the branch, or for a max_turns cutoff use /quack execute turns=<n> to also raise the turn budget.
Fix	Finds the newest existing task branch (either feature/… or fix/… prefix, including WIP:), reads the failure context, and repairs on top of what’s there — reusing the open PR if one exists.	Comment what went wrong before running — the agent reads the last 10 comments as context.
Revert	Idempotent teardown of the plan: closing already-closed tasks and stripping already-absent labels are no-ops. Always restores the last human-authored body revision, never a previous bot revision.	Not steerable — it’s a fixed undo, not a revision.
Close	Idempotent teardown of everything: closing already-closed issues/PRs and deleting already-deleted branches are no-ops.	Not steerable — full teardown.

Locked once delivery starts

Re-running the Architect or the Engineer stops being safe once tasks are actually being built — revising the design or the plan underneath in-flight work could silently orphan it. So both agents check, before doing anything else, whether delivery has started: a Work:* label is present, or the pipeline branch already exists. If either is true, the run is refused with a comment pointing at the escape hatch below, instead of touching the issue body.

To get back to a re-runnable state, undo the plan first:

• /quack revert — closes the task issues, strips pipeline labels, restores the last human-authored body, and leaves the issue open. This is the usual choice.
• /quack close — full teardown (branches, PRs, the issue itself); use this if you’re abandoning the work entirely.

Either one returns the issue to the discovery phase, where /quack architect and /quack engineer are re-runnable again. See /quack revert and /quack close for the full behavior.

How to steer a re-run

Two mechanisms work today, and a third is planned:

1. Edit the issue body. The Architect always re-reads the current body on every run — a design you’ve hand-edited is preserved in revision mode rather than being rewritten, so editing the body is the primary way to steer it.
2. Leave a preceding issue comment. The Engineer’s revision context already includes the last 20 comments (and /fix’s failure context includes the last 10), so feedback left as a comment before you re-run reaches the agent even though the trigger comment itself carries no extra text today.
3. A trigger-comment prompt (planned enhancement) — once it lands, free text placed directly in the trigger comment (e.g. /architect <your instructions> or /engineer <your instructions>) will be passed to the agent as additional context for that run, without needing a separate preceding comment. Until then, use (1) or (2).

Tip

For the Engineer specifically, Questions Mode is the same mechanism: it posts blocking questions and stops the chain, and your answers — left as comments — are exactly the “preceding comment” context that steers the re-run.

What’s preserved vs. rewritten

Stage	Preserved	Rewritten
Architect	Explicit requirements, code blocks, and type definitions in the design zone	Loose prose restructured into the standard sections; gaps filled; the Feature/Bug classification; the tactical zone — stripped (with a warning), not preserved
Engineer	Existing task issue numbers, comment history, and assignees; the design zone (never touched)	The wave plan and ## Progress checklist; tasks dropped from the revised plan are closed as superseded
Maestro	The pipeline branch and its draft PR; any task with an open or merged PR is never re-dispatched	The wave-dispatch computation itself, every run

See When things fail for the failure-specific recovery paths, and Chaining & overrides for combining a re-run with #auto: to continue further down the pipeline in one comment.