Flujos recomendados

Cada recorrido junta varias páginas de la wiki en el orden en que conviene hacerlas. El esfuerzo sale de sumar los flujos medidos en esas páginas: acciones, pantallas (una misma pantalla cuenta cada vez que se vuelve a ella) y campos a completar. El tiempo es una estimación para alguien que lo hace por primera vez, sin contar lo que tarda el agente en trabajar.

Si todavía no tenés claro qué es una etapa, un agente o una corrida, leé antes Qué es Thulu.

Recorrido	Para qué	Tiempo estimado	Acciones / pantallas / campos
De cero a la primera tarea con PR	Ver a un agente trabajar una tarea real	45 a 60 min	68 / 30 / 18
Armar tu propio proceso	Columnas, agentes por etapa, revisión y aprobaciones	1 a 2 h	63 / 23 / 21
QA con casos filmados y Evidencia	Probar cada cambio con video y repetir los casos en cada entorno	1 h	46 / 17 / 18
Trabajar en equipo con agentes	Sumar personas y repartir preguntas, aprobaciones y menciones	15 a 20 min	39 / 17 / 14
Instalar y operar una instalación propia	Correr Thulu en tu servidor y mantenerlo	1 h	54 / 16 / 16
Revisar costos y flujo del mes	Saber cuánto se gastó, en qué y dónde se traban las tareas	5 a 10 min	12 / 7 / 1

De cero a la primera tarea con PR

Para quien entra a un workspace nuevo en la versión SaaS y quiere ver a un agente de Claude Code abrir un pull request en su repo. Necesitás acceso a la beta, una API key de Anthropic (o un perfil de Amazon Bedrock o Google Vertex) y permiso para instalar una GitHub App en la organización del repo. En una instalación propia el recorrido es igual a partir del paso 2.

1. Creá la cuenta en MisterD ID, verificá el email y entrá a octopus.misterd.dev. Llegás al Panel de un workspace propio, vacío, con los “Primeros pasos” y el botón “Configuración inicial” en el header. Detalle en Empezar en la versión SaaS.

   

   Primer ingreso: el número del header es lo que falta configurar.

2. Cargá la clave del modelo. Configuración, “Motores de IA”, tarjeta de Claude Code: “Configurar clave predeterminada”, elegí el proveedor (Anthropic API) y la credencial “API key”, y pegá el valor en “Clave”. Detalle en Credenciales y motores.

   

   El perfil predeterminado es el que usan los agentes que no eligen otro.

3. Conectá GitHub y creá el proyecto. En “Proyectos”, “Nuevo proyecto”, origen “Repositorio Git”, elegí “GitHub App”, instalala en la organización (se abre GitHub y el modal vuelve solo) y elegí el repo. Si el código no está en GitHub, “Subir carpeta” lo trae desde tu computadora, pero sin GitHub no hay pull request. Detalle en Git y GitHub y Proyectos.

4. Creá el agente. En “Agentes”, “Nuevo agente”: nombre y descripción. Al crearlo, Thulu ofrece “Usar en En curso”: tocalo y el agente queda con esa columna en “Etapas válidas” y elegido para ella en la plantilla de cada proyecto del tablero. Detalle en Agentes.

5. Prepará el tablero. En “Editar tablero”, abrí “Comportamiento” de “En curso”: “Agente por defecto” ya muestra tu agente (si no tocaste “Usar en”, elegilo acá) y “Pushear la rama” viene prendido. Prendé “Avanzar cuando el agente termina”. Agregá una columna “Revisión”, movela entre “En curso” y “Hecho”, y prendé en ella “Abrir un pull request”. Detalle en Tableros y etapas.

   

   Una columna donde trabaja un agente: el agente por defecto y los switches de la columna.

6. Si el proyecto ya tenía tareas, revisalas: “Agente por defecto” escribe la plantilla de los proyectos, que copian las tareas nuevas. Las que existían antes siguen sin agente hasta que lo elijas en su propiedad “Agente”.

7. Creá la tarea con “Nueva tarea” (o la tecla N): tocá el chip del repo, escribí título y descripción, y “Crear”. Si hay más de un tablero, elegí en “Tablero” en cuál cae. La tarea copia la plantilla del proyecto. Detalle en Tareas.

8. Arrastrá la tarjeta a “En curso”. Abrila para seguir la corrida: el estado, la última acción, “Ver log” y “Abrir chat” para hablarle. Detalle en Corridas de agentes.

