theus-cli-linux-x64 1.2.1 → 1.3.0

package/vendor/theus-arsenal/skills/sistema-operativo-agentico/SKILL.md

@@ -1,375 +0,0 @@
----
-name: sistema-operativo-agentico
-description: Construye sistemas operativos multiagente persistentes sobre el CLI de Theus. Cubre
-  arquitectura de kernel, agentes especialistas, comandos slash, memoria basada en archivos,
-  automatización programada y gestión de estado sin bases de datos externas.
----
-
-# Sistema operativo agéntico
-
-Trata el CLI de Theus como un runtime persistente / sistema operativo en lugar de una sesión de chat. Esta skill codifica la arquitectura usada por montajes agénticos de producción: una configuración kernel que enruta tareas a agentes especialistas, memoria persistente basada en archivos, automatización programada y una capa de datos en JSON/markdown.
-
-## Cuándo activarla
-
-- Construir un flujo multiagente dentro del CLI
-- Montar automatización persistente que sobreviva reinicios de sesión
-- Crear un "OS personal" o "OS agéntico" para tareas recurrentes
-- El usuario dice "OS agéntico", "OS personal", "multiagente", "coordinador de agentes", "agente persistente"
-- Estructurar proyectos largos donde el contexto debe sobrevivir entre sesiones
-
-## Visión general de la arquitectura
-
-El OS agéntico tiene cuatro capas. Cada capa es un directorio en la raíz del proyecto.
-
-```
-raiz-del-proyecto/
-├── AGENTS.md          # Kernel: identidad, reglas de enrutamiento, registro de agentes
-├── agents/            # Definiciones de agentes especialistas (prompts en markdown)
-├── .theus/commands/   # Comandos slash: la CLI de cara al usuario
-├── scripts/           # Scripts daemon: tareas programadas o por eventos
-└── data/              # Estado: sistema de archivos JSON/markdown, sin BD externa
-```
-
-### Responsabilidades por capa
-
-| Capa | Propósito | Persistencia |
-|---|---|---|
-| Kernel (`AGENTS.md`) | Identidad, enrutamiento, políticas de modelo, registro de agentes | En git |
-| Agentes (`agents/`) | Identidades especialistas con tools y memoria acotadas | En git |
-| Comandos (`.theus/commands/`) | Comandos slash de cara al usuario (`/sync-diario`, `/prospeccion`) | En git |
-| Scripts (`scripts/`) | Daemons Python/JS disparados por cron o webhooks | En git |
-| Estado (`data/`) | Logs solo-anexar, estado de proyectos, registros de decisiones | Ignorado en git o versionado |
-
-## El kernel
-
-`AGENTS.md` es el kernel. Actúa como el COO / orquestador. El agente lo lee al inicio de la sesión y lo usa para enrutar el trabajo.
-
-### Estructura del kernel
-
-```markdown
-# AGENTS.md - Kernel del OS agéntico
-
-## Identidad
-Eres el COO de [nombre-del-proyecto]. Enrutas tareas a agentes especialistas.
-Nunca escribes código directamente. Delegas al agente correcto y sintetizas los resultados.
-
-## Registro de agentes
-
-| Agente | Rol | Disparador |
-|---|---|---|
-| @dev | Código, arquitectura, depuración | El usuario dice "construye", "arregla", "refactoriza" |
-| @redactor | Documentación, contenido, correos | El usuario dice "escribe", "redacta", "blog" |
-| @investigador | Investigación, análisis, verificación | El usuario dice "investiga", "analiza", "compara" |
-| @ops | DevOps, despliegue, infraestructura | El usuario dice "despliega", "CI", "servidor" |
-
-## Reglas de enrutamiento
-1. Analiza la solicitud del usuario en busca de palabras clave de intención
-2. Cruza con la columna de disparadores del registro de agentes
-3. Carga el archivo del agente correspondiente desde `agents/<nombre>.md`
-4. Cede la ejecución con el contexto completo
-5. Sintetiza y presenta el resultado al usuario
-
-## Políticas de modelo
-- Modelo por defecto: usa el predeterminado del repositorio o del harness.
-- Tareas @dev: prefiere un modelo de mayor razonamiento para arquitectura compleja.
-- Tareas @investigador: usa el modelo con capacidad de investigación configurado y las tools de búsqueda aprobadas.
-- Techo de costo: advierte antes de superar el umbral de gasto configurado del proyecto.
-```
-
-### Principio clave
-
-El kernel debe ser **pequeño y declarativo**. La lógica de enrutamiento vive en tablas de markdown, no en código. Esto hace al sistema inspeccionable y editable sin depurar.
-
-## Agentes especialistas
-
-Cada agente es un archivo markdown independiente en `agents/`. El agente carga el archivo relevante al enrutar una tarea.
-
-### Formato de definición de agente
-
-```markdown
-# @dev - Ingeniero de software
-
-## Identidad
-Eres un ingeniero de software senior. Escribes código limpio, probado y de calidad de producción.
-Prefieres soluciones simples. Haces preguntas aclaratorias cuando los requisitos son ambiguos.
-
-## Alcance de memoria
-- Lee `data/projects/<proyecto-actual>.md` para el contexto
-- Lee `data/decisions/` para las decisiones de arquitectura
-- Anexa logs de ejecución a `data/logs/<fecha>-@dev.md`
-
-## Acceso a tools
-- Acceso completo al sistema de archivos dentro de la raíz del proyecto
-- Operaciones git (status, diff, commit, branch)
-- Acceso al runner de tests
-- Servidores MCP según lo configurado en `.theus/mcp.json`
-
-## Restricciones
-- Escribe siempre tests para las funcionalidades nuevas
-- Nunca hagas commit directo a `main`; usa ramas de feature
-- Prefiere editar archivos existentes antes que crear nuevos
-- Mantén las funciones por debajo de 50 líneas cuando sea posible
-```
-
-### Patrón de colaboración multiagente
-
-Cuando una tarea abarca varios agentes, el kernel los ejecuta en secuencia o en paralelo:
-
-```
-Usuario: "Construye una landing page y escribe el post de lanzamiento"
-
-Enrutamiento del kernel:
-1. @dev - "Construye una landing page con [requisitos]"
-2. @redactor - "Escribe un post de lanzamiento para [producto] usando el copy de la landing"
-3. El kernel sintetiza ambas salidas en una respuesta unificada
-```
-
-Para ejecución en paralelo, usa la capacidad de tareas en segundo plano del CLI o scripts de shell que invoquen a Theus con contextos de agente específicos.
-
-## Comandos y flujos diarios
-
-Los comandos slash son archivos markdown en `.theus/commands/`. Definen flujos reutilizables.
-
-### Estructura de un comando
-
-```markdown
-# /sync-diario
-
-Ejecuta el briefing matutino:
-
-1. Lee `data/logs/last-sync.md` para el contexto
-2. Revisa el estado del proyecto: `git status`, PRs pendientes, salud del CI
-3. Revisa `data/inbox/` en busca de tareas nuevas o decisiones pendientes
-4. Genera un resumen de bloqueos, prioridades y siguientes acciones
-5. Anexa el briefing a `data/logs/daily/<fecha>.md`
-```
-
-### Conjunto estándar de comandos
-
-| Comando | Propósito |
-|---|---|
-| `/sync-diario` | Briefing matutino: estado, bloqueos, prioridades |
-| `/prospeccion` | Ejecutar el flujo de prospección (correo, LinkedIn, etc.) |
-| `/investigar <tema>` | Investigación profunda con seguimiento de citas |
-| `/postular-empleos` | Adaptar CV + carta de presentación a un rol objetivo |
-| `/analitica` | Extraer métricas de Stripe, GitHub o fuentes propias |
-| `/prep-entrevista` | Generar flashcards o preguntas de entrevista simulada |
-| `/decision <tema>` | Registrar una decisión con pros/contras y la ruta elegida |
-
-### Activación de comandos
-
-Coloca los archivos en `.theus/commands/<nombre-comando>.md`. El CLI los descubre automáticamente. Los usuarios los invocan con `/<nombre-comando>`.
-
-## Memoria persistente
-
-La memoria es basada en archivos. Sin base vectorial, sin Redis, sin PostgreSQL. Los archivos JSON y markdown en `data/` son la base de datos.
-
-### Estructura del directorio de memoria
-
-```
-data/
-├── daily-logs/         # Logs diarios de actividad, solo-anexar
-├── projects/           # Archivos de contexto por proyecto
-├── decisions/          # Decisiones de arquitectura y de negocio (formato ADR)
-├── inbox/              # Tareas o ideas nuevas a la espera de triaje
-├── contacts/           # Personas, empresas, notas de relación
-└── templates/          # Prompts y formatos reutilizables
-```
-
-### Formato del log diario
-
-```markdown
-# 2026-04-22 - Log diario
-
-## Sesiones
-- 09:00 - Sesión 1: Refactorizado el módulo de auth (@dev)
-- 11:30 - Sesión 2: Borrador de la actualización a inversores (@redactor)
-
-## Decisiones
-- Cambio de JWT a cookies de sesión (ver `data/decisions/2026-04-22-auth.md`)
-
-## Bloqueos
-- A la espera de la API key del proveedor (seguimiento 2026-04-24)
-
-## Siguientes acciones
-- [ ] Mergear el PR del refactor de auth
-- [ ] Enviar la actualización a inversores para revisión
-```
-
-### Patrón de auto-reflexión
-
-Al final de cada sesión, el kernel anexa una reflexión:
-
-```markdown
-## Reflexión - Sesión 3
-- Qué funcionó: la ejecución de agentes en paralelo ahorró 20 minutos
-- Qué no: @investigador chocó con una fuente de pago, falta mejor ranking de fuentes
-- Qué cambiar: añadir campo `source-tier` a las notas de investigación (credibilidad A/B/C)
-```
-
-Esto crea un bucle de retroalimentación que mejora el sistema con el tiempo sin cambios de código.
-
-## Automatización programada
-
-Las tareas del OS agéntico corren con un programador **externo** (cron del sistema operativo), no con temporizadores internos de la sesión del CLI, que mueren cuando la sesión termina.
-
-### macOS: LaunchAgent
-
-```xml
-<!-- ~/Library/LaunchAgents/com.agentic.sync-diario.plist -->
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" ...>
-<plist version="1.0">
-<dict>
-    <key>Label</key>
-    <string>com.agentic.sync-diario</string>
-    <key>ProgramArguments</key>
-    <array>
-        <string>/usr/local/bin/theus</string>
-        <string>--cwd</string>
-        <string>/ruta/al/proyecto</string>
-        <string>--command</string>
-        <string>/sync-diario</string>
-    </array>
-    <key>StartCalendarInterval</key>
-    <dict>
-        <key>Hour</key>
-        <integer>8</integer>
-        <key>Minute</key>
-        <integer>0</integer>
-    </dict>
-    <key>StandardOutPath</key>
-    <string>/tmp/agentic-sync-diario.log</string>
-</dict>
-</plist>
-```
-
-### Linux: temporizador systemd
-
-```ini
-# ~/.config/systemd/user/agentic-sync-diario.service
-[Unit]
-Description=Sync diario del OS agéntico
-
-[Service]
-Type=oneshot
-ExecStart=/usr/local/bin/theus --cwd /ruta/al/proyecto --command /sync-diario
-```
-
-```ini
-# ~/.config/systemd/user/agentic-sync-diario.timer
-[Unit]
-Description=Ejecutar el sync diario cada mañana
-
-[Timer]
-OnCalendar=*-*-* 8:00:00
-Persistent=true
-
-[Install]
-WantedBy=timers.target
-```
-
-En otras plataformas, cualquier programador del sistema (Programador de tareas de Windows, `crontab`) que invoque `theus --cwd <proyecto> --command /<comando>` cumple el mismo rol.
-
-## Capa de datos
-
-La capa de datos es tu sistema de archivos. Usa JSON para datos estructurados y markdown para contenido narrativo.
-
-### JSON para estado estructurado
-
-```json
-// data/projects/web-v2.json
-{
-  "name": "Web v2",
-  "status": "in-progress",
-  "milestone": "beta-launch",
-  "agents_involved": ["@dev", "@redactor"],
-  "files": {
-    "spec": "docs/web-v2-spec.md",
-    "design": "designs/web-v2.fig"
-  },
-  "metrics": {
-    "commits": 47,
-    "last_session": "2026-04-22T11:30:00Z"
-  }
-}
-```
-
-### Markdown para narrativa
-
-Usa markdown para todo lo que lee un humano: decisiones, logs, notas de investigación, fichas de contactos.
-
-### Evolución de esquemas
-
-Nunca renombres campos existentes. Añade campos nuevos y marca los viejos como deprecados:
-
-```json
-{
-  "name": "Web v2",
-  "status": "in-progress",
-  "milestone": "beta-launch",
-  "_deprecated_priority": "high",
-  "priority_v2": { "level": "high", "rationale": "Bloquea la demo a inversores" }
-}
-```
-
-Esto mantiene legible el histórico sin scripts de migración.
-
-## Antipatrones
-
-### Agente único monolítico
-
-```markdown
-# MAL - Un agente lo hace todo
-Eres desarrollador full-stack, redactor, investigador e ingeniero DevOps.
-```
-
-Divide en agentes especialistas. El kernel se encarga del enrutamiento.
-
-### Sesiones sin estado
-
-```markdown
-# MAL - Sin memoria entre sesiones
-Empezar de cero cada vez que se abre el CLI.
-```
-
-Lee siempre `data/` al inicio de la sesión y escribe de vuelta al final.
-
-### Credenciales incrustadas
-
-```markdown
-# MAL - API keys en archivos de agentes o en AGENTS.md
-La API key del proveedor es sk-xxxxxxxx
-```
-
-Usa variables de entorno o un `.env` cargado por los scripts. Los agentes referencian `process.env.API_KEY`.
-
-### Base de datos externa para estado simple
-
-```markdown
-# MAL - PostgreSQL para el OS agéntico de un solo usuario
-```
-
-Usa archivos JSON/markdown hasta que tengas múltiples usuarios concurrentes o GBs de datos.
-
-### Enrutamiento sobreingenierizado
-
-```markdown
-# MAL - Lógica de enrutamiento en código en vez de tablas markdown
-if (intent.includes('deploy')) { agent = opsAgent; }
-```
-
-Mantén el enrutamiento declarativo en tablas markdown de `AGENTS.md`. Es inspeccionable, editable y depurable.
-
-## Buenas prácticas
-
-- [ ] `AGENTS.md` tiene menos de 200 líneas y cabe en la ventana de contexto
-- [ ] Cada archivo de agente tiene menos de 100 líneas y se enfoca en un dominio
-- [ ] `data/` va ignorado en git para logs sensibles, versionado para decisiones y specs
-- [ ] Los comandos usan nombres imperativos: `/sync-diario`, no `/ejecutar-sync-diario`
-- [ ] Los logs son solo-anexar; nunca edites logs diarios pasados
-- [ ] Todo agente tiene una sección `Alcance de memoria` que define qué archivos lee
-- [ ] Las reflexiones se escriben al final de cada sesión
-- [ ] Las tareas programadas usan cron externo (LaunchAgent, systemd), no temporizadores de la sesión del CLI
-- [ ] Seguimiento de costos: registra el gasto de API por sesión en `data/logs/<fecha>-costos.json`
-- [ ] Un proyecto = un OS agéntico. No compartas un mismo `AGENTS.md` entre proyectos no relacionados.

