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.

Informações da origem

Repositório
Buleje/Mercado
Última atividade na origem
18 de abril de 2026 às 20:07
Idioma detectado do SKILL.md
espanhol
Estrelas
0
Forks
0

Opções de instalação

Por padrão, está selecionado o prompt que primeiro revisa a origem. Você pode mudar para um comando direto ou baixar uma cópia local.

Revise os arquivos de origem

Leia o SKILL.md e os arquivos complementares exibidos pelo SkillsMP antes de decidir se vai instalar.

Exibindo SKILL.md

SKILL.md
Instruções da origem · Visualização somente leitura
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 no GitHub