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

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

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

Corrección de bugs: diagnóstico, corrección TDD y validación

Muestra los comandos disponibles de Alfred Dev

Lista las tareas en curso del kanban de SonIA

Segunda opinión técnica externa vía Codex CLI — diagnóstico y prescripción por ítem

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

Resumen operativo del proyecto: progreso, kanban, bloqueos y trazabilidad

Cambio pequeño y acotado con menos ceremonia, pero con tests y seguridad

Retoma una sesión activa o un handoff pendiente

Busca texto en artefactos de SonIA y memoria SQLite del proyecto

Preparar entrega: auditoría final, documentación, empaquetado y despliegue

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

Standup operativo breve desde SonIA: en curso, bloqueos, progreso y siguiente paso

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

Ejecuta SonIA Sync: refleja el tablero local en GitHub Issues usando gh CLI

Comprueba y aplica actualizaciones del plugin Alfred Dev

Valida la integridad operativa de SonIA: kanban, trazabilidad, UAT y sync local

Prepara o registra la verificación manual/UAT del entregable actual

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>

Eres **El Conserje del Repo**, gestor de GitHub del equipo Alfred Dev. **Agente opcional**: solo participas en los flujos cuando el usuario te ha activado en su configuración. Mantienes el repositorio como una casa bien ordenada: cada issue etiquetado, cada PR con su descripción, cada release con sus notas. Sabes usar `gh` como extensión de tu propio brazo y guías al usuario paso a paso si no tiene las herramientas instaladas.

Usar para internacionalización y localización: auditoría de claves i18n, detección de cadenas hardcodeadas, validación de formatos por locale, generación de esqueletos para nuevos idiomas y revisión de calidad lingüística. Se activa cuando el proyecto maneja múltiples idiomas o necesita prepararse para ello. <example> El proyecto tiene ficheros de traducción en JSON para ES, EN y FR, pero al añadir pantallas nuevas se han quedado claves sin traducir en FR. El agente detecta las 12 claves huérfanas, genera el esqueleto para FR y señala las interpolaciones que difieren entre idiomas. <commentary> Trigger de calidad: el qa-engineer detecta textos sin traducir en una locale y activa a la i18n-specialist para auditar la cobertura. </commentary> </example> <example> Un desarrollador ha escrito "Guardar cambios" directamente en un componente React en lugar de usar la función t(). El agente escanea el código fuente, detecta 8 cadenas hardcodeadas en 3 ficheros y genera las claves i18n correspondientes con su ubicación exacta. <commentary> Trigger de detección: durante la fase de calidad, se buscan cadenas que deberían estar externalizadas para garantizar la traducibilidad. </commentary> </example> <example> El proyecto necesita añadir soporte para japonés. El agente genera el fichero de traducción completo con todas las claves del idioma base, marca las que necesitan revisión de longitud (textos que pueden romper layouts en CJK) y valida que los formatos de fecha y moneda usen las convenciones de ja-JP. <commentary> Trigger directo: el usuario quiere añadir un idioma nuevo. El agente genera el esqueleto completo y señala los puntos de atención específicos del locale. </commentary> </example>

Usar para consultar y gestionar la memoria persistente del proyecto: decisiones, iteraciones, commits, cronología, relaciones entre decisiones, validación de integridad, y exportación/importación de datos. Se activa cuando el usuario pregunta por histórico, cuando Alfred necesita contexto de sesiones anteriores, al inicio de flujos feature/fix para contextualizar con decisiones previas relacionadas, o cuando se requiere mantenimiento de la base de memoria (actualizar estados, vincular decisiones, auditar integridad, exportar a ADR o importar desde Git/ADR). <example> El usuario pregunta "por qué decidimos usar SQLite en vez de PostgreSQL". El agente busca en la memoria, localiza la decisión con su ID, fecha e iteración, y devuelve la justificación exacta con las alternativas que se descartaron. <commentary> Trigger de consulta histórica: el usuario quiere recuperar el razonamiento detrás de una decisión pasada. El agente consulta la DB y responde con evidencia verificable. </commentary> </example> <example> Alfred inicia un flujo /alfred feature y necesita saber si ya hubo intentos previos de implementar algo similar. El agente busca por palabras clave, devuelve las iteraciones relacionadas con su estado y las decisiones que se tomaron en cada una. <commentary> Trigger de contextualización: antes de empezar trabajo nuevo, se consulta la memoria para no repetir errores ni reinventar decisiones ya tomadas. </commentary> </example> <example> El equipo quiere un resumen de actividad del último mes: cuántas iteraciones, cuántas decisiones, qué fases se completaron. El agente consulta las estadísticas y la cronología para generar un informe compacto con datos verificables. <commentary> Trigger estadístico: el usuario necesita una visión general del progreso del proyecto. El agente recopila métricas de la memoria y las presenta con contexto. </commentary> </example>

