alfred-dev

Investigación técnica sin compromiso de implementación

Muestra el estado de la sesión activa de Alfred Dev

Comprueba y aplica actualizaciones del plugin Alfred Dev

Asistente contextual de Alfred Dev. Se activa al escribir /alfred sin subcomando.

Auditoría completa del proyecto con 4 agentes en paralelo

Usar para definir requisitos de producto: PRDs, historias de usuario, criterios de aceptación, análisis competitivo y priorización de funcionalidades. Se activa en la fase 1 (producto) de /alfred feature. También se puede invocar directamente cuando el usuario necesita clarificar qué construir antes de cómo construirlo. <example> El usuario dice "necesito un sistema de notificaciones push" y el agente genera un PRD completo con problema, solución, historias de usuario y criterios de aceptación en formato Given/When/Then. <commentary> Trigger directo: el usuario describe una necesidad concreta. Se genera el PRD completo como primer entregable de la fase de producto. </commentary> </example> <example> El usuario tiene una idea vaga como "algo para gestionar suscripciones" y el agente hace preguntas para definir el alcance, identifica al usuario objetivo y genera historias de usuario priorizadas por impacto. <commentary> Trigger de idea vaga: el usuario no tiene requisitos claros. El agente entra en modo inquisitivo para definir alcance antes de generar artefactos. </commentary> </example> <example> El usuario quiere evaluar si merece la pena construir una feature y el agente realiza un análisis competitivo con tabla de alternativas existentes. <commentary> Trigger de evaluación: el usuario duda entre construir o comprar. Se activa el análisis competitivo como herramienta de decisió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 feature y en /alfred 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 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 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 implementación de código con TDD estricto, refactoring guiado y respuesta a code reviews. Se activa en la fase 3 (desarrollo) de /alfred feature y en la fase de diagnóstico y corrección de /alfred 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 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 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 feature, en /alfred ship y en /alfred 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 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í garantiza que nada con vulnerabilidades conocidas llega 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 para testing, code review de calidad, testing exploratorio y análisis de regresión. Se activa en la fase 4 (calidad) de /alfred feature, en /alfred fix (fase de validación), en /alfred ship (auditoría final) y en /alfred audit. También se puede invocar directamente para revisar código, generar test plans o ejecutar sesiones de testing exploratorio. <example> El senior-dev ha terminado la implementación de un módulo de pagos y el agente genera un test plan priorizado por riesgo, ejecuta code review sobre el código nuevo y documenta los hallazgos con severidad y sugerencia de corrección. <commentary> Se activa porque el código nuevo necesita validación de calidad antes de avanzar. Un módulo de pagos es crítico y requiere cobertura exhaustiva. </commentary> </example> <example> El usuario sospecha que un cambio reciente ha roto algo y el agente ejecuta un análisis de regresión: identifica los componentes afectados por el cambio, verifica que los tests existentes cubren esos escenarios y sugiere tests adicionales si hay huecos. <commentary> Se activa ante sospecha de regresión. La detección temprana de roturas evita que los defectos se acumulen y se propaguen a otras partes del sistema. </commentary> </example> <example> El agente realiza una sesión de testing exploratorio sobre el flujo de registro: prueba con datos válidos, inválidos, extremos, vacíos, con caracteres especiales y con secuencias de acciones inesperadas. Documenta cada hallazgo. <commentary> El testing exploratorio cubre los huecos que los tests automatizados no alcanzan. Los edge cases en flujos de usuario son donde se esconden los bugs más sutiles. </commentary> </example> <example> Si el plugin pr-review-toolkit está disponible, el agente delega la revisión de código en code-reviewer, silent-failure-hunter y code-simplifier, y consolida sus resultados en un informe único. <commentary> La delegación en herramientas especializadas acelera la revisión sin sacrificar profundidad. El qa-engineer aporta el contexto de negocio que las herramientas no tienen. </commentary> </example>

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.

Usar para evaluar si una dependencia merece la pena antes de añadirla. Activar cuando el usuario quiera añadir una librería, saber si merece la pena esta dependencia, evaluar un paquete antes de instalarlo, hacer npm install o pip install de algo nuevo, buscar alternativas a una librería o decidir si implementar algo internamente.

Usar para documentar decisiones arquitectónicas como ADR. Activar cuando el usuario quiera documentar por qué se tomó una decisión, registrar alternativas descartadas, crear un ADR, un decision record, dejar constancia de una elección técnica o justificar una decisión de diseño ante el equipo.

Usar para revisar código con foco en calidad, legibilidad y errores lógicos. También: revisar código, buscar errores, calidad del código, revisión de PR, pull request review.

22 hooks across 6 events