drewperd1000

Orchestrating Parallel Sessions — Development skill for Claude Code

Development community

Run a project - or a whole business - through orchestrator agents that fan work out to parallel Claude Code sessions, keep them from colliding, and collate what returns.

How to install Orchestrating Parallel Sessions

This entry records only its repository, not the path inside it, so there is no exact command to give. Open drewperd1000/orchestrating-parallel-sessions and copy the folder into ~/.claude/skills/, or the file into ~/.claude/agents/.

What Orchestrating Parallel Sessions does

Run a project - or a whole business - through orchestrator agents that fan work out to parallel Claude Code sessions, keep them from colliding, and collate what returns. Several orchestrators can each own a domain and collaborate: critiquing each other's work and catching what the others missed.

Alternatives in Development

Returns — 组合收益归因 — 拆解总收益为各持仓贡献 + 行业/流派归因 + Top 贡献/拖累 + vs 基准 6.6k ★
Reddit Fetch — Fetches Reddit content via Gemini CLI when WebFetch is blocked or returns 403 errors 6.5k ★
Oob — Out-of-band orchestrator — confirm BLIND SSRF/XXE/SQLi/RCE/Log4Shell by correlating interactsh callbacks to th 4.5k ★

README

orchestrating-parallel-sessions

A Claude Code skill for running a **whole project** through an orchestrator agent.

The orchestrator fans work out to parallel sessions - headless or hand-launched - keeps them from colliding on shared ground, tells workers to fan out their **own** agents when the work needs it, and collates what comes back into one picture.

It has been used across an entire business, of which only a small part is coding: in-depth research, planning, brainstorming, copywriting, database creation and analysis, applications, browser software, knowledge graphs, websites and the KPI measurement pipelines behind them, research tools, and Docs/Sheets integrations. **The common shape is not code - it is a large project with layered, overlapping parts.**

Several orchestrators, working as a team

The larger win is running **more than one**. The working rule is **one orchestrator per project** - or, for a sharper dividing line, think of them as **departments in a business**: Operations, Finance, IT, DevOps, HR. Each owns a domain, has its own standing concerns, and runs for weeks. That analogy answers the question people actually get stuck on - *is this a new orchestrator, or another lane?* A lane is a slice of one project. A department outlives it.

⭐ **And you do not hand-start them.** The first session you open is usually not a project orchestrator at all - it is the one that **creates** them. Call it the **Maestro**: the executive over the host. You tell it what the new domain is, and it allocates the id and mailbox, writes the charter, **introduces the new orchestrator to its peers** so it does not duplicate their work without ever finding out, shows it how to message them directly, and **stays available for the questions it has in its first ten minutes** - about scope, about overlap, about what was decided six weeks ago. A bootstrap document cannot answer those. A colleague who was there when the other eight were started can.

Each department orch