Submit
All skills
Skillintermediate

Work Execution Command

Execute work efficiently while maintaining quality and finishing features.

Claude Code Knowledge Pack7/10/2026

Overview

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.

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

  2. Assess complexity and route

    ComplexitySignalsAction
    Trivial1-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 / MediumClear scope, under ~10 filesBuild a task list from discovery. Proceed to Phase 1 step 2
    LargeCross-cutting, architectural decisions, 10+ files, touches auth/payments/migrationsInform 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
    • 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.

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

  3. 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

  4. Choose Execution Strategy

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

    StrategyWhen to use
    Inline1-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 subagents3+ 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 subagents3+ 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 any overlap is found, 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 risks

    Even with no file overlap, parallel subagents sharing a 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). The parallel subagent constraints below mitigate these.

    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

    Parallel subagent constraints — when dispatching units in parallel (not serial or inline):

    • 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

    Permission mode: Omit the mode parameter when dispatching subagents so the user's configured permission settings apply. Do not pass mode: "auto" — it overrides user-level settings like bypassPermissions.

    After each subagent completes (serial mode):

    1. Review the subagent's diff — verify changes match the unit's scope and Files: list
    2. Run the relevant test suite to confirm the tree is healthy
    3. If tests fail, diagnose and fix before proceeding — do not dispatch dependent units on a broken tree
    4. Update the task list (do not edit the plan body — progress is carried by the commit)
    5. Dispatch the next unit

    After all parallel subagents in a batch complete:

    1. Wait for every subagent in the current parallel batch to finish before acting on any of their results
    2. Cross-check for discovered file collisions: compare the actual files modified by all subagents in the batch (not just their declared Files: lists). Subagents may create or modify files not anticipated during planning — this is expected, since plans describe what not how. A collision only matters when 2+ subagents in the same batch modified the same file. In a shared working directory, only the last writer's version survives — the other unit's changes to that file are lost. If a collision is detected: commit all non-colliding files from all units first, then re-run the affected units serially for the shared file so each builds on the other's committed work
    3. For each completed unit, in dependency order: review the diff, run the relevant test suite, stage only that unit's files, and commit with a conventional message derived from the unit's Goal
    4. If tests fail after committing a unit's changes, diagnose and fix before committing the next unit
    5. Update the task list (do not edit the plan body — progress is carried by the commits just made)
    6. Dispatch the next batch of independent units, or the next dependent unit

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
  - **If the unit's work is already present and matches the plan's intent** (files exist with the expected capability, or the unit's `Verification` criteria are already satisfied by the current code), the work has likely shipped on a prior branch or session. Verify it matches, mark the task complete, and move on. Do not silently reimplement.
  - 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 e