ce-work-beta

name	ce:work-beta
description	[BETA] Execute work with external delegate support. Same as ce:work but includes experimental Codex delegation mode for token-conserving code implementation.
disable-model-invocation	true
argument-hint	[Plan doc path or description of work. Blank to auto use latest plan doc]

Work Execution Command

Execute work efficiently while maintaining quality and finishing features.

Introduction

This command takes a work document (plan, specification, or todo file) 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.

Input Document

<input_document> #$ARGUMENTS </input_document>

Execution Workflow

Phase 0: Input Triage

Determine how to proceed based on what was provided in <input_document>.

Plan document (input is a file path to an existing plan, specification, or todo file) → 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

2. 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 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
   • Get user approval to proceed
   • Do not skip this - better to ask questions now than build the wrong thing

2. Setup Environment

   First, check the current branch:

   current_branch=$(git branch --show-current)
   default_branch=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@')
   
   # Fallback if remote HEAD isn't set
   if [ -z "$default_branch" ]; then
     default_branch=$(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):

Phase 2: Execute

1. Task Execution Loop

   For each task in priority order:

   while (tasks remain):
     - Mark task as in-progress
     - Read any referenced files from the plan or discovered during Phase 0
     - Look for similar patterns in codebase
     - Find existing test files for implementation files being changed (Test Discovery — see below)
     - Implement following existing conventions
     - Add, update, or remove tests to match implementation changes (see Test Discovery below)
     - Run System-Wide Test Check (see below)
     - Run tests after changes
     - Assess testing coverage: did this task change behavior? If yes, were tests written or updated? If no tests were added, is the justification deliberate (e.g., pure config, no behavioral change)?
     - Mark task as completed
     - Evaluate for incremental commit (see below)
   

   When a unit carries an Execution note, honor it. For test-first units, write the failing test before implementation for that unit. For characterization-first units, capture existing behavior before changing it. For units without an Execution note, proceed pragmatically.

   Guardrails for execution posture:

   • Do not write the test and implementation in the same step when working test-first
   • Do not skip verifying that a new test fails before implementing the fix or feature
   • Do not over-implement beyond the current behavior slice when working test-first
   • Skip test-first discipline for trivial renames, pure configuration, and pure styling work

   Test Discovery — Before implementing changes to a file, find its existing test files (search for test/spec files that import, reference, or share naming patterns with the implementation file). When a plan specifies test scenarios or test files, start there, then check for additional test coverage the plan may not have enumerated. Changes to implementation files should be accompanied by corresponding test updates — new tests for new behavior, modified tests for changed behavior, removed or updated tests for deleted behavior.

   Test Scenario Completeness — Before writing tests for a feature-bearing unit, check whether the plan's Test scenarios cover all categories that apply to this unit. If a category is missing or scenarios are vague (e.g., "validates correctly" without naming inputs and expected outcomes), supplement from the unit's own context before writing tests:

   Category	When it applies	How to derive if missing
   Happy path	Always for feature-bearing units	Read the unit's Goal and Approach for core input/output pairs

Phase 3: Quality Check

1. Run Core Quality Checks

   Always run before submitting:

   # Run full test suite (use project's test command)
   # Examples: bin/rails test, npm test, pytest, go test, etc.
   
   # Run linting (per AGENTS.md)
   # Use linting-agent before pushing to origin
   

2. Code Review (REQUIRED)

   Every change gets reviewed before shipping. The depth scales with the change's risk profile, but review itself is never skipped.

   Tier 2: Full review (default) — REQUIRED unless Tier 1 criteria are explicitly met. Invoke the ce:review skill with mode:autofix to run specialized reviewer agents, auto-apply safe fixes, and surface residual work as todos. When the plan file path is known, pass it as plan:<path>. This is the mandatory default — proceed to Tier 1 only after confirming every criterion below.

   Tier 1: Inline self-review — A lighter alternative permitted only when all four criteria are true. Before choosing Tier 1, explicitly state which criteria apply and why. If any criterion is uncertain, use Tier 2.

   • Purely additive (new files only, no existing behavior modified)
   • Single concern (one skill, one component — not cross-cutting)
   • Pattern-following (implementation mirrors an existing example with no novel logic)
   • Plan-faithful (no scope growth, no deferred questions resolved with surprising answers)

3. Final Validation

   • All tasks marked completed
   • Testing addressed -- tests pass and new/changed behavior has corresponding test coverage (or an explicit justification for why tests are not needed)
   • Linting passes
   • Code follows existing patterns
   • Figma designs match (if applicable)
   • No console errors or warnings
   • If the plan has a Requirements Trace, verify each requirement is satisfied by the completed work
   • If any Deferred to Implementation questions were noted, confirm they were resolved during execution

