Plan and orchestrate multiple parallel worktree development sessions. Use this skill when the user wants to work on multiple features, issues, stories, or tasks simultaneously — e.g., "let's work on these 3 stories in parallel", "spin up workstreams for these tickets", "I want to parallelize this work", or provides multiple issue IDs and expects concurrent development. Also use when they mention "parallel development", "multiple worktrees at once", or "batch these tasks". Requires worktrunk CLI.
How this skill is triggered — by the user, by Claude, or both
Slash command
/chrisbloom7-development:parallel-workstreamsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Plan and orchestrate multiple parallel worktree development sessions. This skill coordinates several instances of the `worktree-start` workflow, adding pre-flight validation, independence checking, and a unified planning phase.
Plan and orchestrate multiple parallel worktree development sessions. This skill coordinates several instances of the worktree-start workflow, adding pre-flight validation, independence checking, and a unified planning phase.
Running 3-5 independent workstreams simultaneously recaptures time lost to CI queues, PR review waits, and context switching. The key is ensuring tasks are genuinely independent before parallelizing them.
wt) installed and configuredGather all tasks the user wants to parallelize:
Before creating any worktrees:
Project prerequisites — Check for project-specific companion skills (same extensibility mechanism as worktree-start). If one exists, invoke it for pre-flight checks: services that need to be running, authentication that needs to be valid, etc. Run these once, not per-worktree.
Independence validation — Confirm the tasks are genuinely independent. For each pair of tasks, check:
If tasks overlap, flag them and ask the user whether to:
Ordering constraints — Note any merge ordering dependencies. Example: "Task A introduces a new API that Task B consumes — Task A must merge first." Record these for inclusion in each WORKTREE_CONTEXT.md.
For each task, produce the implementation plan that worktree-start Step 2 would generate. This means:
Present all plans together in a single summary for user review. Format as a table or numbered list showing each workstream with its plan summary, estimated scope, and any noted constraints.
Wait for user approval before proceeding to execution.
After approval, create each workstream sequentially using the worktree-start workflow:
wt switch --createWORKTREE_CONTEXT.md (include ordering constraints from Step 2 if applicable)tmux note: When creating multiple windows, derive unique window names from task IDs or short slugs. Test the first window before looping — mistakes create duplicate windows that must be manually killed.
Present a summary table of all workstreams:
| # | Task | Branch | Worktree Path | Session | Constraints |
|---|---|---|---|---|---|
| 1 | [title] | branch-name | /path/to/wt | tmux: window-name | None |
| 2 | [title] | branch-name | /path/to/wt | tmux: window-name | Merges after #1 |
| 3 | [title] | branch-name | /path/to/wt | tmux: window-name | None |
Include:
WORKTREE_CONTEXT.md on first promptThis workflow reflects current automation capabilities. When starting a new round of parallel streams, consider whether new capabilities (e.g., spawning sessions, monitoring progress) could shift the automation boundary. If something feels manual that shouldn't be, revisit.
npx claudepluginhub chrisbloom7/ai-tools --plugin chrisbloom7-developmentGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.