Extend

The registry at _processes/_shared/request-types.md is the source of truth for this type; the agent's instructions live at _processes/_operations/extend/extend.prompt.md. Like every operation, extend runs outside the per-job stage pipeline and is never dispatched by the orchestrator.

The flow

You start extend by pasting its prompt path (optionally with the slug and the stages to add) into a fresh coding-agent session. The agent resolves the target slug, reads its JOB.md end-to-end, resolves the stages to add (asking you when the choice is ambiguous), rebuilds the ## Stages block and appends the matching per-stage config, moves the folder back to 2_ready/, and records the operation. It never touches the mandate body (except an optional ## Extension append you opt into) or another job's state.

From there you re-send the orchestrator on the slug: it sees the already-[x] stages in PROGRESS.md, skips them, and resumes at the first newly-pending stage.

What it is for

Use extend to add stages and per-stage config to an existing job and re-stage it. The classic case is continuing a finished brainstorm-only job into the building stages — plan, execute, test, document, validate — so the work you converged on actually gets built, without recreating the job from scratch.

• Continue, don't recreate. The job keeps its slug, its mandate, and its completed-stage history. extend only adds the stages you ask for and the matching config blocks.
• Re-stages the job. After editing JOB.md, the agent moves the folder back to 2_ready/ so the next orchestrator run picks it up at the first newly-pending stage.
• Resume-safe. Completed stages stay marked [x] with their original dates, so the orchestrator skips them and starts at the first new stage — it never re-runs work that is already done.
• Operates on any extendable queue. The target can live in 2_ready/, 3_ongoing/, or 4_done/; jobs in 0_new/ or 1_creation/ are not extendable (send the orchestrator instead).

The logic

extend sits in the operation layer with the op-card shape. It is direct-invoked — you paste the prompt path; the orchestrator never routes to it. It edits the target job's JOB.md within a documented carve-out (D-31): it may rewrite ## Stages, ## Approval gates, ## Per-stage config, ## Expected artifacts, and the **Status:** line, and append to PROGRESS.md → ## Decisions / ## Handoff notes. Continuity files (note.md, key-findings.md) stay read-only — their write authority remains the orchestrator's.

• Records an operation_record. At end-of-run the agent authors its own small report-only job born complete in jobs/4_done/<op-slug>/ (D-44, D-54), so the extend operation itself is tracked. It never writes a .lock and never moves the folder — the record is already in its final queue.
• You re-send the orchestrator afterward. extend only re-stages the job; it does not run the new stages. After it finishes, you send the orchestrator on the slug to advance the pipeline from the first newly-pending stage.
• Idempotent. Re-running on the same slug with the same stages produces the same final state — stages already enabled or done are skipped, existing config blocks are preserved, and duplicate expected-artifact lines are not added.
• Refuses on bad prerequisites. Workflow-version mismatch, a slug in a non-extendable queue, a missing JOB.md / PROGRESS.md, or a missing Codex runtime when adding review all refuse-and-report rather than half-apply.

The fields

The agent's two inputs are both optional text — if you omit them, the agent derives or asks:

How to run it

Send the extend prompt path to a fresh coding-agent session. Add the slug and the stages to add after the path when you already know them (e.g. <slug> add document, validate); otherwise the agent will ask.

_processes/_operations/extend/extend.prompt.md

When the agent finishes, it tells you the first newly-pending stage and where the operation_record was written. Re-send the orchestrator on the slug to advance the job:

_processes/02_orchestrator/orchestrator.prompt.md

See also