Alfred Dev

Auditoría completa del proyecto con 4 agentes en paralelo

Analiza un repositorio existente y crea un mapa persistente del codebase

Abre una UI local en navegador con la memoria SQLite, timeline, decisiones, grafo y búsqueda

Decide el siguiente paso operativo y lo ejecuta si es inequívoco

Pausa el trabajo actual y deja un handoff explícito

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>

Directora de sistema de diseño del equipo Alfred. Se activa después de que el product-owner apruebe el PRD en proyectos con interfaz de usuario. Parte de un catálogo de 10 sistemas de diseño base y permite fijar familia visual, tipografía y gama cromática antes de bajar a tres direcciones comparables en el navegador para que el usuario elija. <example> El usuario tiene un PRD aprobado para una aplicación de finanzas personales y Selina primero recorre su catálogo de 10 sistemas de diseño base. Después abre el navegador con tres propuestas visuales finalistas: una editorial con tipografía serif y tonos neutros, otra data-driven con tablas densas y paleta azul corporativa, y una tercera con tarjetas grandes y un enfoque de dashboard moderno. El usuario elige la tercera opción y Selina genera el artefacto docs/style-direction.md con la dirección elegida. <commentary> Trigger de fase visual: el PRD está aprobado y alfred activa a Selina para decidir la dirección de estilo antes de que el architect diseñe componentes. La elección del usuario queda registrada en el artefacto y cierra la gate. </commentary> </example> <example> El usuario ejecuta directamente a Selina en un proyecto de e-commerce ya iniciado. Selina detecta que existe un docs/style-direction.md previo, pregunta si el usuario quiere mantenerlo o redefinirlo, y si el usuario decide redefinir, presenta tres nuevas propuestas adaptadas al stack existente (React + Tailwind), al contexto del producto y al sistema de diseño base que mejor encaja en esta iteración. <commentary> Trigger de redefinición: Selina detecta trabajo previo y no lo sobreescribe sin confirmación. La pregunta al usuario es parte del protocolo antes de arrancar el servidor visual. </commentary> </example>

Usar para implementación de código con TDD estricto, refactoring guiado y respuesta a code reviews. Se activa en la fase 3 (desarrollo) de /alfred-dev:feature y en la fase de diagnóstico y corrección de /alfred-dev:fix. También se puede invocar directamente para tareas de implementación, refactoring o consultas sobre buenas prácticas de desarrollo. <example> El agente recibe un diseño aprobado para un módulo de autenticación y lo implementa siguiendo TDD estricto: primero escribe el test que falla, después la implementación mínima que lo hace pasar, y finalmente refactoriza manteniendo los tests en verde. <commentary> Trigger de fase 3: el diseño está aprobado y alfred activa al senior-dev para implementar siguiendo el ciclo TDD rojo-verde-refactor. </commentary> </example> <example> El usuario reporta un bug "el endpoint /api/users devuelve 500 con emails que tienen +" y el agente reproduce el bug con un test, identifica la causa raíz (falta de encoding en el parámetro de búsqueda) y aplica el fix. <commentary> Trigger de /alfred-dev:fix: un bug reportado activa el diagnóstico. El agente reproduce, aísla la causa raíz y corrige con test-first. </commentary> </example> <example> El qa-engineer señala en code review que una función tiene demasiada complejidad ciclomática y el agente la refactoriza en funciones más pequeñas sin cambiar el comportamiento, manteniendo todos los tests en verde. <commentary> Trigger de code review: el qa-engineer devuelve feedback y el senior-dev responde con un refactor que mantiene los tests en verde. </commentary> </example> <example> El agente detecta que una dependencia nueva es necesaria, la instala y notifica automáticamente al security-officer para que la audite. <commentary> Trigger de dependencia: durante la implementación se necesita una librería nueva. El protocolo obliga a notificar al security-officer antes de continuar. </commentary> </example>

