theus-cli-linux-arm64 1.2.1 → 1.3.0

package/vendor/theus-arsenal/skills/operaciones-agentes-empresariales/SKILL.md

@@ -1,51 +0,0 @@
----
-name: operaciones-agentes-empresariales
-description: Opera cargas de trabajo de agentes de larga duración con observabilidad, límites
-  de seguridad y gestión del ciclo de vida. Úsala para sistemas de agentes en la nube o en
-  ejecución continua que necesitan controles operativos más allá de una sesión del CLI.
----
-
-# Operaciones de agentes empresariales
-
-Usa esta skill para sistemas de agentes alojados en la nube o en ejecución continua que necesitan controles operativos más allá de sesiones individuales del CLI.
-
-## Dominios operativos
-
-1. Ciclo de vida del runtime (arrancar, pausar, detener, reiniciar).
-2. Observabilidad (logs, métricas, trazas).
-3. Controles de seguridad (alcances, permisos, interruptores de emergencia).
-4. Gestión del cambio (despliegue gradual, rollback, auditoría).
-
-## Controles base
-
-- Artefactos de despliegue inmutables.
-- Credenciales de mínimo privilegio.
-- Inyección de secretos a nivel de entorno.
-- Presupuestos estrictos de timeout y reintentos.
-- Registro de auditoría para acciones de alto riesgo.
-
-## Métricas a seguir
-
-- Tasa de éxito.
-- Media de reintentos por tarea.
-- Tiempo de recuperación.
-- Costo por tarea exitosa.
-- Distribución por clase de fallo.
-
-## Patrón de incidentes
-
-Cuando los fallos se disparan:
-1. Congela los despliegues nuevos.
-2. Captura trazas representativas.
-3. Aísla la ruta que falla.
-4. Aplica el parche con el cambio seguro más pequeño.
-5. Ejecuta regresión + chequeos de seguridad.
-6. Reanuda gradualmente.
-
-## Integraciones de despliegue
-
-Esta skill se complementa con:
-- Servicios systemd.
-- Gestores de procesos del ecosistema Node (u otros equivalentes de tu plataforma).
-- Orquestadores de contenedores.
-- Gates de CI/CD.

package/vendor/theus-arsenal/skills/operaciones-conocimiento/SKILL.md

