Parallel Worker Task

Assignment

$ARGUMENTS

Context

• Branch: !git branch --show-current
• Working directory: !pwd
• Repository: !basename $(git rev-parse --show-toplevel 2>/dev/null)

Workspace Rules

Check and follow project-specific CLAUDE.md:

if [ -f "CLAUDE.md" ]; then
  echo "=== Project CLAUDE.md ==="
  head -100 CLAUDE.md
fi

Base Branch Detection

Detect the base branch from workspace configuration (NOT always main/master):

# Check CLAUDE.md for base branch specification
BASE_BRANCH=""
if [ -f "CLAUDE.md" ]; then
  BASE_BRANCH=$(grep -i "base.branch\|default.branch\|primary.branch" CLAUDE.md | head -1 | grep -oE "(main|master|develop|dev|release[^[:space:]]*)" || echo "")
fi

# Fallback: check git remote HEAD or common branches
if [ -z "$BASE_BRANCH" ]; then
  BASE_BRANCH=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@' || echo "")
fi

# Final fallback: check which exists
if [ -z "$BASE_BRANCH" ]; then
  for branch in main master develop dev; do
    if git show-ref --verify --quiet "refs/heads/$branch" 2>/dev/null; then
      BASE_BRANCH="$branch"
      break
    fi
  done
fi

echo "Base branch: ${BASE_BRANCH:-main}"

Automatic Subagent Usage

MANDATORY: Before any implementation, you MUST use subagents:

1. ALWAYS use explorer subagent first to understand the codebase structure
2. For complex or risky changes, use analyzer subagent to assess impact
3. Never skip exploration - it prevents mistakes and ensures pattern compliance

Execution Process

Phase 1: Understanding (REQUIRED)

MANDATORY: Use explorer subagent to understand the codebase:

Use explorer subagent to find relevant files and patterns for this task

For complex changes, also use analyzer:

Use analyzer subagent to understand the architecture and dependencies

Key questions to answer:

• What existing patterns should I follow?
• What files need to be modified?
• Are there related tests I should update?

Phase 2: Planning

Before writing any code:

1. List files to create/modify
2. Identify patterns to follow
3. Plan minimal, focused changes
4. Consider edge cases

Phase 3: Implementation

Follow workspace conventions:

• Maintain existing code style
• Add type annotations where required
• Keep changes focused on the assigned task
• Do NOT modify files outside your scope

Apply Quality Skills:

• Follow /pw:code-quality standards (readability, maintainability, error handling)
• Follow /pw:security-review standards if handling auth, user input, or sensitive data

Phase 4: Verification

Run project-specific checks:

# Try common verification commands
if [ -f "Makefile" ] && grep -q "check" Makefile; then
  make check
elif [ -f "package.json" ]; then
  npm test 2>/dev/null || npm run test 2>/dev/null || true
elif [ -f "pyproject.toml" ]; then
  uv run pytest 2>/dev/null || uv run mypy . 2>/dev/null || true
else
  echo "No standard check command found - verify manually"
fi

Phase 5: Commit

Create atomic commit with conventional message:

git add .
git commit -m "$(cat <<'EOF'
feat: [brief description]

[Detailed description of changes]

- [Change 1]
- [Change 2]

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
EOF
)"

Phase 6: Create PR

# Push branch
git push -u origin $(git branch --show-current)

# Create PR
gh pr create --title "[type]: [brief description]" --body "$(cat <<'EOF'
## Summary
[What this PR does]

## Changes
- [Change 1]
- [Change 2]

## Testing
- [ ] [Test performed]

## Related Issues
Closes #[issue-number] (if applicable)

---
🤖 Generated with [Claude Code](https://claude.com/claude-code)
EOF
)"

Output Report

When complete, provide:

# Worker Report

## Task Completed
[Description of what was implemented]

## Files Changed
- `path/to/file1` - [What changed]
- `path/to/file2` - [What changed]

## PR Created
- **URL**: [PR URL]
- **Title**: [PR Title]
- **Status**: Ready for review

## Verification
- [ ] Tests pass
- [ ] Lint/type check pass
- [ ] Changes are focused and minimal

## Notes
[Any issues encountered or decisions made]

Error Handling

If blocked:

1. Document the blocker clearly
2. Check if it's a dependency on another worker
3. If critical, notify orchestrator
4. Do NOT proceed with incomplete implementation