Labels
Labels are autoducks’ state machine: they route commands, record stage progress, and drive the Definition-of-Ready cascade. Agents create and apply all of them automatically — you never label anything by hand.
Stage labels
Section titled “Stage labels”Each pipeline stage has an in-progress and a done label:
| Label | Applied by | Meaning |
|---|---|---|
Design:draft | Architect | Design is being written |
Design:done | Architect | Design complete — the Engineer’s Definition of Ready |
Tactics:crafting | Engineer | Plan is being written |
Tactics:done | Engineer | Plan complete — the Maestro’s routing signal and the Engineer’s revision-mode marker |
Work:orchestrating | Maestro | Waves are being coordinated on this issue |
Work:coding | Developer | This task is being implemented |
Work:done | Maestro / Developer | Work complete (all waves finished, or task merged) |
On failure, the in-progress label is removed and the done label is not applied — a stage label always reflects reality.
A Work:* label (together with the pipeline branch already existing) is also the “delivery started” boundary: once either is true, the Architect and Engineer refuse to re-run rather than revise a design or plan out from under work that’s already in flight. /quack revert or /quack close clears both and returns the issue to the discovery phase. See Re-running agents.
Review labels
Section titled “Review labels”The Reviewer sits outside the four-agent pipeline, but still carries its own stage labels — with two possible terminal states instead of one, driven by the review verdict. Each label is applied to both the feature/bug issue and its PR, so review state is visible on either.
| Label | Applied by | Meaning |
|---|---|---|
Review:reviewing | Reviewer | A PR review is in progress |
Review:done | Reviewer | Review finished with verdict approve or comment — no blocking findings |
Review:changes | Reviewer | Review finished with verdict request-changes — at least one blocker/major finding or a missing acceptance criterion |
Any lingering Review:* label is removed from both the issue and the PR when /rework re-enters orchestration on an actionable round.
Triage labels
Section titled “Triage labels”The Product Owner (/triage, /merge) applies these when the labels priority backend is active, or the project backend can’t be reached. They are a named taxonomy, distinct from — and not a replacement scheme continuing — the retired lowercase priority:P0–priority:P3 labels below; nothing migrates one to the other automatically.
| Label | Color | Meaning | Applied by |
|---|---|---|---|
Priority:Critical | #B60205 | Critical — drop-everything | Product Owner |
Priority:High | #D93F0B | High | Product Owner |
Priority:Medium | #FBCA04 | Medium | Product Owner |
Priority:Low | #0E8A16 | Low | Product Owner |
Duplicate | #CFD3D7 | Issue closed as a duplicate of another issue (/triage or /merge) | Product Owner |
When product.priority_backend resolves to project instead, priority lives on the repository’s Projects v2 board’s native single-select field and no Priority:* label is applied — see Configuration and the Product Owner reference.
Classification and routing labels
Section titled “Classification and routing labels”| Label | Applied by | Meaning |
|---|---|---|
Feature | Architect (authoritative) / Product Owner (provisional) | Routing + classification; pipeline branch feature/… |
Bug | Architect (authoritative) / Product Owner (provisional) | Same pipeline as features; pipeline branch fix/… |
Task | Engineer | A task issue split from a plan — routes execute to the Developer |
Draft | you (optional) | Human marker for “still needs design”; removed by the Architect |
Labels are the route-critical signal on every repository kind; the native issue types (Feature/Task/Bug) are a best-effort visual enhancement on organization repos. The Bug/Feature label is the single route-critical classification signal on every issue, regardless of whether the Product Owner proposed it provisionally at intake or the Architect later confirmed or overrode it.
Orchestrator mode labels
Section titled “Orchestrator mode labels”Optional, human-applied labels that pin the Maestro’s dispatch topology for a single issue — waves (parallel, wave-by-wave dispatch) or sequential (one task at a time, in dependency order, ignoring wave grouping).
| Label | Applied by | Meaning |
|---|---|---|
Mode:waves | you (optional) | Pin this issue to parallel wave-by-wave dispatch |
Mode:sequential | you (optional) | Pin this issue to one-task-at-a-time dispatch |
A Mode:* label overrides orchestrator.mode in .autoducks/autoducks.json, but yields to an explicit mode: directive on the triggering comment — see Maestro → Topology for the full resolution order.
Retired labels
Section titled “Retired labels”These belonged to the previous taxonomy and are cleaned up on sight by the Engineer, Revert, and Close agents:
Spec:draft, Spec:plan, Tactics:ready, Ready, Work:progress, Tactics:single, priority:P0–priority:P3
If you’re migrating an older install, see Migrating from /agents.