From rafayels-engineering
Execute work plans efficiently while maintaining quality and finishing features
npx claudepluginhub rafayelgardishyan/rafayels-engineering[plan file, specification, or todo file path]workflows/# 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 0.5: Retrieve Relevant Cases from Memory Before starting work, query memory for relevant past implementation c...
/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.
/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 identifiers (GitHub/Jira/Azure DevOps) and routes to workflow orchestrators. Resumes existing tasks.
/workAuto-classifies tasks from descriptions, folder paths, or issue IDs and routes to workflow orchestrators; resumes existing tasks from .maister folders.
/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 </input_document>
Before starting work, query memory for relevant past implementation cases:
python3 ${CLAUDE_PLUGIN_ROOT}/skills/memory/scripts/memory.py query \
"<plan title or feature description>" --phase work --k 3 --format md 2>/dev/null
If cases are returned, include them in the work context. Pay attention to past failure cases — they list things to avoid. Exit code 75 or empty output means proceed without injection.
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
- FOR pure coding tasks: delegate to Codex via the codex-bridge MCP server first
- Review Codex output; integrate, fix, or iterate as needed
- Implement any remaining work 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: go 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.
Delegate to Codex
When a task is a pure coding task (implement X, refactor Y, add Z) with clear requirements:
delegate_coding_task from the codex-bridge MCP servertask_description, file_paths, and any relevant contextstatus, final_message, and file_changesUse codex_answer_question for quick technical clarifications before deciding whether to delegate.
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: go 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(rafayel-go-reviewer): "Check Go 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
Capture Case to Memory
After the PR is created, capture this work as a memory case:
python3 ${CLAUDE_PLUGIN_ROOT}/skills/memory/scripts/memory.py write \
--phase work \
--type solution \
--query "<plan title or feature description>" \
--title "<short description of what was built>" \
--plan "<approach summary>" \
--trajectory '<key actions as JSON>' \
--outcome "<PR URL>" \
--tags "<JSON array of tags>" \
--json 2>/dev/null
Store the returned case_id for later signal emission.
Emit Signals
python3 ${CLAUDE_PLUGIN_ROOT}/skills/memory/scripts/memory.py signal \
<case_id> ci 1.0 --source "tests-passed" 2>/dev/null
python3 ${CLAUDE_PLUGIN_ROOT}/skills/memory/scripts/memory.py signal \
<case_id> ci 0.0 --source "tests-retried" 2>/dev/null
/workflows:review or user), the review workflow will emit the merge signal.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.