Ce:work Beta

Work Execution Command

Execute work efficiently while maintaining quality and finishing features.

Introduction

This command takes a work document (plan or specification) or a bare prompt describing the work, and executes it systematically. The focus is on shipping complete features by understanding requirements quickly, following existing patterns, and maintaining quality throughout.

Beta rollout note: Invoke ce-work-beta manually when you want to trial Codex delegation. During the beta period, planning and workflow handoffs remain pointed at stable ce-work to avoid dual-path orchestration complexity.

Input Document

#$ARGUMENTS

Argument Parsing

Parse $ARGUMENTS for the following optional tokens. Strip each recognized token before interpreting the remainder as the plan file path or bare prompt.

| Token | Example | Effect | |-------|---------|--------| | delegate:codex | delegate:codex | Activate Codex delegation mode for plan execution | | delegate:local | delegate:local | Deactivate delegation even if enabled in config |

All tokens are optional. When absent, fall back to the resolution chain below.

Fuzzy activation: Also recognize imperative delegation-intent phrases such as "use codex", "delegate to codex", "codex mode", or "delegate mode" as equivalent to delegate:codex. A bare mention of "codex" in a prompt (e.g., "fix codex converter bugs") must NOT activate delegation -- only clear delegation intent triggers it.

Fuzzy deactivation: Also recognize phrases such as "no codex", "local mode", "standard mode" as equivalent to delegate:local.

Settings Resolution Chain

After extracting tokens from arguments, resolve the delegation state using this precedence chain:

1. Argument flag -- delegate:codex or delegate:local from the current invocation (highest priority)
2. Config file -- extract settings from the config block below. Value codex for work_delegate activates delegation; false deactivates.
3. Hard default -- false (delegation off)

Config (pre-resolved): !cat "$(git rev-parse --show-toplevel 2>/dev/null)/.compound-engineering/config.local.yaml" 2>/dev/null || echo '__NO_CONFIG__'

If the block above contains YAML key-value pairs, extract values for the keys listed below. If it shows __NO_CONFIG__, the file does not exist — all settings fall through to defaults. If it shows an unresolved command string, read .compound-engineering/config.local.yaml from the repo root using the native file-read tool (e.g., Read in Claude Code, read_file in Codex). If the file does not exist, all settings fall through to defaults.

If any setting has an unrecognized value, fall through to the hard default for that setting. For optional settings without a hard default (work_delegate_model, work_delegate_effort), an unrecognized or unparseable value resolves to unset — the corresponding flag is omitted from the codex exec invocation so Codex resolves from ~/.codex/config.toml. Never substitute an invalid value into the CLI flags.

Config keys:

• work_delegate -- codex or default false
• work_delegate_consent -- true or default false
• work_delegate_sandbox -- yolo (default) or full-auto
• work_delegate_decision -- auto (default) or ask
• work_delegate_model -- Codex model to use. Optional — when unset or unparseable, defers to the user's ~/.codex/config.toml default. Passthrough — any non-empty string is accepted as valid; only YAML parse failures or empty values resolve to unset.
• work_delegate_effort -- one of minimal, low, medium, high, or xhigh. Optional — when unset or set to a value outside this enum, resolves to unset and defers to the user's ~/.codex/config.toml default.

Store the resolved state for downstream consumption:

• delegation_active -- boolean, whether delegation mode is on
• delegation_source -- argument or config or default -- how delegation was resolved (used by environment guard to decide notification verbosity)
• sandbox_mode -- yolo or full-auto (from config or default yolo)
• consent_granted -- boolean (from config work_delegate_consent)
• delegate_model -- string from config, or unset (defer to Codex config)
• delegate_effort -- string from config, or unset (defer to Codex config). Floor for per-batch effort selection; not passed directly to codex exec.
• effective_effort -- per-batch derived value (default | medium | high | xhigh), computed before each batch from delegate_effort and the picked level per references/codex-delegation-workflow.md ("Per-Batch Effort"). Feeds the codex exec invocation in place of delegate_effort.

---

Execution Workflow

Phase 0: Input Triage

Determine how to proceed based on what was provided in ``.

Plan document (input is a file path to an existing plan or specification) → skip to Phase 1.

Bare prompt (input is a description of work, not a file path):

1. Scan the work area

• Identify files likely to change based on the prompt
• Find existing test files for those areas (search for test/spec files that import, reference, or share names with the implementation files)
• Note local patterns and conventions in the affected areas

