v0.5.2 Plugin independiente para Claude Code
GitHub English
Claude Code, pero con equipo
PLUGIN PARA CLAUDE CODE

UN SISTEMA DE TRABAJO PARA CLAUDE CODE

19 agentes reales, 26 comandos, 61 skills publicadas, memoria SQLite por proyecto y PM operativo. Alfred convierte Claude Code en un flujo con continuidad, contexto y gates de calidad.

19 agentes 26 comandos SQLite + PM
Instaladores por sistema Cada botón abre un popup con el comando listo para copiar.

CHANGELOG

Última release v0.5.2
11/04/2026
Añadido
  • Catálogo completo de skills publicado: plugin.json deja de enumerar una muestra parcial y pasa a exponer los 14 dominios completos de skills/.
  • Contratos de superficie pública más estrictos: la suite valida catálogo publicado, frontmatters canónicos, skills manuales y ausencia de colisiones con comandos.
  • Selina con flujo guiado real: primero sistema base, luego tipografía y paleta, y solo después tres propuestas finales comparables dentro de esa misma familia.
Cambiado
  • Los skills más pesados o con side effects claros quedan publicados, pero forzados a activación manual con disable-model-invocation: true.
  • La ayuda y la documentación pública agrupan ahora los comandos por valor real: core, operativos avanzados y vistas/aliases.
  • Las propuestas finales de Selina ya respetan el sistema visual elegido y dejan de recolorear la misma maqueta genérica.
Corregido
  • style-direction ya declara un frontmatter canónico y no depende de inferencias implícitas.
  • La superficie pública de skills deja de depender de listas parciales desalineadas con el repositorio real.
  • El companion visual de Selina registra la elección humana incluso cuando el WebSocket local no completa el handshake y necesita fallback HTTP.
Un plugin de CLAUDE CODE para trabajar con método
19 agentes26 comandosmemoria localquality gates

que convierten una sesión aislada en un proceso gobernado.

Lo que hace Alfred
01

Decide el siguiente paso

Lee el repo, la sesión y el estado de SonIA para arrancar por map-codebase, discuss, feature o verify sin montar el flujo a mano.

02

Expone el estado operativo

Kanban, bloqueos, handoff, UAT, memoria y siguiente acción quedan visibles desde CLI con progress, standup, blocked, validate y search.

03

Entrega con evidencia

El flujo obliga a pasar por diseño técnico, TDD, seguridad, QA, documentación y release antes de cerrar una fase.

Equipo 19 agentes reales

Publicados en plugin.json. Núcleo y opcionales, con nombres y función real del plugin.
10 Core

Núcleo operativo

Orquestación, alcance, arquitectura, implementación, seguridad, QA, release, trazabilidad y sistema de diseño.

09 Opcionales

Especialistas activables

Se activan según stack, tarea o configuración: datos, UX, rendimiento, GitHub, SEO, i18n, copy, memoria y auditoría externa.

Comandos 26

Los 26 comandos públicos del plugin, agrupados por entrada, orientación, construcción, control y operación.
03

Entrada

Arranque y ayuda

Cargar Alfred, fijar configuración y entender la superficie pública del plugin.

07

Orientación

Contexto y continuidad

Leer el estado real del repo y decidir el siguiente paso sin reabrir todo el contexto.

06

Construcción

Entrega y auditoría

Abrir entrega real: features, cambios rápidos, fixes, exploración técnica, ship y auditoría.

05

Control

Verificación y bloqueos

Verificar UAT, detectar bloqueos y revisar la salud operativa antes de seguir o cerrar.

05

Operación

Memoria y mantenimiento

Buscar en memoria, abrir la UI local, sincronizar GitHub, actualizar y pedir una segunda opinión.

Skills y playbooks

61 publicadas / 14 dominios
61 skills publicadas 14 dominios cubiertos

El catálogo publicado encapsula decisiones repetibles para incidentes, releases, dependencias, estilo, QA, seguridad y entrega.

Ejemplos destacados

Incident ResponseSonarqubeRelease PlanningDependency StrategyStyle Direction
Procedimientos reutilizables y versionados dentro del plugin, no prompts ad hoc.
Producto 4 skills
Acceptance Criteria · Competitive Analysis · User Stories · Write Prd
Arquitectura 4 skills
Choose Stack · Design System · Evaluate Dependencies · Write ADR
Desarrollo 4 skills
Code Review Response · Explore Codebase · Refactor · Tdd Cycle
Calidad 8 skills
Code Review · E2e Testing · Exploratory Testing · Incident Response · Regression Check · Sonarqube · Spelling Check · Test Plan
Seguridad 7 skills
Compliance Check · Dependency Audit · Dependency Strategy · Dependency Update · Sbom Generate · Security Review · Threat Model
Datos 3 skills
Migration Plan · Query Optimization · Schema Design

Capas auxiliares

6 activas

Cómo empezar 03 pasos

Empieza en 3 pasos

entry flow
01

Instala Alfred Dev

Usa el instalador de tu sistema; registra el plugin y deja el runtime listo para trabajar.

02

Configura stack y equipo

Ejecuta /alfred-dev:config para fijar stack, memoria, autonomía y opcionales.

03

Entra por el comando correcto

Nuevo repo: /alfred-dev:alfred. Repo existente: /alfred-dev:map-codebase y /alfred-dev:discuss.

Brownfield primero: /map-codebase y /discuss. Greenfield: /alfred-dev:alfred.

Instalar, actualizar y desinstalar

CLI-FIRST
Instalación en macOS Copiar
curl -fsSL https://raw.githubusercontent.com/686f6c61/alfred-dev/main/install.sh | bash

El comando registra la fuente GitHub global en Claude Code y deja Alfred Dev listo para instalar o actualizar.

Actualizar /alfred-dev:update Lee release notes y decide desde Claude Code.

FAQ

¿Funciona en Windows?

Sí. Alfred Dev tiene un instalador nativo en PowerShell para Windows 10/11. También puedes usar el instalador bash a través de WSL (Windows Subsystem for Linux) o Git Bash. La única dependencia en Windows es git; no necesita python3.