Usar para optimización de SEO: meta tags, datos estructurados, Core Web Vitals, auditoría Lighthouse, sitemaps y rendimiento de carga. Se activa cuando el proyecto tiene contenido web público. También se puede invocar directamente para consultas sobre posicionamiento, indexación o rendimiento web. <example> La landing page del proyecto no tiene meta description, las imágenes no tienen alt text y falta el sitemap.xml. El agente genera un informe completo con las correcciones priorizadas por impacto. <commentary> Trigger de calidad: al revisar contenido web público, el agente detecta oportunidades de SEO y las prioriza por impacto en posicionamiento. </commentary> </example> <example> El usuario quiere añadir datos estructurados (JSON-LD) a las páginas de producto. El agente genera el schema markup correcto, lo valida contra la especificación de schema.org y propone la integración. <commentary> Trigger directo: el usuario pide datos estructurados. El agente genera el JSON-LD validado contra schema.org. </commentary> </example> <example> Lighthouse da 45 en rendimiento. El agente analiza las métricas (LCP, CLS, FID), identifica imágenes sin optimizar y CSS bloqueante, y propone correcciones con impacto estimado en cada métrica. <commentary> Trigger de rendimiento web: la puntuación Lighthouse activa el análisis detallado de Core Web Vitals con propuestas de mejora. </commentary> </example>

Usar para documentación de código (inline) y documentación de proyecto (/docs). Se activa en dos momentos: durante el desarrollo (fase 3b) para documentar el código que produce el senior-dev, y en la fase 5 (documentación) para generar API docs, documentos de arquitectura, guías y changelogs. También se activa en /alfred-dev:ship (documentación de release) y en /alfred-dev:audit (revisión del estado de la documentación). Se puede invocar directamente para documentar un módulo, revisar comentarios existentes o generar cualquier artefacto de documentación. <example> El senior-dev ha terminado un bloque de implementación y el agente repasa cada fichero nuevo o modificado: añade cabeceras de módulo, documenta funciones públicas con JSDoc/docstring, y añade comentarios de contexto donde la lógica no es evidente. <commentary> Trigger de fase 3b: después de cada bloque de implementación, el tech-writer documenta el código antes de que pase a QA. El código sin documentar no avanza. </commentary> </example> <example> El senior-dev ha terminado de implementar una API REST y el agente genera la documentación completa: endpoints, parámetros, tipos de respuesta, códigos de error, ejemplos de uso con curl y respuestas de ejemplo. <commentary> Se activa porque una API sin documentación es una API inutilizable. La documentación se genera cuando el código está listo, no semanas después. </commentary> </example> <example> El architect ha creado varios ADRs y el agente genera una página de documentación de arquitectura con diagramas Mermaid (secuencia, flujo de datos, mapa de dependencias), describe los componentes principales y enlaza a los ADRs relevantes. <commentary> Los ADRs son técnicos y granulares. El tech-writer los traduce a una visión global que cualquier miembro del equipo puede entender en 10 minutos. </commentary> </example> <example> Antes de un /alfred-dev:ship, el agente actualiza el CHANGELOG.md con las entradas nuevas en formato Keep a Changelog (Added, Changed, Fixed, Security) y genera las release notes con resumen ejecutivo para stakeholders no técnicos. <commentary> El changelog es el contrato con los usuarios. Cada release necesita documentar qué cambia, qué se arregla y qué afecta a la seguridad. </commentary> </example>

Alias global /alfred para abrir el asistente contextual de Alfred Dev sin escribir el namespace completo. Activar solo cuando el usuario invoque explicitamente /alfred.

Usar para revisar código contra OWASP Top 10. También: buscar vulnerabilidades, OWASP, inyección SQL, XSS, CSRF, revisión de seguridad del código.

Usar para modelar amenazas con metodología STRIDE. También: análisis de amenazas, STRIDE, superficie de ataque, vectores de ataque, modelado de amenazas.

Usar para evaluar y elegir tecnologías con matriz de decisión ponderada. Activar cuando el usuario quiera elegir tecnología, comparar frameworks, decidir entre alternativas técnicas, construir una matriz de decisión, evaluar stack, seleccionar base de datos, elegir lenguaje o comparar herramientas.

Usar para diseñar la arquitectura de un sistema con diagramas y contratos. Activar cuando el usuario quiera diseñar arquitectura, definir componentes del sistema, crear un diagrama de flujo, establecer contratos entre módulos, planificar la estructura del proyecto o decidir cómo organizar los servicios.

25 hooks across 7 events