@@ -1,159 +0,0 @@
----
-name: operaciones-conocimiento
-description: Gestión de bases de conocimiento — ingesta, sincronización, deduplicación y recuperación a través de múltiples capas de almacenamiento (archivos locales, memoria MCP, almacenes de datos, repos Git). Úsala cuando el usuario quiera guardar, organizar, sincronizar, deduplicar o buscar en sus sistemas de conocimiento.
----
-
-# Operaciones de conocimiento
-
-Gestiona un sistema de conocimiento multicapa para ingerir, organizar, sincronizar y recuperar conocimiento a través de varios almacenes.
-
-Prefiere el modelo de espacio de trabajo vivo:
-- el trabajo de código vive en los repos reales clonados
-- el contexto de ejecución activo vive en GitHub, Linear y archivos de contexto locales al repo
-- las notas más amplias orientadas a personas pueden vivir en una carpeta de contexto/archivo fuera del repo
-- la memoria duradera entre máquinas pertenece a la base de conocimiento, no a un espacio de trabajo sombra
-
-## Cuándo activarla
-
-- El usuario quiere guardar información en su base de conocimiento
-- Ingesta de documentos, conversaciones o datos hacia almacenamiento estructurado
-- Sincronización de conocimiento entre sistemas (archivos locales, memoria MCP, Supabase, repos Git)
-- Deduplicación u organización de conocimiento existente
-- El usuario dice "guarda esto en la KB", "sincroniza el conocimiento", "¿qué sé sobre X?", "ingiere esto", "actualiza la base de conocimiento"
-- Cualquier tarea de gestión de conocimiento que vaya más allá de un simple recuerdo de memoria
-
-## Arquitectura de conocimiento
-
-### Capa 1: verdad de ejecución activa
-- **Fuentes:** issues, PRs, discusiones y notas de versión de GitHub; issues/proyectos/documentos de Linear
-- **Úsala para:** el estado operativo actual del trabajo
-- **Regla:** si algo afecta un plan de ingeniería, roadmap, despliegue o release activo, prioriza registrarlo aquí primero
-
-### Capa 2: memoria del proyecto de Theus (acceso rápido)
-- **Ruta:** `~/.theus/projects/*/memory/`
-- **Formato:** archivos Markdown con frontmatter
-- **Tipos:** preferencias del usuario, feedback, contexto del proyecto, referencia
-- **Úsala para:** contexto de acceso rápido que persiste entre conversaciones
-- **Se carga automáticamente al inicio de la sesión**
-
-### Capa 3: servidor MCP de memoria (grafo de conocimiento estructurado)
-- **Acceso:** herramientas MCP de memoria (create_entities, create_relations, add_observations, search_nodes)
-- **Úsala para:** búsqueda semántica sobre todas las memorias almacenadas, mapeo de relaciones
-- **Persistencia entre sesiones con estructura de grafo consultable**
-- **Nota:** requiere tener configurado un servidor MCP de memoria; si no está disponible, apóyate en las capas 2 y 4
-
-### Capa 4: repo de base de conocimiento / almacén documental duradero
-- **Úsala para:** notas duraderas curadas, exportaciones de sesiones, investigación sintetizada, memoria del operador, documentos largos
-- **Regla:** es el almacén duradero preferido para contexto entre máquinas cuando el contenido no es código propiedad de un repo
-
-### Capa 5: almacén de datos externo (Supabase, PostgreSQL, etc.)
-- **Úsala para:** datos estructurados, almacenamiento de documentos grandes, búsqueda de texto completo
-- **Buena para:** documentos demasiado grandes para archivos de memoria, datos que necesitan consultas SQL
-
-### Capa 6: carpeta local de contexto/archivo
-- **Úsala para:** notas orientadas a personas, planes archivados, organización local de medios, documentos temporales que no son código
-- **Regla:** se puede escribir para almacenar información, pero no es un espacio de trabajo sombra de código
-- **No la uses para:** cambios de código activos ni verdad del repo que debería vivir upstream
-
-## Flujo de ingesta
-
-Cuando haya que capturar conocimiento nuevo:
-
-### 1. Clasifica
-¿Qué tipo de conocimiento es?
-- Decisión de negocio -> archivo de memoria (tipo proyecto) + memoria MCP
-- Roadmap / release / estado de implementación activo -> GitHub + Linear primero
-- Preferencia personal -> archivo de memoria (tipo usuario/feedback)
-- Información de referencia -> archivo de memoria (tipo referencia) + memoria MCP
-- Documento grande -> almacén de datos externo + resumen en memoria
-- Conversación/sesión -> repo de base de conocimiento + resumen breve en memoria
-
-### 2. Deduplica
-Comprueba si ese conocimiento ya existe:
-- Busca entradas existentes en los archivos de memoria
-- Consulta la memoria MCP con los términos relevantes
-- Verifica si la información ya existe en GitHub o Linear antes de crear otra nota local
-- No crees duplicados. Actualiza las entradas existentes en su lugar.
-
-### 3. Almacena
-Escribe en la(s) capa(s) adecuada(s):
-- Actualiza siempre la memoria del proyecto para acceso rápido
-- Usa la memoria MCP para búsqueda semántica y mapeo de relaciones
-- Actualiza GitHub / Linear primero cuando la información cambie la verdad viva del proyecto
-- Haz commit al repo de base de conocimiento para adiciones duraderas de formato largo
-
-### 4. Indexa
-Actualiza los índices o archivos de resumen relevantes.
-
-## Operaciones de sincronización
-
-### Sincronización de conversaciones
-Sincroniza periódicamente el historial de conversaciones hacia la base de conocimiento:
-- Fuentes: archivos de sesión del CLI y sesiones de otros agentes
-- Destino: repo de base de conocimiento
-- Genera un índice de sesiones para navegación rápida
-- Haz commit y push
-
-### Sincronización del estado del espacio de trabajo
-Refleja configuración y scripts importantes del espacio de trabajo hacia la base de conocimiento:
-- Genera mapas de directorios
-- Redacta la configuración sensible antes de hacer commit
-- Rastrea los cambios en el tiempo
-- No trates la base de conocimiento ni la carpeta de archivo como el espacio de trabajo de código vivo
-
-### Sincronización con GitHub / Linear
-Cuando la información afecta la ejecución activa:
-- actualiza el issue, PR, discusión, nota de versión o hilo de roadmap correspondiente en GitHub
-- adjunta documentos de soporte en Linear cuando el trabajo necesite contexto de planificación duradero
-- solo refleja una nota local después, si aún aporta valor
-
-### Sincronización de conocimiento multi-fuente
-Reúne conocimiento de varias fuentes en un solo lugar:
-- Exportaciones de conversaciones de distintos asistentes y agentes
-- Marcadores del navegador
-- Eventos de actividad de GitHub
-- Escribe un resumen de estado, haz commit y push
-
-## Patrones de memoria
-
-```
-# Corto plazo: contexto de la sesión actual
-Usa TodoWrite para el seguimiento de tareas dentro de la sesión
-
-# Medio plazo: archivos de memoria del proyecto
-Escribe en ~/.theus/projects/*/memory/ para recuerdo entre sesiones
-
-# Largo plazo: GitHub / Linear / KB
-Pon la verdad de ejecución activa en GitHub + Linear
-Pon el contexto sintetizado duradero en el repo de base de conocimiento
-
-# Capa semántica: grafo de conocimiento MCP
-Usa mcp__memory__create_entities para datos estructurados permanentes
-Usa mcp__memory__create_relations para mapeo de relaciones
-Usa mcp__memory__add_observations para hechos nuevos sobre entidades conocidas
-Usa mcp__memory__search_nodes para encontrar conocimiento existente
-```
-
-## Buenas prácticas
-
-- Mantén los archivos de memoria concisos. Archiva los datos antiguos en lugar de dejar que los archivos crezcan sin límite.
-- Usa frontmatter (YAML) para los metadatos en todos los archivos de conocimiento.
-- Deduplica antes de almacenar. Busca primero, luego crea o actualiza.
-- Prefiere un único hogar canónico por conjunto de hechos. Evita copias paralelas del mismo plan entre notas locales, archivos de repo y documentos de trackers.
-- Redacta la información sensible (claves de API, contraseñas) antes de hacer commit a Git.
-- Usa convenciones de nombres consistentes para los archivos de conocimiento (minúsculas-con-guiones).
-- Etiqueta las entradas con temas/categorías para facilitar la recuperación.
-
-## Puerta de calidad
-
-Antes de dar por completada cualquier operación de conocimiento:
-- no se crearon entradas duplicadas
-- los datos sensibles fueron redactados de los archivos rastreados por Git
-- los índices y resúmenes están actualizados
-- se eligió la capa de almacenamiento apropiada para el tipo de dato
-- se añadieron referencias cruzadas donde corresponda
-
-## Skills relacionadas
-
-- `operaciones-github`
-- `operaciones-investigacion`

