Implementa una nueva tool que permite buscar películas y series en IMDb
usando la API de OMDb. Retorna hasta 5 resultados con título, año, tipo,
poster URL e IMDb ID.
Cambios:
- tools/imdb/imdb.go: tool imdb_search con integración a OMDb API
- internal/config/schema.go: IMDbToolCfg con api_key, api_key_env y timeout
- agents/runtime.go: registro de tool en buildToolRegistry
- agents/asistente-2/config.yaml: habilitación de tool imdb
- .env.example: OMDB_API_KEY para configuración
La tool soporta parámetros:
- query (requerido): título de película/serie a buscar
- year (opcional): año para filtrar resultados
Configuración via api_key directa o variable de entorno OMDB_API_KEY.
API key gratuita disponible en http://www.omdbapi.com/🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Se crea template_para_llm.md en agents/_template/ con los campos mínimos necesarios para que Claude genere un agente completo:
- Campos obligatorios: id, name, description, system prompt
- Campos opcionales con defaults: provider LLM, model, tool_use, personalidad
- Checkboxes para capacidades específicas (HTTP, SSH, files, etc.)
- Ejemplo completado para referencia
El template permite crear agentes solo proporcionando lo esencial, sin necesidad de entender toda la estructura interna del sistema.
Sistema de personalidades enriquecido con traits y prompts dinamicos. Agente template completo con configuracion estandarizada. Comando !info mejorado con metadata completa.
Issue 0014 completado:
✅ Fase 1: Sistema de personalidades enriquecido
- PersonalityCfg ampliado con role, backstory, expertise, limitations
- CommunicationCfg con formality, humor, personality, response_style, quirks
- BuildPersonalityPrompt() genera bloque para system prompt
- Integrado en runtime con FromConfig + concatenacion automatica
✅ Fase 2: Agente plantilla (_template)
- Campo Template bool en AgentMeta (launcher lo filtra)
- agents/_template/ completo con todas las secciones documentadas
- agent.go + prompts/system.md + config.yaml canonica
- new-agent.sh actualizado para copiar desde _template/
✅ Fase 3: Ejemplos de personalidades
- PERSONALITIES.md con 4 perfiles: DevOps pragmatico, Analista meticuloso,
Asistente amigable, Guardian de seguridad
✅ Fase 4: Comando !info enriquecido
- Metadata completa: identidad, personalidad, LLM, tools, skills,
knowledge, memoria, schedules, uptime
Fase 5 (estandarizar configs existentes): aplazada — los agentes actuales
funcionan correctamente. Los nuevos agentes usaran el template completo.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Fase 1: Sistema de personalidades enriquecido
- Ampliar PersonalityCfg con role, backstory, expertise, limitations
- Añadir CommunicationCfg (formality, humor, personality, response_style, quirks, catchphrases)
- Crear tipos puros en pkg/personality/traits.go
- Implementar BuildPersonalityPrompt() para generar bloque de system prompt
- Integrar personalidad en agents/runtime.go (FromConfig + concatenacion al system prompt)
Fase 2: Agente plantilla
- Añadir campo Template bool a AgentMeta
- Filtrar agentes template en launcher (skip si template: true)
- Crear agents/_template/ con config.yaml completo y documentado
- Incluir TODAS las secciones (skills, shared_knowledge, schedules, security)
- agent.go minimo + prompts/system.md plantilla
- Actualizar dev-scripts/agent/new-agent.sh para copiar desde _template/
Fase 3: Ejemplos de personalidades
- Crear agents/_template/PERSONALITIES.md con 4 perfiles:
* DevOps pragmatico
* Analista meticuloso
* Asistente amigable
* Guardian de seguridad
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Sistema completo de skills reutilizables que permiten a los agentes
ejecutar flujos multi-paso complejos combinando tools, logica condicional
y conocimiento de dominio.
Componentes implementados:
- pkg/skills/: tipos puros (SkillMeta, Skill, matching)
- shell/skills/: loader (filesystem) + executor (scripts seguros)
- tools/skilltools/: 4 tools de function calling (search, load, read, run)
- internal/config/: SkillsCfg con filtros de categoria
- agents/runtime.go: integracion opcional con agentes
- skills/: 4 skills de ejemplo (deploy, log-analyzer, health-check, daily-report)
- .claude/rules/create_skill.md: guia completa para crear skills
Diferencia clave: tools son atomicas, skills son flujos declarativos.
Arquitectura: pure core (pkg/), impure shell (shell/), contenido declarativo (skills/).
Tests: matching, loader con path traversal protection, executor con allowlist.
Commits del merge:
- feat: tipos puros para sistema de skills
- feat: loader y executor de skills en shell
- feat: configuracion de skills en schema
- feat: tools de function calling para skills
- feat: integrar skills en runtime de agentes
- feat: skills de ejemplo y README del sistema
- docs: documentar sistema de skills
- chore: cerrar issue 0016 — sistema de skills
Mover issue 0016 a completed/ y actualizar README:
El issue 0016-skills-system ha sido completado con todas las fases:
- Estructura de directorios y skills de ejemplo
- Tipos puros (pkg/skills/)
- Loader y executor (shell/skills/)
- Configuracion en schema
- Tools de function calling
- Integracion con runtime
- Tests unitarios completos
- Documentacion completa
Estado en dev/issues/README.md: pendiente → completado
Sistema de skills operativo y listo para usar.
Documentar sistema de skills en .claude/:
CLAUDE.md:
- Agregar pkg/skills/, shell/skills/, tools/skilltools/ y skills/ a estructura
- skills/ como contenido declarativo (SKILL.md + recursos)
.claude/rules/create_skill.md:
- Guia completa para crear nuevas skills
- Template de SKILL.md con frontmatter
- Proceso paso a paso (categoria → estructura → SKILL.md → recursos → tests)
- Reglas criticas: skills != tools, < 500 lineas, idempotencia
- Ejemplos y anti-patrones
.claude/rules/index.md:
- Agregar regla "Crear skill" al indice
- Explicar cuando usar skills vs tools
La regla create_skill.md es la guia oficial para añadir skills.
Agregar 4 skills de ejemplo funcionales y README del sistema:
Skills de ejemplo:
- devops/deploy-service: deploy completo con rollback
- analysis/log-analyzer: analisis de logs con metricas
- communication/daily-report: reportes diarios automaticos
- system/health-check: verificacion de salud multi-servicio
Cada skill incluye:
- SKILL.md con frontmatter YAML + instrucciones markdown
- Descripcion de parametros y proceso paso a paso
- Ejemplos de uso y consideraciones de seguridad
skills/README.md documenta:
- Diferencia entre tools (atomicas) y skills (flujos multi-paso)
- Formato de SKILL.md y carga progresiva (3 niveles)
- Categorias disponibles y uso desde agentes
Las skills son contenido declarativo, no codigo Go.
Integrar sistema de skills en agents/runtime.go:
- Agregar skillLoader al struct Agent
- Inicializar loader y executor cuando skills.enabled = true
- Registrar skill tools en buildToolRegistry
- Respetar filtro de categorias configurado
- Aplicar timeout configurado para scripts
Las skills quedan disponibles automaticamente para agentes que
las habiliten en su config YAML.
Arquitectura: skills como extension opcional, no dependencia core.
Agregar tools en tools/skilltools/ para interactuar con skills:
- skill_search: busca skills relevantes por query
- skill_load: carga instrucciones completas de una skill
- skill_read_resource: lee recursos especificos (scripts, references, templates)
- skill_run_script: ejecuta scripts de skills con argumentos
Las tools permiten al LLM descubrir, cargar y ejecutar skills
de forma progresiva (metadata → instrucciones → recursos).
Patron standard: Def (puro) + Exec (impuro).
Agregar SkillsCfg y SkillsToolCfg al config schema:
SkillsCfg (nivel agente):
- enabled: activar/desactivar skills
- path: directorio de skills (default: skills/)
- categories: filtro de categorias a cargar
- timeout: timeout de ejecucion de scripts
SkillsToolCfg (nivel tools):
- allowed_interpreters: allowlist de interpreters (bash, python3, etc.)
Permite configurar skills por agente de forma granular.
Agregar componentes impuros para manejo de skills en shell/skills/:
Loader (filesystem I/O):
- LoadMeta(): carga metadata de todas las skills
- LoadSkill(): carga skill completa con instrucciones
- ReadResource(): lee recursos con path traversal protection
- Parsing de SKILL.md con frontmatter YAML
Executor (script execution):
- Ejecucion segura de scripts con allowlist de interpreters
- Timeout obligatorio por script
- Inferencia de interpreter desde extension
- Proteccion contra scripts maliciosos
Incluye tests completos con tmpdir para loader y executor.
Arquitectura: impure shell, todo I/O aislado en shell/.
Agregar tipos puros en pkg/skills/ para el sistema de skills:
- SkillMeta: metadata de skills (name, description, category)
- Skill: representacion completa con instrucciones y recursos
- SkillMatch: resultado de matching con confidence score
- Match(): funcion pura de matching por keywords
- FilterByCategory(): filtrado de skills por categorias
Incluye tests unitarios completos para matching y filtrado.
Arquitectura: pure core, cero side effects en pkg/.
Sistema completo de shared knowledge que permite colaboración entre agentes:
**Implementado:**
- Config SharedKnowledge en schema.go (enabled, dir, db_path)
- WAL mode en FileStore para concurrencia entre procesos
- Tools compartidas: shared_knowledge_{search,read,write,list}
- Integración en agents/runtime.go con instanciación y registro
- Carpeta knowledges/ con README explicativo
- Documentación en prompts de agentes
- Tests completos con coexistencia privado/compartido
- .gitignore actualizado (knowledges/data/)
- Estructura actualizada en CLAUDE.md
**Arquitectura:**
- Reutiliza FileStore existente con directorio compartido
- WAL mode permite múltiples lectores + single writer
- Tools prefijadas shared_knowledge_* vs knowledge_* (privado)
- Los .md se commitean, la DB se reconstruye con Sync()
Issue: dev/issues/completed/0018-shared-knowledge.md
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Mover dev/issues/0018-shared-knowledge.md a completed/
- Actualizar dev/issues/README.md: estado completado
- Sistema de conocimiento compartido completamente implementado
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Agregar knowledges/data/ a .gitignore (DB no se commitea)
- Agregar knowledges/ a estructura en CLAUDE.md
- Los .md compartidos sí se commitean
- Issue 0018: Shared Knowledge (fase 7)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Separar herramientas en dos secciones
- Explicar diferencia entre knowledge privado y shared
- Guía de cuándo usar cada una
- Issue 0018: Shared Knowledge (fase 5)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Carpeta raiz para documentos compartidos entre agentes
- README explica proposito, funcionamiento, diferencia con privado
- Ejemplo de flujo de colaboracion entre agentes
- Issue 0018: Shared Knowledge (fase 4)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Agregar campo sharedKnowledgeStore al Agent struct
- Inicializar shared store si cfg.Tools.SharedKnowledge.Enabled
- Registrar shared tools en buildToolRegistry
- Cerrar shared store en Run defer
- Defaults: dir=knowledges, db=knowledges/data/knowledge.db
- Issue 0018: Shared Knowledge (fase 3)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Ejecutar PRAGMA journal_mode=WAL al abrir la DB
- Permite múltiples lectores + single writer concurrentes
- Mejora el rendimiento del shared knowledge compartido
- Issue 0018: Shared Knowledge (fase 2a)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Nuevo tipo SharedKnowledgeToolCfg con enabled, dir, db_path
- Agregar campo SharedKnowledge a ToolsCfg
- Issue 0018: Shared Knowledge (fase 1)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Integra soporte para conectarse a servidores MCP externos y consumir sus tools. El cliente MCP permite descubrir y ejecutar tools remotas, ampliando las capacidades de los agentes sin modificar el core. Esta implementación mantiene la separación pure/impure y se integra con el sistema de tools existente.
Implementa el cliente MCP que permite a los agentes conectarse a servidores
MCP externos y usar sus tools como si fueran tools nativas del agente.
Arquitectura implementada:
- shell/mcp/client.go: Cliente MCP con soporte stdio y SSE
- shell/mcp/manager.go: Gestor de múltiples clientes MCP
- tools/mcptools/mcp.go: Bridge que convierte MCP tools → tools.Tool
- shell/mcp/server.go: Movido desde shell/protocols/ para colocación junto al client
Cambios en config:
- MCPServerCfg extendido con campos Transport, Command, Args, Env, Headers,
Prefix, Timeout para soportar stdio y SSE transport
Integración en runtime:
- agents/runtime.go: Inicializa MCP manager si config.Tools.MCP.Enabled
- buildToolRegistry: Registra tools MCP automáticamente con prefijos configurables
- Agent: Campo mcpManager que se cierra en shutdown
Transportes soportados:
- stdio: Lanza subproceso (ej: npx -y @anthropic/mcp-server-brave-search)
- SSE: Se conecta a servidor HTTP MCP
Las tools MCP son indistinguibles de tools nativas desde el punto de vista
del LLM. Auto-discovery via ListTools(), conversión de JSON Schema a tools.Param.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Conecta el sistema centralizado de grupos y permisos al launcher y runtime.
Elimina controles per-agente obsoletos. Activa feature flag. Docs actualizados.
- Actualiza docs/security.md: nueva sección "Sistema de grupos centralizados"
con estructura de los 3 YAML, acciones disponibles, campos deprecados
- Actualiza .claude/CLAUDE.md: añade security/ en la estructura del proyecto
- Mueve 0024 y 0024c a dev/issues/completed/
- Actualiza dev/issues/README.md: marca 0024, 0024a, 0024b, 0024c como completado
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Migrar admin a security/user-groups.yaml (admins group)
- agents.New() ahora acepta acl.ACL pre-resuelta como parámetro;
elimina construcción interna desde cfg.Security.Roles
- cmd/launcher: carga shellsecurity.Load("security/") al arranque;
si falla, WARN + política vacía (open access). Para cada agente
llama pksecurity.ResolveACL y pasa la ACL a agents.New()
- cmd/launcher/registry.go: stores secPolicy en launchDeps para
que reload() también resuelva ACL centralmente
- shell/matrix/listener.go: elimina invite gating y allowlist check
basados en AllowedUsers; el control de acceso lo hace el runtime
- internal/config/schema.go: depreca campos Roles y AllowedUsers
(backward compat, no eliminados)
- agents/*/config.yaml: elimina bloques security.roles y allowed_users
- dev/feature_flags.json: activa centralized-security-groups (enabled: true)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Crea los tres archivos YAML de configuración de seguridad centralizada en
security/ (user-groups.yaml, agent-groups.yaml, permissions.yaml) y el
loader impuro shell/security/loader.go que los lee y construye un
security.SecurityPolicy puro.
- security/user-groups.yaml: grupos de usuarios (admins, everyone)
- security/agent-groups.yaml: grupos de agentes (assistants, all)
- security/permissions.yaml: políticas de permisos por grupo de agentes
- shell/security/loader.go: Load(dir) → SecurityPolicy; usa structs YAML
intermedios para mantener pkg/security/ libre de gopkg.in/yaml.v3
- shell/security/loader_test.go: 6 tests cubren los casos del issue
(dir inexistente, vacío, 3 YAMLs, solo uno, malformado, wildcards)
El código se mergea con feature flag centralized-security-groups = false
(loader creado, todavía no wired al launcher — eso es 0024c).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Crea el paquete puro pkg/security/ con los tipos base del sistema
centralizado de permisos y la función ResolveACL.
Cambios:
- pkg/acl/config.go: añade FromRoles([]Role) ACL como constructor directo
- pkg/security/groups.go: UserGroup, AgentGroup
- pkg/security/policy.go: Permission, AgentPolicy, SecurityPolicy
- pkg/security/resolver.go: ResolveACL(agentID, SecurityPolicy) → acl.ACL
* soporte wildcard de agente ("*") y de usuario ("*")
* políticas acumulativas: unión de permisos entre grupos
* referencia directa por agentID sin definir grupo
- pkg/security/security_test.go: 7 tests cubriendo todos los casos del issue
El paquete es pure core: cero I/O, cero side effects.
Mergeado con feature flag centralized-security-groups = false (no wired).
Registra el flag 'centralized-security-groups' desactivado. Protege el
código del issue 0024 (sistema centralizado de grupos de usuarios y
agentes) hasta que todas las sub-issues estén completas.
Simplifica el flujo de fix-issue para crear la rama directamente con
git checkout -b en lugar de invocar /git-branch, que añadía una capa
de indirección innecesaria. Añade lógica para detectar si ya estamos
en la rama correcta y continuar sin recrearla.
Actualiza la tabla de estructura del proyecto para reflejar los nuevos
directorios creados en el issue 0025. Añade también README.md en
dev-scripts/cron/ con descripción de cada script y ejemplos de uso.
Implementa issue 0025: catálogo central de automatizaciones cron y scaffolder.
- crons/: directorio de automatizaciones nombradas con README explicando la
convención. Incluye dos ejemplos listos para usar:
· good-morning (send_message, 0 9 * * *) — saludo diario
· daily-summary (llm_prompt, 0 18 * * *) — resumen generado por LLM
- dev-scripts/cron/new.sh: scaffolder interactivo — pregunta nombre,
descripción, tipo de acción y cron expression; crea schedule.yaml +
archivo de prompt vacío; imprime el bloque YAML para copiar en config.yaml.
- dev-scripts/cron/list.sh: lista todas las automatizaciones del catálogo
con nombre, tipo, cron y descripción en formato tabular.
- dev-scripts/cron/apply.sh: añade la automatización al config.yaml del
agente indicado usando yq si está disponible; si no, imprime el bloque
YAML para copiar a mano (sin dependencias obligatorias).
- shell/cron/scheduler.go: exporta Fire(ctx, sc) para disparo inmediato
de un schedule sin esperar al timer cron — útil en tests y CLI.
- shell/cron/scheduler_test.go: cuatro tests nuevos para Fire()
(send_message inline, llm_prompt, sin output_room, sin LLM).
TestScheduler_SkipsInvalidSchedule y TestFire_LLMPrompt_NoLLM_Skips
reemplazados por versiones instantáneas usando Fire en lugar de
@every 100ms + sleep, eliminando ~700ms de tiempo de test.
Se instancia shellcron.Scheduler en agents.New() cuando cfg.Schedules tiene
entradas (scheduler queda nil en agentes sin schedules, sin overhead).
En agents.Run() se arranca el scheduler en una goroutine independiente que
termina cuando el ctx del agente es cancelado — el shutdown es limpio gracias
a cron.Stop() que devuelve un contexto que se espera.
La integración no rompe agentes existentes: el campo scheduler es nil por
defecto y todo el código nuevo está tras if a.scheduler != nil.
Nuevo paquete shell/cron con dos archivos:
shell/cron/scheduler.go — Scheduler struct con método Start(ctx) que:
- Registra todas las entradas de config.ScheduleCfg como jobs de robfig/cron
- Omite schedules sin output_room o sin action.kind (warn en log)
- Bloquea hasta que ctx sea cancelado, luego detiene el cron limpiamente
- Recibe MatrixSender, CompleteFunc y *slog.Logger como dependencias (sin importar agents/)
shell/cron/actions.go — ejecutores para fase 1:
- send_message: resuelve contenido desde Message (inline) o Template (archivo .md),
luego llama a matrix.SendMarkdown
- llm_prompt: resuelve prompt desde Prompt o Template, llama al LLM y envía
la respuesta al room configurado; no-op silencioso si no hay LLM
resolveContent() prioriza texto inline sobre ruta de archivo, lo que permite
tanto mensajes cortos en YAML como prompts largos en archivos .md separados.
Fase 2 (run_tool) y fase 3 (inter-bot) quedan pendientes según el issue.
Se añaden tres campos nuevos a ScheduledAction en internal/config/schema.go:
- Message: texto inline para send_message
- Template: ruta a archivo .md para send_message o llm_prompt
- Prompt: texto inline del prompt para llm_prompt
Se agrega github.com/robfig/cron/v3 v3.0.1 como dependencia.
No hay cambios de ruptura: los campos son opcionales y el schema existente
sigue siendo compatible.
egutierrez