team-coordination
Multi-team orchestration — create teams, assign members, detect cross-team blockers
Best use case
team-coordination is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Multi-team orchestration — create teams, assign members, detect cross-team blockers
Teams using team-coordination should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/team-coordination/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How team-coordination Compares
| Feature / Agent | team-coordination | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Multi-team orchestration — create teams, assign members, detect cross-team blockers
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Skill: Team Coordination
> Prerequisito: @docs/rules/domain/team-structure.md
> Complementa: @.claude/skills/capacity-planning/SKILL.md
Orquesta la creación, gestión y coordinación de equipos dentro de departamentos.
Detecta dependencias cross-equipo, bloqueos y problemas de capacidad.
## Flujo 1 — Crear equipo (`create`)
1. Verificar que el departamento existe en `teams/departments.md`
- Si no existe, preguntar si crear el departamento primero
2. Crear estructura de directorios: `teams/{dept}/{team}/`
3. Generar `team.md` con schema de @team-structure.md:
- name, department, lead (vacío si no se indica), members: []
- capacity_total: 0, velocity_avg: 0, sprint_cadence: 2w
4. Generar `deps.md` vacío: `dependencies: []`
5. Actualizar `teams/departments.md` con el nuevo equipo
6. Output: confirmación + ruta + siguiente paso ("asigna miembros con /team-orchestrator assign")
## Flujo 2 — Asignar miembro (`assign`)
1. Verificar que el equipo existe en `teams/{dept}/{team}/team.md`
2. Verificar que el usuario tiene perfil (`.claude/profiles/{user}/` o `active-user.md`)
3. Añadir entrada a `members:` en team.md:
- handle, role (contributor|pm|tech-lead|qa|architect), capacity (FTE), projects
4. Recalcular `capacity_total` (suma de FTE de todos los miembros)
5. Si el usuario ya está en otro equipo, advertir (multi-equipo permitido si capacity < 1.0)
6. Output: miembro asignado + capacidad total actualizada
## Flujo 3 — Dependencias cross-equipo (`deps`)
1. Leer todos los `teams/*/*/deps.md` recursivamente
2. Construir grafo de dependencias:
- Nodos = equipos
- Aristas = dependencias (blocking, informational, shared-resource)
3. Detectar:
- **Bloqueos activos** (deps con status: red o amber)
- **Dependencias circulares** (A→B→C→A)
- **Equipos aislados** (sin ninguna dependencia declarada — posible gap)
4. Si `--critical`: filtrar solo blocking con status red/amber
5. Output: tabla de dependencias + alertas + gráfico ASCII
```
Ejemplo output:
┌─────────┐ blocking ┌─────────┐
│ Backend │──────────→│ Frontend │
└─────────┘ └─────────┘
│ shared-resource │ informational
▼ ▼
┌──────────┐ ┌──────────┐
│ Platform │ │ Mobile │
└──────────┘ └──────────┘
⚠️ 2 bloqueos activos:
Backend → Frontend (red): API contracts pendientes
Platform → Backend (amber): migración K8s en progreso
```
## Flujo 4 — Sincronizar estado (`sync`)
1. Para cada equipo, leer team.md y deps.md
2. Verificar coherencia:
- ¿Todos los miembros listados tienen perfil?
- ¿Las deps referencian equipos que existen?
- ¿La capacity_total coincide con suma de FTE?
3. Recalcular velocity_avg si hay datos de sprint disponibles
4. Actualizar status de deps basándose en última actividad
5. Guardar `output/team-sync-YYYYMMDD.md` con resumen
## Flujo 5 — Dashboard de estado (`status`)
1. Leer todos los equipos (o filtrar por dept si `--dept`)
2. Para cada equipo calcular:
- Capacidad: total FTE, % utilizado (si hay sprint activo)
- Salud: dependency_health (% deps en green)
- Velocidad: velocity_avg + tendencia (↑↗→↘↓)
- Bloqueos: count de deps blocking con status != green
3. Agregar por departamento si `--all`
4. Output: tabla resumen + alertas
```
Ejemplo output:
══════════════════════════════════════════════
Multi-Team Status — Engineering Department
══════════════════════════════════════════════
Team │ FTE │ Velocity │ Health │ Blocks
─────────────┼─────┼──────────┼────────┼───────
Backend Core │ 4.5 │ 42 ↗ │ 80% │ 1
Frontend Web │ 3.0 │ 35 → │ 100% │ 0
Platform │ 2.0 │ 18 ↘ │ 50% │ 2
Mobile │ 3.5 │ 28 ↑ │ 100% │ 0
─────────────┼─────┼──────────┼────────┼───────
TOTAL │13.0 │ 123 │ 83% │ 3
⚠️ Platform: 2 bloqueos activos, velocity descendente
```
## Errores
| Error | Acción |
|---|---|
| Departamento no existe | Preguntar si crear. Si sí, crear departments.md |
| Equipo ya existe | Mostrar datos actuales, preguntar si actualizar |
| Miembro sin perfil | Ejecutar `/profile-setup` primero |
| Dependencia circular detectada | Alertar como CRÍTICO, sugerir reunión de resolución |
| deps.md referencia equipo inexistente | Advertir + sugerir actualizar |
## Seguridad
- NUNCA exponer datos personales de miembros en output público
- SIEMPRE usar @handles, no nombres reales en reports exportables
- Datos de equipo en `teams/` — git-tracked (sin datos sensibles)
- Rates/salarios NUNCA en team.md — esos van en `.flow-data/rates.json` (git-ignored)Related Skills
team-onboarding
Onboarding y evaluación de competencias para nuevos miembros del equipo
zoom-out
Elevates perspective from trees to forest. Maps architecture, dependencies, and second-order effects before implementation decisions. Use when designing, when evaluating trade-offs, or at the start of design sessions.
workspace-integrity
Catalogo de integrity auditors — drift CLAUDE.md, rule manifest, orphan rules, agents catalog sync, baseline, agent size
wellbeing-guardian
Sistema proactivo de bienestar individual
web-research
Search the web to resolve context gaps — documentation, versions, CVEs, best practices. Auto-starts SearxNG Docker if available, falls back to WebSearch.
voice-inbox
Transcripción de audio y flujo audio→texto→acción para mensajes de voz
verification-lattice
Multi-layer verification pipeline beyond Code Review
topic-cluster
BERTopic clustering — agrupa retros/PBIs/incidents/lessons en topics tematicos con labels. Filtra ruido, descubre patrones cross-proyecto
time-tracking-report
Generación de informes de imputación de horas a Excel/Word
tier3-probes
Catalogo de feasibility probes para champions Tier 3 — Scrapling, Oumi, Memvid, BERTopic, Reranker, PDF extract
test-architect
Design and generate highest-quality tests across 16 languages and 14 test types
tech-research-agent
Agente de investigación técnica autónoma — investiga temas, genera informes, notifica al humano designado