1. Assess complexity and route

| Complexity | Signals | Action | |-----------|---------|--------| | Trivial | 1-2 files, no behavioral change (typo, config, rename) | Proceed to Phase 1 step 2 (environment setup), then implement directly — no task list, no execution loop. Apply Test Discovery if the change touches behavior-bearing code | | Small / Medium | Clear scope, under ~10 files | Build a task list from discovery. Proceed to Phase 1 step 2 | | Large | Cross-cutting, architectural decisions, 10+ files, touches auth/payments/migrations | Inform the user this would benefit from /ce-brainstorm or /ce-plan to surface edge cases and scope boundaries. Honor their choice. If proceeding, build a task list and continue to Phase 1 step 2 |

---

Phase 1: Quick Start

1. Read Plan and Clarify (skip if arriving from Phase 0 with a bare prompt)

• Read the work document completely
• Treat the plan as a decision artifact, not an execution script
• If the plan includes sections such as Implementation Units, Work Breakdown, Requirements (or legacy Requirements Trace), Files, Test Scenarios, or Verification, use those as the primary source material for execution
• Check for Execution note on each implementation unit — these carry the plan's execution posture signal for that unit (for example, test-first or characterization-first). Note them when creating tasks.
• Check for a Deferred to Implementation or Implementation-Time Unknowns section — these are questions the planner intentionally left for you to resolve during execution. Note them before starting so they inform your approach rather than surprising you mid-task
• Check for a Scope Boundaries section — these are explicit non-goals. Refer back to them if implementation starts pulling you toward adjacent work
• Review any references or links provided in the plan
• If the user explicitly asks for TDD, test-first, or characterization-first execution in this session, honor that request even if the plan has no Execution note
• If anything is unclear or ambiguous, ask clarifying questions now
• If clarifying questions were needed above, get user approval on the resolved answers. If no clarifications were needed, proceed without a separate approval step — plan scope is the plan's authority, not something to renegotiate
• Do not skip this - better to ask questions now than build the wrong thing
• Do not edit the plan body during execution. The plan is a decision artifact; progress lives in git commits and the task tracker. The only plan mutation during ce-work is the final status: active → completed flip at shipping (see references/shipping-workflow.md Phase 4 Step 2). Legacy plans may contain - [ ] / - [x] marks on unit headings — ignore them as state; per-unit completion is determined during execution by reading the current file state.

1. Setup Environment

First, check the current branch:

```bash currentbranch=$(git branch --show-current) defaultbranch=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@')

# Fallback if remote HEAD isn't set if [ -z "$defaultbranch" ]; then defaultbranch=$(git rev-parse --verify origin/main >/dev/null 2>&1 && echo "main" || echo "master") fi ```

If already on a feature branch (not the default branch):

First, check whether the branch name is meaningful — a name like feat/crowd-sniff or fix/email-validation tells future readers what the work is about. Auto-generated worktree names (e.g., worktree-jolly-beaming-raven) or other opaque names do not.

If the branch name is meaningless or auto-generated, suggest renaming it before continuing: ``bash git branch -m ` Derive the new name from the plan title or work description (e.g., feat/crowd-sniff`). Present the rename as a recommended option alongside continuing as-is.

Then ask: "Continue working on [current_branch], or create a new branch?"

• If continuing (with or without rename), proceed to step 3
• If creating new, follow Option A or B below

If on the default branch, choose how to proceed:

Option A: Create a new branch ``bash git pull origin [default_branch] git checkout -b feature-branch-name ` Use a meaningful name based on the work (e.g., feat/user-authentication, fix/email-validation`).

Option B: Use a worktree (recommended for parallel development) ``bash skill: ce-worktree # The skill will create a new branch from the default branch in an isolated worktree ``

Option C: Continue on the default branch

• Requires explicit user confirmation
• Only proceed after user explicitly says "yes, commit to [default_branch]"
• Never commit directly to the default branch without explicit permission

Recommendation: Use worktree if:

• You want to work on multiple features simultaneously
• You want to keep the default branch clean while experimenting
• You plan to switch between branches frequently

1. Create Task List (skip if Phase 0 already built one, or if Phase 0 routed as Trivial)

