Alfred Dev

Auditoría completa del proyecto con 4 agentes en paralelo

Lista las tareas bloqueadas del kanban de SonIA

Configura Alfred Dev: autonomía, proyecto, agentes opcionales, memoria y personalidad

Refina una idea o feature antes de abrir un flujo completo de implementación

Ciclo completo de desarrollo: producto, arquitectura, desarrollo, QA, docs, entrega

Usar cuando se necesita orquestar un flujo completo de desarrollo: /alfred-dev:feature, /alfred-dev:fix, /alfred-dev:ship, /alfred-dev:spike o /alfred-dev:audit. Este agente es el mayordomo jefe del equipo Alfred Dev: decide qué agentes activar, en qué orden, y evalúa las quality gates entre fases. También se activa cuando el usuario necesita una visión general del estado del proyecto o quiere entender qué paso dar a continuación. <example> El usuario escribe "/alfred-dev:feature sistema de autenticación con OAuth2" y el agente arranca el flujo de 6 fases, delegando primero en product-owner para el PRD. <commentary> Trigger directo: el usuario invoca /alfred-dev:feature con descripción. Se arranca el flujo feature completo empezando por product-owner. </commentary> </example> <example> El usuario escribe "/alfred-dev:fix el endpoint de login devuelve 500 con emails que tienen caracteres especiales" y el agente arranca el flujo de 3 fases, delegando en senior-dev para el diagnóstico. <commentary> Trigger de bug: el usuario invoca /alfred-dev:fix con descripción del error. Se arranca el flujo fix empezando por senior-dev para diagnóstico. </commentary> </example> <example> El usuario escribe "/alfred-dev:ship" y el agente coordina la auditoría final con qa-engineer y security-officer en paralelo antes de proceder al empaquetado. <commentary> Trigger de despliegue: /alfred-dev:ship lanza la auditoría final obligatoria antes de empaquetar y desplegar. </commentary> </example> <example> El usuario pregunta "qué debería hacer ahora?" y el agente revisa el estado de la sesión activa para indicar la fase pendiente y los agentes que deben actuar. <commentary> Trigger de estado: el usuario pide orientación sin comando específico. Alfred revisa la sesión activa y recomienda la próxima acción. </commentary> </example>

Usar para diseño de arquitectura, elección de stack tecnológico, ADRs (Architecture Decision Records) y evaluación de dependencias. Se activa en la fase 2 (arquitectura) de /alfred-dev:feature y en /alfred-dev:spike. También se puede invocar directamente para consultas de diseño de sistemas, evaluación de patrones o revisión de acoplamiento. <example> El usuario tiene un PRD aprobado para un sistema de pagos y el agente diseña la arquitectura: componentes, flujo de datos, patrón de integración con la pasarela de pago, y genera un diagrama Mermaid del sistema. <commentary> Trigger de fase 2: el PRD está aprobado y alfred activa al architect para diseñar la arquitectura completa del sistema. </commentary> </example> <example> El equipo necesita elegir entre Drizzle y Prisma como ORM y el agente genera una matriz de decisión con criterios ponderados (rendimiento, DX, migraciones, tipado, madurez, comunidad) y una recomendación argumentada. <commentary> Trigger de elección tecnológica: el equipo necesita decidir entre alternativas. Se genera la matriz de decisión ponderada como herramienta objetiva. </commentary> </example> <example> El usuario ejecuta "/alfred-dev:spike websockets vs SSE para notificaciones en tiempo real" y el agente investiga ambas opciones, las compara con pruebas de concepto y documenta los hallazgos en un ADR. <commentary> Trigger de spike: /alfred-dev:spike activa la investigación técnica. El architect explora alternativas y documenta hallazgos sin compromiso de implementación. </commentary> </example> <example> El agente detecta acoplamiento entre dos módulos y propone una interfaz de separación con diagrama de dependencias antes/después. <commentary> Trigger de revisión: durante una auditoría o revisión de arquitectura, el agente detecta un anti-patrón y propone la solución con diagramas. </commentary> </example>

Usar para revisión y redacción de textos públicos: landing pages, emails, onboarding, CTAs, microcopy y guías de tono. Se activa cuando el proyecto tiene textos dirigidos a usuarios o visitantes. También se puede invocar directamente para mejorar copys, revisar el tono de comunicación o generar variantes de texto para A/B testing. <example> La landing page del producto tiene CTAs genéricos ("Haz clic aquí", "Enviar") y párrafos largos sin estructura. El agente reescribe los textos con CTAs orientados a acción, párrafos cortos y tono coherente. <commentary> Trigger de calidad: al revisar la landing, el agente detecta copys genéricos y los reescribe manteniendo el tono de la marca. </commentary> </example> <example> El usuario necesita los textos para un flujo de onboarding: bienvenida, primeros pasos, confirmación. El agente redacta cada pantalla con tono cercano, instrucciones claras y sin jerga técnica innecesaria. <commentary> Trigger directo: el usuario pide textos para un flujo nuevo. El agente redacta adaptándose al contexto y al público objetivo. </commentary> </example> <example> El equipo quiere definir una guía de tono para que toda la comunicación del producto sea coherente. El agente genera la guía con principios, ejemplos de lo que sí y lo que no, y variantes por contexto (marketing, soporte, documentación). <commentary> Trigger de documentación: el equipo necesita coherencia en la comunicación. El agente genera la guía de tono como referencia. </commentary> </example>

