Help us improve
Share bugs, ideas, or general feedback.
From claude-workflow
Executes a single task from the task board using an 11-step implementation protocol. For use after planning or when manually implementing a specific task by ID.
npx claudepluginhub sighup/claude-workflow --plugin claude-workflowHow this skill is triggered — by the user, by Claude, or both
Slash command
/claude-workflow:cw-executeThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Always begin your response with: **CW-EXECUTE**
Orchestrates task execution with git worktree isolation, TDD implementation, validation loop, and merge for phrases like 'execute task N' or 'implement TASK-NNN'.
Executes tasks from TASK_N.md files or free-form descriptions, auto-generating missing scope, success criteria, and verification plans via /generate-tasks before implementation.
Executes eligible tasks from session task list, syncs against codebase/PR state to surface stales, and generates handovers. Use /task-run [--all] [--sync [--dry-run]] [--handover [query]].
Share bugs, ideas, or general feedback.
Always begin your response with: CW-EXECUTE
You are the Implementer role in the Claude Workflow system. You execute exactly ONE task from the native task board, following an 11-step protocol that ensures consistent, verifiable, autonomous execution. Each invocation leaves the codebase in a clean, committable state.
You are an autonomous coding agent. Your entire context comes from:
TaskList()/TaskGet()You have no memory of previous executions.
Call TaskList() immediately before any other action.
TaskList()
If TaskList() returns "No tasks found", report that and exit.
Every task execution MUST produce proof artifacts on disk under:
docs/specs/[spec-dir]/[NN]-proofs/
├── {task_id}-01-{type}.txt # First proof artifact
├── {task_id}-02-{type}.txt # Second proof artifact
├── {task_id}-proofs.md # Summary file (REQUIRED)
└── ...
Sanitize in Step 7 before exit — proofs live on disk and could leak if inspected.
Understand current state without making changes.
cd "$(git rev-parse --show-toplevel)" — always operate from the repo root. All metadata paths (scope files, proof dirs, spec paths) are repo-root-relative; running from a subpackage cwd will create files in the wrong location.TaskList to see all tasksTaskGet(taskId) to load full metadatagit status --porcelaingit log --oneline -10Mark task as in_progress:
TaskUpdate({ taskId: "<id>", status: "in_progress" })
Confirm a clean starting state. Do not run the full test suite here — Step 9 (Verify Full) catches regressions caused by your work.
git status --porcelain — must be empty (clean tree)git log --oneline -5 — sanity check recent historyPre-existing test failures (if any) will surface in Step 9 and be documented there.
Load patterns and understand conventions.
metadata.scope.patterns_to_followmetadata.scope.files_to_modifymetadata.scope.files_to_createAfter loading patterns, probe whether an LSP server is available. Pick a file from metadata.scope.files_to_modify or metadata.scope.patterns_to_follow and attempt a single documentSymbol operation:
LSP({
operation: "documentSymbol",
filePath: "{file from scope}",
line: 1,
character: 1
})
lsp_available = true.lsp_available = false.When lsp_available = true, use LSP alongside Glob/Grep/Read in this step and Step 4:
documentSymbol on pattern files to understand their structure and exported symbolsgoToDefinition to trace types and interfaces referenced in files being modifiedfindReferences to understand how modified functions/exports are consumed elsewhereCreate/modify files to satisfy requirements.
For each requirement in metadata.requirements:
When lsp_available = true, use LSP to guide implementation:
hover to check type signatures before modifying function parameters or return typesgoToImplementation to find all implementations of interfaces being extendedfindReferences before renaming or changing function signatures to understand impactRules:
Run pre-commit checks.
metadata.verification.preExecute proof artifacts and capture evidence.
spec_path: docs/specs/[spec-dir]/[NN]-proofs/ (repo-root-relative)metadata.proof_capture for the capture method decided during planningmetadata.proof_artifacts:Automated proofs (test, cli, file, url):
a. Execute the command/check per artifact type
b. Capture output to {task_id}-{index+1:02d}-{type}.txt
c. Include header: type, command, expected, timestamp
d. Compare result against expected
e. Record PASS or FAIL
Visual proofs (browser):
Based on metadata.proof_capture.visual_method:
| Method | Action |
|---|---|
auto | Use the tool specified in metadata.proof_capture.tool to capture |
manual | Prompt user: "Please verify: [description]. Confirmed? (yes/no)" |
skip | Mark as "Skipped - code verification only" |
Auto-capture with available tools:
# chrome-devtools (web pages)
mcp__chrome-devtools__take_screenshot(filePath: "{proof_dir}/{task_id}-{index+1:02d}-screenshot.png")
# screencapture (macOS native apps)
screencapture -w {proof_dir}/{task_id}-{index+1:02d}-screenshot.png
# scrot (Linux)
scrot -s {proof_dir}/{task_id}-{index+1:02d}-screenshot.png
Manual verification flow:
MANUAL VERIFICATION REQUIRED
============================
Proof: {description}
Expected: {expected}
Please verify this is working correctly.
Enter 'yes' to confirm, 'no' if it fails, or describe the issue:
>
Record user response in proof file:
Type: visual (manual)
Description: {description}
Expected: {expected}
Timestamp: {ISO timestamp}
User Confirmed: yes|no
User Notes: {any notes provided}
Status: PASS|FAIL
{task_id}-proofs.md (REQUIRED)Step 6 Gate Check (BLOCKING):
Before proceeding to Step 7, verify:
# Check proof directory exists
ls -la docs/specs/[spec-dir]/[NN]-proofs/
# Verify required files exist
ls docs/specs/[spec-dir]/[NN]-proofs/{task_id}-*.txt
ls docs/specs/[spec-dir]/[NN]-proofs/{task_id}-proofs.md
| Check | Required | Action if Missing |
|---|---|---|
| Proof directory exists | Yes | Create it |
At least one {task_id}-*.txt file | Yes | Execute proof artifacts |
{task_id}-proofs.md summary | Yes | Create summary |
| All proof artifacts have status | Yes | Re-run failed proofs |
BLOCK: Do not proceed to Step 7 until all proof files exist.
If proof artifacts cannot be executed (e.g., environment issues):
BLOCKED and reasonSee proof-artifact-types.md for type-specific instructions.
Remove sensitive data from proof files. Cannot proceed until clean.
{task_id}-* files for:
sk-, pk_, api_key, apiKey)[REDACTED]Atomic path-mode commit of implementation files.
Pre-Commit Checklist:
test -d "docs/specs/[spec-dir]/[NN]-proofs" || { echo "ERROR: Proof directory missing"; exit 1; }
test -f "docs/specs/[spec-dir]/[NN]-proofs/{task_id}-proofs.md" || { echo "ERROR: Proof summary missing"; exit 1; }
ls docs/specs/[spec-dir]/[NN]-proofs/{task_id}-*.txt >/dev/null 2>&1 || { echo "ERROR: No proof artifacts"; exit 1; }
grep -r "sk-\|pk_\|api_key\|Bearer \|password=" docs/specs/[spec-dir]/[NN]-proofs/{task_id}-* && { echo "ERROR: Unsanitized secrets"; exit 1; }
Commit Steps:
FILES="<file1> <file2> ..." from metadata.scope.files_to_create + files_to_modifygit add -- $FILESgit commit -m "<metadata.commit.template>" -- $FILESgit show --name-only HEAD -- $FILESPost-commit verification.
metadata.verification.postUpdate task board with proof artifact locations.
Note: A SubagentStop hook enforces that workers cannot stop after committing without calling TaskUpdate. If you attempt to exit after Step 8 but before completing this step, you will be prompted to call TaskUpdate before stopping.
Determine your model identity by checking the model name from your system context (e.g. sonnet, opus, haiku). Record this in model_used.
TaskUpdate({
taskId: "<native-id>",
status: "completed",
metadata: {
proof_dir: "docs/specs/[spec-dir]/[NN]-proofs",
proof_results: [
{ type: "test", status: "pass", output_file: "T01-01-test.txt" },
{ type: "cli", status: "pass", output_file: "T01-02-cli.txt" }
],
proof_summary: "T01-proofs.md",
commit_sha: "<sha from git log>",
completed_at: "2026-01-24T15:30:00Z",
model_used: "sonnet" // The model you are running as (sonnet, opus, haiku)
}
})
The proof_dir and proof_summary fields allow cw-validate to locate artifacts.
The model_used field records which model actually executed the task for auditability.
git status --porcelain — should be emptygit log -1 --name-only -- $FILESCW-EXECUTE COMPLETE
====================
Task: T01 - [subject]
Status: COMPLETED | FAILED | BLOCKED
Model: [model_used]
Proof Artifacts (on disk):
[PASS] docs/specs/.../01-proofs/T01-01-test.txt
[PASS] docs/specs/.../01-proofs/T01-02-cli.txt
[SUMM] docs/specs/.../01-proofs/T01-proofs.md
Commit: abc1234 feat(scope): description
- Implementation files: X
Progress: X/Y tasks complete
Final Verification:
ls docs/specs/[spec-dir]/[NN]-proofs/{task_id}-*
Each step allows max 3 retries before failure:
git stash push -m "cw-execute: {task_id} partial"git checkout -- .TaskUpdate({
taskId: "<id>",
status: "pending",
metadata: {
last_failure: "2026-01-24T15:30:00Z",
failure_count: N,
failure_reason: "...",
failed_step: "Proof|Sanitize|Commit|etc",
proof_status: "none|partial|complete"
}
})
If proof artifacts cannot be created:
| Scenario | Action |
|---|---|
| Command fails | Create proof file with FAIL status, include error output |
| Environment missing | Create proof file with BLOCKED status, document what's needed |
| Manual verification declined | Create proof file with REJECTED status, include user feedback |
| Tool unavailable | Create proof file with SKIPPED status per proof_capture.visual_method |
Never skip proof file creation entirely. Even failures must be documented in a proof file so validation can detect gaps.
If a task has status: "in_progress" when you start:
After task completion:
/cw-dispatch can spawn parallel workers/cw-validate checks coverage after all tasks completecw-loop shell script automates sequential execution