Cómo gestionar un proyecto software personal con varios agentes de IA
Ejecuta agentes especialistas por repositorio sin convertirte en el mensajero humano entre terminales inconexas.
Revisado con Agents City 0.3.0-beta.22 · commit c985198 ↗El problema real
Un creador independiente mantiene backend, app móvil, documentación y checks de release. Abrir un asistente por carpeta genera trabajo paralelo, pero aún obliga a reconstruir qué respuesta posee la decisión de producto.
Resultado buscado
Una ciudad personal conserva objetivo, repositorios, roles, runtimes, skills e historial de decisiones mientras el asiento sigue siendo el límite de coordinación.
proyecto-personal
backenddevAPI, persistencia, migraciones y fallos de runtime
appproduct-designFlujo, accesibilidad e integración cliente
docspoInstalación, onboarding y contrato público
qaqualityEvidencia de aceptación y verificación independiente
Antes de empezar
- 01
Repositorios del producto clonados o disponibles mediante el selector de GitHub.
- 02
Al menos un runtime soportado autenticado; todas las ventanas pueden usar el mismo.
- 03
Un objetivo de producto más acotado que un roadmap permanente.
Cómo hacerlo
Paso 01 Crea una vez la ciudad del producto
Usa onboarding para seleccionar dominio, rol del asiento, repositorios, objetivo y runtimes. La ciudad persiste entre sesiones.
$agents-city setup --city proyecto-personalPaso 02 Da una responsabilidad real a cada repo
Asigna roles según la evidencia que posee el repositorio. Inspecciona skills reconocidas antes de elegir qué miembro debe ejecutar.
$agents-city seat --city proyecto-personal --agent-roles$agents-city skills proyecto-personalPaso 03 Abre sólo el conjunto de hoy
Conserva todos los repositorios en la ficha, pero arranca sólo backend y app cuando no necesites documentación ni QA. El filtro no borra configuración.
$agents-city seat --city proyecto-personal --only backend,appPaso 04 Usa comité sólo para decisiones entre repos
La implementación rutinaria permanece en una ventana. Abre un comité cuando evidencia de varios repositorios pueda cambiar una decisión de API, release o producto.
$agents-city committee open --input decision-producto.json
Qué deberías obtener
- El objetivo y las responsabilidades sobreviven a reinicios de terminal.
- Puedes usar un modelo en todo o elegir un runtime diferente por ventana.
- Las decisiones entre repos quedan registradas sin convertir cada tarea en una reunión.
Qué no resuelve
- Agents City no sustituye issue tracking, control de versiones ni criterio de producto.
- Abrir más agentes aumenta coste y coordinación; empieza con la ciudad mínima útil.
- Guarda el trabajo antes de cerrar una sesión tmux viva con agents-city exit.