Configurar con tu asistente de AI

Esta página es una guía de configuración escrita para un asistente AI: Claude Code, Codex, Cursor, o cualquier asistente capaz de leer una página web y, idealmente, trabajar en una copia local de tu repositorio. Guía al asistente en la configuración de Coroid para uno o más repositorios. Se detiene en cada paso que solo una persona puede realizar: iniciar sesión, conceder acceso, introducir un secreto o aprobar un cambio.

Pásaselo a tu asistente#

Abre tu asistente en el repositorio donde quieras que Coroid trabaje y dale este prompt:

Set up Coroid for this repository. Follow the runbook at
https://coroid.ai/docs/export/en-US/getting-started/assistant-setup.md
step by step. Ask me before you change anything, and never ask me to paste a
password or token into this chat.

Para varios repositorios, abre el asistente en un directorio que los contenga todos e indícalos en el prompt. El asistente realizará la inspección y la verificación, y te indicará exactamente qué hacer en cada paso que requiera tu intervención.

Reglas básicas para el asistente#

Tú actúas; él prepara. Estás configurando Coroid, una plataforma de fabricación de software AI alojada que convierte la descripción de un trabajo en un pull request probado y revisado dentro del repositorio del usuario. Sigue estas reglas en todo momento:

1. El usuario actúa; tú preparas. No puedes registrarte, iniciar sesión, aceptar términos, instalar aplicaciones ni conceder acceso en nombre del usuario. Indica exactamente qué hacer y dónde, y espera a que el usuario confirme que lo ha hecho.
2. Mantén los secretos fuera de la conversación. Nunca pidas una contraseña, token de acceso personal, clave de proveedor o token MCP. El usuario introduce los secretos en el portal de Coroid o en su propio shell. Si algún secreto se pega en el chat, indícale al usuario que lo revoque y cree uno nuevo.
3. Pregunta antes de cada cambio: commits, ramas y pull requests en el repositorio del usuario, proyectos de Coroid e invitaciones.
4. Verifica cada paso antes de continuar. Si una verificación falla, utiliza las notas de ese paso y continúa solo cuando se haya superado o el usuario decida omitirlo.
5. Sigue el producto, no tus suposiciones. Si el portal muestra algo que esta guía no describe, indícale al usuario lo que ves y sigue las instrucciones del portal. No inventes configuraciones.
6. Lleva un registro de la configuración de cada paso y su resultado, para el final.

Cada paso enlaza con las páginas que contienen los detalles. https://coroid.ai/llms.txt indexa toda la documentación.

Paso 1: Acordar el plan#

Hazle al usuario estas preguntas todas juntas, no una por una:

A continuación, repite el plan: los pasos siguientes que requieren la intervención del usuario y los repositorios incluidos.

Consulta Planes y precios, Límites y cuotas y Sincronizado o solo local.

Paso 2: Verifica que cada repositorio compile y se pruebe desde una copia limpia#

Esta es la tarea más útil que puedes realizar. Cada tarea de Coroid se ejecuta en un entorno Linux limpio y desechable: una copia nueva, sin caché ni elementos instalados aparte de la cadena de herramientas de la imagen. Un agente que no pueda compilar y probar el proyecto no podrá verificar su propio trabajo, y sus tareas fallarán en la validación por motivos ajenos al cambio.

Si puedes trabajar en el repositorio de forma local, haz lo siguiente para cada uno:

1. Identifica los lenguajes, el gestor de paquetes y si se trata de un monorepo.
2. Encuentra los comandos de instalación, compilación y prueba en el README, la configuración de CI y los manifiestos.
3. Pregunta antes de ejecutar cualquier cosa. Luego clona el repositorio en un directorio temporal vacío y ejecuta allí los comandos de instalación, compilación y prueba sin ninguna otra configuración previa. La copia de trabajo del usuario contiene cachés y .env archivos que ocultan problemas.
4. Anota todo lo que el proceso necesitó y que una copia nueva no posee:
   • Servicios que esperan las pruebas, como una base de datos, una caché o una cola
   • Pasos previos a las pruebas, como generación de código, migraciones o fixtures
   • Variables de entorno o un .env archivo que no está confirmado
   • Registros de paquetes privados
   • Un entorno de ejecución que no esté en el entorno del agente

