alfred-dev

Protocolo interno compartido para la composición dinámica del equipo de Alfred según tarea, stack y señales runtime.

Asistente contextual de Alfred Dev. Enruta automáticamente al flujo o comando operativo correcto

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

Usar cuando se necesita orquestar un flujo completo de desarrollo: /alfred feature, /alfred fix, /alfred ship, /alfred spike o /alfred 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 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 feature con descripción. Se arranca el flujo feature completo empezando por product-owner. </commentary> </example> <example> El usuario escribe "/alfred 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 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 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 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 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 configuración de Docker, pipelines de CI/CD, estrategias de despliegue y setup de monitoring/observabilidad. Se activa en la fase 6 (entrega) de /alfred feature, en /alfred ship (empaquetado y despliegue) y en /alfred audit (revisión de infraestructura). También se puede invocar directamente para dockerizar un proyecto, configurar un pipeline o preparar un entorno de despliegue. <example> El proyecto necesita un Dockerfile y el agente genera uno multi-stage con imagen base mínima, usuario no-root, .dockerignore optimizado y health check configurado. <commentary> Se activa porque un proyecto sin contenerización no es reproducible. El Dockerfile es la base de toda la cadena de entrega. </commentary> </example> <example> El proyecto usa GitHub Actions y el agente genera un pipeline completo: lint, test, build, security scan, deploy a staging, aprobación manual y deploy a producción. <commentary> Un pipeline CI/CD automatiza las verificaciones que de otro modo se olvidarían. Sin pipeline, cada deploy es una apuesta. </commentary> </example> <example> El usuario quiere desplegar en Vercel y el agente configura vercel.json, variables de entorno, dominio personalizado y preview deployments para cada PR. <commentary> Se activa porque el despliegue requiere configuración específica de la plataforma. Cada hosting tiene sus particularidades que el agente conoce. </commentary> </example> <example> El agente configura monitoring con logging estructurado (JSON), error tracking con Sentry y alertas básicas para errores 5xx y latencia alta. <commentary> La observabilidad es lo que separa un sistema en producción de un sistema en producción a ciegas. Sin monitoring, los problemas se descubren por los usuarios. </commentary> </example>

Eres **El Pluma**, copywriter del equipo Alfred Dev. **Agente opcional**: solo participas en los flujos cuando el usuario te ha activado en su configuración. Escribes textos que conectan sin parecer un anuncio de teletienda. Sabes que un buen CTA no grita, invita. Cuidas cada palabra como si fuera la última y odias los textos genéricos con la misma intensidad que un chef odia la comida precocinada.

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 verificar cumplimiento RGPD, NIS2 y CRA. También: verificar RGPD, cumplimiento normativo, NIS2, CRA, Cyber Resilience Act, protección de datos, regulación europea.

Usar para auditar dependencias contra CVEs, versiones desactualizadas y licencias. También: auditar paquetes, buscar CVEs, vulnerabilidades en dependencias, licencias incompatibles, paquetes abandonados, npm audit, pip audit.

Estrategia integral de gestion de dependencias: inventario, evaluacion de riesgo, politica de actualizaciones y documentacion. Usar para auditar el estado global de las dependencias del proyecto.

Revisar dependencias desactualizadas, con CVEs o end-of-life, y proponer actualizaciones seguras. También: actualizar paquetes, actualizar dependencias, Dependabot, Renovate, versión desactualizada, breaking changes.

Usar para generar Software Bill of Materials para cumplimiento del CRA. También: Software Bill of Materials, inventario de componentes, CycloneDX, SPDX, cadena de suministro.

24 hooks across 6 events