Configurar con tu asistente de AI

Esta página es una guía destinada a un asistente de AI: Claude Code, Codex, Cursor o cualquier asistente capaz de leer una página web e, 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, otorgar 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 a todos y menciona sus nombres 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 desarrollo de software de AI alojada que convierte una descripción de 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 u otorgar acceso en nombre del usuario. Indica exactamente qué hacer y dónde, y espera a que el usuario confirme que se ha completado.
2. Mantén los secretos fuera de la conversación. Nunca pidas una contraseña, token de acceso personal, clave de proveedor o token de 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 de todos modos, 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, consulta las notas de ese paso y continúa solo cuando se apruebe 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. Guarda un registro de la configuración. de cada paso y su resultado, para el final.

Cada paso vincula las páginas con los detalles correspondientes. https://coroid.ai/llms.txt Indexa toda la documentación.

Paso 1: Acordar el plan.#

Haz estas preguntas al usuario de forma conjunta, no una por una:

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

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

Paso 2: Verificar 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 de trabajo Linux limpio y desechable: un clon recién creado, sin caché ni elementos instalados aparte del conjunto 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 real.

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. Busca 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 archivos que ocultan problemas. .env archivos que ocultan problemas.
4. Anota todo lo que necesitó la ejecución y que no está disponible en un clon recién creado:
   • 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 archivo .env archivo que no está incluido en el commit.
   • 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 de pruebas es lenta o utiliza servicios de pago, pregunta primero al usuario.

Informa de una breve comprobación de disponibilidad por repositorio: los comandos utilizados, cuánto tiempo tardó la suite, qué pasó y cada discrepancia con una solución propuesta.

La falta de un entorno de ejecución tampoco supone un obstáculo: un contenedor que incluya el conjunto de herramientas lo resuelve. Si no puedes acceder al repositorio de forma local, recopila toda la información posible del usuario y registra que la comprobación del clon limpio no se realizó.

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

Paso 3: Escribe 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 validaste en el Paso 2 deben ir allí.

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

• los comandos de instalación, compilación y prueba, validados a partir de un clon 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 específico.
• 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.

Omitir lo que ya se indica en el código y mantener el archivo breve. Si CLAUDE.md o .cursor/rules contiene las mismas instrucciones, guárdalas una vez en AGENTS.md y impórtalo desde el otro archivo con una línea @AGENTS.md .

Muestra al usuario las diferencias. Con su aprobación, se confirma en una rama nueva y se abre un pull request, o bien se deja que el propio usuario lo 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 esa rama. Gestiona las correcciones del Paso 2 que el usuario haya aceptado de la misma manera.

Ver 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 pertenece a una organización de Coroid como Propietario o Administrador.

Pídale 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: si el usuario puede 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 código fuente y agregar claves de proveedor.

Ver Cree su cuenta y organización.

Paso 5: Conectar control de código fuente (el usuario)#

Revisa con el usuario los requisitos de acceso antes de que comience. Un proceso de instalación que se detenga a la mitad 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 únicamente repositorios y elige los acordados en el Paso 1. La aplicación sigue funcionando cuando la persona que la instaló se marcha, recibe eventos de webhook y es lo que permite a Coroid publicar 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 preferible un token 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 el acceso.

GitLab#

GitLab está en versión privada de previsualización y solo aparece en cuentas donde está habilitado. Se conecta mediante un token de acceso personal con el api ámbito. Si GitLab no aparece bajo 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 genera pull requests estándar, por lo que las reglas de protección de ramas, las comprobaciones obligatorias y las normas de revisión siguen aplicándose. Se recomienda mantener activada la protección. Si dichas reglas requieren commits firmados o una comprobación de estado que Coroid no pueda generar, sus pull requests se abrirán y permanecerán sin fusionar. Informe al usuario y no modifique sus reglas.

Comprobar: que el proveedor aparezca como conectado en Control de código fuente. La verdadera confirmación llega en el Paso 6, cuando los repositorios aparezcan en la lista de proyectos.

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

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 pull requests, 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 fusiona cambios en una rama distinta a la predeterminada, como develop, configure la rama base en la configuración del repositorio del proyecto. Una rama base incorrecta enviará los pull requests 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 recibió permiso para acceder a ese repositorio
• el alcance del token es demasiado limitado para enumerarlo
• el repositorio pertenece a una organización diferente a la conectada

Ver Crear tu primer proyecto y Configuración de repositorio y rama.

Paso 7: Comprobar 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 configuración:

• Estado y Rama: el repositorio está clonado y en la rama base acordada. Si en la vista general indica que el repositorio aún no se ha clonado, el usuario debe seleccionar Clonar repositorio.
• Stack: los lenguajes, frameworks, gestores de paquetes y herramientas de prueba que detectó Coroid. Compárelos con su comprobación de preparación. Si el stack está vacío o es incorrecto después de la primera sincronización, el usuario puede volver a escanearlo desde allí.
• Finalizar 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 sección 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, significa que el archivo aún no ha llegado a la rama conectada.

Ver 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, en Configuración → Miembros: las personas que revisarán los pull requests como Propietario, Administrador, Miembro o Revisor. Se recomienda asignar el rol de Administrador solo a quienes deban modificar políticas y claves de proveedor. Requiere el plan Professional.
• Claves de proveedor, en Configuración → Claves de proveedor: únicamente para utilizar las cuentas del proveedor de modelos propias de la organización. El usuario ingresa la clave en el portal. Se recomienda usar una clave con restricciones y límite de gasto establecido por el proveedor.
• Configuraciones de otra organización: exporte un paquete de configuraciones allí e impórtelo en Configuración → Datos → Exportar configuraciones. Los secretos se transmiten como marcadores de posición, por lo que cada elemento en la vista previa requiere atención. needsRebind Cada elemento en la vista previa necesita atención.

Consulte Crear su cuenta y organización, Claves de proveedor y Exportar e importar configuraciones.

Paso 9: Conectarse 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 verificar los proyectos por sí mismo y ayudar al usuario a ejecutar trabajos más adelante.

1. El usuario abre Configuración → Automatización → Coroid MCP server (https://client.coroid.ai/settings/automation/coroid-mcp). Si no está disponible para su organización, omita este paso.
2. Configuración del cliente muestra los comandos según el 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. Usted nunca necesita ver ese valor.
3. Recomendamos otorgar el mínimo acceso necesario: mcp.read para verificar la configuración, más mcp.work.write únicamente si va a crear tareas. Limite el token a estos proyectos, establezca una fecha de caducidad y configure Políticas de automatización antes de que cualquier cliente ejecute procesos sin supervisión.

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

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

Consulte 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, pagos, migraciones de datos, tareas de limpieza indefinidas y cualquier cosa que requiera una decisión de diseño aún no tomada.

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

Consulte Ejecutar su primera tarea y Especificaciones.

Paso 11: Entregar la informació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 código fuente 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 cada repositorio, las correcciones aplicadas, las pendientes (como una solicitud de extracción abierta con AGENTS.md), y las que el usuario decidió omitir
• La configuración opcional realizada y omitida, y la primera tarea redactada

Luego, indique al usuario a dónde dirigirse Revisar y fusionar el resultado para saber qué incluye la primera pull request.

Siguiente#

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