package/vendor/theus-arsenal/skills/operaciones-correo/SKILL.md

@@ -1,123 +0,0 @@
----
-name: operaciones-correo
-description: Triaje de buzón basado en evidencia, redacción, verificación de envío y flujo de
-  seguimiento seguro sobre la carpeta Enviados. Úsala cuando el usuario quiera organizar su
-  correo, redactar o enviar a través de la superficie de correo real, o probar qué quedó en
-  Enviados.
----
-
-# Operaciones de correo
-
-Usa esta skill cuando la tarea real sea trabajo de buzón: triaje, redacción, respuesta, envío, o demostrar que un mensaje quedó en Enviados.
-
-No es una skill genérica de escritura. Es un flujo de operador sobre la superficie de correo real.
-
-## Skills complementarias
-
-Incorpora estas skills del arsenal al flujo cuando sean relevantes:
-
-- `voz-de-marca` antes de redactar cualquier cosa de cara al usuario.
-- `contacto-inversores` para correo dirigido a inversores, socios o patrocinadores.
-- `operaciones-facturacion` cuando el hilo sea un incidente de facturación/soporte y no correspondencia genérica.
-- `operaciones-conocimiento` cuando el mensaje o hilo deba capturarse después como contexto duradero.
-- `operaciones-investigacion` cuando una respuesta dependa de datos externos frescos.
-
-## Cuándo usarla
-
-- El usuario pide triar la bandeja de entrada o archivar correo de bajo valor.
-- El usuario quiere un borrador, una respuesta o un correo saliente nuevo.
-- El usuario quiere saber si un correo ya fue enviado.
-- El usuario quiere prueba de qué cuenta, hilo o entrada de Enviados se usó.
-
-## Barandillas
-
-- Primero borrador, salvo que el usuario haya pedido claramente un envío en vivo.
-- Nunca afirmes que un mensaje fue enviado sin una confirmación real de la carpeta Enviados o del cliente de correo.
-- No cambies de cuenta remitente a la ligera; elige la cuenta que corresponda al proyecto y al destinatario.
-- No borres correo de negocio dudoso durante una limpieza.
-- Si la tarea es en realidad de mensajería directa (DM, mensajes de texto), está fuera del alcance de esta skill: decláralo y limítate al correo.
-
-## Flujo de trabajo
-
-### 1. Resuelve la superficie exacta
-
-Antes de actuar, define:
-
-- qué cuenta de buzón,
-- qué hilo o destinatario,
-- si la tarea es triaje, borrador, respuesta o envío,
-- si el usuario quiere solo borrador o envío en vivo.
-
-### 2. Lee el hilo antes de redactar
-
-Si es una respuesta:
-
-- lee el hilo existente,
-- identifica el último contacto saliente,
-- identifica compromisos, plazos o preguntas sin responder.
-
-Si es un correo saliente nuevo:
-
-- identifica el nivel de cercanía con el destinatario,
-- selecciona el canal y la cuenta remitente correctos,
-- consulta `voz-de-marca` antes de redactar.
-
-### 3. Redacta y luego verifica
-
-Para trabajo de solo borrador:
-
-- produce el texto final,
-- indica remitente, destinatario, asunto y propósito.
-
-Para envío en vivo:
-
-- verifica primero el cuerpo final exacto,
-- envía a través de la superficie de correo elegida,
-- confirma que el mensaje quedó en Enviados o en el almacén de copias enviadas equivalente.
-
-### 4. Reporta el estado exacto
-
-Usa palabras de estado exactas:
-
-- borrador
-- pendiente de aprobación
-- enviado
-- bloqueado
-- verificación pendiente
-
-Si la superficie de envío está bloqueada, conserva el borrador y reporta el bloqueo exacto en lugar de improvisar un segundo transporte sin decirlo.
-
-## Formato de salida
-
-```text
-SUPERFICIE DE CORREO
-- cuenta
-- hilo / destinatario
-- acción solicitada
-
-BORRADOR
-- asunto
-- cuerpo
-
-ESTADO
-- borrador / enviado / bloqueado
-- prueba de Enviados cuando aplique
-
-PRÓXIMO PASO
-- enviar
-- hacer seguimiento
-- archivar / mover
-```
-
-## Errores comunes
-
-- No afirmes que el envío tuvo éxito sin comprobar la copia en Enviados.
-- No ignores el historial del hilo escribiendo una respuesta sin contexto.
-- No mezcles trabajo de buzón con flujos de mensajería directa o SMS.
-- No expongas secretos, credenciales ni metadatos de mensajes innecesarios.
-
-## Verificación
-
-- La respuesta nombra la cuenta y el hilo o destinatario.
-- Toda afirmación de envío incluye prueba de Enviados o una confirmación explícita del cliente.
-- El estado final es uno de: borrador / enviado / bloqueado / verificación pendiente.

