Help us improve
Share bugs, ideas, or general feedback.
From compound-engineering
Executes 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.
npx claudepluginhub gvkhosla/compound-engineering-pi --plugin compound-engineeringHow this command is triggered — by the user, by Claude, or both
Slash command
/compound-engineering:work [plan file, specification, or todo file path]workflows/Files this command reads when invoked
The summary Claude sees in its command listing — used to decide when to auto-load this command
# Work Plan Execution Command Execute a work plan efficiently while maintaining quality and finishing features. ## Introduction 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 <input_document> #$ARGUMENTS </input_document> ## Execution Workflow ### Phase 1: Quick Start 1. **Read Plan and Clarify** - Read the work document completely - Review any references...
/SKILLExecutes implementation plans from a specified or auto-detected folder using Superpower Loop, agent teams for task creation, parallel batch execution, verification, and git commits.
/buildExecutes a Rails work plan from a file, sets up feature branch or worktree, breaks into tasks, and implements features while maintaining quality.
/makeCreates structured implementation plan in docs/plans/yyyymmdd-<task-name>.md for described feature or task via interactive context gathering and focused questions.
/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.
/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.
Share bugs, ideas, or general feedback.
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 </input_document>
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 in TodoWrite
- Read any referenced files from the plan
- Look for similar patterns in codebase
- Implement following existing conventions
- Write tests for new functionality
- Run tests after changes
- Mark task as completed in TodoWrite
- Mark off the corresponding checkbox in the plan file ([ ] → [x])
- Evaluate for incremental commit (see below)
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: bin/rails test, npm test, pytest, 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. The final Phase 4 commit/PR includes the full attribution.
Follow Existing Patterns
Test Continuously
Figma Design Sync (if applicable)
For UI work with Figma designs:
Track Progress
Run Core Quality Checks
Always run before submitting:
# Run full test suite (use project's test command)
# Examples: bin/rails test, npm test, pytest, go test, etc.
# Run linting (per CLAUDE.md)
# Use linting-agent before pushing to origin
Consider Reviewer Agents (Optional)
Use for complex, risky, or large changes:
Run reviewers in parallel with Task tool:
Task(code-simplicity-reviewer): "Review changes for simplicity"
Task(kieran-rails-reviewer): "Check Rails conventions"
Present findings to user and address critical issues.
Final Validation
Create Commit
git add .
git status # Review what's being committed
git diff --staged # Check the changes
# Commit with conventional format
git commit -m "$(cat <<'EOF'
feat(scope): description of what and why
Brief explanation if needed.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
EOF
)"
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)
bin/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
See the agent-browser skill for detailed usage.
Step 3: Upload using imgup skill
skill: imgup
# Then upload each screenshot:
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.
Create Pull Request
git push -u origin feature-branch-name
gh pr create --title "Feature: [Description]" --body "$(cat <<'EOF'
## Summary
- What was built
- Why it was needed
- Key decisions made
## Testing
- Tests added/modified
- Manual testing performed
## Before / After Screenshots
| Before | After |
|--------|-------|
|  |  |
## Figma Design
[Link if applicable]
---
[](https://github.com/EveryInc/compound-engineering-plugin) 🤖 Generated with [Claude Code](https://claude.com/claude-code)
EOF
)"
Notify User
For complex plans with multiple independent workstreams, enable swarm mode for parallel execution with coordinated agents.
| Use Swarm Mode when... | Use Standard Mode when... |
|---|---|
| Plan has 5+ independent tasks | Plan is linear/sequential |
| Multiple specialists needed (review + test + implement) | Single-focus work |
| Want maximum parallelism | Simpler mental model preferred |
| Large feature with clear phases | Small feature or bug fix |
To trigger swarm execution, say:
"Make a Task list and launch an army of agent swarm subagents to build the plan"
Or explicitly request: "Use swarm mode for this work"
When swarm mode is enabled, the workflow changes:
Create Team
Teammate({ operation: "spawnTeam", team_name: "work-{timestamp}" })
Create Task List with Dependencies
Spawn Specialized Teammates
Task({
team_name: "work-{timestamp}",
name: "implementer",
subagent_type: "general-purpose",
prompt: "Claim implementation tasks, execute, mark complete",
run_in_background: true
})
Task({
team_name: "work-{timestamp}",
name: "tester",
subagent_type: "general-purpose",
prompt: "Claim testing tasks, run tests, mark complete",
run_in_background: true
})
Coordinate and Monitor
Cleanup
Teammate({ operation: "requestShutdown", target_agent_id: "implementer" })
Teammate({ operation: "requestShutdown", target_agent_id: "tester" })
Teammate({ operation: "cleanup" })
See the orchestrating-swarms skill for detailed swarm patterns and best practices.
Before creating PR, verify:
Don't use by default. Use reviewer agents only when:
For most features: tests + linting + following patterns is sufficient.