feat: skills de ejemplo y README del sistema

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.
This commit is contained in:
2026-03-08 22:13:41 +00:00
parent b68ced5c23
commit 55c907a3ac
5 changed files with 567 additions and 284 deletions
+91 -69
View File
@@ -1,89 +1,111 @@
---
name: deploy-service
description: >
Despliega un servicio en un servidor remoto via SSH. Usa esta skill cuando
el usuario pida hacer deploy, actualizar un servicio, o subir cambios a
produccion/staging. Cubre: pull de codigo, build, restart del servicio,
y verificacion post-deploy.
Deploy de un servicio via SSH a un servidor remoto. Verifica que el servicio
este corriendo, hace backup de la version anterior, actualiza el binario,
reinicia el servicio y valida que responda correctamente.
---
# Deploy de servicio via SSH
# Deploy Service Skill
Esta skill guia el proceso completo de deploy de un servicio a produccion via SSH.
## Prerequisitos
- El agente debe tener la tool `ssh_command` habilitada
- El servidor destino debe estar configurado en `ssh.allowed_targets`
- El usuario debe tener permisos de deploy (verificar roles si RBAC esta activo)
- Acceso SSH al servidor de destino
- El servicio debe estar configurado como systemd unit
- El binario compilado debe estar disponible localmente o via URL
## Flujo
## Proceso de deploy
### 1. Confirmar parametros
### 1. Verificar estado del servicio
Antes de ejecutar, confirmar con el usuario:
- **Servicio**: nombre del servicio a desplegar
- **Servidor**: host destino (debe estar en allowed_targets)
- **Branch/tag**: rama o tag a desplegar (default: main)
- **Ruta**: directorio del servicio en el servidor
### 2. Pre-checks
Ejecutar en el servidor remoto:
```bash
# Verificar conectividad
ssh_command: "echo 'OK'" en el host destino
# Verificar que el directorio existe
ssh_command: "test -d /path/to/service && echo 'exists'"
# Verificar estado actual del servicio
ssh_command: "systemctl is-active nombre-servicio || true"
```
Si algun pre-check falla, informar al usuario y no continuar.
### 3. Deploy
Ejecutar secuencialmente:
```bash
# Pull de cambios
ssh_command: "cd /path/to/service && git fetch origin && git checkout <branch> && git pull"
# Build (si aplica)
ssh_command: "cd /path/to/service && make build"
# o: "cd /path/to/service && go build -o bin/service ./cmd/..."
# o: "cd /path/to/service && docker-compose build"
# Restart del servicio
ssh_command: "sudo systemctl restart nombre-servicio"
```
### 4. Verificacion post-deploy
Usa `ssh_command` para verificar el estado actual del servicio:
```bash
# Esperar 5 segundos para que el servicio arranque
ssh_command: "sleep 5 && systemctl is-active nombre-servicio"
# Verificar logs recientes (buscar errores)
ssh_command: "journalctl -u nombre-servicio --since '1 min ago' --no-pager | tail -20"
# Health check HTTP si aplica
http_get: "http://servidor:puerto/health"
systemctl status <service-name>
```
### 5. Reportar resultado
Si el servicio no existe, pregunta al usuario si debe crearlo.
Informar al usuario:
- Estado del deploy (exitoso/fallido)
- Version desplegada (commit hash o tag)
- Estado del servicio post-deploy
- Cualquier warning en los logs
### 2. Crear backup de la version anterior
## Rollback
Si el deploy falla o el servicio no arranca:
```bash
ssh_command: "cd /path/to/service && git checkout <commit-anterior>"
ssh_command: "sudo systemctl restart nombre-servicio"
cp /path/to/service /path/to/service.backup.$(date +%Y%m%d-%H%M%S)
```
Informar al usuario que se hizo rollback y el motivo.
### 3. Detener el servicio
```bash
systemctl stop <service-name>
```
### 4. Actualizar el binario
Opciones:
- Si el binario esta local: usa `scp` o `ssh_command` con heredoc
- Si el binario esta en URL: usa `ssh_command` con `wget` o `curl`
```bash
# Ejemplo con URL
wget -O /path/to/service <binary-url>
chmod +x /path/to/service
```
### 5. Reiniciar el servicio
```bash
systemctl start <service-name>
```
### 6. Verificar que el servicio responde
Espera 5 segundos y verifica:
```bash
systemctl is-active <service-name>
```
Si el servicio expone un endpoint HTTP, usa `http_get` para verificar que responde:
```bash
curl -f http://localhost:<port>/health
```
### 7. Rollback en caso de error
Si el servicio no arranca o no responde:
1. Detener el servicio
2. Restaurar el backup
3. Reiniciar con la version anterior
4. Notificar al usuario del error
## Parametros requeridos
El usuario debe proporcionar:
- `host`: servidor de destino (ej: "prod-server-01")
- `service_name`: nombre del systemd unit (ej: "myapp.service")
- `service_path`: ruta al binario en el servidor (ej: "/usr/local/bin/myapp")
- `binary_source`: "local" o URL del binario
Parametros opcionales:
- `health_endpoint`: endpoint HTTP para verificar salud (ej: "http://localhost:8080/health")
- `post_deploy_command`: comando adicional a ejecutar despues del deploy
## Seguridad
- Valida que el host este en la allowlist de SSH del agente
- Valida que el binario tenga checksum correcto (si se proporciona)
- Nunca ejecutes comandos arbitrarios sin validar
## Ejemplo de uso
Usuario: "Haz deploy de myapp a prod-server-01"
Agente:
1. skill_search("deploy service")
2. skill_load("deploy-service")
3. Preguntar parametros faltantes
4. Ejecutar el proceso paso a paso
5. Reportar resultado