/ce-work

name: ce:work
description: Execute work efficiently while maintaining quality and finishing features
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):

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:

   git branch -m <meaningful-name>

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**

   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)**

   skill: git-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

3. **Create Todo List** _(skip if Phase 0 already built one, or if Phase 0 routed as Trivial)_

• Use your available task tracking tool (e.g., TodoWrite, task lists) to break the plan into actionable tasks
• Derive tasks from the plan's implementation