package/vendor/theus-arsenal/skills/sistemas-latencia-critica/SKILL.md

@@ -1,65 +0,0 @@
----
-name: sistemas-latencia-critica
-description: Usa esta skill para sistemas sensibles a la latencia como dashboards en tiempo real, datos de mercado, agentes de streaming, gateways de ejecución, colas, cachés o infraestructura tipo HFT donde importan la frescura y la latencia p95.
----
-
-# Sistemas de latencia crítica
-
-Usa esta skill cuando importe el comportamiento en tiempo real, las rutas calientes, la frescura del streaming o la velocidad de ejecución. Esto incluye infraestructura tipo HFT, pero la skill tiene un enfoque de ingeniería: no autoriza trading en vivo ni asesoría financiera.
-
-## Separa las métricas
-
-No colapses todo en "rápido". Haz seguimiento de:
-
-- latencia p50, p95 y p99;
-- throughput;
-- edad de frescura de los datos;
-- profundidad de las colas;
-- tasa de aciertos de caché;
-- tiempo de respuesta de proveedores/APIs;
-- tiempo de renderizado en el navegador;
-- corrección bajo carga;
-- comportamiento ante fallos y reintentos.
-
-## Mapea la ruta caliente
-
-Escribe la ruta desde el usuario/evento hasta el estado final visible:
-
-```text
-evento origen -> API del proveedor -> worker de ingesta -> cola -> caché -> ruta edge
--> stream al cliente -> renderizado en el navegador -> estado visible para el usuario
-```
-
-Después, mide cada segmento por separado.
-
-## Orden de optimización
-
-1. Elimina los viajes de ida y vuelta innecesarios.
-2. Cachea las lecturas estables con metadatos de frescura.
-3. Agrupa (batch) las llamadas y escrituras pequeñas.
-4. Acerca el cómputo a los datos o al usuario.
-5. Separa las rutas calientes de las frías.
-6. Aplica backpressure antes de que las colas crezcan sin límite.
-7. Usa streaming solo cuando mejore la frescura o la experiencia de usuario.
-8. Añade canarios para datos obsoletos, proveedores degradados y estado de caché corrupto.
-
-## Verificación
-
-Usa lecturas en vivo cuando exista una superficie desplegada:
-
-- timing HTTP y cabeceras de respuesta;
-- timestamp de frescura del proveedor;
-- estado de las colas o los jobs;
-- estado del edge/caché;
-- verificación en el navegador para la frescura real de la UI;
-- logs alrededor de los reintentos y del modo degradado.
-
-Para rutas de datos de mercado o adyacentes a la ejecución, verifica además la edad del orderbook, los supuestos de VWAP, el estado del proveedor y el comportamiento del kill-switch antes de dar la ruta por lista.
-
-## Salvaguardas
-
-- No optimices la latencia eliminando validaciones requeridas.
-- No escondas datos obsoletos detrás de aciertos de caché rápidos.
-- No afirmes comportamiento de milisegundos a partir de etiquetas en el cliente sin medición.
-- No ejecutes órdenes en vivo, migraciones destructivas ni despliegues que impacten a clientes sin una puerta de aprobación explícita.
-- Mantén los secretos y las cargas privadas fuera de los logs y de los artefactos de benchmark.