package/vendor/theus-arsenal/skills/operaciones-facturacion/SKILL.md

@@ -1,142 +0,0 @@
----
-name: operaciones-facturacion
-description: Opera flujos de facturación de clientes reales — suscripciones, reembolsos, triaje
-  de churn, recuperación vía portal de facturación y análisis de planes — usando herramientas de
-  facturación conectadas como Stripe. Úsala cuando haya que atender a un cliente, inspeccionar el
-  estado de una suscripción o gestionar operaciones de facturación con impacto en ingresos.
----
-
-# Operaciones de facturación de clientes
-
-Usa esta skill para operaciones reales con clientes, no para diseño genérico de APIs de pago.
-
-El objetivo es ayudar al operador a responder: ¿quién es este cliente, qué pasó, cuál es la corrección más segura y qué seguimiento debemos enviar?
-
-## Cuándo usarla
-
-- Un cliente dice que la facturación está rota, quiere un reembolso o no puede cancelar.
-- Al investigar suscripciones duplicadas, cobros accidentales, renovaciones fallidas o riesgo de churn.
-- Al revisar la mezcla de planes, suscripciones activas, conversión anual vs. mensual o confusión con asientos de equipo.
-- Al crear o validar un flujo de portal de facturación.
-- Al auditar quejas de soporte que tocan suscripciones, facturas, reembolsos o métodos de pago.
-
-## Superficie de herramientas preferida
-
-- Usa primero las herramientas de facturación conectadas, como Stripe.
-- Usa correo, GitHub o gestores de incidencias solo como evidencia de apoyo.
-- Prefiere portales alojados de facturación/cliente antes que código propio de gestión de cuentas cuando la plataforma ya ofrece los controles necesarios.
-
-## Salvaguardas
-
-- Nunca expongas claves secretas, datos completos de tarjeta ni PII innecesaria del cliente en la respuesta.
-- No reembolses a ciegas; primero clasifica el caso.
-- Distingue entre:
-  - compra duplicada accidental
-  - compra deliberada multi-asiento o de equipo
-  - producto roto / valor no entregado
-  - checkout fallido o incompleto
-  - cancelación por falta de controles de autoservicio
-- Para planes anuales, planes de equipo y estados prorrateados, verifica la forma del contrato antes de actuar.
-
-## Flujo de trabajo
-
-### 1. Identifica al cliente con limpieza
-
-Parte del identificador más fuerte disponible:
-
-- correo del cliente
-- ID de cliente de Stripe
-- ID de suscripción
-- ID de factura
-- usuario de GitHub o correo de soporte si se sabe que mapea a facturación
-
-Devuelve un resumen de identidad conciso:
-
-- cliente
-- suscripciones activas
-- suscripciones canceladas
-- facturas
-- anomalías obvias, como suscripciones activas duplicadas
-
-### 2. Clasifica el caso
-
-Ubica el caso en una categoría antes de actuar:
-
-| Caso | Acción típica |
-|------|----------------|
-| Suscripción personal duplicada | cancelar los extras, considerar reembolso |
-| Intención real multi-asiento/equipo | preservar asientos, aclarar el modelo de facturación |
-| Pago fallido / checkout incompleto | recuperar vía portal o actualizar método de pago |
-| Falta de controles de autoservicio | dar portal, ruta de cancelación o acceso a facturas |
-| Fallo de producto o ruptura de confianza | reembolsar, disculparse, registrar el problema de producto |
-
-### 3. Toma primero la acción reversible más segura
-
-Orden preferido:
-
-1. restaurar la gestión de autoservicio
-2. corregir el estado de facturación duplicado o roto
-3. reembolsar solo el cargo afectado o duplicado
-4. documentar el motivo
-5. enviar un seguimiento breve al cliente
-
-Si la corrección requiere trabajo de producto, separa:
-
-- remediación del cliente ahora
-- bug de producto / brecha de flujo para el backlog
-
-### 4. Revisa brechas de producto del lado operador
-
-Si el dolor del cliente viene de una superficie de operador ausente, señálalo explícitamente. Ejemplos comunes:
-
-- no hay portal de facturación
-- no hay visibilidad de uso/límites
-- no hay explicación de plan/asientos
-- no hay flujo de cancelación
-- no hay guarda contra suscripciones duplicadas
-
-Trátalas como pendientes de producto o del sitio web, no solo como incidencias de soporte.
-
-### 5. Produce el traspaso al operador
-
-Termina con:
-
-- resumen del estado del cliente
-- acción tomada
-- impacto en ingresos
-- texto de seguimiento a enviar
-- issue de producto o backlog a crear
-
-## Formato de salida
-
-Usa esta estructura:
-
-```text
-CLIENTE
-- nombre / correo
-- identificadores de cuenta relevantes
-
-ESTADO DE FACTURACIÓN
-- suscripciones activas
-- estado de facturas o renovaciones
-- anomalías
-
-DECISIÓN
-- clasificación del caso
-- por qué esta acción es la correcta
-
-ACCIÓN TOMADA
-- reembolso / cancelación / portal / ninguna
-
-SEGUIMIENTO
-- mensaje breve al cliente
-
-BRECHA DE PRODUCTO
-- qué debería corregirse en el producto o el sitio web
-```
-
-## Ejemplos de buenas recomendaciones
-
-- "La corrección correcta es un portal de facturación, no un dashboard a medida todavía."
-- "Esto parece un checkout personal duplicado, no una compra real de asientos de equipo."
-- "Reembolsa un cargo duplicado, mantén la suscripción activa restante y convierte al cliente a facturación de organización más adelante si hace falta."