9. Cuando el agente termina, la tarea pasa sola a “Revisión” y Thulu abre el PR. En el panel de la tarea, “Rama y PR” muestra el número, el estado del CI y la revisión.

   

   Una tarea con dos repos abre un PR en cada uno, sobre la misma rama.

Si la tarjeta no arranca

Si creaste la tarea antes de elegir el agente de la columna, nació sin agente y moverla no lanza nada: la tarjeta dice “Sin agente”. Abrila, elegí el agente en la propiedad “Agente” y volvé a moverla.

Armar tu propio proceso

Para cuando el primer recorrido ya anduvo y querés que el tablero refleje cómo trabaja tu equipo: una columna de refinamiento, una de desarrollo con agente y auditor, y una revisión humana con aprobación antes de cerrar.

1. Creá el tablero o editá el que tenés. Agregá las columnas y ordenalas arrastrándolas: “Agregar columna” la deja después de la de fin. Detalle en Tableros y etapas.

2. Para cada columna donde trabaja un agente, tildala en “Etapas válidas” del agente y elegí ese agente en “Agente por defecto” del Comportamiento de la columna. Las columnas de inicio y de fin no corren agentes.

3. Escribí el prompt de cada etapa. En el agente, pestaña “Prompts”, creá el override de esa etapa; sin override, el agente usa main.md. Detalle en Agentes.

4. Sumá las convenciones del equipo como skills. Creá la skill en “Skills” y concedela al agente en la etapa, pestaña “Skills”. El Workshop trae una de ejemplo y sirve para importar las que exportaste de otro workspace. Detalle en Skills.

5. Dale al agente las herramientas que necesita en cada etapa, pestaña “MCP”. El tilde del servidor concede sus tools de lectura y escritura; merge y deploy no los concede ningún scope: un admin los nombra uno por uno. Detalle en MCPs.

6. Prendé el auditor en la etapa de desarrollo: pestaña “Configuración” del agente, “Auditor por etapa”. Corre con el motor del agente, salvo que ahí elijas otro. Al terminar la corrida, revisa el trabajo y puede devolver la tarea con los criterios que faltan.

   

   Una devolución del auditor: qué criterios no se cumplen y qué tiene que hacer el agente.

7. En la columna de revisión humana, abrí “Comportamiento” y agregá una fila en “Aprobaciones requeridas”. Toda tarea que entre a esa columna espera la aprobación en “Pendientes”. Detalle en Pendientes.

QA con casos filmados y Evidencia

Para probar cada cambio con un video antes y después, y quedarte con los casos que valen la pena repetir en cada entorno sin gastar modelo. Los casos de una tarea se llaman TC-n; los de la biblioteca de Evidencia, EV-n.

1. En la tarea, bloque “Casos de prueba”, escribí cada caso: título, pasos y un resultado esperado con valores concretos. Detalle en Casos de prueba y videos.

2. Dale al agente de la etapa que prueba los MCP argus-browser y octopus-api, en la pestaña “MCP”. Sin el primero no abre el navegador; sin el segundo no escribe en la tarea.

3. Tocá “Correr casos” en el bloque de casos: elegí el agente (la lista avisa si le falta el navegador), la “URL a probar”, opcionalmente otra en “Comparar con” para el video lado a lado, y los casos, y “Lanzar”. También corren si movés la tarea a la columna del agente o lo mencionás en un hilo.

4. Revisá el resultado en el bloque de casos y en la pestaña “Reportes”.

   

   El mismo paso contra la versión vieja y la nueva.

5. Pasá a la biblioteca los casos que quieras repetir: “Evidencia”, pestaña “Desde tareas”, “Agregar a la biblioteca”. Si el caso tenía una corrida filmada, se copia con su grabación.

6. En “Evidencia”, pestaña “Entornos”, aparecen solos los entornos de tus proyectos, con el nombre y la dirección que cargaste en el proyecto, y el Sandbox de cada uno. Editá el que quieras para sumarle logins de prueba, un horario o “Después de un deploy”. Para un sitio que no es de ningún proyecto, “Nuevo entorno”. Después, en la pestaña “Casos”, “Correr todo en…” corre los casos grabados contra ese entorno. Evidencia graba y repite aplicaciones web, en Chromium. Detalle en Evidencia.

