parallel-streamslisted

Split a larger project into independent work streams and build them in several parallel headless claude -p terminals at once. Limit-tolerant: when the subscription window is exhausted, every stream pauses automatically and resumes until its done marker exists. Use when the user says "in multiple terminals", "build in parallel", "streams", "build through the night", "split it up and run simultaneously", "overnight run", "keep going even when the limit hits", or when a build job is clearly too big for one session (3+ independent work packages). Also use when the user wants to watch running streams live, steer one ("tell stream B that..."), pause one, or take over interactively (steer file / takeover). Not for small tasks (<3 packages: subagents or sequential work).
belschak/parallel-streams · ★ 0 · AI & Automation · score 67

Install: claude install-skill belschak/parallel-streams

# parallel-streams: build a project in parallel terminals The orchestrator (you) freezes the contracts, streams (headless `claude -p` loops in their own terminals) build independently, you integrate at the end. Why this shape: streams cannot see each other. Every shared file becomes a merge accident, every vague definition-of-done becomes a false "finished". The upfront contracts are the actual success factor. ## Status: what is tested, what is not The PowerShell runner (`assets/windows/`) is battle-tested on Windows: it has run real overnight builds with multiple parallel streams, including limit pauses, resumes, steering and takeovers. The POSIX port (`assets/posix/`) is a faithful line-by-line port but has NOT been executed on macOS/Linux yet; it is syntax-checked only. Review it and run one short throwaway stream before you trust it with a night. ## Orchestrator triage: what belongs in a stream, what does NOT Streams are normal `claude -p` sessions with your full user config (skills, agents, CLAUDE.md, user-scope MCP servers, web tools, gh CLI). Everything file-based, stateless or API-key-driven runs in a stream exactly as it would for you. The one class that does not work headless: anything that needs an interactive login, an OAuth popup, or your live browser session, because nobody is sitting there to click it. Keep those parts in your own interactive terminal: browser MCPs on logged-in sites, OAuth-gated connectors, and above all browser-based visual QA. A stream