theus-cli-darwin-x64 0.2.84

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

@@ -0,0 +1,51 @@
+---
+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

@@ -0,0 +1,159 @@
+---
+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

@@ -0,0 +1,123 @@
+---
+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

@@ -0,0 +1,142 @@
+---
+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

@@ -0,0 +1,110 @@
+---
+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"