ce:work

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
   • Validate the plan's Prior-Art Survey state before environment setup using this exhaustive partition:
     • No survey section + recorded date before 2026-08-18: the plan predates this contract; proceed without rejecting it. Read the plan's YAML frontmatter date: first. If that is absent, use only another explicit, trustworthy creation date defined by the host workflow or document format; a filename, location, or VCS record counts only when the host explicitly defines it as authoritative, and version control is never required.
     • No survey section + recorded date on or after 2026-08-18: this is a contract failure; stop and name the missing section. Resolve it by rerunning planning and recording exactly one schema-conforming structured survey block.
     • No survey section + no determinable date: do not guess whether the plan is old or recent. Stop and report that the grandfather condition cannot be established. Resolve it by recording a trustworthy plan date; if the date cannot be established, rerun planning and add the required survey rather than proceeding on an assumption.
     • Survey section present and valid: it contains exactly one fenced json block, and that block validates against skills/ce-plan/references/prior-art-survey-schema.json; continue to the remaining workflow checks below. A present section is never grandfathered by its date.
     • Survey section present and invalid: stop before setup when any of these conditions applies:
       1. Empty or non-unique survey block: the section is present but empty, or contains zero or multiple fenced json blocks. Resolve it by rerunning planning and recording exactly one schema-conforming structured survey block.
       2. Malformed or schema-invalid survey block: the sole block is not valid JSON or fails schema validation. Resolve it by replacing the block with one valid survey payload; prose or placeholder values do not satisfy the contract.
       3. Unaccepted failure verdict: the validated verdict is unscoped or unresolved and the block has no recorded user acceptance for that same verdict. Resolve it by narrowing the scope, increasing the bounded budget, or getting the user to accept the uncertainty and recording matching acceptance.
       4. Stale surveyed scope: the recorded scope has changed since the survey ran. Check only the workspace or subtree in scope, not the whole repository. When freshness.vcs_reference is present and usable VCS data is available, compare the current VCS reference or scoped diff; otherwise compare the current portable digest/baseline with freshness.scope_baseline. If neither comparison can be performed, stop and request a fresh survey or explicit re-baselining rather than assuming the result is fresh. Resolve a stale result by rerunning the survey against the current scope and updating the plan.
   • When refusing execution for a survey condition, name the condition that fired and the concrete resolution required; do not fail opaquely.
   • 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