Usar para obtener una segunda opinión técnica externa sobre el código del proyecto. Lucius invoca el Codex CLI de OpenAI y entrega un informe estructurado con diagnóstico y prescripción por ítem. Solo activo cuando el usuario tiene Codex CLI instalado y una suscripción activa de OpenAI. Recomendado tras terminar una feature o antes de hacer ship. <example> El usuario ha terminado de implementar un módulo de autenticación con Alfred y quiere una segunda opinión antes de hacer ship. Invoca `/alfred-dev:lucius` y Lucius audita el directorio, detecta que los tokens no tienen expiración explícita, y prescribe añadir `expiresAt` al modelo de sesión. <commentary> Trigger de auditoría post-feature: el desarrollador quiere validación externa antes de considerar el trabajo cerrado. Lucius aporta perspectiva de un modelo distinto sin modificar ningún fichero. </commentary> </example> <example> El usuario invoca `/alfred-dev:lucius src/api/ --scope security` para auditar solo la capa de API con foco en seguridad. Lucius ejecuta Codex CLI restringido al subdirectorio y devuelve un informe centrado en OWASP Top 10. <commentary> Trigger de auditoría acotada: el usuario controla el alcance y el coste de la operación. Lucius respeta el scope y no sale de los límites indicados. </commentary> </example>

Eres **El Cronómetro**, ingeniero de rendimiento del equipo Alfred Dev. **Agente opcional**: solo participas en los flujos cuando el usuario te ha activado en su configuración. Mides todo en milisegundos y te duelen los kilobytes innecesarios. Sabes que un segundo de más en la carga es un usuario de menos. Tu herramienta favorita es el profiler y tu enemigo mortal, el bundle sin tree-shaking.

Eres **El Rastreador**, especialista SEO del equipo Alfred Dev. **Agente opcional**: solo participas en los flujos cuando el usuario te ha activado en su configuración. Piensas como un motor de búsqueda y hablas como un humano. Sabes que de nada sirve una web perfecta si nadie la encuentra. Obsesionado con los meta tags, los datos estructurados y las Core Web Vitals. No descansas hasta que Lighthouse da verde en todo.

Eres **El Abogado del Usuario**, revisor de UX del equipo Alfred Dev. **Agente opcional**: solo participas en los flujos cuando el usuario te ha activado en su configuración. Defiendes al usuario final como si fuera tu cliente en un juicio. Ves barreras de accesibilidad donde otros ven botones bonitos y detectas flujos confusos a kilómetros. Tu principio fundamental: si el usuario necesita un manual, el diseño ha fallado.

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 gestión de proyecto transversal: descomposición de PRDs en tareas, seguimiento con kanban en ficheros Markdown, trazabilidad de criterios de aceptación, verificación de completitud y detección de desvíos de alcance. Se activa después de la fase 1 (producto) para crear el kanban y al final de cada fase para actualizar el estado. También se activa en /alfred audit para evaluar la salud del proyecto. Se puede invocar directamente para consultar el estado de las tareas o la trazabilidad de cualquier criterio de aceptación. <example> El product-owner ha generado un PRD con 5 historias de usuario y 12 criterios de aceptación. SonIA descompone las historias en 8 tareas concretas, crea el kanban en docs/project/kanban/ y la matriz de trazabilidad inicial. <commentary> Trigger de fase 1 completada: el PRD está aprobado y SonIA crea la estructura de seguimiento antes de que empiece la fase de arquitectura. </commentary> </example> <example> Al terminar la fase 3 (desarrollo), SonIA revisa qué tareas ha completado el senior-dev, actualiza el kanban moviendo tareas a done.md con evidencia (tests, commits) y detecta que un criterio de aceptación no tiene tarea asociada. <commentary> Trigger de fin de fase: SonIA actualiza el estado y señala huecos de trazabilidad antes de que el flujo avance. Los huecos no bloquean las fases intermedias, pero sí bloquean el cierre de la iteración. </commentary> </example> <example> El senior-dev ha implementado un endpoint que no estaba en el PRD. SonIA lo detecta al comparar las tareas del kanban con los cambios reales y lo señala como desvío de alcance para que el usuario decida si es una ampliación legítima o scope creep. <commentary> Trigger de desvío: SonIA compara lo planificado con lo ejecutado. No bloquea, pero avisa. El usuario decide si el desvío se acepta o se revierte. </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 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>

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 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 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 ship (documentación de release) y en /alfred 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 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>

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.

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.

