Skip to main content

parallel-work

Lanza N agentes en worktrees aislados para trabajar en features independientes en paralelo. Cada agente tiene su propia copia del repo sin conflictos.

Datos de origen

Repositorio
Buleje/Mercado
Última actividad en el origen
18 de abril de 2026 a las 20:07
Idioma detectado de SKILL.md
español
Estrellas
0
Forks
0

Opciones de instalación

De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.

Revisa los archivos de origen

Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.

Mostrando SKILL.md

SKILL.md
Instrucciones de origen · Vista previa de solo lectura
name
parallel-work
description
Lanza N agentes en worktrees aislados para trabajar en features independientes en paralelo. Cada agente tiene su propia copia del repo sin conflictos.
user-invocable
true
model
opus
context
fork
# /parallel-work — Trabajo paralelo en worktrees aislados ## Cuando usarlo - 2+ features independientes que pueden desarrollarse al mismo tiempo - Refactors grandes que tocan muchos archivos (aislar cada frente) - Sprints con N iniciativas independientes - Cualquier trabajo donde los agentes pisarian archivos del otro ## Flujo ### Paso 1: Descomponer en frentes independientes Al recibir la tarea, el Orquestador: 1. Identifica N sub-tareas independientes (sin archivos compartidos) 2. Para cada sub-tarea, define: branch name, archivos que tocara, agente especialista 3. Valida que NO hay overlap de archivos entre frentes ### Paso 2: Lanzar agentes con isolation: "worktree" ``` Para cada frente independiente, lanzar: Agent({ description: "Frente N: [descripcion corta]", subagent_type: "[agente-especialista]", isolation: "worktree", prompt: "[instrucciones completas con contexto]", run_in_background: true }) ``` **CRITICO:** Usar `isolation: "worktree"` para que cada agente tenga su propia copia del repo. Sin esto, los agentes pisan archivos del otro. ### Paso 3: Mientras los agentes trabajan El Orquestador: - Trabaja en quick wins que no tocan los mismos archivos - Prepara documentacion (ADRs, TECH-DEBT updates) - Monitorea progreso via notificaciones ### Paso 4: Consolidar resultados Cuando los agentes terminan: 1. Revisar el output de cada worktree 2. Si el agente hizo cambios, el worktree queda como branch 3. Merge cada branch al branch principal (secuencial para evitar conflictos) 4. Correr verificacion completa: `npm run lint && npx tsc --noEmit && npm run test && npm run build` 5. Commit consolidado o commits atomicos por frente ### Paso 5: Cleanup Los worktrees sin cambios se limpian automaticamente. Los que tienen cambios quedan como branches para merge. ## Ejemplo real ``` Brandon: "Necesito agregar pgvector recommender + WhatsApp concierge + billing metering" Orquestador detecta 3 frentes independientes: Frente 1 (DATABASE): pgvector extension + embeddings table + recommender DB class → Agent: database-engineer, worktree, branch: feat/pgvector-recommender Frente 2 (INTEGRACIONES): WhatsApp Business API + webhook handler + concierge flow → Agent: integration-specialist, worktree, branch: feat/whatsapp-concierge Frente 3 (BACKEND): billing metering endpoint + usage tracking + Stripe integration → Agent: backend-platform-engineer, worktree, branch: feat/billing-metering Los 3 corren en paralelo. Cero conflictos. ``` ## Limites - Maximo **8 worktrees simultaneos** en modo turbo (ADR-061). Default 6. Mas que 8 degrada disco. - Cada worktree consume ~500MB de disco (copia completa del repo) - **run_in_background: true + 1 solo mensaje multi-Agent** = verdadero paralelismo. Nunca spawnear agentes secuencialmente. - No usar para tareas que comparten archivos criticos (checkout, cart-context, schema.prisma) - Para archivos compartidos, usar el flujo A2A con gating de dependencias (feedback_multi_agent_hierarchy_level3) ## Reglas 1. SIEMPRE declarar el arbol de frentes ANTES de lanzar agentes 2. SIEMPRE verificar que no hay overlap de archivos 3. SIEMPRE correr verificacion completa despues del merge 4. Si un frente falla, NO bloquear los otros — aislar y reportar 5. **TURBO (ADR-061):** spawn de 3-8 agentes va en 1 solo mensaje con run_in_background=true; no esperar entre calls.
Ver en GitHub