BaepatLabs/specialist-team-orchestrator

Specialist Team Orchestrator

Coordinate complex work as a small specialist team while keeping one lead accountable for integration and verification.

When to use

Activate this skill when a request contains at least two useful workstreams that can proceed independently, such as:

• product research and technical discovery;
• UX direction and implementation planning;
• frontend and backend work with a stable interface;
• implementation and independent QA;
• migration analysis across separate services.

Stay single-agent for trivial edits, tightly sequential work, or tasks where coordination would cost more than it saves.

Delegation gate

Before implementation:

1. Break the requested outcome into concrete workstreams.
2. Mark dependencies between them.
3. Count the workstreams that can proceed independently.
4. If at least two independent workstreams exist and workers are available, delegate.
5. If delegation is unavailable, execute sequentially while preserving the same role boundaries.
6. Keep one lead responsible for scope, integration, verification, and final delivery.

A user-selected model is the lead by default. It is not automatically the only worker.

Choose roles by work

Create only the roles the task needs:

• Product/Research — requirements, references, domain research, content, and risks.
• Design — information architecture, UX direction, design system, responsive behavior, and visual acceptance criteria.
• Build — components, interactions, implementation, and performance.
• Systems — data model, authentication, APIs, integrations, and deployment constraints.
• QA/Audit — independent review, accessibility, regression, edge cases, and end-to-end flow verification.

Assign models after roles are defined:

• use strong visual judgment for Design;
• use strong repository and coding ability for Build and Systems;
• use long-context research ability for Product/Research;
• prefer a different model or a fresh context for QA;
• reserve small or local models for bounded, low-risk extraction, classification, summarization, or drafting.

Do not route production-critical decisions, autonomous high-impact actions, or final QA to an unproven weak model.

Define contracts before parallel work

Every delegated workstream must state:

• objective;
• allowed files or scope;
• required inputs;
• exact output artifact;
• acceptance criteria;
• dependencies and blockers;
• prohibition on unrelated edits.

Prefer artifacts that other roles can consume directly:

• requirements brief;
• design tokens or DESIGN.md;
• component or API contract;
• schema or migration plan;
• test checklist with evidence.

Do not ask several workers to build the same complete feature unless the task explicitly requests competing prototypes.

Coordinate in phases

1. Lead framing — inspect the project, restate the outcome, identify constraints, and define workstreams.
2. Parallel discovery — run independent research, design exploration, repository inspection, or risk analysis concurrently.
3. Contract checkpoint — reconcile conflicts and freeze shared interfaces before dependent implementation.
4. Implementation — give workers non-overlapping file ownership whenever practical.
5. Independent QA — use a fresh worker when available; the builder must not be the sole final reviewer.
6. Lead integration — resolve conflicts and run end-to-end verification against acceptance criteria.

A worker reporting completion is not evidence that the integrated result works. The lead must verify the assembled outcome.

Scale the team

• Small isolated change: lead only, or lead plus one specialist.
• Medium multi-domain task: lead plus two specialists.
• Large build or redesign: lead plus three specialists, adding more only when capacity exists and the work remains independent.

Never spawn agents merely to reach a target number.

Safety

Delegation does not broaden authorization. All workers must preserve:

• user-owned changes;
• repository and workspace boundaries;
• approval gates;
• production safety rules;
• secrets and private data;
• restrictions on external communication.

The lead remains responsible for every external action and destructive change.

Examples

Web feature

• Product/Research: clarify the user flow and edge cases.
• Design: define responsive states and interaction acceptance criteria.
• Build: implement against the frozen contract.
• QA: test keyboard, mobile, errors, and the complete flow.

Data migration

• Research: inventory current data and constraints.
• Systems: draft mapping, rollback, and validation plan.
• Build: implement non-overlapping migration code.
• QA: compare counts, samples, failures, and rollback behavior.

Research report

• Researchers: investigate independent evidence streams.
• Critic: challenge unsupported conclusions.
• Lead: reconcile evidence, cite sources, and write the final decision.

Completion report

Report:

• roles used;
• artifact produced by each role;
• verification performed by the lead;
• limitations or work left;
• models used for each role.

If no delegation occurred, state why the task did not pass the delegation gate.