Usar para modelado de datos, diseño de esquemas, planificación de migraciones, optimización de queries y gestión de ETL. Se activa cuando el proyecto trabaja con bases de datos, ORMs o pipelines de datos. También se puede invocar directamente para consultas sobre modelado relacional, índices o rendimiento de queries. <example> El proyecto usa Prisma con PostgreSQL y necesita añadir un sistema de permisos por roles. El agente diseña el esquema (tablas, relaciones, índices) y genera la migración con rollback incluido. <commentary> Trigger de arquitectura: el architect necesita un esquema de datos para el diseño. El data-engineer diseña tablas, relaciones e índices. </commentary> </example> <example> Una query tarda 3 segundos en producción. El agente analiza el plan de ejecución, identifica un full scan por falta de índice y propone la solución con benchmark antes/después. <commentary> Trigger de rendimiento: una query lenta activa el análisis. El agente diagnostica con EXPLAIN y propone índices o reescritura. </commentary> </example> <example> El equipo necesita migrar de SQLite a PostgreSQL. El agente planifica la migración paso a paso: mapeo de tipos, adaptación de queries, script de migración de datos y plan de rollback. <commentary> Trigger directo: el usuario pide una migración de motor. El agente planifica cada paso con red de seguridad. </commentary> </example>

Usar para auditoría de seguridad, compliance RGPD/NIS2/CRA, revisión OWASP Top 10, auditoría de dependencias (CVEs, licencias, versiones) y generación de SBOM. Se activa en las fases 2, 3, 4 y 6 de /alfred-dev:feature, en /alfred-dev:ship y en /alfred-dev:audit. Es gate obligatoria en todo despliegue a producción. También se puede invocar directamente para consultas de seguridad o compliance. <example> El architect presenta un diseño y el agente revisa los vectores de ataque usando STRIDE, genera un threat model y valida que el diseño cumple con RGPD artículo 25 (protección desde el diseño). <commentary> Se activa porque un diseño nuevo introduce superficie de ataque que debe evaluarse antes de escribir código. La seguridad se diseña, no se parchea. </commentary> </example> <example> El senior-dev instala una nueva dependencia y el agente la audita: busca CVEs conocidos, revisa la licencia, comprueba la frecuencia de mantenimiento y analiza las dependencias transitivas. <commentary> Cada dependencia nueva es código de terceros que se ejecuta con los mismos privilegios que el nuestro. Auditar antes de integrar evita heredar vulnerabilidades. </commentary> </example> <example> Antes de un despliegue con /alfred-dev:ship, el agente ejecuta una auditoría completa: OWASP Top 10 sobre el código, auditoría de dependencias, checklist de compliance RGPD + NIS2 + CRA y generación del SBOM. <commentary> El despliegue a producción es la última barrera. Una auditoría completa aquí debe bloquear vulnerabilidades conocidas detectadas antes de que lleguen a los usuarios. </commentary> </example> <example> El agente detecta un token hardcodeado en el código y bloquea el avance hasta que se mueva a variables de entorno, argumentando que viola OWASP A07 (Security Misconfiguration) y CRA artículo 10. <commentary> Los secretos en el código fuente son una de las causas más frecuentes de brechas. Un solo token expuesto puede comprometer todo el sistema. </commentary> </example>

Usar siempre antes de implementar código. Ciclo rojo-verde-refactor estricto. Activar cuando el usuario quiera hacer test first, escribir test antes de implementar, seguir el ciclo rojo verde refactor, desarrollo guiado por tests, TDD o implementar una funcionalidad de forma segura con tests.

Configurar pipeline CI/CD adaptado al proyecto. Activar cuando el usuario quiera configurar CI, crear GitHub Actions, configurar GitLab CI, montar un pipeline de despliegue, automatizar tests o implementar integracion continua.

Configurar despliegue según hosting. Activar cuando el usuario quiera desplegar en Vercel, Railway, AWS, configurar hosting, preparar para produccion o gestionar variables de entorno de despliegue.

Generar Dockerfile optimizado. Activar cuando el usuario quiera crear contenedor, generar imagen Docker, configurar Docker Compose, contenerizar aplicacion o crear un Dockerfile multi-stage.

Configurar observabilidad del servicio. Activar cuando el usuario quiera configurar logging, integrar Sentry, implementar error tracking, definir metricas, configurar alertas, mejorar la observabilidad o monitorizar un servicio.

25 hooks across 7 events