Plan Execution Workflow

Work Execution Command

Outcome

• Result: A fully implemented, locally verified change set from a plan, specification, or concrete work prompt.
• Next consumer: In standalone use, the shipping workflow takes the verified change through review and delivery. In Return-to-Caller Mode, the invoking workflow receives the structured implementation and verification result and owns its remaining gates.
• Done: Every in-scope task is complete, required verification evidence is recorded, relevant checks pass, and the run reaches either its owned shipping handoff (with a code-review receipt or explicit skip phrase — see Phase 3-4), a complete return result, or an explicit blocker.
• Intent: Finish the requested feature without renegotiating the plan or transferring canonical integration authority. Workers receive bounded units; the host orchestrator inspects actual changes and owns authoritative verification and canonical commits.

Execution Workflow

Bundled references must be read, never approximated. Resolve each reference or script path named below from this skill's loaded SKILL.md directory, using the full skill path the harness supplied, and never glob the target repository to find a bundled file. Read each reference when you enter the phase it governs; a read made before that phase does not satisfy it, and a reference this file says to read again is read again at its step even when already in context. If the harness does not expose the skill directory, or a required file cannot be read, stop before the action it governs and report which file is missing. Do not reconstruct its rules from memory; report the missing reference instead of continuing natively.

Phase 0: Input Triage

Recovery activation comes first. Before classifying the input as a plan, a path, a blank, or a bare prompt, recognize requests to resume, inspect, reap, or clean up an existing run. Recovery never dispatches a new worker, selects a new route, discovers another plan, reruns completed verification, or enters either shipping path. If the run id is missing, ask for it; never guess one.

Before any other input decision, read references/input-triage.md. It decides source resolution, control tokens, recovery, read-only discovery, plan readiness, non-code routing, blank input, and bare-prompt sizing. Three rules from it hold here:

• A bare prompt that is Trivial — one or two files, no behavioral change — skips the task list but still resolves its execution engine before writing. A purely mechanical diff also ships without a post-PR watch. When either is uncertain, take the fuller route.
• A bare prompt that ce-plan already sized in this session is executed, not planned again. A decision the user would weigh is asked as a question, never as a route back to ce-plan or ce-brainstorm.
• If that reference cannot be read, stop; never treat control tokens or a non-executable artifact as code work.

When triage selects Return-to-Caller Mode, read references/return-to-caller.md immediately and record that it governs how this run ends. If it cannot be read, stop before any mutation; do not fall back to standalone behavior.

Phase 1: Quick Start

1. Establish the workspace. Before moving branches, editing, dispatching, or committing, read references/workspace-setup.md. It decides the writable checkout, plan clarification, branch placement, the pre-work inventory, already-dirty files, and task setup. Never write without a writable canonical checkout, and never write on the real default branch unless the user explicitly directed that in this session.

   Do not commit or publish anything the user did not offer. When a unit needs a file that was already dirty, standalone mode asks once whether to include or exclude that file. Return-to-Caller Mode neither asks nor edits it; it returns blocked, naming the collision and how to recover.

2. Resolve the engine, then strategy. After bounded plan intake and task derivation, but before selecting a unit for execution, writing, dispatching, or committing, read references/execution-engines.md and complete its route selection. It applies with or without a typed binding; native execution is eligible only when that reference selects it or exhausts an allowed fallback. The engine choice never changes which reference governs how the run ends.

   If cross-model execution is selected, read references/cross-model-execution.md before any content or authority crosses to the other model. It defines controller initialization, the post-init engine lock, bounded egress, transactions, recovery, and receipts.

   Before choosing inline, serial, or parallel execution, and before dispatching any worker, read references/execution-strategy.md. It decides scheduling, isolation, the packet each worker receives, worker lifecycle, and integration. The host orchestrator keeps authoritative verification and makes the canonical commits.