| name | team-orchestration |
| description | THE ROUTER. Given any engineering task, decide which roles and lifecycle phases apply, in what order, and whether to run them sequentially or in parallel. Use when someone says "assemble the team", "who should work on this", "route this task", "what roles do I need", or invokes the /dev-collective:assemble command. Handles right-sizing so a one-line fix does not spin up the whole org. |
Team Orchestration
Team orchestration is the meta-skill that sits above all other dev-collective lifecycle phases. Given a task description, it selects the minimum viable set of roles and phases, sequences them correctly, and launches the appropriate subagents.
When to Use This Skill
- User says "assemble the team", "who should work on this", or "route this task"
- User runs
/dev-collective:assemble
- Any task that is ambiguous about which phase to start in
- Multi-phase work where the right sequence is unclear
Routing Table
Map the strongest signal in the task description to the recommended starting point.
Signal Primary Role(s) Phase(s)
─────────────────────────────────────────────────────────────────────────────
"what should we build / why" product-manager discovery
"how should we design / architect" principal-architect technical-design
staff-engineer
"implement / build / code this" tech-lead + lang expert implementation-workflow
"review / check this PR" code-reviewer code-review-process
security-engineer (if auth,
payments, secrets touched)
"ship / deploy / release" sre + tech-lead shipping
"bug in production" sre → tech-lead shipping → implementation-workflow
"security concern" security-engineer technical-design + code-review-process
"performance problem" staff-engineer + sre technical-design → implementation-workflow
"greenfield feature" product-manager → discovery → technical-design →
principal-architect → implementation-workflow →
tech-lead + lang expert code-review-process → shipping
Right-Sizing Guide
Not every task needs the full org. Apply the minimum necessary roles.
Task size Roles needed
───────────────────────────────────────────────────────────
Typo / 1-liner lang expert only (skip all lifecycle phases)
Small bug fix tech-lead + lang expert + code-reviewer
Feature (<1 day) tech-lead + lang expert + code-reviewer + sre sign-off
Feature (>1 day) discovery + technical-design + full pipeline
New system Full pipeline, all strategic roles in design
Security patch security-engineer leads; code-reviewer required; sre for deploy
Sequential vs. Parallel Execution
Run phases sequentially when:
- Output of one phase is required input for the next (e.g., acceptance criteria feed design)
- A blocking decision has not been made yet
Run roles in parallel when:
- Multiple independent workstreams exist (e.g., backend and frontend implementation)
- Review roles can operate alongside implementation (e.g., security review while feature branches merge)
Process
- Read the task description and identify the strongest signal from the routing table above.
- Determine task size and apply the right-sizing guide.
- Identify which lifecycle phases are needed, in order.
- For each phase, identify the owning role and any supporting roles.
- Decide which steps can run in parallel vs. must be sequential.
- Launch subagents: invoke the matching lifecycle skill (e.g.,
dev-collective:discovery) with the task context as input.
- Pass outputs from each phase as context into the next phase.
- Surface a summary of the routing plan to the user before execution if the plan involves more than two roles.
Outputs
- A routing plan: ordered list of phases, roles, and execution mode (sequential/parallel)
- Delegated subagent invocations for each phase
- A final synthesis once all phases complete
Delegating to Subagents
When launching a subagent for a phase, pass:
- The original task description
- Any prior phase outputs (problem statement, design doc, etc.)
- The specific deliverable expected from this phase
Example delegation message:
Phase: technical-design
Owner: principal-architect
Input: [problem statement from discovery]
Expected output: design doc covering data model, API contract, trade-offs, and ADR
user: "We need to add multi-currency support to checkout. Assemble the team."
assistant: This is a greenfield feature touching payments, so I'll route through the full pipeline with security review embedded.
Routing plan:
- discovery (product-manager) — clarify which currencies, regulatory constraints, success criteria
- technical-design (principal-architect + security-engineer) — currency conversion model, data storage, PCI scope; run in parallel with security threat model
- implementation-workflow (tech-lead + rails-engineer + go-engineer) — backend currency service (Go), Rails checkout integration; two parallel workstreams
- code-review-process (code-reviewer + security-engineer) — security-engineer required due to payment scope
- shipping (sre + tech-lead) — feature-flag rollout, rollback plan, alerting on conversion failures
Launching discovery subagent now with the task context.