Analizar resultados de Lighthouse y proponer mejoras priorizadas. Activar ante: rendimiento web, Core Web Vitals, LCP, CLS, FID, puntuacion Lighthouse, velocidad de carga

Auditar y corregir meta tags para SEO y redes sociales. Activar ante: SEO basico, meta description, Open Graph, Twitter Cards, titulo de pagina, etiquetas meta

Generar datos estructurados JSON-LD validados contra schema.org. Activar ante: JSON-LD, schema.org, rich snippets, datos estructurados, marcado semantico

Auditar accesibilidad WCAG 2.1 nivel AA con checklist y correcciones. Activar ante: accesibilidad web, WCAG, lector de pantalla, contraste, navegacion por teclado, a11y

Analizar flujos de usuario: pasos, abandono, simplificación. Activar ante: flujo de usuario, pasos innecesarios, simplificar proceso, experiencia de usuario, conversion, abandono

Evaluar interfaces con las 10 heurísticas de Nielsen. Activar ante: heuristicas de Nielsen, evaluacion de usabilidad, problemas de UX, interfaz confusa, consistencia de la interfaz

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.

Configurar y escribir tests end-to-end con Playwright o Cypress. También: validar flujos de usuario completos, testing de integración en navegador, tests E2E en CI, tests de aceptación, smoke tests en producción.

Usar para testing exploratorio con sesiones documentadas. También: probar sin script, buscar bugs, testing manual, edge cases, sesión de testing.

Protocolo de respuesta ante incidentes en produccion: triaje, mitigacion, causa raiz y postmortem. Usar ante caidas, errores criticos, incidentes de seguridad o degradacion de servicio.

Usar para verificar que cambios nuevos no rompen funcionalidad existente. También: algo se ha roto, cambio rompe funcionalidad, verificar que no hay regresión, tests de regresión.

Levantar SonarQube con Docker, analizar el código y proponer mejoras. También: análisis estático, deuda técnica, code smells, cobertura, calidad automatizada.

Verificar ortografía en castellano: tildes, concordancia y erratas en código y documentación. También: ortografía, tildes, erratas, castellano, acentos.

Usar para generar un plan de testing priorizado por riesgo. También: plan de testing, qué probar, priorizar tests por riesgo, estrategia de testing, cobertura de tests.

Planificar migraciones de base de datos con rollback y estimación de impacto. Activar cuando el usuario quiera migrar base de datos, cambiar esquema, ejecutar ALTER TABLE, planificar un rollback o realizar una migracion segura.

Optimizar queries lentas con EXPLAIN, índices y reescritura. Activar cuando el usuario tenga una query lenta, quiera optimizar SQL, usar EXPLAIN, crear indices, resolver problemas N+1 o mejorar el rendimiento de consultas.

Diseñar esquemas de base de datos normalizados con índices y documentación. Activar cuando el usuario quiera diseñar base de datos, crear tablas, definir relaciones, aplicar normalizacion, configurar indices, crear un modelo de datos o generar un ERD.

Usar al recibir feedback de code review para responder técnicamente. Activar cuando el usuario quiera responder a comentarios de PR, gestionar feedback de code review, resolver comentarios de un revisor, o cuando el revisor pide cambios en el código.

Usar antes de modificar código existente para entender el contexto. Activar cuando el usuario quiera entender el código, saber cómo funciona esto, explorar un repositorio, prepararse antes de modificar, analizar la estructura del proyecto o familiarizarse con una base de código nueva.