• Use the platform's task tracking tool (TaskCreate/TaskUpdate/TaskList in Claude Code, update_plan in Codex, or the equivalent on other harnesses) to break the plan into actionable tasks
• Derive tasks from the plan's implementation units, dependencies, files, test targets, and verification criteria
• When the plan defines U-IDs for Implementation Units, preserve the unit's U-ID as a prefix in the task subject (e.g., "U3: Add parser coverage"). This keeps blocker references, deferred-work notes, and final summaries anchored to the same identifier the plan uses, so progress and traceability remain unambiguous across plan edits
• Carry each unit's Execution note into the task when present
• For each unit, read the Patterns to follow field before implementing — these point to specific files or conventions to mirror
• Use each unit's Verification field as the primary "done" signal for that task
• Do not expect the plan to contain implementation code, micro-step TDD instructions, or exact shell commands
• Include dependencies between tasks
• Prioritize based on what needs to be done first
• Include testing and quality check tasks
• Keep tasks specific and completable

1. Choose Execution Strategy

Delegation routing gate: If delegation_active is true AND the input is a plan file (not a bare prompt), read references/codex-delegation-workflow.md and follow its Pre-Delegation Checks and Delegation Decision flow. If all checks pass and delegation proceeds, force serial execution and proceed directly to Phase 2 using the workflow's batched execution loop. If any check disables delegation, fall through to the standard strategy table below. If delegation is active but the input is a bare prompt (no plan file), set delegation_active to false with a brief note: "Codex delegation requires a plan file -- using standard mode." and continue with the standard strategy selection below.

After creating the task list, decide how to execute based on the plan's size and dependency structure:

| Strategy | When to use | |----------|-------------| | Inline | 1-2 small tasks, or tasks needing user interaction mid-flight. Default for bare-prompt work — bare prompts rarely produce enough structured context to justify subagent dispatch | | Serial subagents | 3+ tasks with dependencies between them. Each subagent gets a fresh context window focused on one unit — prevents context degradation across many tasks. Requires plan-unit metadata (Goal, Files, Approach, Test scenarios) | | Parallel subagents | 3+ tasks that pass the Parallel Safety Check (below). Dispatch independent units simultaneously, run dependent units after their prerequisites complete. Requires plan-unit metadata |

Parallel Safety Check — required before choosing parallel dispatch:

1. Build a file-to-unit mapping from every candidate unit's Files: section (Create, Modify, and Test paths)
2. Check for intersection — any file path appearing in 2+ units means overlap
3. If overlap is found AND worktree isolation is unavailable: downgrade to serial subagents. Log the reason (e.g., "Units 2 and 4 share config/routes.rb — using serial dispatch"). Serial subagents still provide context-window isolation without shared-directory write races.
4. If overlap is found AND worktree isolation is available: parallel dispatch is still safe — subagents work in isolation, and the overlap surfaces as a predictable merge conflict the orchestrator handles via the post-batch flow below. Log the predicted overlap so the post-batch flow knows which merges to expect conflicts on.

Even with no file overlap, parallel subagents sharing the orchestrator's working directory face git index contention (concurrent staging/committing corrupts the index) and test interference (concurrent test runs pick up each other's in-progress changes). Worktree isolation eliminates both; the shared-directory fallback constraints below mitigate them.

Subagent isolation — give each parallel subagent its own working tree:

• Claude Code (Agent tool): pass isolation: "worktree" and run_in_background: true. The harness creates a per-subagent worktree under .claude/worktrees/agent- on its own branch. Verify .claude/worktrees/ is gitignored before relying on this.
• Other platforms without built-in worktree isolation (e.g., Codex spawn_agent, Pi subagent): subagents share the orchestrator's directory.

Subagent dispatch uses your available subagent or task spawning mechanism. For each unit, give the subagent:

• The full plan file path (for overall context)
• The specific unit's Goal, Files, Approach, Execution note, Patterns, Test scenarios, and Verification
• Any resolved deferred questions relevant to that unit
• Instruction to check whether the unit's test scenarios cover all applicable categories (happy paths, edge cases, error paths, integration) and supplement gaps before writing tests

Shared-directory fallback constraints — apply only when worktree isolation is unavailable:

• Instruct each subagent: "Do not stage files (git add), create commits, or run the project test suite. The orchestrator handles testing, staging, and committing after all parallel units complete."
• These constraints prevent git index contention and test interference between concurrent subagents.
• With worktr

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Jerrylalala
• Source: Jerrylalala/compound-engineering
• License: MIT

Install and usage instructions live in the source repository linked above.