From claude-swe-workflows
Orchestrates multi-ticket batches: plans execution order, creates project branch, implements each via /implement in autonomous mode, runs quality passes and merges, presents for review.
npx claudepluginhub chrisallenlane/claude-swe-workflows --plugin claude-swe-workflowsThis skill uses the workspace's default tool permissions.
Orchestrates a batch of tickets as a cohesive unit. Creates a project branch, implements each ticket sequentially using the `/implement` workflow in autonomous mode, runs cross-cutting quality passes, and presents results for final human review.
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
Orchestrates a batch of tickets as a cohesive unit. Creates a project branch, implements each ticket sequentially using the /implement workflow in autonomous mode, runs cross-cutting quality passes, and presents results for final human review.
Maximize autonomy, minimize accumulated error. The goal is to complete an entire batch of tickets without user intervention — but not at the cost of letting problems compound. When something goes wrong, pull the andon cord immediately rather than pressing forward and hoping later steps will compensate.
The project branch is the integration point. Each ticket gets its own topic branch. Work flows from topic branches into the project branch, never directly into main. This keeps main clean and gives the user a single decision point at the end: merge the project branch or don't.
┌──────────────────────────────────────────────────────┐
│ BATCH WORKFLOW │
├──────────────────────────────────────────────────────┤
│ 1. Receive ticket specification │
│ 2. Detect issue tracker & fetch tickets │
│ 3. Batch planning (present to user) │
│ 4. Create project branch │
│ 5. Per-ticket loop: │
│ ├─ 5a. Create topic branch │
│ ├─ 5b. Run /implement (autonomous mode) │
│ ├─ 5c. Merge topic branch → project branch │
│ ├─ 5d. Post-merge verification gate │
│ └─ 5e. Delete topic branch │
│ 6. Cross-cutting quality passes │
│ ├─ 6a. /refactor (SAFE aggression) │
│ └─ 6b. /review-doc │
│ 7. Final review (present to user) │
└──────────────────────────────────────────────────────┘
This protocol applies throughout the entire workflow. When the andon cord is pulled:
Andon cord triggers:
/implement step 4)/implement step 5a)Accept tickets from the user in any of these forms:
#12, #15, #18)v2.0")Detect platform:
git remote -v and inspect the URLgithub.com → use gh CLImcp__gitea__* MCP tools if available, otherwise APIgitlab.com or GitLab instances → use glab CLI if availableFetch each ticket:
Andon cord if tracker is unavailable or tickets can't be fetched.
Analyze all fetched tickets and produce an execution plan:
Dependency analysis:
Execution ordering:
Present the plan to user:
Wait for user approval before proceeding. This is the one planned user interaction point.
main or master)feat/batch-<descriptive-name>For each ticket in the planned order:
feat/issue-<number>-<brief-slug>/implement Workflow (Autonomous Mode)Follow the /implement workflow with these overrides for autonomous operation:
/implement Step | Autonomous Override |
|---|---|
| Step 1 (requirements) | Pre-loaded from ticket body. Do not prompt user for requirements. If the ticket lacks explicit acceptance criteria, derive them from the description. If the description is empty or incoherent, andon cord. |
| Step 2 (planning) | Follow normal conditional logic — invoke swe-planner for complex tasks, skip for simple ones. |
| Steps 3-4 (implementation + acceptance) | Follow normal logic. If acceptance verification fails 3 times, andon cord (do not escalate to user within /implement — escalate here at the batch level). |
| Step 5a (security review) | Follow normal logic. If critical/high findings cannot be resolved by the implementation agent, andon cord. |
| Steps 5b-5c (refactoring/perf review) | Follow normal logic — these are advisory. |
| Step 6 (implement review feedback) | Follow normal logic. |
| Step 7 (peer review) | Follow normal logic. Handle deep issues autonomously — trust agents. If peer review breaks tests, revert peer review changes per standard /implement logic. |
| Step 8 (coverage/quality verification) | Follow normal logic. Handle autonomously — if tests pass, proceed. Do not prompt user for approval of minor issues. |
| Step 9 (documentation) | Follow normal logic. |
| Step 10 (final verification) | Follow normal logic. |
| Step 11a (commit) | Auto-commit with ticket reference. Use Fixes #<number> in the commit message. |
| Step 11b (ticket update/close) | Post a comment on the ticket summarizing changes made. Do not close the ticket — leave that for the user after final review. |
| Step 11c (rebase on main) | Skip entirely. We're on topic branches off the project branch, not main. |
git merge --no-ff feat/issue-<number>-<brief-slug>--no-ff preserves topic branch history for claritygit branch -d feat/issue-<number>-<brief-slug>After all tickets are implemented and merged into the project branch:
Run the /refactor workflow with these parameters:
/refactor workflow handles its own iteration loop, commits, and QA verificationRun the /review-doc workflow:
Present comprehensive summary to user:
## Batch Complete
### Tickets Implemented
- #12: <title> — <brief outcome>
- #15: <title> — <brief outcome>
- #18: <title> — <brief outcome>
### Statistics
- Total commits: N
- Net lines changed: +/-N
- Tests added/modified: N
- Documentation files updated: N
### Quality Passes
- Refactoring: N improvements, net -N lines
- Documentation: N updates
### Branch Status
- Project branch: feat/batch-<name>
- Base branch: <main branch>
- Ready to merge
User decides next steps: merge to main, further work, or discard.
The orchestrator maintains:
Sequential execution:
Context management:
/implement workflow within each ticket manages its own agent lifecycleFresh state per ticket:
/implement workflow starts from scratch for each ticketRelationship to /implement:
/implement-batch is a higher-level orchestrator that runs /implement for each ticket/implement handles the full development cycle for a single ticket/implement-batch adds: batching, ordering, branching strategy, cross-cutting quality passesRelationship to /scope:
/scope creates tickets; /implement-batch consumes them/scope to plan and create tickets, then /implement-batch to implement the batchRelationship to /refactor, /review-doc: