From team-orchestrator
Use when changes span frontend, backend, and tests where each layer needs a dedicated owner plus an integration agent for cross-cutting consistency
How this skill is triggered — by the user, by Claude, or both
Slash command
/team-orchestrator:cross-layer-collaborationThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Changes that span frontend, backend, and tests need layer specialists who each own their domain, plus an integrator who ensures cross-cutting consistency.
Changes that span frontend, backend, and tests need layer specialists who each own their domain, plus an integrator who ensures cross-cutting consistency.
Core principle: Conway's Law deliberately applied — one agent per layer produces clean boundaries. Integrator prevents Conway's downside (boundaries becoming walls).
Management theory: Conway's Law (structure → architecture), T-Shaped Skills (deep in one layer, understand all), Belbin Teamworker (integrator bridges gaps).
Don't use when:
coordinator (lead, delegate mode)
├── implementer (frontend) — UI components, state, UX
├── implementer (backend) — API, database, business logic
├── finisher (tests) — Test coverage for both layers
└── integrator × 1 — API contracts, cross-cutting concerns
Belbin coverage:
Optional additions:
architect — if the API contract is complex or newreviewer — if code quality review is needed post-integrationdevil-advocate — if the design has risky trade-offsBefore any implementation:
Contract definition:
Endpoint: POST /api/feature-x
Request: { field1: string, field2: number }
Response: { id: string, status: "created" | "error" }
Errors: { 400: validation, 401: unauth, 500: server }
Auth: Bearer token required
Critical: The contract is the integration point. It MUST be agreed upon before parallel work begins. Changes to the contract during implementation require all parties to stop and re-agree.
Frontend implementer:
Backend implementer:
Finisher (tests):
Integrator:
Integrator leads:
Common integration issues:
userId vs user_id)| Area | Owner | Other agents |
|---|---|---|
src/components/, src/pages/ | FE implementer | NO edits |
src/api/, src/models/ | BE implementer | NO edits |
tests/e2e/, tests/integration/ | Finisher | NO edits |
src/types/, src/shared/ | Integrator | Read-only for others |
| API contract doc | Coordinator | All review, only coord edits |
Rule: No two agents edit the same file. Violations cause merge conflicts and wasted work.
| Mistake | Fix |
|---|---|
| Starting implementation before contract agreed | Phase 1 is mandatory |
| FE and BE disagree on field names | Contract must specify exact names |
| No integration phase — just merge | Integrator role exists for this |
| Testing only happy paths | Finisher must cover error states |
| Contract changes mid-implementation | Stop all work, re-agree, then resume |
| FE uses mock that doesn't match contract | Mock must be generated from contract |
Pre-requisite: team-orchestrator:orchestrating-work routes here Post-requisite: team-orchestrator:session-reflection records learnings Related: team-orchestrator:feature-development for module-level splitting
npx claudepluginhub labrinyang/team-ochestractorProvides 5 agent-team topologies for parallelizing complex code tasks across frontend-backend-tests, architecture reviews, debugging, and docs, with task decomposition, file ownership, worktree guidance, and quality gates.
Coordinates parallel feature development with file ownership strategies, conflict avoidance rules, and integration patterns for multi-agent implementation.
Use when a task benefits from multiple Claude instances collaborating with peer-to-peer messaging - parallel research, multi-module features, cross-layer changes, or competing hypothesis debugging. Not for simple independent tasks (use parallel-execution) or sequential tasks (use delegated-execution).