¿Qué dependencias necesita?

En macOS y Linux: git y python3. Ambas suelen estar preinstaladas o son fáciles de instalar con el gestor de paquetes del sistema.

En Windows: solo git. PowerShell maneja el JSON de forma nativa, así que python3 no es necesario. PowerShell 5.1+ viene preinstalado en Windows 10/11.

¿Cómo actualizo el plugin?

Ejecuta /alfred-dev:update dentro de Claude Code. El comando consulta GitHub, compara versiones y te muestra las notas de la release si hay versión nueva. También puedes volver a ejecutar el instalador: sobreescribe la versión anterior sin conflictos.

¿Qué hace Alfred en un repo ya existente?

Si el proyecto ya tiene código pero todavía no tiene mapa persistente, Alfred prioriza /alfred-dev:map-codebase. Analiza la estructura, detecta stack, entrypoints, riesgos y convenciones, y deja el contexto en docs/project/codebase-map.md y docs/project/current.md antes de abrir feature, fix, spike o audit.

¿Cuándo uso quick y cuándo feature?

/alfred-dev:quick es para cambios pequeños, locales y acotados: dos fases ligeras, tests de la zona tocada y revisión rápida de seguridad. /alfred-dev:feature es para funcionalidad nueva o cambios que cruzan varios dominios, necesitan PRD, decisiones de arquitectura o un ciclo completo de producto a entrega.

¿Puedo pausar y retomar una sesión?

Sí. /alfred-dev:pause guarda el estado actual en .claude/alfred-handoff.json y docs/project/handoff.md. Después puedes volver con /alfred-dev:resume o pedir simplemente /alfred-dev:next. Alfred recupera el flujo, la fase actual, la gate pendiente y el siguiente paso concreto.

¿Qué es verify y por qué existe si ya hay tests?

/alfred-dev:verify cierra la validación humana del entregable. Los tests automáticos dicen si el sistema funciona técnicamente; verify registra si cumple la expectativa del usuario en UAT. El estado queda trazado como pendiente, aprobado o rechazado en .claude/alfred-uat.json y docs/project/uat.md.

¿Qué muestra progress?

/alfred-dev:progress hace visible el estado operativo del proyecto: flujo activo o handoff, progreso general, kanban, bloqueos, trazabilidad y estado de UAT. No abre trabajo nuevo ni fuerza una gate; sirve para decidir qué toca ahora con contexto real.

¿GitHub pasa a ser la fuente de verdad del proyecto?

No. /alfred-dev:sync-github ejecuta SonIA Sync como espejo colaborativo para issues. La fuente de verdad sigue siendo local: docs/project/, .claude/ y la memoria SQLite del proyecto.

¿Qué es Memory UI y cuándo debería usarla?

/alfred-dev:memory-ui abre una vista local en navegador sobre la SQLite real del proyecto. Úsala cuando quieras entender rápido qué ha pasado, qué decisiones hay registradas, qué commits se han capturado, cómo va la continuidad o si la memoria está sana, sin leer la base de datos a mano.

¿Tengo que configurar Alfred a mano la primera vez?

No necesariamente. En la primera sesión Alfred puede bootstrappear .claude/alfred-dev.local.md con una configuración base usable para CLI. Después puedes afinar autonomía, agentes opcionales, memoria o personalidad con /alfred-dev:config.

¿Qué es la memoria persistente?

Es una base de datos SQLite local que almacena las decisiones, commits e iteraciones de cada proyecto. Se activa opcionalmente desde /alfred-dev:config. Una vez activa, Alfred registra automáticamente los eventos del flujo de trabajo y el agente El Bibliotecario puede responder consultas históricas como "por qué se eligió esta arquitectura" o "qué se hizo en la última iteración", citando siempre las fuentes. Los datos no salen del proyecto: todo queda en .claude/alfred-memory.db.

Si ya usas Claude Code, instala Alfred Dev y entra al flujo con contexto, memoria y equipo completo.

Plugin independiente para equipos que quieren pasar de prompt aislado a flujo operativo con estado, trazabilidad y gates.

Instalación 
 
El comando se copia automáticamente cuando el navegador lo permite. Si no, usa el botón Copiar.
 
   
 
 Desinstalar Alfred Dev  
 
 
 
Dos caminos claros
 
Si solo quieres quitar Alfred Dev de Claude Code, usa el script de tu sistema. Si la instalación quedó a medias o quieres revisar cada rastro, usa la ruta manual.
 
 
 
 
 
macOS / Linux
  
 
curl -fsSL https://raw.githubusercontent.com/686f6c61/alfred-dev/main/uninstall.sh | bash
 
Primero intenta la desinstalación nativa con Claude CLI y luego limpia caché, marketplace y registros residuales.
 
 
 
 
Windows
  
 
irm https://raw.githubusercontent.com/686f6c61/alfred-dev/main/uninstall.ps1 | iex
 
Hace la misma limpieza completa en Windows: plugin, marketplace, caché y JSON internos si siguen teniendo rastro.
 
 
 
 
 
Manual
 
 
 
 1. Intenta la vía nativa de Claude Code 
 claude plugin uninstall alfred-dev@alfred-dev  
 claude plugin marketplace remove alfred-dev  
 
 
 2. Si quedan restos, revisa estas rutas 
     
  • ~/.claude/plugins/cache/alfred-dev/
  • ~/.claude/plugins/marketplaces/alfred-dev/
  • ~/.claude/plugins/known_marketplaces.json
  • ~/.claude/plugins/installed_plugins.json
  • ~/.claude/settings.json
    •  
 
 
 3. Esto no se borra automáticamente 
     
  • .claude/alfred-dev.local.md
  • .claude/alfred-dev-state.json
    •  
 
Si quieres limpieza total de un proyecto concreto, elimina esos ficheros a mano dentro de cada repo donde hayas usado Alfred Dev.
 
 
 
 
Después de desinstalar, reinicia Claude Code para que el cambio se aplique de verdad.
 
 
   
 
 Changelog completo  
 
 
 
 
