ce-work

A work-execution command that takes a plan document or a bare prompt describing work and executes it systematically, with the focus on shipping complete features by understanding requirements quickly, following existing patterns, and maintaining quality throughout. It accepts either a path to an existing plan or specification, or a plain description of the work, and can auto-detect the latest plan when invoked blank.

Execution opens with Phase 0 input triage. For a plan document it reads the metadata first (YAML frontmatter for markdown or the header text for HTML); a plan marked execution knowledge-work is a non-code plan handled by a separate carve-out, while code plans proceed to the normal lifecycle. For a bare prompt it scans the work area to identify files likely to change and their existing tests, then assesses complexity and routes accordingly: trivial changes (one or two files, no behavioral change) are implemented directly without a task list, small or medium scope builds a task list, and large cross-cutting work that touches auth, payments, or migrations is flagged as benefiting from a brainstorm or plan command first. Phase 1 reads the plan completely, treating it as a decision artifact rather than an execution script, and mines sections such as Implementation Units, Work Breakdown, Requirements, Files, Test Scenarios, and Verification. It honors per-unit Execution notes (for example test-first or characterization-first) and surfaces Deferred to Implementation, Implementation-Time Unknowns, and Scope Boundaries before starting.

Environment setup detects the current and default branch and handles branching carefully: it suggests renaming meaningless or auto-generated branch names, offers a new branch, a worktree (recommended for parallel development via the ce-worktree skill), or continuing on the default branch only with explicit user confirmation, and never commits directly to the default branch without permission. Tasks are tracked with the platform's task tooling. The plan body is never edited during execution: progress lives in git commits and the task tracker, and legacy checkbox or status marks are ignored as state.