Usar para refactorizar código con tests como red de seguridad. Activar cuando el usuario quiera limpiar código, reducir complejidad, extraer función, mejorar nombres, eliminar duplicación, resolver un code smell o reorganizar la estructura interna sin cambiar comportamiento.

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.

Planificar y ejecutar releases: inventario de cambios, versionado semantico, changelog, notas de release y publicacion. Usar antes de cada version nueva.

Usar para documentar API con endpoints, parámetros y ejemplos. Activar ante: documentar API, endpoints, OpenAPI, Swagger, parametros, respuestas de la API

Usar para documentar la arquitectura del sistema. Activar ante: documentar arquitectura, diagrama del sistema, como funciona el proyecto, vision general tecnica

Usar para generar entradas de changelog siguiendo Keep a Changelog. Activar ante: generar changelog, documentar cambios, Keep a Changelog, notas de version, que ha cambiado

Crear y mantener un glosario de términos del proyecto para evitar ambigüedades. Activar ante: glosario, definir terminos, vocabulario del proyecto, que significa

Generar guías de migración entre versiones para los usuarios del proyecto. Activar ante: guia de migracion, actualizar version, breaking changes, instrucciones de actualizacion

Generar una guía de onboarding para nuevos desarrolladores del proyecto. Activar ante: guia para nuevos, como empezar, setup del proyecto, incorporacion al equipo

Documentar el proyecto completo en docs/ para dar contexto absoluto a cualquier desarrollador. Activar ante: documentacion del proyecto, crear docs, organizar documentacion, estructura de docs

Auditar y mejorar el README del proyecto: estructura, completitud y claridad. Activar ante: mejorar README, auditar README, primera impresion del proyecto, readme incompleto

Usar para escribir guías de usuario o desarrollador. Activar ante: guia de usuario, como usar, manual de uso, tutorial, instrucciones para el usuario

Abrir y operar el companion visual de Selina para elegir una direccion de estilo en proyectos con interfaz. Skill manual: levanta un servidor local y escribe artefactos visuales.

Generar templates de issues para bug reports y feature requests

Crear pull requests completas con descripcion, labels y reviewers

Crear releases con versionado semantico, notas y artefactos

Configurar un repositorio GitHub con branch protection, templates y labels

Revisar textos publicos: claridad, tono, ortografia y CTAs. Activar ante: revisar textos, mejorar copy, tono de comunicacion, textos de la web, landing page copy

Redactar CTAs efectivos orientados a accion. Activar ante: escribir botones, call to action, texto de boton, conversion, microcopy

Crear una guia de tono para coherencia en la comunicacion del producto. Activar ante: voz de marca, guia de estilo de escritura, coherencia en comunicacion, copywriting, identidad verbal

Generar criterios de aceptación en formato Given/When/Then. Activar cuando el usuario quiera definir criterios de aceptacion, usar formato Given When Then, escribir en Gherkin, saber como determinar que algo esta terminado o establecer una definicion de hecho.

Investigar cómo resuelven el mismo problema otras herramientas. Activar cuando el usuario quiera hacer un analisis competitivo, saber que hace la competencia, evaluar alternativas existentes o realizar benchmarking de mercado.

Descomponer una feature en historias de usuario verificables. Activar cuando el usuario quiera crear historias de usuario, usar el formato como usuario quiero, descomponer una feature o definir requisitos funcionales.

Generar un PRD completo con problema, solución, historias de usuario y criterios de aceptación. Activar cuando el usuario quiera definir requisitos de producto, decidir que construir, crear un documento de requisitos, redactar un PRD o elaborar una especificacion funcional.

Crear y ejecutar benchmarks para medir impacto de cambios. Activar cuando el usuario quiera medir rendimiento, comparar antes y despues, evaluar velocidad, throughput o ejecutar un benchmark de codigo.

Analizar y reducir el tamaño de bundles frontend. Activar cuando el bundle sea grande, se quiera reducir tamaño, aplicar tree shaking, configurar lazy loading, usar webpack analyzer o analizar el peso de la aplicacion.

Perfilar aplicaciones para encontrar cuellos de botella de CPU y memoria. Activar cuando la aplicacion este lenta, haya un cuello de botella, problemas de latencia, se necesite un flamegraph, se detecte alto uso de CPU, un memory leak o se quiera analizar el rendimiento.

24 hooks across 6 events