Harness
Coordina el recorrido: reparte el alcance del repo entre agentes y reúne las salidas en un resultado coherente.
Agente QEquipo de agentes QA sobre repositorios
Harness de agentes QA sobre GitHub y CI/CD
Un equipo de agentes QA que trabaja con tu equipo de desarrollo: revisa repositorios en GitHub y se alinea con vuestros sistemas de integración continua. Análisis estático, skills por dominio, informes e issues accionables, sin arrancar el producto.
Solo estático · issues con id de dominio · evidencia en rama del repo
Cómo se integra con desarrollo
Flujo de valor
Del repositorio a Issues, sin salir de GitHub
Con permisos, los hallazgos se publican como issues en el mismo repositorio del equipo.
GitHub
Repositorio a auditar
lee
Harness Agente Q
Agentes QA y skills
InventarioSeguridadCI/CD…
entrega
#
GitHub Issues
Tickets en el mismo repo
Informes en el portal
Resumen y docs por área
Rama de evidencia
agente-q/… en el repo
Acordáis el alcance con el equipo
Conectáis GitHub, elegís el repo y qué áreas de calidad entran en esta ronda (rápida, seguridad, completa…). Como un b…
El equipo de agentes QA revisa el código
Lee el árbol y la configuración sin ejecutar la app. Harness coordina agentes y skills por especialidad sobre ese alca…
Informes para desarrollo
Resumen, documentos por área y backlog priorizado quedan en el portal, listos para el triage del equipo.
Issues directas en GitHub Issues
Con permisos, se abren issues en el mismo repositorio (tablero Issues de GitHub), priorizadas y con criterios de acept…
Qué obtienes
Informes en el portal
Documentos por área y resumen para decidir con desarrollo y producto.
Issues en GitHub Issues
Tickets reales en el repo del equipo (P0-P3), listos para PR y triage.
Rama de evidencia
Copia de los informes en una rama agente-q/… sin tocar la rama que se revisó.
No es un auditor externo que desaparece con un PDF: con permisos, abre issues en GitHub Issues del propio repo y deja la evidencia en una rama. El issue es la unidad de trabajo; el informe, la evidencia.
Cómo está organizado ese equipo de agentes QA
Por dentro, el trabajo se reparte como en un equipo de calidad con especialidades: Harness coordina; los agentes ejecutan cada revisión; las skills definen qué mirar en cada área.
Agentes
Cada agente hace una pasada con una skill. Varios agentes sobre el mismo alcance contrastan hallazgos.
Skills
Especialidades: inventario, seguridad, pruebas, CI, runtime… Qué se revisa y cómo se documenta.
Ámbitos de auditoría
Análisis estático (solo lectura de código y configuración). Al lanzar una ronda elegís un paquete de alcance o dominios sueltos.
Paquetes de alcance
Rápida
Due diligence inicial: inventario, preparación estática, seguridad ligera, CI y tests.
InventarioRuntimeSeguridadCITestsNúcleo
Producto estándar: lo de «Rápida» más arquitectura, fiabilidad, datos, calidad y seguridad profunda.
Rápida +ArquitecturaFiabilidadDatosCalidadEnfoque seguridad
Prioriza AppSec y compliance técnico junto con inventario y preparación estática.
InventarioRuntimeSeguridadComplianceCompleta
Los 13 dominios y consolidación del backlog de trabajo para el equipo.
13 dominiosBacklogIssues
Dominios (especialidades)
Cada chip es un área del equipo de QA. Pasa el cursor para el resumen.
- Inventario
- Arquitectura
- Seguridad
- Calidad de código
- Fiabilidad
- Datos e integridad
- Pruebas
- CI/CD
- Rendimiento
- UX / API
- Compliance técnico
- Operación
- Preparación estática
Cuándo encaja
Cuando desarrollo necesita una pasada de calidad ordenada sin montar un proceso ad hoc: release, due diligence, AppSec o contraste de lecturas. Siempre en el mismo repositorio, con el alcance que definís y solo análisis estático.
Due diligence
Mapa del repo y huecos críticos en un tiempo acotado.
AppSec
Auth, inyecciones, config y dependencias desde el código.
Antes del release
CI, fiabilidad y backlog priorizado para el sprint.
Contraste
Varias lecturas sobre la misma área reducen el punto ciego.
Mismo repositorioAlcance que definísSolo análisis estático
GitHub e integración continua
El harness opera sobre el repositorio en GitHub: lee el código y, con permisos, publica issues en GitHub Issues del mismo repo y una rama de evidencia. En CI/CD, las skills revisan pipelines, gates y permisos como código, para que la calidad entre en el mismo flujo que el desarrollo.
Preguntas frecuentes
Respuestas de producto sobre alcance, dominios, entrega en GitHub y límites del harness. Sin jerga de infraestructura.
¿Qué es Agente Q en una frase?
Un harness de agentes QA que revisa repositorios en GitHub de forma estática (sin arrancar la app), genera informes por dominio y, con permisos, abre issues accionables en el mismo repo.
¿Ejecuta la aplicación o instala dependencias?
No. Es solo análisis estático: lee el árbol, la configuración y el código. No hace install, build ni tests en vuestro entorno. Eso reduce riesgo y deja la verificación dinámica a vuestro CI.
¿Dónde acaban los hallazgos?
En tres sitios: informes en el portal de Agente Q, issues en GitHub Issues del repositorio auditado (si hay permisos) y una rama de evidencia (agente-q/…) con la documentación. El issue es la unidad de trabajo del equipo; el informe, la evidencia.
¿Podemos elegir qué se revisa?
Sí. Al lanzar una ronda elegís un paquete de alcance (rápida, núcleo, seguridad, completa) o dominios sueltos. No hace falta una auditoría completa cada vez: el equipo de desarrollo define el brief de QA.
¿Qué dominios cubre el equipo de agentes?
Trece especialidades estáticas: inventario, arquitectura, seguridad, calidad de código, fiabilidad, datos, pruebas (existencia y forma de la suite, sin ejecutarla), CI/CD, rendimiento, UX/API, compliance técnico, operación y preparación estática (runtime). La completa consolida todo en un backlog priorizado.
¿Rápida, núcleo, seguridad o completa: cuándo cada una?
Rápida: due diligence inicial (inventario, runtime, seguridad ligera, CI y tests). Núcleo: producto estándar (rápida más arquitectura, fiabilidad, datos y calidad). Seguridad: foco AppSec y compliance. Completa: los 13 dominios y skill de backlog para issues canónicos.
¿En qué momentos de producto encaja mejor?
Due diligence de un repo desconocido, pasada AppSec antes de un release, limpieza de deuda de CI/calidad en sprint, o contraste de varias lecturas sobre la misma área. Cuando necesitáis orden y tickets en el tablero, no otro PDF suelto.
¿Por qué varios agentes o modelos sobre el mismo alcance?
Cada agente hace una pasada completa con las skills del alcance; el agregador fusiona por dominio. Varias lecturas reducen el punto ciego de un solo revisor o un solo modelo, y el resultado se unifica en informes e issues con id de dominio (por ejemplo AQ-SEC-001).
¿Sustituye a nuestro CI/CD?
No. Complementa: las skills de CI/CD revisan pipelines, gates y permisos como código. Los issues salen a GitHub para que el equipo cierre con PR en el mismo flujo de desarrollo e integración continua.
¿Cómo se priorizan las issues?
Con etiquetas P0–P3 y prefijos de dominio (SEC, ARCH, QUAL…). Hay un tope configurable de issues P0 por job para no aplanar el tablero; el resto se degrada a P1 si hace falta. Idempotencia: reauditorías no duplican el mismo hallazgo.
¿Qué permisos de GitHub hacen falta?
Lectura del repositorio para auditar. Para publicar issues y la rama de evidencia hacen falta permisos de escritura (App o token con scope adecuado). Sin escritura, siguen los informes en el portal; no se crean tickets en el repo.
¿Cómo se obtiene acceso?
El registro está cerrado: acceso por invitación o preaprobación. Podéis solicitar acceso desde la landing; el login con GitHub es para cuentas ya autorizadas.
Acceso por invitación
El registro está cerrado. Solo entran cuentas preaprobadas. Si aún no tienes acceso, envía una solicitud breve.