v0.5.2
 11/04/2026 
 
 Añadido 
     
  • Catálogo completo de skills publicado: plugin.json deja de enumerar una muestra parcial y pasa a exponer los 14 dominios completos de skills/.
  • Contratos de superficie pública más estrictos: la suite valida catálogo publicado, frontmatters canónicos, skills manuales y ausencia de colisiones con comandos.
  • Selina con flujo guiado real: primero sistema base, luego tipografía y paleta, y solo después tres propuestas finales comparables dentro de esa misma familia.
    •  
 
 
 Cambiado 
     
  • Los skills más pesados o con side effects claros quedan publicados, pero forzados a activación manual con disable-model-invocation: true.
  • La ayuda y la documentación pública agrupan ahora los comandos por valor real: core, operativos avanzados y vistas/aliases.
  • Las propuestas finales de Selina ya respetan el sistema visual elegido y dejan de recolorear la misma maqueta genérica.
  • La landing deja de presentar el catálogo como una muestra interna/parcial y refleja ya las 61 skills publicadas de la release.
  • Versionado coherente a 0.5.2 en plugin, marketplace, instaladores, paquetes, docs, changelog y landing.
    •  
 
 
 Corregido 
     
  • style-direction ya declara un frontmatter canónico y no depende de inferencias implícitas.
  • La superficie pública de skills deja de depender de listas parciales desalineadas con el repositorio real.
  • El companion visual de Selina registra la elección humana incluso cuando el WebSocket local no completa el handshake y necesita fallback HTTP.
    •  
 
 
 
 
v0.5.1
 10/04/2026 
 
 Añadido 
     
  • Catálogo canónico de Selina con 10 sistemas de diseño base: core/selina_style_catalog.py reúne el modo libre/contextual y nueve familias visuales guiadas por tendencia para que la fase visual parta de un vocabulario explícito.
  • Galería de demos visuales: core/selina_style_demo.py y visual/scripts/write-style-demo-gallery.py generan una muestra navegable del catálogo antes de cerrar las tres propuestas finales.
  • Paletas y tipografías por familia: cada sistema de diseño declara modos cromáticos, pairing tipográfico y enlaces a referencias o Google Fonts.
    •  
 
 
 Cambiado 
     
  • Selina deja de presentarse como “tres estilos” aislados: ahora trabaja con 10 sistemas de diseño base y los reduce a tres propuestas comparables según PRD, audiencia y stack.
  • Versionado coherente a 0.5.1: plugin, marketplace, instaladores, paquetes, memoria MCP, session report, README, changelog, docs y landing quedan alineados.
  • La landing explica mejor cómo entra Selina en el flujo y qué significa realmente cerrar un sistema de diseño antes de tocar frontend.
    •  
 
 
 Corregido 
     
  • Superficie de actualización sin drift: los puntos internos que todavía caían por defecto a una release anterior pasan a reflejar la release actual.
  • Tests de release menos frágiles: la suite deja de depender de wrappers finos de Astro o rutas hardcodeadas por versión cuando la fuente de verdad es el manifiesto.
    •  
 
 
 
 