package/vendor/theus-arsenal/skills/operaciones-flujo-proyectos/SKILL.md

@@ -1,110 +0,0 @@
----
-name: operaciones-flujo-proyectos
-description: Opera el flujo de ejecución entre GitHub y Linear triando issues y pull requests, enlazando el trabajo activo y manteniendo GitHub como cara pública mientras Linear es la capa interna de ejecución. Úsala para controlar el backlog, triar PRs o coordinar GitHub con Linear.
----
-
-# Operaciones de flujo de proyectos
-
-Esta skill convierte issues de GitHub, PRs y tareas de Linear desconectados en un único flujo de ejecución.
-
-Úsala cuando el problema es de coordinación, no de código.
-
-## Cuándo usarla
-
-- Triar backlogs de PRs o issues abiertos
-- Decidir qué pertenece a Linear y qué debe permanecer solo en GitHub
-- Enlazar trabajo activo de GitHub a los carriles internos de ejecución
-- Clasificar PRs en fusionar, portar/reconstruir, cerrar o aparcar
-- Auditar si comentarios de revisión, fallos de CI o issues estancados están bloqueando la ejecución
-
-## Modelo operativo
-
-- **GitHub** es la verdad pública y de comunidad
-- **Linear** es la verdad interna de ejecución para el trabajo activo y calendarizado
-- No todo issue de GitHub necesita un issue en Linear
-- Crea o actualiza Linear solo cuando el trabajo es:
-  - activo
-  - delegado
-  - calendarizado
-  - transversal a varios equipos
-  - lo bastante importante para rastrearlo internamente
-
-## Flujo principal
-
-### 1. Lee primero la superficie pública
-
-Reúne:
-
-- estado del issue o PR en GitHub
-- autor y estado de la rama
-- comentarios de revisión
-- estado de CI
-- issues enlazados
-
-### 2. Clasifica el trabajo
-
-Cada ítem debe terminar en uno de estos estados:
-
-| Estado | Significado |
-|--------|-------------|
-| Fusionar | autocontenido, conforme a las políticas, listo |
-| Portar/Reconstruir | idea útil, pero debe reintegrarse manualmente dentro del proyecto |
-| Cerrar | dirección equivocada, estancado, inseguro o duplicado |
-| Aparcar | potencialmente útil, pero no calendarizado ahora |
-
-### 3. Decide si Linear se justifica
-
-Crea o actualiza Linear solo si:
-
-- la ejecución está activamente planificada
-- involucra varios repos o líneas de trabajo
-- el trabajo necesita responsable interno o secuenciación
-- el issue forma parte de un carril de programa mayor
-
-No espejes todo mecánicamente.
-
-### 4. Mantén los dos sistemas consistentes
-
-Cuando el trabajo está activo:
-
-- el issue/PR de GitHub debe decir públicamente qué está pasando
-- Linear debe rastrear internamente responsable, prioridad y carril de ejecución
-
-Cuando el trabajo se entrega o se rechaza:
-
-- publica la resolución pública de vuelta en GitHub
-- marca la tarea de Linear en consecuencia
-
-## Reglas de revisión
-
-- Nunca fusiones a partir del título, el resumen o la confianza; usa el diff completo
-- Las funcionalidades de origen externo deben reconstruirse dentro del proyecto cuando son valiosas pero no autocontenidas
-- CI en rojo significa clasificar y arreglar o bloquear; no finjas que está listo para fusionar
-- Si el bloqueo real es la dirección de producto, dilo en lugar de esconderte detrás de las herramientas
-
-## Formato de salida
-
-Devuelve:
-
-```text
-ESTADO PÚBLICO
-- estado del issue / PR
-- estado de CI / revisión
-
-CLASIFICACIÓN
-- fusionar / portar-reconstruir / cerrar / aparcar
-- justificación en un párrafo
-
-ACCIÓN EN LINEAR
-- crear / actualizar / no se necesita ítem en Linear
-- proyecto / carril si aplica
-
-SIGUIENTE ACCIÓN DEL OPERADOR
-- el movimiento exacto siguiente
-```
-
-## Buenos casos de uso
-
-- "Audita el backlog de PRs abiertos y dime qué fusionar y qué reconstruir"
-- "Mapea los issues de GitHub a nuestros carriles de programa de la versión actual y la siguiente"
-- "Verifica si esto necesita un issue en Linear o debe quedarse solo en GitHub"