4. Prepare Operational Validation Plan (REQUIRED)

   • Add a ## Post-Deploy Monitoring & Validation section to the PR description for every change.
   • Include concrete:

Phase 4: Ship It

1. Capture and Upload Screenshots for UI Changes (REQUIRED for any UI work)

   For any design changes, new views, or UI modifications, capture and upload screenshots before creating the PR:

   Step 1: Start dev server (if not running)

   bin/dev  # Run in background
   

   Step 2: Capture screenshots with agent-browser CLI

   agent-browser open http://localhost:3000/[route]
   agent-browser snapshot -i
   agent-browser screenshot output.png
   

   See the agent-browser skill for detailed usage.

   Step 3: Upload using imgup skill

   skill: imgup
   # Then upload each screenshot:
   imgup -h pixhost screenshot.png  # pixhost works without API key
   # Alternative hosts: catbox, imagebin, beeimg
   

   What to capture:

   • New screens: Screenshot of the new UI
   • Modified screens: Before AND after screenshots
   • Design implementation: Screenshot showing Figma design match

2. Commit and Create Pull Request

   Load the git-commit-push-pr skill to handle committing, pushing, and PR creation. The skill handles convention detection, branch safety, logical commit splitting, adaptive PR descriptions, and attribution badges.

   When providing context for the PR description, include:

   • The plan's summary and key decisions
   • Testing notes (tests added/modified, manual testing performed)
   • Screenshot URLs from step 1 (if applicable)
   • Figma design link (if applicable)
   • The Post-Deploy Monitoring & Validation section (see Phase 3 Step 4)

   If the user prefers to commit without creating a PR, load the git-commit skill instead.

3. Update Plan Status

   If the input document has YAML frontmatter with a status field, update it to completed:

   status: active  →  status: completed
   

4. Notify User

   • Summarize what was completed

---

Swarm Mode with Agent Teams (Optional)

For genuinely large plans where agents need to communicate with each other, challenge approaches, or coordinate across 10+ tasks with persistent specialized roles, use agent team capabilities if available (e.g., Agent Teams in Claude Code, multi-agent workflows in Codex).

Agent teams are typically experimental and require opt-in. Do not attempt to use agent teams unless the user explicitly requests swarm mode or agent teams, and the platform supports it.

When to Use Agent Teams vs Subagents

Agent Teams	Subagents (standard mode)
Agents need to discuss and challenge each other's approaches	Each task is independent — only the result matters
Persistent specialized roles (e.g., dedicated tester running continuously)	Workers report back and finish
10+ tasks with complex cross-cutting coordination	3-8 tasks with clear dependency chains
User explicitly requests "swarm mode" or "agent teams"	Default for most plans

Most plans should use subagent dispatch from standard mode. Agent teams add significant token cost and coordination overhead — use them when the inter-agent communication genuinely improves the outcome.

Agent Teams Workflow

1. Create team — use your available team creation mechanism
2. Create task list — parse Implementation Units into tasks with dependency relationships
3. Spawn teammates — assign specialized roles (implementer, tester, reviewer) based on the plan's needs. Give each teammate the plan file path and their specific task assignments
4. Coordinate — the lead monitors task completion, reassigns work if someone gets stuck, and spawns additional workers as phases unblock
5. Cleanup — shut down all teammates, then clean up the team resources

---

External Delegate Mode (Optional)

For plans where token conservation matters, delegate code implementation to an external delegate (currently Codex CLI) while keeping planning, review, and git operations in the current agent.

This mode integrates with the existing Phase 1 Step 4 strategy selection as a task-level modifier - the strategy (inline/serial/parallel) still applies, but the implementation step within each tagged task delegates to the external tool instead of executing directly.

When to Use External Delegation

External Delegation	Standard Mode
Task is pure code implementation	Task requires research or exploration
Plan has clear acceptance criteria	Task is ambiguous or needs iteration
Token conservation matters (e.g., Max20 plan)	Unlimited plan or small task
Files to change are well-scoped	Changes span many interconnected files

Enabling External Delegation

External delegation activates when any of these conditions are met:

• The user says "use codex for this work", "delegate to codex", or "delegate mode"
• A plan implementation unit contains Execution target: external-delegate in its Execution note (set by ce:plan)

The specific delegate tool is resolved at execution time. Currently the only supported delegate is Codex CLI. Future delegates can be added without changing plan files.

Environment Guard

Before attempting delegation, check whether the current agent is already running inside a delegate's sandbox. Delegation from within a sandbox will fail silently or recurse.

Check for known sandbox indicators:

• CODEX_SANDBOX environment variable is set
• CODEX_SESSION_ID environment variable is set
• The filesystem is read-only at .git/ (Codex sandbox blocks git writes)

