القائمة
Use when changes span frontend, backend, and tests where each layer needs a dedicated owner plus an integration agent for cross-cutting consistency
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when facing a task that could benefit from parallel work - decides whether to use subagents or agent teams, then composes the right team from the role pool based on task analysis
Use when debugging with unclear root cause and multiple plausible explanations that need parallel adversarial testing to converge on the answer
Use when building new modules or features where teammates can each own a separate piece without stepping on each other
Use when multiple aspects of a problem need parallel investigation with findings shared and challenged between investigators
Use at the end of every team session or work session to record mistakes, lessons, and patterns to .claude.md for self-evolution across sessions
| name | cross-layer-collaboration |
| description | Use when changes span frontend, backend, and tests where each layer needs a dedicated owner plus an integration agent for 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