Expande el paquete tools/file/ con 4 operaciones nuevas para que los agentes
puedan interactuar con carpetas de trabajo (workspaces, outputs).
Cambios:
- Extraer validatePath() y resolveReal() a validate.go para reutilizarlos
- Agregar validateWritePath() que verifica ReadOnly == false
- write_file: crea/sobreescribe archivos, crea dirs padre, limite 1MB
- list_directory: lista archivos con metadata, modo recursivo, limite 500 entries
- append_file: agrega contenido al final, crea si no existe, limite 10MB total
- delete_file: borra solo archivos (nunca directorios), previene rm -rf accidental
- Registrar las 4 tools nuevas en runtime.go condicionalmente:
- list_directory: siempre (no requiere escritura)
- write/append/delete: solo si ReadOnly == false
Seguridad: todas las tools reutilizan validatePath() con deny-by-default,
resolucion de symlinks y proteccion contra path traversal.
Cobertura completa del registro global de reglas:
- Register + GetRules: registro exitoso y recuperacion
- GetRules con ID inexistente: retorna nil
- Register duplicado: panic con mensaje descriptivo
- RegisteredIDs: retorna todos los IDs registrados
- resetRegistry: limpia el registro (helper para tests)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- new-agent.sh: reemplaza edicion del rulesRegistry map con insercion
de un blank import simple. Ahora tambien sustituye AGENT_ID_PLACEHOLDER
en agent.go con el ID real del agente.
- create_agent.md: actualiza template de agent.go con patron init() +
agents.Register(), secciones de registro en launcher y checklist.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Introduce un registro global de reglas en agents/registry.go con
Register() y GetRules(). Cada paquete de agente se auto-registra
via init(), eliminando la necesidad de editar manualmente el map
rulesRegistry en cmd/launcher/main.go.
Cambios:
- agents/registry.go: nuevo registro global con sync.RWMutex
- agents/*/agent.go: cada agente llama agents.Register() en init()
- agents/_template/agent.go: placeholder AGENT_ID_PLACEHOLDER para scaffold
- cmd/launcher/main.go: elimina rulesRegistry, usa blank imports +
agents.GetRules() para obtener reglas por agent ID
Patron: init() + blank import (estandar Go: database/sql, image codecs)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Mover issue 0027-prune-config-schema a completed/ y actualizar indice.
Todas las tareas implementadas: schema podado, template simplificado,
configs de agentes limpiados, tests de parsing agregados.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Tres tests para internal/config:
- TestAgentConfigParseMinimal: config minimo con campos requeridos
- TestAgentConfigIgnoresRemovedSections: YAMLs antiguos con agents/observability/
resilience siguen parseando sin error (yaml.v3 ignora campos desconocidos)
- TestAgentConfigParseFull: config completo con todas las secciones activas
incluyendo personality.communication, tools, security, storage, memory y skills
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Elimina 14 structs nunca referenciados en el codebase:
- ObservabilityCfg y sub-structs (LoggingCfg, MetricsCfg, HealthCfg, TracingCfg)
- ResilienceCfg y sub-structs (CircuitBreakerCfg, RetryCfg, ShutdownCfg, QueueCfg)
- AgentsCfg y sub-structs (PeerCfg, DelegationCfg, ProtocolCfg)
Se eliminan los campos Agents, Observability y Resilience del AgentConfig root.
CommunicationCfg se mantiene porque esta activamente usada por pkg/personality/
y agents/commands.go.
schema.go pasa de 561 lineas / 61 structs a 460 lineas / 47 structs.
El template _template/config.yaml se reduce de 414 a ~220 lineas.
Los configs de assistant-bot y asistente-2 se limpian de secciones muertas.
yaml.v3 ignora campos extra, asi que YAMLs antiguos siguen parseando sin error.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Registra los nuevos issues pendientes en el indice y excluye
la carpeta worktrees/ del control de versiones.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Dos skills declarativas para automatizar flujos complejos:
- create-agent: pipeline completo de scaffold + build + register + verify
para nuevos agentes/robots Matrix, con templates para agent.go,
config.yaml y system prompt.
- parallel-fix-issues: implementación concurrente de múltiples issues
usando git worktrees y agentes paralelos, con análisis de dependencias,
verificación por wave e integración ordenada a master.
Ambas skills incluyen templates y scripts auxiliares.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Mueve el issue a dev/issues/completed/ y actualiza el README.
Issue completado: runtime.go dividido en 5 archivos especializados
con tests para buildToolRegistry.
Agrega 8 tests para buildToolRegistry() que verifican:
- Config minima: solo tools always-on (current_time, get_weather, matrix_send)
- HTTP habilitado/deshabilitado: http_get y http_post
- FileOps read-only: registra read_file y list_directory pero NO write/append/delete
- FileOps read-write: registra todas las 5 file tools
- IMDb habilitado: imdb_search
- SSH habilitado: ssh_command
- Conteo total: 12 tools con todo habilitado (sin deps externas)
Estos tests validan la logica condicional de registro que ahora vive
en registry_build.go, separada del runtime principal.
- CLAUDE.md: actualizar estructura (types.go, robot.go), seccion
"Agentes y Robots" con tabla comparativa y mencion de ambos templates
- create_agent.md: tabla comparativa Robot vs Agent al inicio,
input "type" en la tabla de inputs para decidir si crear agent o robot
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Incluye 12 tests que cubren:
- Comandos built-in del Robot (help, ping, status, info, version)
- Verificacion de que !help muestra solo comandos de robot (no tools/clear/prompts)
- Registro y ejecucion de comandos custom via RegisterCommand
- Aliases de comandos
- Robot ignora mensajes sin comando (no hay LLM)
- Ciclo de vida: Stop/Done
- Stop seguro con cancel nil
- Verificacion compile-time de que Agent y Robot satisfacen Runner interface
- Conteo exacto de comandos built-in (5, no mas)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Introduce la separacion Robot vs Agent en el sistema:
- agents/types.go: interfaz Runner comun (Run, Stop, Done, RegisterCommand)
que tanto Agent como Robot satisfacen
- agents/robot.go: struct Robot — runtime minimo que solo conecta a Matrix
y despacha comandos. Sin LLM, reglas, memoria, knowledge, skills ni tools.
Mensajes normales se ignoran silenciosamente
- internal/config/schema.go: campo Type en AgentMeta ("agent"|"robot")
- cmd/launcher: usa Runner interface para manejar ambos tipos uniformemente.
Si cfg.Agent.Type == "robot" crea NewRobot en vez de New (tanto en
arranque como en hot-reload)
- agents/_template_robot/config.yaml: plantilla minima (~55 lineas) para
robots command-only
El Robot soporta built-in commands reducidos (help, ping, status, info,
version) y comandos custom via RegisterCommand. No incluye tools, tool,
clear ni prompts ya que no tiene LLM ni memoria.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Registra los nuevos issues pendientes en el indice y excluye
la carpeta worktrees/ del control de versiones.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Cobertura completa del registro global de reglas:
- Register + GetRules: registro exitoso y recuperacion
- GetRules con ID inexistente: retorna nil
- Register duplicado: panic con mensaje descriptivo
- RegisteredIDs: retorna todos los IDs registrados
- resetRegistry: limpia el registro (helper para tests)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Mover issue 0027-prune-config-schema a completed/ y actualizar indice.
Todas las tareas implementadas: schema podado, template simplificado,
configs de agentes limpiados, tests de parsing agregados.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Tres tests para internal/config:
- TestAgentConfigParseMinimal: config minimo con campos requeridos
- TestAgentConfigIgnoresRemovedSections: YAMLs antiguos con agents/observability/
resilience siguen parseando sin error (yaml.v3 ignora campos desconocidos)
- TestAgentConfigParseFull: config completo con todas las secciones activas
incluyendo personality.communication, tools, security, storage, memory y skills
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Elimina 14 structs nunca referenciados en el codebase:
- ObservabilityCfg y sub-structs (LoggingCfg, MetricsCfg, HealthCfg, TracingCfg)
- ResilienceCfg y sub-structs (CircuitBreakerCfg, RetryCfg, ShutdownCfg, QueueCfg)
- AgentsCfg y sub-structs (PeerCfg, DelegationCfg, ProtocolCfg)
Se eliminan los campos Agents, Observability y Resilience del AgentConfig root.
CommunicationCfg se mantiene porque esta activamente usada por pkg/personality/
y agents/commands.go.
schema.go pasa de 561 lineas / 61 structs a 460 lineas / 47 structs.
El template _template/config.yaml se reduce de 414 a ~220 lineas.
Los configs de assistant-bot y asistente-2 se limpian de secciones muertas.
yaml.v3 ignora campos extra, asi que YAMLs antiguos siguen parseando sin error.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- new-agent.sh: reemplaza edicion del rulesRegistry map con insercion
de un blank import simple. Ahora tambien sustituye AGENT_ID_PLACEHOLDER
en agent.go con el ID real del agente.
- create_agent.md: actualiza template de agent.go con patron init() +
agents.Register(), secciones de registro en launcher y checklist.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Expande el paquete tools/file/ con 4 operaciones nuevas para que los agentes
puedan interactuar con carpetas de trabajo (workspaces, outputs).
Cambios:
- Extraer validatePath() y resolveReal() a validate.go para reutilizarlos
- Agregar validateWritePath() que verifica ReadOnly == false
- write_file: crea/sobreescribe archivos, crea dirs padre, limite 1MB
- list_directory: lista archivos con metadata, modo recursivo, limite 500 entries
- append_file: agrega contenido al final, crea si no existe, limite 10MB total
- delete_file: borra solo archivos (nunca directorios), previene rm -rf accidental
- Registrar las 4 tools nuevas en runtime.go condicionalmente:
- list_directory: siempre (no requiere escritura)
- write/append/delete: solo si ReadOnly == false
Seguridad: todas las tools reutilizan validatePath() con deny-by-default,
resolucion de symlinks y proteccion contra path traversal.
Introduce un registro global de reglas en agents/registry.go con
Register() y GetRules(). Cada paquete de agente se auto-registra
via init(), eliminando la necesidad de editar manualmente el map
rulesRegistry en cmd/launcher/main.go.
Cambios:
- agents/registry.go: nuevo registro global con sync.RWMutex
- agents/*/agent.go: cada agente llama agents.Register() en init()
- agents/_template/agent.go: placeholder AGENT_ID_PLACEHOLDER para scaffold
- cmd/launcher/main.go: elimina rulesRegistry, usa blank imports +
agents.GetRules() para obtener reglas por agent ID
Patron: init() + blank import (estandar Go: database/sql, image codecs)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
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.
egutierrez