v0.5.0
 31/03/2026 
 
 Añadido 
     
  • Lucius — El Director Técnico: nuevo agente opcional que actúa como segunda opinión técnica externa. Invoca codex review con GPT-5.4 en modo de solo lectura y entrega diagnóstico + prescripción por ítem.
  • Comando /alfred-dev:lucius: punto de entrada para invocar la auditoría. Acepta directorio objetivo y scope opcionales (all, security, tests, architecture, performance).
  • Informe estructurado por ítem: Lucius devuelve diagnóstico + prescripción + esfuerzo (S/M/L) + sugerencia de con quién implementar (Alfred o Codex) en cuatro secciones: Crítico, Relevante, Oportunidades y Lo que está bien.
  • Preflight de prerequisitos: verifica que codex está en el PATH y autenticado. Si falta algún requisito, para con instrucciones claras de instalación.
  • HARD-GATE sin modificaciones: el subcomando codex review activa sandbox: read-only y approval: never de forma nativa, garantizando que ningún fichero se toca.
  • Selina — La Estilista: nuevo agente de núcleo (10.º) que ocupa la fase 1b del flujo feature y presenta tres direcciones de estilo visual antes de diseñar componentes.
  • Servidor visual local: servidor HTTP + WebSocket de dependencias cero en visual/scripts/server.cjs con hot-reload, sesiones por proyecto y cierre limpio.
  • Skill de estilo visual: skills/estilo/style-direction/SKILL.md guía a Selina para arrancar el servidor, proponer opciones, recoger la elección y generar docs/style-direction.md.
  • Fase condicional estilo_visual: el orquestador la activa sólo cuando config_loader.has_frontend(stack) detecta interfaz de usuario.
  • Helper _advance_skipping_phases: función extraída del orquestador para gestionar saltos de fase cuando una condición no se cumple y reducir complejidad cognitiva.
    •  
 
 
 Cambiado 
     
  • 19 agentes totales: el plugin pasa de 18 a 19 agentes (10 de núcleo + 9 opcionales) con la incorporación de Lucius.
  • 26 comandos: /alfred-dev:lucius entra en el manifiesto y en la superficie pública del plugin.
  • Versionado coherente a 0.5.0: plugin, marketplace, instaladores, paquetes, README, changelog, docs y landing quedan alineados.
  • Landing actualizada: tarjeta de Lucius antes de Selina con badge «Nuevo», agente opcional con casos de uso y contadores ajustados a 19 agentes y 26 comandos.
    •  
 
 
 Corregido 
     
  • Imports de módulos nativos en server.cjs: prefijo node: obligatorio (node:http, node:crypto, node:fs, node:path).
  • Number.parseInt en lugar de parseInt en server.cjs (regla de linting SonarQube).
  • Complejidad cognitiva de handleRequest reducida: el bloque /files/* se extrae a serveStaticFile().
  • Bloque catch sin variable no usada: catch (e) pasa a catch {} en serveStaticFile.
  • Complejidad cognitiva en config_loader.py: _count_source_files y suggest_optional_agents bajan extrayendo helpers reutilizables.
  • Skill de SonarQube registrado en plugin.json: el fichero existía pero no estaba en el manifiesto del plugin.
  • Permisos de Docker en subagentes: entradas Bash(docker ...) en ~/.claude/settings.json permiten que security-officer arranque SonarQube sin pedir confirmación al usuario.
    •  
 
 
 
 
v0.4.7
 31/03/2026 
  
 Cambiado 
     
  • La generación JSON del hook pasa de interpolación en heredoc bash a emisión directa por stdin con json.dumps, eliminando la clase de error por completo.
  • Versionado coherente a 0.4.7: plugin, marketplace, instaladores, paquetes, metadata estructurada, README, changelog, docs y landing quedan alineados.
    •  
 
 
 Corregido 
     
  • Hook SessionStart corregido: la emisión JSON del contexto de sesión ya no se trunca cuando el contenido supera ARG_MAX del kernel o contiene caracteres especiales.
    •  
 
 
 
 
v0.4.6
 23/03/2026 
 
 Añadido 
     
  • Nueva Memory UI local: /alfred-dev:memory-ui abre overview, timeline, decisiones, commits, búsqueda y health directamente sobre la SQLite del proyecto.
  • La Memory UI ya nace con datos útiles: map-codebase, discuss y quick siembran progreso, trazabilidad, kanban e iteraciones ligeras de forma natural.
  • La UI importa commits Git recientes cuando la memoria aún no tenía commits enlazados y muestra mejor los estados vacíos en workspaces temporales o sin repo.
  • Cobertura E2E ampliada para Memory UI, siembra helper-first y renderizado visual del servidor local.
    •  
 
 
 Cambiado 
     
  • Alfred pasa a reflejar 25 comandos visibles y añade memory-ui como superficie pública de primer nivel en web, README, help y session-start.
  • La release limpia docs internas de planificación y alinea homepage, metadata y documentación operativa para 0.4.6.
    •  
 
  
 
 
v0.4.5
 22/03/2026 
 
 Añadido 
     
  • Nueva capa PM para SonIA: /alfred-dev:standup, /alfred-dev:blocked, /alfred-dev:in-progress, /alfred-dev:validate y /alfred-dev:search.
  • SonIA Sync para GitHub mediante /alfred-dev:sync-github, manteniendo docs/project y SQLite como fuente de verdad.
  • Cobertura E2E ampliada para helpers PM, parsing del tablero y sincronización de Issues.
    •  
 
 
 Cambiado 
     
  • Alfred expone ahora 24 comandos y 13 hooks visibles: continuidad, PM operativo, memoria persistente y flujos multiagente en una sola interfaz.
  • La web, el README y la documentación se alinean con SonIA operativa en CLI y con la nueva capa de colaboración en GitHub.
    •  
 
  
 
 
v0.4.4
 22/03/2026 
 
 Añadido 
     
  • Capa operativa de continuidad: nuevos comandos /alfred-dev:map-codebase, /alfred-dev:next, /alfred-dev:pause, /alfred-dev:resume, /alfred-dev:verify y /alfred-dev:progress.
  • Comando /alfred-dev:discuss para refinar ideas antes de construir, con artefactos discovery.md y current.md.
  • Nuevo flujo /alfred-dev:quick de 2 fases para cambios pequeños con tests y revisión de seguridad.
  • Parser compartido de configuración de memoria y nueva cobertura para FTS de eventos, purge + health, import Git con "|" y sync más allá de 1000 decisiones.
    •  
 
 
 Cambiado 
     
  • /alfred-dev:alfred pasa a ser un router contextual: decide si toca continuidad, brownfield, refinado o flujo multiagente.
  • SessionStart bootstrappea la configuración local y recomienda el siguiente paso desde la primera sesión.
  • La web se alinea con el modelo actual: 6 flujos de ejecución, 18 comandos y capa operativa visible.
  • La memoria persistente deja de dar falsos errores: los eventos con content son buscables, la purga limpia FTS, retention_days se lee desde la config del proyecto y size_bytes incluye WAL.
    •  
 
  
 
 
v0.4.2
 14/03/2026 
 
 Añadido 
     
  • Soporte para go test en evidence guard: la salida de go test se detecta correctamente como exito.
  • Informe de sesiones parciales: el stop-hook genera informe cuando una sesion se interrumpe, no solo cuando se completa.
  • Modo autopilot e iteraciones en informes: los informes muestran si la sesion fue autopilot y cuantos reintentos tuvo cada fase.
  • Verificacion de evidencia en markdown: instruccion explicita para que se lea alfred-evidence.json antes de avanzar gates automaticas.
  • Loop iterativo documentado en los comandos feature, fix y ship (max 5 reintentos por fase).
    •  
 
 
 Cambiado 
     
  • Stop-hook refactorizado en funciones testables: should_block, build_block_message, handle_session_report.
  • Mensaje de bloqueo adaptado a autopilot: no pide confirmacion del usuario sino que indica investigar el error.
  • Version dinamica en informes: el template lee la version de plugin.json.
  • Limpieza de evidencia entre sesiones para evitar contaminacion cruzada.
    •  
 
 
 Corregido 
     
  • Falso positivo en evidence guard: el patron de deteccion de fallos detectaba "0 failures" como fallo. Corregido para excluir el cero.
  • Gate de arquitectura mal tipada: la fase de arquitectura tenia gate "usuario" en lugar de "usuario+seguridad", haciendo inoperante la validacion de seguridad.
  • Patrones divergentes: quality-gate.py tenia patrones propios que divergian de evidence_guard_lib.py. Unificado para usar una sola fuente de verdad.
  • Clave de autopilot inconsistente: los comandos buscaban "modo: autopilot" pero el codigo escribia "autopilot: true". Corregido.
    •  
 
 
 
 
v0.4.1
 13/03/2026 
 
 Añadido 
     
  • Configuracion inicial automatica: al usar Alfred por primera vez en un proyecto, pregunta si se quiere modo interactivo o autopilot. Sin pasos manuales previos.
    •  
 
  
 Corregido 
     
  • Modo autopilot desconectado del flujo real: la deteccion de autopilot no llegaba a la composicion. Corregido para que las gates de usuario se aprueben automaticamente cuando el modo es autopilot.
    •  
 
 
 
 
v0.4.0
 13/03/2026 
 
 Añadido 
     
  • Verificacion de evidencia (evidence guard): hook que registra cada ejecucion de tests como evidencia verificable. Cuando un agente afirma que los tests pasan, el sistema comprueba que efectivamente se ejecutaron.
  • Informe de sesion al cierre: resumen automatico en docs/alfred-reports/ con fases, evidencia de tests, equipo y artefactos.
  • Loop iterativo dentro de fases: los agentes iteran hasta 5 veces dentro de una fase hasta superar la gate, habilitando ciclos TDD naturales.
  • Modo autopilot: ejecucion completa sin interrupcion humana. Las gates de usuario se aprueban automaticamente; las automaticas y de seguridad se evaluan normalmente.
    •  
 
 
 Cambiado 
     
  • 17 personalidades reescritas con tono Alfred Pennyworth: servicio impecable, ironia sutil, precision tecnica.
  • Orquestador ampliado con funciones de loop iterativo (should_retry_phase, reset_phase_iterations) y autopilot (is_autopilot_gate_passable, run_flow_autopilot).
  • Stop-hook genera informe de sesion automaticamente al cerrar una sesion completada.
    •  
 
  
 
 
v0.3.9
 13/03/2026 
 
 Añadido 
     
  • Agente opcional i18n-specialist para proyectos multiidioma: deteccion automatica de señales i18n (directorios i18n/, locales/, translations/), integracion en fases de desarrollo y calidad.
  • Deteccion automatica de i18n en suggest_optional_agents(): analiza directorios y ficheros de configuracion i18n del proyecto.
    •  
 
 
 Cambiado 
     
  • Seleccion de agentes opcionales rediseñada: 2 preguntas multiSelect agrupadas por tema (técnicos + contenido/UX) en vez de una lista larga, compatible con el limite de 4 opciones de AskUserQuestion.
  • Product Owner reformulado: las preguntas de la fase de producto se hacen una a una (una por turno) en vez de en bloque, siguiendo el patron de refinamiento progresivo de superpowers:brainstorming.
  • 8 agentes opcionales (antes 7): añadido i18n-specialist al catalogo, config, orquestador, documentacion y tests.
    •  
 
  
 
 
v0.3.8
 13/03/2026 
 
 Añadido 
     
  • Capa de sincronizacion SQLite a memoria nativa: las decisiones, iteraciones y commits almacenados en alfred-memory.db se proyectan automaticamente como ficheros .md en ~/.claude/projects//memory/ con formato nativo de Claude Code.
  • Sincronizacion hibrida: regeneracion completa al arrancar la sesion + actualizaciones incrementales tras cada escritura en SQLite.
  • Gestion segura de MEMORY.md con marcadores delimitados que preservan el contenido manual del usuario.
  • Creacion automatica del directorio de memoria al cargar Alfred por primera vez.
  • Nuevo skill de testing E2E (calidad/e2e-testing) para configurar Playwright o Cypress.
    •  
 
 
 Cambiado 
     
  • 60 skills revisadas y mejoradas: descriptions enriquecidas para mejor triggering, seccion "Que NO hacer" en 51 skills, integracion con memoria persistente en 10 skills, referencia a detect_stack en 9 skills.
  • 3 protocolos sueltos (incident-response, dependency-strategy, release-planning) reorganizados en sus categorias logicas (calidad/, seguridad/, devops/).
  • Solapamientos entre skills documentados explicitamente. Versiones normativas (RGPD, NIS2, CRA, OWASP, WCAG) añadidas.
    •  
 
  
 
 
v0.3.7
 12/03/2026 
 
 Añadido 
     
  • SonIA -- Project Manager -- nuevo agente de nucleo transversal. Descompone el PRD en tareas, gestiona un kanban en docs/project/kanban/ con 4 ficheros MD (backlog, in-progress, done, blocked), mantiene la matriz de trazabilidad (criterio -- tarea -- test -- doc) y genera informes de progreso por fase.
  • La Intérprete -- i18n Specialist -- nuevo agente opcional para internacionalización. Auditoría de claves i18n, detección de cadenas hardcodeadas, validación de formatos por locale, generación de esqueletos para nuevos idiomas. HARD-GATE: completitud de claves (N en base = N en todos los idiomas).
  • QA Engineer ampliado -- nueva seccion de testing de integracion y E2E con estrategias para Playwright/Cypress, tabla de decision entre tipos de test (unitario, integracion, E2E, regresion) y criterios de seleccion.
    •  
 
 
 Cambiado 
     
  • El Escriba (antes El Traductor) -- tech-writer reescrito como agente de nucleo con doble activacion: fase 3b (documentacion inline de codigo: cabeceras, docstrings, comentarios de contexto) y fase 5 (documentacion de proyecto: API, arquitectura con diagramas Mermaid, guias, changelogs). Guia de estilo estricta: castellano sin latinismos, anglicismos permitidos, sin emojis.
  • HARD-GATEs en 5 agentes opcionales -- data-engineer (integridad de migraciones), ux-reviewer (WCAG 2.1 nivel A), performance-engineer (umbrales de rendimiento), seo-specialist (requisitos minimos de indexacion), github-manager (operaciones destructivas requieren confirmacion).
  • Equipo ampliado a 17 agentes -- 9 de nucleo (antes 8) + 8 opcionales (antes 7). Todos los conteos actualizados en web, README y manifiesto.
  • Colores de agentes unificados -- QA Engineer de red a amber (conflicto con security-officer), performance-engineer y copywriter alineados entre frontmatter y cuerpo del agente.
  • Memoria persistente mejorada -- optimizaciones en el modulo SQLite, consultas mas eficientes y mejor gestion de la base de datos entre sesiones.
  • Hooks de captura unificados -- memory-capture.py y commit-capture.py fusionados en activity-capture.py, un unico hook con dispatch interno por tipo de evento. De 11 a 10 hooks.
  • Todos los agentes revisados -- inconsistencias corregidas en frontmatter, descripciones alineadas con las capacidades reales, personalidades refinadas y cadenas de integracion actualizadas.
    •  
 
  
 
 
v0.3.6
 10/03/2026 
   
 Corregido 
     
  • Agentes de nucleo registrados -- los 7 agentes de nucleo no estaban en el manifiesto del plugin y Claude Code no cargaba sus system prompts. Ahora los 15 agentes (8 nucleo + 7 opcionales) estan registrados y operativos.
  • Herramientas MCP del librarian -- el agente librarian referenciaba 5 herramientas MCP con nombres incorrectos. Corregidos a los nombres reales del servidor.
  • Dashboard vacio en primera sesion -- el pipeline de datos fallaba en cascada: config sin memoria, commits sin iteracion y consultas vacias. Corregido con auto-creacion de config, iteracion automatica y fallback global.
  • Conflicto de puertos -- si otro proyecto usaba los puertos del dashboard, ahora se detecta y se buscan alternativas automaticamente.
    •  
 
 
 
 
v0.3.5
 10/03/2026 
  
 Cambiado 
     
  • SonarQube movido al security-officer -- el análisis de SonarQube lo ejecuta ahora el security-officer en lugar del qa-engineer durante /alfred-dev:audit. Levanta Docker, ejecuta el scanner end-to-end e integra los hallazgos en su informe de seguridad.
  • Instrucciones imperativas -- el subagente recibe pasos explícitos y secuenciales (leer el skill, ejecutar los 7 pasos, integrar resultados) en lugar de una referencia textual que podía ignorarse.
    •  
 
  
 
 
v0.3.4
 03/03/2026 
   
 Corregido 
     
  • Nomenclatura de comandos -- todos los comandos de la web actualizados de /alfred X a /alfred-dev:X para reflejar la convención real de Claude Code.
  • Stats corregidos -- skills de 56 a 59, comandos de 10 a 11, hooks de 7 a 11. Alineados con la implementación real.
  • Comando /alfred-dev:gui visible -- añadido a la tabla pública de comandos en ambos idiomas.
  • SonarQube integrado en audit -- el security-officer ejecuta el skill de SonarQube como paso por defecto. Verificado end-to-end con Docker.
  • Fichero de puertos del dashboard -- session-start.sh crea .claude/alfred-gui-port y verifica la conexión real al servidor en vez de confiar en kill -0.
  • Colores de agentes opcionales -- los 5 agentes sin color en el frontmatter ahora tienen colores asignados para el dashboard.
    •  
 
 
 
 
v0.3.3
 24/02/2026 
   
 Corregido 
     
  • Inicialización de SQLite al arrancar -- la BD de memoria se crea automáticamente en cada sesión si no existe. Elimina la dependencia circular que impedía arrancar el servidor GUI en la primera sesión.
  • Servidor GUI siempre operativo -- el dashboard arranca desde el minuto 1. El WebSocket está disponible inmediatamente para el cliente.
  • Agentes servidos por WebSocket -- el catálogo de 15 agentes se envía desde el servidor en el mensaje init, eliminando la lista hardcodeada en el dashboard.
  • Hooks resilientes a actualizaciones -- guardas test -f en todos los hooks para degradación graceful cuando el directorio del plugin ha cambiado.
    •  
 
 
 
 
v0.3.2
 23/02/2026 
 
 Añadido 
     
  • Composición dinámica de equipo -- sistema de 4 capas (heurística, razonamiento, presentación, ejecución) que sugiere agentes opcionales según la descripción de la tarea. La selección es efímera y no modifica la configuración persistente.
  • Función run_flow() -- punto de entrada para flujos con equipo de sesión efímero. Valida la estructura, inyecta el equipo y registra diagnósticos de error.
  • Tabla TASK_KEYWORDS -- mapa de 8 agentes opcionales con keywords contextuales y pesos base para la composición dinámica.
    •  
 
 
 Cambiado 
     
  • _KNOWN_OPTIONAL_AGENTS derivado de TASK_KEYWORDS (fuente única de verdad). 6 skills de comandos actualizados. 326 tests.
    •  
 
 
 Corregido 
     
  • Matching por palabra completa -- match_task_keywords() usa word boundary en vez de subcadena, eliminando falsos positivos para keywords cortas.
  • Retroalimentación de validación -- el motivo del descarte del equipo se registra en la sesión para diagnóstico.
  • Aviso al truncar -- descripciones de tarea mayores de 10 000 caracteres emiten aviso en vez de truncarse silenciosamente.
    •  
 
 
 
 
v0.3.1
 23/02/2026 
 
 Añadido 
     
  • Soporte móvil -- menú hamburguesa con sidebar deslizante para pantallas estrechas.
  • Cabeceras de seguridad HTTP -- X-Content-Type-Options, Cache-Control y Content-Security-Policy.
  • Inyección dinámica -- versión y puerto WebSocket inyectados desde el servidor, sin valores hardcodeados.
  • Icono SVG de marcado -- sustituido [*] por icono de pin en timeline y decisiones.
  • Auditoría SEO -- canonical, og:image, FAQPage schema, hreflang, dimensiones de imágenes (CLS).
    •  
 
  
 Corregido 
     
  • Lectura robusta de frames WebSocket -- reescrito con readexactly() para eliminar desconexiones por fragmentación TCP.
  • Conexión SQLite cross-thread -- añadido check_same_thread=False para evitar errores en Python 3.12+.
  • Consistencia en get_full_state() -- todas las consultas usan la misma conexión de polling.
  • Polling de marcados -- los elementos marcados ahora se propagan en tiempo real.
  • Formato de timestamps -- detección automática de epoch (s/ms) y cadenas ISO sin zona horaria.
  • Validación de tipos en acciones GUI -- casts explícitos para prevenir inyección de tipos.
  • Buffer de handshake WebSocket -- ampliado a 8192 bytes.
  • Limpieza de writers WebSocket -- cierre explícito de sockets al parar el servidor.
    •  
 
 
 
 
v0.3.0
 22/02/2026 
 
 Añadido 
     
  • Dashboard GUI (Fase Alpha) -- dashboard web en tiempo real con 7 vistas: estado, timeline, decisiones, agentes, memoria, commits y marcados. Se lanza con /alfred-dev:gui.
  • Servidor monolítico Python -- HTTP + WebSocket RFC 6455 manual + SQLite watcher. Sin dependencias externas.
  • Protocolo WebSocket bidireccional -- mensajes init, update, action y action_ack. Reconexión con backoff exponencial.
  • Sistema de marcado -- elementos marcados sobreviven a la compactación del contexto.
  • Tablas SQLite nuevas -- gui_actions y pinned_items. Migración automática a esquema v3.
  • Arranque automático -- el servidor GUI se levanta con cada sesión y se para al cerrar.
  • Principio fail-open: si la GUI falla, Alfred funciona igual. 297 tests.
    •  
 
 
 Cambiado 
     
  • README y documentación ampliados con capturas del dashboard y guía del protocolo WebSocket.
    •  
 
  
 
 
v0.2.3
 21/02/2026 
 
 Añadido 
     
  • Memoria persistente v2 -- migración de esquema, etiquetas, estado y relaciones entre decisiones.
  • 5 herramientas MCP nuevas -- total 15: update, link, health, export, import.
  • Filtros de búsqueda -- parámetros since, until, tags, status.
  • Export/Import -- decisiones a Markdown (ADR), import desde Git y ADRs.
  • Hook activity-capture.py -- hook unificado de captura (eventos del flujo + commits).
  • Hook memory-compact.py -- protege decisiones durante la compactación.
  • Inyección de contexto por iteración activa. ~268 tests.
    •  
 
 
 Cambiado 
     
  • El Bibliotecario ampliado: ciclo de vida de decisiones, integridad, export/import.
    •  
 
  
 
 
v0.2.2
 21/02/2026 
 
 Añadido 
     
  • Hook dangerous-command-guard.py -- bloquea rm -rf /, force push, DROP DATABASE, fork bombs y más.
  • Hook sensitive-read-guard.py -- aviso al leer claves privadas, .env, credenciales.
  • 4 herramientas MCP nuevas -- total 10: stats, iteraciones, abandon.
  • 3 skills nuevos -- incident-response, release-planning, dependency-strategy.
  • /alfred-dev:feature permite seleccionar fase de inicio.
  • Test de consistencia de versión. 219 tests en total.
    •  
 
  
 Corregido 
     
  • quality-gate.py -- ancla de posición para runners, re.IGNORECASE en fallos.
  • Respuestas MCP con isError: true para errores.
  • 8 incidencias de deuda técnica: logging, encapsulación, recuperación.
    •  
 
 
 
 
v0.2.1
 21/02/2026 
   
 Corregido 
     
  • Ruta de caché en Windows -- install.ps1 y uninstall.ps1 alineados con la convención de Claude Code.
  • activity-capture.py -- diagnóstico en bloques except silenciosos.
  • session-start.sh -- catches específicos en vez de Exception genérico.
    •  
 
 
 
 
v0.2.0
 20/02/2026 
 
 Añadido 
     
  • Memoria persistente -- SQLite local por proyecto con decisiones, commits, iteraciones y eventos.
  • Servidor MCP -- 6 herramientas stdio: buscar, registrar, consultar.
  • El Bibliotecario -- agente opcional para consultas históricas.
  • Hook activity-capture.py -- captura automática de eventos del flujo.
  • Búsqueda FTS5, sanitización de secretos, permisos 0600.
  • 114 tests (58 nuevos para memoria).
    •  
 
   
 
 
v0.1.5
 20/02/2026 
   
 Corregido 
     
  • Secret-guard fail-closed -- bloquea cuando no puede determinar la ruta destino.
  • Instalador idempotente en entorno limpio (mkdir -p).
  • Detección de versión en /alfred-dev:update más fiable.
    •  
 
 
 
 
v0.1.4
 19/02/2026 
 
 Añadido 
     
  • 6 agentes opcionales -- data-engineer, ux-reviewer, performance, github, seo, copywriter.
  • 27 skills nuevos en 6 dominios. Total: 56 skills en 13 dominios.
  • Soporte Windows -- install.ps1 y uninstall.ps1 nativos.
  • Hook spelling-guard.py -- tildes omitidas en castellano.
  • Quality gates ampliados: 8 a 18.
    •  
 
   
 
 
v0.1.2
 18/02/2026 
  
 Cambiado 
     
  • Nueva personalidad -- compañero cercano con humor, los 8 agentes con voz propia.
  • Corrección ortográfica completa en 68 ficheros (RAE).
    •  
 
 
 Corregido 
     
  • Prefijo correcto en comandos, update robusto, registro explícito de los 10 comandos.
    •  
 
 
 
 
v0.1.1
 18/02/2026 
   
 Corregido 
     
  • session-start.sh -- error de sintaxis que impedía la inyección de contexto.
  • secret-guard.sh -- política fail-closed restaurada.
  • stop-hook.py -- validación de tipos para estado corrupto.
    •  
 
 
 
 
v0.1.0
 18/02/2026 
 
 Añadido 
     
  • Primera release pública.
  • 8 agentes especializados, 5 flujos, 29 skills, 5 hooks.
  • Quality gates, compliance RGPD/NIS2/CRA, detección de stack.
    •  
 
   
 
 
   
 
 
 Alfred Dev Origen 
  
 
  
 
 
Qué quería construir
 
No quería otro prompt bonito ni una colección de personajes haciendo teatro. Quería un sistema que ayudara de verdad a un desarrollador: alguien que ordena el trabajo, detecta lo importante, mantiene continuidad entre sesiones y empuja hacia una ejecución seria.
 
 
Por qué se llama Alfred
 
El nombre viene de Alfred Pennyworth, la figura de Batman que siempre estaba donde hacía falta. No era el protagonista visible, pero era el que sostenía la operación con criterio, calma y fiabilidad. Resolutivo, preciso, elegante en la ejecución y capaz de decir las cosas con una ironía seca cuando tocaba, sin dejar de ser impecable.
 
 
Qué quería trasladar de esa referencia
 
Me interesaba esa mezcla difícil: un asistente con personalidad, pero sin histrionismo; con estilo, pero sin frivolidad; con criterio propio, pero al servicio del trabajo. Alfred Dev intenta capturar justo eso: ayudarte a tomar mejores decisiones, anticipar problemas y mantener el listón alto sin convertir la herramienta en un espectáculo.
 
 
Cómo se traduce en el plugin
 
Por eso Alfred orquesta agentes, memoria, quality gates, trazabilidad y continuidad en vez de limitarse a contestar prompts. La ambición del producto es sencilla de explicar y difícil de ejecutar: que, como desarrollador, sientas que por fin tienes un asistente serio, fiable y con oficio.
 
 
 
 
   
 
 
 Visión técnica del plugin System map 
  
 
  
 
 
Qué es este proyecto
 
Transforma desarrollo asistido por IA en un proceso gobernado por fases secuenciales, agentes especializados y puntos de control que no se pueden saltar sin evidencia.
 
     
  • Trabaja con 19 agentes especializados y responsabilidades delimitadas.
  • Automatiza seis flujos principales: feature, fix, spike, ship, audit y quick.
  • Detecta el stack tecnológico del repo y adapta artefactos, testing y agentes opcionales.
    •  
 
 
Resumen operativo para reconstrucción
 
La superficie visible son 26 ficheros de comandos y un catálogo de agentes, pero el sistema real vive detrás: core Python, hooks del ciclo de vida, memoria SQLite y un orchestrator que no delega el estado a nadie más.
 
     
  • 10 agentes de núcleo quedan fuera de plugin.json y entran sólo a través del flujo orquestado.
  • 9 agentes opcionales sí son configurables y activables según stack o tarea.
  • Las quality gates son duras: evidence-guard y quality-gate frenan el avance si falta prueba real.
  • Cada fase puede reintentarse hasta 5 veces antes de escalar al usuario.
    •  
 
 
Stack tecnológico
 
El proyecto opera sobre ecosistemas separados pero coordinados: Python para orquestación y memoria, Astro para la documentación pública y Node.js nativo para el runtime visual de Selina.
 
     
  • El core usa Python 3.10+ para orchestrator, config_loader, memory, continuity y hooks.
  • La web pública vive en Astro estático con TypeScript y sitemap.
  • Selina usa módulos nativos de Node.js para servir la galería de 10 sistemas de diseño y la ronda final de propuestas, sin dependencias externas.
  • El desarrollo se apoya en pytest para Python y astro check para la parte web.
    •  
 
 
Arquitectura por capas
 
Commands, agentes, core, hooks, MCP y servidor visual están separados. Los commands no llaman agentes directamente: activan al orchestrator, y Alfred decide qué entra y en qué orden.
 
     
  • Commands visibles -> orchestrator.py -> agentes y fases.
  • Hooks interceptan SessionStart, PreToolUse, PostToolUse y Stop.
  • memory_server expone herramientas MCP para consultar memoria desde cualquier agente.
  • Los agentes no se comunican entre sí; todo pasa por Alfred y el estado de sesión.
    •  
 
 
Persistencia y base de datos
 
La memoria persistente vive en .claude/alfred-memory.db. Está diseñada para ser local, portable y segura, no para depender de servicios remotos o infraestructura adicional.
 
     
  • SQLite local con modo WAL y búsqueda FTS5.
  • Persistencia de decisiones, commits, iteraciones y eventos.
  • Permisos 0600 y sanitización con 14 patrones regex para secretos.
  • Migración automática del esquema y purga configurable con retention_days.
    •  
 
 
Lógica de negocio y quality gates
 
El sistema resuelve un problema muy concreto: evitar que el desarrollo con IA salte fases críticas y cierre trabajo sin seguridad, QA, documentación o evidencia suficiente.
 
     
  • Sin evidencia registrada, una afirmación de “tests pasan” no vale.
  • Security Officer aparece de forma transversal en arquitectura, calidad y entrega.
  • La fase visual de Selina sólo se activa cuando el stack tiene frontend y usa un catálogo base de 10 sistemas antes de cerrar la dirección final.
  • Las gates de usuario y las automáticas están separadas; autopilot no salta seguridad ni evidencia.
    •  
 
 
Runtime y componentes auxiliares
 
Además del core, el sistema añade piezas operativas que vuelven usable el flujo en el día a día: continuidad, memoria consultable, sincronía opcional con GitHub y servidor visual con timeout.
 
     
  • Continuity mantiene next, pause, resume y handoff sin perder fase.
  • Memory UI abre timeline, decisiones, commits y health sobre SQLite local.
  • GitHub Sync refleja el estado local en issues cuando conviene compartir seguimiento.
  • El runtime visual de Selina usa timeout de 30 minutos, comprueba el proceso padre cada 60 segundos y soporta tanto galería base como selección final.
    •  
 
 
Puesta en marcha y reconstrucción
 
Para reconstruirlo o ponerlo en marcha no hace falta una infraestructura compleja, pero sí respetar las reglas que hacen fiable el sistema.
 
     
  • Claude Code, Python 3.10+ y Node.js deben estar disponibles en el entorno.
  • La memoria SQLite se crea automáticamente al activar memoria en /alfred-dev:config.
  • map-codebase, discuss y quick generan contexto útil para que la memoria no nazca vacía.
  • El error más caro sería romper el aislamiento de agentes o dejar que otra capa sustituya al orchestrator como fuente de verdad.
    •  
 
 
 
 
   
 
 
 /alfred-dev:command Operativo 
  
 
  
 
 
Núcleo que entra
 
 
 
 
Opcionales que pueden entrar
 
 
 
 
Capas activas
 
 
 
 
Qué hace de verdad
 
     
     
     
     
           
     
     
     Agente Core 
      
     
      
     
     
    Cómo entra en el flujo
     
       
       
       
      Qué hace
       
         
         
         
        Qué no hace
         
           
           
           
           
                       
           
           
           Capa auxiliar Runtime 
            
           
           
           
           
          Qué aporta