7. Para correr la biblioteca desde otro pipeline, copiá el comando para el CI que aparece al editar el entorno guardado y guardá una API key en OCTOPUS_API_KEY.

Trabajar en equipo con agentes

Para sumar personas a un workspace donde ya corren agentes. Hace falta ser dueño o administrador del workspace.

1. Invitá por email desde el menú de workspaces, “Invitar personas”, con el rol que corresponde: lector, desarrollador o administrador. Thulu no manda mails: copiá el link de la invitación (“Copiar link”) y pasáselo a la persona por otro canal. En la beta SaaS, si su email no tiene acceso, el operador tiene que darlo aparte. Detalle en Workspaces y equipo.

   

   Miembros e invitaciones pendientes. La invitación que espera acceso a la beta lo dice en su fila.

2. Conversá con los agentes en la tarea. En la actividad, escribí @ y el nombre del agente para abrir un hilo; el agente contesta en ese mismo hilo. Detalle en Conversación e hilos.

3. Repartí “Pendientes”. Ahí llegan las preguntas de los agentes (con la marca “Trabado” cuando el agente no puede seguir sin respuesta) y las aprobaciones de las columnas. “Pedir cambios” devuelve el trabajo con tu nota. Detalle en Pendientes.

   

   Preguntas y aprobaciones en una sola bandeja. Cada fila abre la tarea.

4. Para consultas que no son de una tarea, usá el chat lateral con un agente que tenga “Chat” entre sus etapas válidas. “Actuar por mí” le deja trabajar sobre tus tareas en tu nombre durante 8 horas; lo que quiera borrar espera tu confirmación. Detalle en Chat.

Instalar y operar una instalación propia

Para correr Thulu en tu servidor con Docker Compose, sin login (una persona o una red de confianza). Necesitás Docker andando y, mientras el repositorio sea privado, un token de GitHub con read:packages para bajar las imágenes de ghcr. Con login OIDC o Kubernetes el recorrido de instalación es más largo.

1. Bajá el binario y corré thulu init con la instalación “Rápida, en esta máquina”: pregunta engines, runner y GitHub, y muestra un resumen antes de escribir nada. Detalle en Instalación self-hosted.

2. Abrí el dashboard con thulu open y completá la “Configuración inicial”: clave del modelo, credencial de git, primer proyecto, agente y columna. Desde ahí, seguí el primer recorrido desde el paso 3.

   

   Primer acceso a una instalación sin login.

3. Programá los backups con una línea de cron en el host que corra deploy/backup.sh una vez por día. Configuración, “Actualizaciones”, muestra el último backup y cuántos snapshots se guardan. Restaurar es parar, correr con RESTORE=1 y levantar. Detalle en Operación self-hosted.

4. Cuando aparece el punto azul junto a la versión, abrí Configuración, “Actualizaciones”: dice qué cambia, si hay migraciones y te da el comando. Corré thulu update en el host; saca un snapshot y vuelve atrás solo si algo falla.

   

   La pantalla Actualizaciones con el comando listo para copiar.

5. Cada tanto, thulu gc lista los contenedores parados, las imágenes viejas y los snapshots que sobran, y thulu gc -apply los borra. Todos los comandos están en CLI de Thulu.

Revisar costos y flujo del mes

Para saber cuánto gastaron los agentes, en qué, y en qué columna se quedan quietas las tareas.

1. Abrí Configuración, “Uso” (o tocá la tarjeta de costo del Panel), elegí “30d” y filtrá por agente o proyecto. Detalle en Uso y costos.

   

   Filtros, las seis tarjetas del período y el costo por día.

2. Bajá a “Tareas más caras” para ver qué tareas concentraron el gasto, con su título y su proyecto. Tocá una para abrirla; la propiedad “Corridas” de la tarea también muestra su costo.

3. Abrí el proyecto, pestaña “Resumen”, para ver lead time, retrabajo, costo por tarea y “Dónde se va el tiempo” por columna. Detalle en Métricas y dashboards.

4. Si necesitás el detalle en una planilla, “Exportar CSV” baja lo que estás viendo con los filtros aplicados.

Relacionado

Qué es ThuluEl modelo y el glosario.

Panel y navegaciónDónde está cada cosa en la barra lateral y en Configuración.

Tableros y etapasQué hace cada opción de una columna.

AgentesEtapas válidas, prompts, skills, MCP y auditor.