Nunca ejecutes comandos que desplieguen, publiquen o modifiquen entornos compartidos. Si la suite es lenta o utiliza servicios de pago, pregúntale primero al usuario.

Informe sobre una breve comprobación de disponibilidad por repositorio: los comandos utilizados, el tiempo que tardó la suite, qué pruebas se superaron y cada incidencia con la solución propuesta.

La ausencia de un entorno de ejecución tampoco supone un obstáculo: un contenedor que incluya la cadena de herramientas lo resuelve. Si no puede acceder al repositorio localmente, recoja toda la información posible del usuario y registre que la comprobación de clonado limpio no se realizó.

Consulte Configuración de compilación y pruebas y Soporte de lenguajes y entorno del agente.

Paso 3: Escriba las instrucciones que leen los agentes de Coroid.#

Antes de cada tarea, los agentes de Coroid leen los archivos de memoria del repositorio: AGENTS.md, CLAUDE.md o GEMINI.md en la raíz, y .cursor/rules. Los comandos que verificó en el Paso 2 deben ir allí.

Proponga un AGENTS.md, o una adición al existente, que indique:

• los comandos de instalación, compilación y prueba, verificados a partir de un clonado limpio, y el directorio donde ejecutarlos.
• los pasos y servicios que necesitan las pruebas.
• cómo ejecutar el conjunto más reducido y útil de pruebas, como un paquete o un archivo.
• las convenciones y límites que el código no muestra: módulos bloqueados, áreas que no se deben modificar, dependencias que no se deben añadir.

Omita lo que ya se indica en el código y mantenga el archivo breve. Si CLAUDE.md or .cursor/rules contiene las mismas instrucciones, guárdelas una sola vez en AGENTS.md y impórtelo desde el otro archivo mediante una línea @AGENTS.md .

Muéstrele al usuario la diferencia. Con su aprobación, confírmela en una rama nueva y abra una solicitud de incorporación de cambios en pull request, o déjela para que él la confirme. Debe llegar a la rama base antes de la primera tarea, ya que cada tarea lee los archivos de memoria desde su propia copia de dicha rama. Gestione las correcciones del Paso 2 que el usuario aceptó de la misma manera.

Consulte Configuración del contexto del proyecto y Contexto del proyecto.

Paso 4: Cuenta y organización (el usuario)#

Omita este paso si el usuario ya forma parte de una organización Coroid como Propietario o Administrador.

Solicite al usuario que:

1. se registre en https://client.coroid.ai/auth/signup con su correo electrónico laboral y verifique la dirección.
2. acepte los términos de servicio.
3. cree la organización.

Compruebe: que el usuario pueda abrir https://client.coroid.ai/projects. La persona que complete esta configuración necesita el rol de Propietario o Administrador, ya que solo esos roles pueden conectar el control de versiones y agregar claves de proveedor.

Consulte Crear su cuenta y organización.

Paso 5: Conectar el control de versiones (el usuario)#

Revise con el usuario los requisitos de acceso antes de que comience. Una instalación que se detiene a mitad de camino para esperar la aprobación de otra persona es la causa habitual por la cual este paso tarda un día en lugar de un minuto.

GitHub#

