Promote
An operation-layer op-card that manually moves a job folder between Kanban queues. You invoke it directly by pasting its prompt path; it validates the move, relocates the folder, records the transition, and records its own run in 4_done/. It is the workflow's queue-management and recovery tool.
promote does no stage work and writes no source code. It performs one job: move jobs/<old-queue>/<slug>/ to jobs/<target-queue>/<slug>/, with sanity checks around it.
The flow
You give promote a slug and a target queue (it asks via a question prompt if either is missing). It validates the move — rejecting no-op moves, destination collisions, foreign .lock files, and intake-file (not folder) sources, and asking you to confirm semantically-suspicious transitions. It then moves the folder with a plain mv (job folders are gitignored, so git mv is never used), updates the moved job's JOB.md → Status and PROGRESS.md queue/next-action lines, and records the run.
What it is for
promote lets you manually move a job between Kanban queues for queue management or recovery — for example undoing a queue move, re-staging a job the orchestrator stopped, or any non-standard transition between 0_new, 1_creation, 2_ready, 3_ongoing, 4_done, and 5_cancelled.
after_creation: no, the orchestrator advances 1_creation → 2_ready itself (D-41), so promote is no longer the normal path for moving a fresh job forward. Reach for it when you need a non-standard or recovery move. For the common "re-open a finished job and add stages" case, prefer the extend operation agent, which does the JOB.md surgery plus the move in one pass.
The logic
Layer: operation
promote runs in the operation layer with the op-card shape. It is not dispatched by the orchestrator and runs no stage pipeline.
Direct-invoked
You start it by pasting its prompt path into a fresh coding-agent session. It calls the user-question prompt directly when it needs to disambiguate the slug or target queue.
Records an operation_record
At end of run it authors its own report-only operation_record job, born complete in 4_done/ (D-44, D-54), so the move is tracked in the audit trail.
The queue is the truth
The Kanban queue folder is the single source of truth for a job's state (D-19); the JOB.md → Status line is informational only and is updated to match the new queue.
The fields
promote takes two inputs, both supplied when you invoke it (it asks for either if omitted):
| Input | Meaning |
|---|---|
| slug | The job folder to move, e.g. 26-05-17-workflow-init — must exist in some queue under jobs/. |
| target queue | Where to move it, from the closed set 0_new, 1_creation, 2_ready, 3_ongoing, 4_done, 5_cancelled. |
How to run it
promote is an op-card: there is no intake to fill out. Copy the prompt path below and paste it into a fresh coding-agent session, optionally followed by the slug and target queue.
_processes/_operations/promote/promote.prompt.md