Trabajo con código y pull requests
Encargue una incidencia a su propio agente de código con un prompt copiado y minddy MCP, y después revise y fusione la pull request vinculada.
Minddy hace el seguimiento del trabajo; su propio agente de código, como Claude Code, Codex o Cursor, modifica el código. Copie un prompt desde la incidencia, deje que el agente lea y actualice la incidencia a través de minddy MCP y revise después la pull request vinculada en Minddy antes de fusionarla. Numo no escribe código, no abre ramas ni ejecuta pruebas.
Encargar una incidencia a un agente de código externo
Conecte primero su agente a minddy MCP para que pueda leer el plan y actualizar sus tareas; consulte Conectar un asistente externo al MCP de minddy. El agente se ejecuta en su ordenador o en su propio servicio, con su propia suscripción o sus propios costes de API. Minddy no le proporciona acceso al repositorio.
- Abra la incidencia y describa el comportamiento esperado, las restricciones y las comprobaciones de aceptación. Escriba o revise el plan en su pestaña Plan cuando el trabajo tenga varios pasos.
- Abra el menú de acciones de la incidencia y elija Copiar como prompt. Elija Generar un plan (o Revisar el plan si ya existe) para delimitar el trabajo sin programar, Implementar la incidencia para empezar el cambio, Verificar la implementación para que el agente revise el trabajo terminado frente al plan y los comentarios, o Personalizado… para escribir su propia instrucción.
- Pegue el prompt en su agente, dentro de la copia de trabajo del repositorio. Copiar no ejecuta ningún modelo de IA ni consume cuota de IA.
- Siga el progreso del plan en la incidencia mientras el agente actualiza sus tareas a través de MCP. Responda a sus preguntas en el agente o añada las decisiones a la incidencia para que el siguiente prompt las incluya.
El contenido del prompt, la rama sugerida y las reglas de idioma se describen en Copiar un prompt para otro agente de código.
Mantener el trabajo vinculado a la incidencia
Cuando el repositorio está vinculado al proyecto, mantenga el identificador de la incidencia en el nombre de la rama, en el título de la pull request o en una línea Fixes MIN-42. Minddy vincula entonces la pull request a la incidencia, y los prompts siguientes indican al agente que continúe la pull request abierta en su rama. Para vincular una incidencia a mano, use Vincular una incidencia en la pull request. Su búsqueda acepta un identificador o palabras del título, y una descripción también muestra incidencias del proyecto encontradas por el sentido bajo Relacionadas por el sentido.
Desde un tablero, haga clic derecho en una incidencia sin pull request abierta y elija Vincular a una pull request para escoger una de las pull requests abiertas de su proyecto, incluidos los borradores. La opción solo aparece cuando ese proyecto tiene al menos una pull request que vincular. Con varias incidencias seleccionadas, Acciones ofrece la misma opción para toda la selección, y Vincular las demás incidencias a #N cuando algunas ya tienen la pull request N. Vincular a una pull request deja de ofrecerse en cuanto una incidencia seleccionada tiene alguna pull request vinculada; Desvincular N incidencias de sus pull requests quita primero todos los vínculos de la selección, después de que lo confirme. Los vínculos aparecen al instante en las tarjetas, y un vínculo rechazado desaparece cuando el tablero se actualiza. Una tarjeta con una pull request abierta muestra su número, coloreado según su estado, y su preparación para la fusión, el mismo indicador que en Revisión de código.
En Configuración de la cuenta → Incidencias → Iniciar una incidencia, Inicia la incidencia o tarea cuando copies su prompt pasa a «En curso» una incidencia o una tarea del cuaderno que aún no ha empezado cuando copia su prompt. Déjelo desactivado si solo copia prompts para leerlos.
Revisar una pull request vinculada
Abra la pull request vinculada a una incidencia o búsquela en la lista de pull requests. Sigue siendo necesario acceder al repositorio; pertenecer al proyecto no concede permisos del proveedor Git.
Lea la descripción y la actividad y después los archivos modificados y los bloques de diferencias. Abra las conversaciones sin resolver y responda en el hilo correspondiente en lugar de crear un comentario aparte. Para devolver a su agente los comentarios pendientes, abra Ver conversaciones, después Corregir todo y Copiar prompt. Marcar archivos como revisados registra su lectura, pero no constituye una aprobación del proveedor. Compruebe los commits, los resultados de CI y las incidencias vinculadas para confirmar que el cambio propuesto cubre el trabajo solicitado.
En una descripción, un comentario o la diferencia de una imagen, haga clic en una imagen para abrirla en toda la ventana; la diferencia de una imagen abre por separado sus lados Antes y Después. Use Cerrar o Escape para volver a la pull request.
Mencione @numo en un comentario de la pull request para pedir a Numo una revisión de solo lectura en una conversación. Numo lee la pull request y responde; no sube commits. Una mención escrita en el proveedor Git solo cuenta si su autor está vinculado al propietario o a un Miembro (no a un lector) de un proyecto que vincula el repositorio, y su uso se imputa al propietario de ese proyecto.
Revisión y fusión
Use Solicitar revisión para elegir un revisor cuando haga falta una segunda revisión. Compruebe si es borrador o está lista para revisión, las discusiones abiertas, las revisiones solicitadas y la política de fusión del proveedor.
Fusione solo después de satisfacer los controles y revisiones aplicables y cuando su cuenta del proveedor tenga permiso. Fusionar con Numo permite que Numo redacte el título y la descripción del commit de fusión a partir de la pull request y fusione en cuanto estén listos. El proveedor Git puede rechazar una acción visible. Si el estado mostrado parece desactualizado, actualice y consulte el proveedor antes de repetir la acción. Una vista previa vinculada depende de un despliegue real del proveedor.
Haga clic derecho en una pull request de la lista para cambiar su estado, fusionarla o pedir una corrección sin abrirla. Una pull request abierta ofrece Convertir en borrador y Cerrar pull request, un borrador ofrece Listo para la revisión y Cerrar pull request, y una cerrada ofrece Reabrir; cada cambio pide confirmación. Una pull request fusionada no ofrece ningún cambio de estado. Las acciones de escritura solo aparecen cuando su cuenta del proveedor puede escribir en el repositorio y no están disponibles hasta que el menú vuelve a leer la pull request. Fusionar aparece cuando la pull request está abierta, no es un borrador y puede fusionarse; abre la pull request en su confirmación de fusión habitual. Copiar prompt de corrección y Corregir con Numo aparecen cuando falla una comprobación, hay una conversación sin resolver o la rama tiene conflictos o está desactualizada. Corregir con Numo envía ese prompt a Numo con la pull request como contexto. Numo puede leer la pull request, responder a una conversación de revisión que no requiere cambios en el código y resolver las conversaciones que la rama ya atiende, pero no modifica el código ni hace push de commits; para los cambios de código, use Copiar prompt de corrección y péguelo en su agente de código. Los permisos y la posibilidad de fusionar se vuelven a comprobar al confirmar.