El usuario abre Configuración → Conexiones → Control de código fuente (https://client.coroid.ai/settings/connections/source-control).

GitHub App: en la pantalla de instalación de GitHub, el usuario selecciona Seleccionar solo repositorios y selecciona las que se acordaron en el Paso 1. La aplicación sigue funcionando cuando la persona que la instaló se va, recibe eventos de webhook y es lo que permite que Coroid publique sus comprobaciones en las solicitudes de extracción. Un token no puede publicar comprobaciones de GitHub.

Token de acceso personal: El usuario lo crea en GitHub con una fecha de caducidad y lo pega en el portal de Coroid. Es recomendable usar un token de alcance específico limitado a los repositorios acordados. Las solicitudes de extracción se atribuyen al propietario del token y la conexión se interrumpe si esa persona pierde acceso.

GitLab#

GitLab está en versión preliminar privada y solo aparece en las cuentas donde está habilitado. Se conecta mediante un token de acceso personal con el api ámbito. Si GitLab no aparece en Control de código fuente, indique al usuario que contacte con Coroid y no planifique en función de él.

Protección de ramas#

Coroid abre solicitudes de extracción normales, por lo que la protección de ramas, las comprobaciones requeridas y las reglas de revisión siguen aplicándose. Se recomienda mantener la protección activada. Si las reglas exigen confirmaciones firmadas o una comprobación de estado que Coroid no puede generar, sus solicitudes de extracción se abrirán y permanecerán sin fusionar. Informe al usuario y no modifique sus reglas.

Comprobación: el proveedor aparece como conectado en Control de código fuente. La verdadera prueba llega en el Paso 6, cuando los repositorios aparecen en la lista de proyectos.

Ver Conectar tu código, GitHub, GitLab y Configuración de repositorio y ramas.

Paso 6: Crear los proyectos (el usuario)#

Cree un proyecto por cada repositorio; nunca cree dos proyectos para un mismo repositorio. El usuario abre Proyectos → Nuevo (https://client.coroid.ai/projects/new) y, para cada repositorio:

1. lo selecciona del proveedor conectado o utiliza Conectar con URL para un repositorio público
2. elige el Modo de repositorio: Sincronizado, donde Coroid envía ramas y abre solicitudes de extracción, o Solo local, donde Coroid nunca escribe en el repositorio hasta que alguien seleccione Iniciar sincronización
3. comprueba la rama predeterminada
4. crea el proyecto

Si el equipo realiza fusiones en otra rama distinta a la predeterminada, como develop, configure la rama base en la configuración del repositorio del proyecto. Una rama base incorrecta enviará las solicitudes de extracción a una rama que nadie revisa.

Si un repositorio no aparece en la lista, la causa suele ser una de estas:

• la aplicación GitHub no tiene permiso para acceder a ese repositorio
• el ámbito del token es demasiado limitado para poder enumerarlo
• el repositorio pertenece a una organización diferente a la conectada

Ver Cree su primer proyecto y Configuración del repositorio y de la rama.

Paso 7: Compruebe lo que encontró Coroid#

Solicite al usuario que abra la vista general de cada proyecto y lea en voz alta los Repositorio detalles y todo lo que aparezca bajo Finalizar la configuración:

• Estado y Rama: el repositorio se clona en la rama base que acordaron. Si en la vista general indica que el repositorio aún no se ha clonado, el usuario elige Clonar repositorio.
• Stack: los lenguajes, frameworks, gestores de paquetes y herramientas de prueba que detectó Coroid. Compárelos con la comprobación de preparación. Si el stack está vacío o es incorrecto tras la primera sincronización, el usuario puede volver a escanearlo desde allí.
• Finalizar la configuración: elementos como "Las dependencias no se instalaron correctamente" señalan las mismas brechas que en el Paso 2. Resuélvalas junto con el usuario.

Luego, el usuario abre la Configuración → Conocimiento → Contexto. El archivo de memoria del Paso 3 debe aparecer bajo Fuentes del repositorio y estar habilitado. Si muestra Crear en su lugar, el archivo aún no ha llegado a la rama conectada.

Consulte Configuración del contexto del proyecto y Configuración de compilación y pruebas.

Paso 8: Configuración de la organización (opcional)#

Pregunte si el usuario desea configurar alguna de estas opciones ahora. Todas tienen valores predeterminados viables:

• Miembros, bajo Configuración → Miembros: las personas que revisarán las solicitudes de extracción, como Propietario, Administrador, Miembro o Revisor. Recomiende ser Administrador solo para quienes deban modificar políticas y claves de proveedor. Requiere la versión Professional.
• Claves de proveedor, bajo Configuración → Claves de proveedor: únicamente para usar las cuentas de proveedor de modelos propias de la organización. El usuario introduce la clave en el portal. Recomiende una clave restringida con límite de gasto en el proveedor.
• Configuraciones de otra organización: exporte un paquete de configuraciones allí e impórtelo bajo Configuración → Datos → Exportar configuracionesLos secretos se transmiten como marcadores de posición, por lo que cada needsRebind elemento en la vista previa requiere atención.

Ver Crea tu cuenta y tu organización, Claves de proveedor y Exportar e importar configuraciones.

Paso 9: Conéctese a Coroid (opcional)#

Si su cliente admite servidores MCP remotos, puede acceder a Coroid a través de su servidor MCP en https://api.coroid.ai/mcp. La configuración no depende de ello, pero le permite revisar los proyectos por sí mismo y ayudar al usuario a ejecutar trabajos más tarde.

1. El usuario abre Configuración → Conexiones → Coroid MCP server (https://client.coroid.ai/settings/connections/coroid-mcp). Si no está disponible para su organización, omita este paso.
2. Configuración del cliente muestra los comandos por cliente. Con OAuth, el usuario aprueba su acceso en el navegador. Con un token de acceso personal, el usuario lo crea en Tokens de acceso y lo guarda en una variable de entorno en su propio shell. Nunca necesitará ver su valor.
3. Recomiende el mínimo nivel de acceso que funcione: mcp.read para comprobar la configuración, además mcp.work.write solo si va a crear tareas. Limite el token a estos proyectos, indíquele una fecha de caducidad y configure Políticas de automatización antes de que cualquier cliente ejecute procesos automáticos.

Comprobación: llame a list_projects, luego get_project para cada proyecto del Paso 6, y confirme el repositorio y la rama.

Utilice solo api.coroid.ai para MCP. El nombre de host del portal del cliente no lo sirve.

Ver Coroid como servidor MCP.

Paso 10: Redactar una primera tarea#

Finalice redactando una primera tarea pequeña con el usuario en uno de los nuevos proyectos. Una buena primera tarea es real, pequeña, cercana a las pruebas existentes y tiene un objetivo claro. Evite la autenticación, los pagos, las migraciones de datos, las tareas de limpieza sin fin y todo aquello que requiera una decisión de diseño que aún no se haya tomado.

Describa el resultado, no la implementación: qué debe ser cierto cuando el trabajo esté terminado, qué archivos son relevantes y qué no tocar. El usuario lo envía desde Nuevo trabajo (https://client.coroid.ai/work/new), lee la specificación y aprueba el plan. Ejecutar trabajos consume horas de agente, y el plan Gratuito incluye 2 por día UTC, así que deje que el usuario decida cuándo se ejecutan.

Ver Ejecute su primera tarea y Especificaciones.

Paso 11: Entregar la solución#

Entregue al usuario el registro de configuración:

• cada repositorio, su proyecto, modo de repositorio y rama base
• cómo está conectado el control de versiones y quién es el propietario de la conexión: el instalador de la Aplicación, o el propietario del token y su fecha de caducidad
• por repositorio, las incidencias resueltas, las pendientes (como una solicitud de extracción abierta con AGENTS.md), y las que el usuario optó por dejar sin tratar
• la configuración opcional realizada y omitida, y la primera tarea redactada

Luego, indique al usuario que visite Revisar y fusionar el resultado para ver qué aporta la primera pull request.

Siguiente#

Crear su cuenta y organización — la misma configuración, realizada manualmente.