Execute work plans efficiently while maintaining quality and finishing features
From compound-engineeringnpx claudepluginhub iliaal/compound-engineering-plugin --plugin compound-engineering[plan file, specification, or todo file path]workflows//workExecutes a development plan end-to-end with checks for <fn-N or idea>. Supports --branch (current|new|worktree) and --review (rp|export|none) options.
/workExecutes a plan file end-to-end with checks using the flow-work skill. Accepts plan file path, Beads ID, or title; prompts for input if none provided.
/workAuto-classifies tasks from descriptions, folder paths, or issue IDs and routes to workflow orchestrators; resumes existing tasks from .maister folders.
/workAuto-classifies tasks from descriptions, folder paths, or issue identifiers (GitHub/Jira/Azure DevOps) and routes to workflow orchestrators. Resumes existing tasks.
/workExecutes a work plan from a plan/spec/todo file path: clarifies requirements, sets up git branch or worktree, generates prioritized todos, and completes tasks maintaining quality.
/workExecutes epic tasks from blueprint using fresh Claude instances via relay script, with quality gate verification and configurable retries.
Execute a work plan efficiently while maintaining quality and finishing features.
This command takes a work document (plan, specification, or todo file) and executes it systematically. The focus is on shipping complete features by understanding requirements quickly, following existing patterns, and maintaining quality throughout.
Input document: #$ARGUMENTS
Read Plan and Clarify
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):
[current_branch], or create a new branch?"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
Recommendation: Use worktree if:
Create Todo List
Task Execution Loop
For each task in priority order:
while (tasks remain):
- Mark task as in_progress via TaskUpdate
- Read any referenced files from the plan
- Look for similar patterns in codebase
- Implement following existing conventions
- Write tests for new functionality
- Run System-Wide Test Check (see below)
- Run tests after changes
- Mark task as completed via TaskUpdate
- Mark off the corresponding checkbox in the plan file ([ ] → [x])
- Evaluate for incremental commit (see below)
System-Wide Test Check -- Before marking a task done, run the blast-radius check from the verification-before-completion skill's system-wide-test-check.md. Skip for leaf-node changes with no callbacks or state persistence.
IMPORTANT: Always update the original plan document by checking off completed items. Use the Edit tool to change - [ ] to - [x] for each task you finish. This keeps the plan as a living document showing progress and ensures no checkboxes are left unchecked.
Incremental Commits
After completing each task, evaluate whether to create an incremental commit:
| Commit when... | Don't commit when... |
|---|---|
| Logical unit complete (model, service, component) | Small part of a larger unit |
| Tests pass + meaningful progress | Tests failing |
| About to switch contexts (backend → frontend) | Purely scaffolding with no behavior |
| About to attempt risky/uncertain changes | Would need a "WIP" commit message |
Heuristic: "Can I write a commit message that describes a complete, valuable change? If yes, commit. If the message would be 'WIP' or 'partial X', wait."
Commit workflow:
# 1. Verify tests pass (use project's test command)
# Examples: npm test, pytest, php artisan test, go test, etc.
# 2. Stage only files related to this logical unit (not `git add .`)
git add <files related to this logical unit>
# 3. Commit with conventional message
git commit -m "feat(scope): description of this unit"
Handling merge conflicts: If conflicts arise during rebasing or merging, resolve them immediately. Incremental commits make conflict resolution easier since each commit is small and focused.
Note: Incremental commits use clean conventional messages without attribution footers.
Follow Existing Patterns
Test Continuously
Figma Design Sync (if applicable)
For UI work with Figma designs:
Track Progress
Subagent Execution Discipline
When dispatching subagents to implement tasks:
Fresh agent per task. Spawn a new subagent for each task rather than reusing one with accumulated context. Stale context from previous tasks causes drift, incorrect assumptions about current state, and hallucinated file contents. One task, one agent, one clean slate.
Two-stage review on deliverables. After each subagent completes, verify spec compliance FIRST: does the output match what was requested? Then evaluate code quality. Order matters -- high-quality code that solves the wrong problem is still wrong. If spec compliance fails, re-dispatch with clarified requirements before reviewing quality.
Model selection by task complexity. Match model cost to task difficulty:
| Task type | Model | Examples |
|---|---|---|
| Mechanical | Cheapest/fastest (e.g., Haiku) | Boilerplate, simple renames, config changes, formatting |
| Integration | Default model | Connecting components, API wiring, service plumbing |
| Architectural | Best available | New abstractions, cross-cutting concerns, design decisions |
When uncertain, default up -- the cost of a wrong architectural decision far exceeds the token savings from a cheaper model.
Implementer status protocol. Require subagents to report status using one of these values:
Treat any response without an explicit status as NEEDS_CONTEXT and follow up.
Before moving to quality checks, run the verification-before-completion gate:
Do not proceed to Phase 3 if verification fails.
Run Core Quality Checks
Always run before submitting:
# Run full test suite (use project's test command)
# Examples: npm test, pytest, php artisan test, go test, etc.
# Run linting (use project's lint command per CLAUDE.md)
Consider Reviewer Agents (Optional)
Use for complex, risky, or large changes. Read agents from compound-engineering.local.md frontmatter (review_agents). If no settings file, run /setup to create one.
Run configured agents in parallel with Task tool. Present findings and address critical issues.
Final Validation
Prepare Operational Validation Plan (REQUIRED)
## Post-Deploy Monitoring & Validation section to the PR description for every change.No additional operational monitoring required and a one-line reason.Capture and Upload Screenshots for UI Changes (REQUIRED for any UI work)
For any design changes, new views, or UI modifications, you MUST capture and upload screenshots:
Step 1: Start dev server (if not running)
npm run dev # Run in background
Step 2: Capture screenshots with agent-browser CLI
agent-browser open http://localhost:3000/[route]
agent-browser snapshot -i
agent-browser screenshot output.png
Run agent-browser --help for full CLI usage.
Step 3: Upload screenshots
# Upload using imgup CLI (if available):
imgup -h pixhost screenshot.png # pixhost works without API key
# Alternative hosts: catbox, imagebin, beeimg
What to capture:
IMPORTANT: Always include uploaded image URLs in PR description. This provides visual context for reviewers and documents the change.
Update Plan Status
If the input document has YAML frontmatter with a status field, update it to completed:
status: active → status: completed
Finish the Branch
Present options: Merge locally (solo work) / Push + PR (team work) / Keep as-is (WIP) / Discard (requires typed "discard" confirmation).
For PRs, use this template:
## Summary
- [What was built and why]
- [Key decisions made]
## Testing
- [Tests added/modified]
- [Manual testing performed]
## Post-Deploy Monitoring & Validation
- **What to monitor**: [logs, metrics, dashboards]
- **Expected healthy behavior**: [signals]
- **Failure signals / rollback trigger**: [trigger + action]
- **If no operational impact**: `No additional monitoring required: <reason>`
## Before / After Screenshots
| Before | After |
|--------|-------|
|  |  |
Safety rules:
git revert -m 1 HEAD), keep branch, diagnoseNotify User
For swarm execution, follow the orchestrating-swarms skill.
Before creating PR, verify:
workflows:plan (provides the plan to execute)verification-before-completion, writing-tests, debugging