If any indicator is detected, print "Already running inside a delegate sandbox - using standard mode." and proceed with standard execution for that task.

External Delegation Workflow

When external delegation is active, follow this workflow for each tagged task. Do not skip delegation because a task seems "small", "simple", or "faster inline". The user or plan explicitly requested delegation.

1. Check availability

   Verify the delegate CLI is installed. If not found, print "Delegate CLI not installed - continuing with standard mode." and proceed normally.

2. Build prompt — For each task, assemble a prompt from the plan's implementation unit (Goal, Files, Approach, Conventions from project CLAUDE.md/AGENTS.md). Include rules: no git commits, no PRs, run git status and git diff --stat when done. Never embed credentials or tokens in the prompt - pass auth through environment variables.

3. Write prompt to file — Save the assembled prompt to a unique temporary file to avoid shell quoting issues and cross-task races. Use a unique filename per task.

4. Delegate — Run the delegate CLI, piping the prompt file via stdin (not argv expansion, which hits ARG_MAX on large prompts). Omit the model flag to use the delegate's default model, which stays current without manual updates.

5. Review diff — After the delegate finishes, verify the diff is non-empty and in-scope. Run the project's test/lint commands. If the diff is empty or out-of-scope, fall back to standard mode for that task.

6. Commit — The current agent handles all git operations. The delegate's sandbox blocks .git/index.lock writes, so the delegate cannot commit. Stage changes and commit with a conventional message.

7. Error handling — On any delegate failure (rate limit, error, empty diff), fall back to standard mode for that task. Track consecutive failures - after 3 consecutive failures, disable delegation for remaining tasks and print "Delegate disabled after 3 consecutive failures - completing remaining tasks in standard mode."

Mixed-Model Attribution

When some tasks are executed by the delegate and others by the current agent, use the following attribution in Phase 4:

• If all tasks used the delegate: attribute to the delegate model
• If all tasks used standard mode: attribute to the current agent's model
• If mixed: use Generated with [CURRENT_MODEL] + [DELEGATE_MODEL] via [HARNESS] and note which tasks were delegated in the PR description

---

Key Principles

Start Fast, Execute Faster

• Get clarification once at the start, then execute
• Don't wait for perfect understanding - ask questions and move
• The goal is to finish the feature, not create perfect process

The Plan is Your Guide

• Work documents should reference similar code and patterns
• Load those references and follow them
• Don't reinvent - match what exists

Test As You Go

• Run tests after each change, not at the end
• Fix failures immediately
• Continuous testing prevents big surprises

Quality is Built In

• Follow existing patterns
• Write tests for new code
• Run linting before pushing
• Review every change — inline for simple additive work, full review for everything else

Ship Complete Features

• Mark all tasks completed before moving on
• Don't leave features 80% done
• A finished feature that ships beats a perfect feature that doesn't

Quality Checklist

Before creating PR, verify:

• All clarifying questions asked and answered
• All tasks marked completed
• Testing addressed -- tests pass AND new/changed behavior has corresponding test coverage (or an explicit justification for why tests are not needed)
• Linting passes (use linting-agent)
• Code follows existing patterns
• Figma designs match implementation (if applicable)
• Before/after screenshots captured and uploaded (for UI changes)
• Commit messages follow conventional format
• PR description includes Post-Deploy Monitoring & Validation section (or explicit no-impact rationale)
• Code review completed (inline self-review or full ce:review)
• PR description includes summary, testing notes, and screenshots
• PR description includes Compound Engineered badge with accurate model and harness

Code Review Tiers

Every change gets reviewed. The tier determines depth, not whether review happens.

Tier 2 (full review) — REQUIRED default. Invoke ce:review mode:autofix with plan:<path> when available. Safe fixes are applied automatically; residual work surfaces as todos. Always use this tier unless all four Tier 1 criteria are explicitly confirmed.

Tier 1 (inline self-review) — permitted only when all four are true (state each explicitly before choosing):

• Purely additive (new files only, no existing behavior modified)
• Single concern (one skill, one component — not cross-cutting)
• Pattern-following (mirrors an existing example, no novel logic)
• Plan-faithful (no scope growth, no surprising deferred-question resolutions)

Common Pitfalls to Avoid

• Analysis paralysis - Don't overthink, read the plan and execute
• Skipping clarifying questions - Ask now, not after building wrong thing
• Ignoring plan references - The plan has links for a reason
• Testing at the end - Test continuously or suffer later
• Forgetting to track progress - Update task status as you go or lose track of what's done
• 80% done syndrome - Finish the feature, don't move on early
• Skipping review - Every change gets reviewed; only the depth varies