theus-cli-linux-arm64 1.2.2 → 1.3.0

package/vendor/theus-arsenal/skills/consejo/SKILL.md

@@ -1,201 +0,0 @@
----
-name: consejo
-description: Convoca un consejo de cuatro voces para decisiones ambiguas, trade-offs y llamadas de avanzar/no avanzar. Úsalo cuando existen varios caminos válidos y necesitas desacuerdo estructurado antes de elegir.
----
-
-# Consejo
-
-Convoca cuatro asesores para decisiones ambiguas:
-- la voz Arquitecto en contexto (el agente principal de la conversación)
-- un subagente Escéptico
-- un subagente Pragmático
-- un subagente Crítico
-
-Esto es para **tomar decisiones bajo ambigüedad**, no para revisión de código, planificación de implementación ni diseño de arquitectura.
-
-## Cuándo usarlo
-
-Usa el consejo cuando:
-- una decisión tiene varios caminos creíbles y ningún ganador obvio
-- necesitas hacer explícitos los trade-offs
-- el usuario pide segundas opiniones, disenso o múltiples perspectivas
-- el anclaje conversacional es un riesgo real
-- una llamada de avanzar / no avanzar se beneficiaría de un desafío adversarial
-
-Ejemplos:
-- monorepo vs polyrepo
-- publicar ahora vs esperar para pulir
-- feature flag vs despliegue completo
-- simplificar el alcance vs mantener amplitud estratégica
-
-## Cuándo NO usarlo
-
-| En lugar del consejo | Usa |
-| --- | --- |
-| Verificar si un resultado es correcto | `bucle-verificacion` |
-| Descomponer una funcionalidad en pasos de implementación | agente `planificador` |
-| Diseñar la arquitectura del sistema | agente `arquitecto-codigo` |
-| Revisar código en busca de bugs o problemas de seguridad | agente `revisor-codigo` o `bucle-verificacion` |
-| Preguntas factuales directas | responde directamente |
-| Tareas de ejecución obvias | simplemente haz la tarea |
-
-## Roles
-
-| Voz | Lente |
-| --- | --- |
-| Arquitecto | corrección, mantenibilidad, implicaciones a largo plazo |
-| Escéptico | cuestionar la premisa, simplificación, romper supuestos |
-| Pragmático | velocidad de entrega, impacto en el usuario, realidad operativa |
-| Crítico | casos límite, riesgo a la baja, modos de fallo |
-
-Las tres voces externas deben lanzarse como subagentes frescos con **solo la pregunta y el contexto relevante**, no con toda la conversación en curso. Ese es el mecanismo anti-anclaje.
-
-## Flujo de trabajo
-
-### 1. Extrae la pregunta real
-
-Reduce la decisión a un enunciado explícito:
-- ¿qué estamos decidiendo?
-- ¿qué restricciones importan?
-- ¿qué cuenta como éxito?
-
-Si la pregunta es vaga, haz una pregunta aclaratoria antes de convocar al consejo.
-
-### 2. Reúne solo el contexto necesario
-
-Si la decisión es específica del código:
-- recopila los archivos, fragmentos, texto de issues o métricas relevantes
-- mantenlo compacto
-- incluye solo el contexto necesario para tomar la decisión
-
-Si la decisión es estratégica/general:
-- omite fragmentos del repositorio salvo que cambien materialmente la respuesta
-
-### 3. Forma primero la posición del Arquitecto
-
-Antes de leer a las otras voces, escribe:
-- tu posición inicial
-- las tres razones más fuertes a su favor
-- el riesgo principal de tu camino preferido
-
-Hazlo primero para que la síntesis no se limite a reflejar las voces externas.
-
-### 4. Lanza tres voces independientes en paralelo
-
-Cada subagente recibe:
-- la pregunta de decisión
-- contexto compacto si hace falta
-- un rol estricto
-- nada de historial de conversación innecesario
-
-Forma del prompt:
-
-```text
-Eres el [ROL] en un consejo de decisión de cuatro voces.
-
-Pregunta:
-[pregunta de decisión]
-
-Contexto:
-[solo los fragmentos o restricciones relevantes]
-
-Responde con:
-1. Posición — 1-2 frases
-2. Razonamiento — 3 viñetas concisas
-3. Riesgo — el mayor riesgo de tu recomendación
-4. Sorpresa — una cosa que las otras voces podrían pasar por alto
-
-Sé directo. Sin rodeos. Máximo 300 palabras.
-```
-
-Énfasis por rol:
-- Escéptico: desafía el encuadre, cuestiona los supuestos, propone la alternativa creíble más simple
-- Pragmático: optimiza velocidad, simplicidad y ejecución en el mundo real
-- Crítico: hace visibles el riesgo a la baja, los casos límite y las razones por las que el plan podría fallar
-
-### 5. Sintetiza con salvaguardas contra el sesgo
-
-Eres a la vez participante y sintetizador, así que aplica estas reglas:
-- no descartes una visión externa sin explicar por qué
-- si una voz externa cambió tu recomendación, dilo explícitamente
-- incluye siempre el disenso más fuerte, aunque lo rechaces
-- si dos voces se alinean contra tu posición inicial, trátalo como una señal real
-- mantén visibles las posiciones en crudo antes del veredicto
-
-### 6. Presenta un veredicto compacto
-
-Usa esta forma de salida:
-
-```markdown
-## Consejo: [título breve de la decisión]
-
-**Arquitecto:** [posición en 1-2 frases]
-[1 línea sobre el porqué]
-
-**Escéptico:** [posición en 1-2 frases]
-[1 línea sobre el porqué]
-
-**Pragmático:** [posición en 1-2 frases]
-[1 línea sobre el porqué]
-
-**Crítico:** [posición en 1-2 frases]
-[1 línea sobre el porqué]
-
-### Veredicto
-- **Consenso:** [dónde coinciden]
-- **Disenso más fuerte:** [el desacuerdo más importante]
-- **Chequeo de premisa:** [¿el Escéptico cuestionó la pregunta misma?]
-- **Recomendación:** [el camino sintetizado]
-```
-
-Que sea escaneable en la pantalla de un teléfono.
-
-## Regla de persistencia
-
-**No** escribas notas ad hoc en `~/.theus/notes` ni en otras rutas paralelas desde esta skill.
-
-Si el consejo cambia materialmente la recomendación:
-- usa `/guardar-sesion` si el resultado pertenece a la memoria de sesión
-- o usa la skill `decisiones-arquitectura` si la decisión merece un registro formal (ADR)
-- o actualiza directamente el issue relevante de GitHub / Linear si la decisión cambia la verdad de la ejecución activa
-
-Persiste una decisión solo cuando cambia algo real.
-
-## Seguimiento multi-ronda
-
-Por defecto es una sola ronda.
-
-Si el usuario quiere otra ronda:
-- mantén la nueva pregunta enfocada
-- incluye el veredicto anterior solo si es necesario
-- mantén al Escéptico lo más limpio posible para preservar el valor anti-anclaje
-
-## Antipatrones
-
-- usar el consejo para revisión de código
-- usar el consejo cuando la tarea es simplemente trabajo de implementación
-- alimentar a los subagentes con la transcripción completa de la conversación
-- esconder el desacuerdo en el veredicto final
-- persistir cada decisión como nota sin importar su relevancia
-
-## Skills relacionadas
-
-- `bucle-verificacion` — verificación adversarial
-- `buscar-primero` — reunir material de referencia externo antes del consejo si hace falta
-- `decisiones-arquitectura` — formaliza el resultado cuando la decisión se convierte en política de sistema de largo plazo
-
-## Ejemplo
-
-Pregunta:
-
-```text
-¿Publicamos la versión 2.0 de Theus como alfa ahora, o esperamos hasta que la UI del plano de control esté más completa?
-```
-
-Forma probable del consejo:
-- El Arquitecto empuja por integridad estructural y por evitar una superficie confusa
-- El Escéptico cuestiona si la UI es realmente el factor bloqueante
-- El Pragmático pregunta qué se puede publicar ahora sin dañar la confianza
-- El Crítico se enfoca en la carga de soporte, la deuda de expectativas y la confusión del despliegue
-
-El valor no es la unanimidad. El valor es hacer legible el desacuerdo antes de elegir.

package/vendor/theus-arsenal/skills/construccion-harness-agentes/SKILL.md

@@ -1,78 +0,0 @@
----
-name: construccion-harness-agentes
-description: Diseña y optimiza espacios de acción de agentes de IA, definiciones de tools y formato
-  de observaciones para elevar la tasa de tareas completadas.
----
-
-# Construcción de harness de agentes
-
-Usa esta skill cuando estés mejorando cómo un agente planifica, llama a tools, se recupera de errores y converge hacia la finalización.
-
-## Modelo base
-
-La calidad de la salida de un agente está limitada por:
-1. Calidad del espacio de acción
-2. Calidad de las observaciones
-3. Calidad de la recuperación
-4. Calidad del presupuesto de contexto
-
-## Diseño del espacio de acción
-
-1. Usa nombres de tools estables y explícitos.
-2. Mantén las entradas schema-first y acotadas.
-3. Devuelve formas de salida deterministas.
-4. Evita tools "para todo" salvo que el aislamiento sea imposible.
-
-## Reglas de granularidad
-
-- Usa micro-tools para operaciones de alto riesgo (deploy, migraciones, permisos).
-- Usa tools medianas para los bucles comunes de edición/lectura/búsqueda.
-- Usa macro-tools solo cuando el costo dominante sea el ida-y-vuelta.
-
-## Diseño de observaciones
-
-Toda respuesta de tool debe incluir:
-- `status`: success|warning|error
-- `summary`: resultado en una línea
-- `next_actions`: siguientes pasos accionables
-- `artifacts`: rutas de archivos / IDs
-
-## Contrato de recuperación de errores
-
-Para cada ruta de error, incluye:
-- pista de causa raíz
-- instrucción de reintento seguro
-- condición de parada explícita
-
-## Presupuesto de contexto
-
-1. Mantén el prompt de sistema mínimo e invariante.
-2. Mueve las guías extensas a skills cargadas bajo demanda.
-3. Prefiere referencias a archivos en lugar de incrustar documentos largos.
-4. Compacta en los límites de fase, no en umbrales de tokens arbitrarios.
-
-## Guía de patrones de arquitectura
-
-- ReAct: mejor para tareas exploratorias con ruta incierta.
-- Function-calling: mejor para flujos estructurados y deterministas.
-- Híbrido (recomendado): planificación ReAct + ejecución de tools tipada.
-
-## Benchmarking
-
-Mide:
-- tasa de finalización
-- reintentos por tarea
-- pass@1 y pass@3
-- costo por tarea exitosa
-
-## Antipatrones
-
-- Demasiadas tools con semántica solapada.
-- Salida de tools opaca sin pistas de recuperación.
-- Salida solo-error sin siguientes pasos.
-- Sobrecarga de contexto con referencias irrelevantes.
-
-## Skills relacionadas
-
-- `auditoria-arquitectura-agentes` — Diagnosticar un sistema de agentes existente
-- `harness-agente-autonomo` — Operar agentes autónomos de larga duración

package/vendor/theus-arsenal/skills/constructor-conectores/SKILL.md

@@ -1,119 +0,0 @@
----
-name: constructor-conectores
-description: Construye un nuevo conector o provider de API replicando exactamente el patrón de integración existente del repositorio destino. Úsala al añadir una integración más sin inventar una segunda arquitectura.
-version: "1.0.0"
----
-
-# Constructor de conectores de API
-
-Usa esta skill cuando el trabajo sea añadir una superficie de integración nativa del repositorio, no solo un cliente HTTP genérico.
-
-La clave es replicar el patrón del repositorio anfitrión:
-
-- estructura del conector
-- esquema de configuración
-- modelo de autenticación
-- manejo de errores
-- estilo de tests
-- cableado de registro/descubrimiento
-
-## Cuándo usarla
-
-- "Construye un conector de Jira para este proyecto"
-- "Añade un provider de Slack siguiendo el patrón existente"
-- "Crea una nueva integración para esta API"
-- "Construye un plugin que siga el estilo de conectores del repositorio"
-
-## Barandillas
-
-- no inventes una nueva arquitectura de integración cuando el repositorio ya tiene una
-- no partas solo de la documentación del proveedor; parte primero de los conectores existentes en el repositorio
-- no te quedes en el código de transporte si el repositorio espera cableado de registro, tests y documentación
-- no imites a ciegas conectores antiguos si el repositorio tiene un patrón actual más reciente
-
-## Flujo de trabajo
-
-### 1. Aprende el estilo de la casa
-
-Inspecciona al menos 2 conectores/providers existentes y mapea:
-
-- estructura de archivos
-- fronteras de abstracción
-- modelo de configuración
-- convenciones de reintentos / paginación
-- hooks de registro
-- fixtures de tests y su nomenclatura
-
-### 2. Acota la integración objetivo
-
-Define solo la superficie que el repositorio realmente necesita:
-
-- flujo de autenticación
-- entidades clave
-- operaciones centrales de lectura/escritura
-- paginación y límites de tasa
-- modelo de webhook o polling
-
-### 3. Construye en capas nativas del repositorio
-
-Cortes típicos:
-
-- configuración/esquema
-- cliente/transporte
-- capa de mapeo
-- punto de entrada del conector/provider
-- registro
-- tests
-
-### 4. Valida contra el patrón de referencia
-
-El nuevo conector debe verse natural en el código base, no como importado de otro ecosistema.
-
-## Formas de referencia
-
-### Estilo provider
-
-```text
-providers/
-  existing_provider/
-    __init__.py
-    provider.py
-    config.py
-```
-
-### Estilo conector
-
-```text
-integrations/
-  existing/
-    client.py
-    models.py
-    connector.py
-```
-
-### Estilo plugin de TypeScript
-
-```text
-src/integrations/
-  existing/
-    index.ts
-    client.ts
-    types.ts
-    test.ts
-```
-
-## Lista de verificación de calidad
-
-- [ ] replica un patrón de integración ya existente en el repositorio
-- [ ] existe validación de configuración
-- [ ] la autenticación y el manejo de errores son explícitos
-- [ ] el comportamiento de paginación/reintentos sigue las normas del repositorio
-- [ ] el cableado de registro/descubrimiento está completo
-- [ ] los tests siguen el estilo del repositorio anfitrión
-- [ ] la documentación/ejemplos se actualizan si el repositorio lo espera
-
-## Skills relacionadas
-
-- `patrones-backend`
-- `patrones-mcp`
-- `operaciones-github`

package/vendor/theus-arsenal/skills/constructor-equipos/SKILL.md

@@ -1,169 +0,0 @@
----
-name: constructor-equipos
-description: Menú interactivo para explorar los agentes disponibles, componer un equipo ad-hoc
-  (máx. 5) y despacharlos en paralelo sobre una tarea, con síntesis final de resultados.
----
-
-# Constructor de equipos
-
-Menú interactivo para explorar y componer equipos de agentes bajo demanda. Funciona con colecciones de agentes planas o con subdirectorios por dominio.
-
-## Cuándo usarla
-
-- Tienes múltiples personas de agente (archivos markdown) y quieres elegir cuáles usar para una tarea.
-- Quieres componer un equipo ad-hoc de dominios distintos (p. ej., Seguridad + SEO + Arquitectura).
-- Quieres ver qué agentes hay disponibles antes de decidir.
-
-## Prerrequisitos
-
-Los archivos de agente deben ser markdown con un prompt de persona (identidad, reglas, flujo de trabajo, entregables). El primer `# Encabezado` se usa como nombre del agente y el primer párrafo como descripción.
-
-Se soportan tanto el layout plano como el de subdirectorios:
-
-**Layout con subdirectorios** — el dominio se infiere del nombre de la carpeta:
-
-```
-agents/
-├── ingenieria/
-│   ├── ingeniero-seguridad.md
-│   └── arquitecto-software.md
-├── marketing/
-│   └── especialista-seo.md
-└── ventas/
-    └── coach-descubrimiento.md
-```
-
-**Layout plano** — el dominio se infiere de prefijos compartidos en los nombres de archivo. Un prefijo cuenta como dominio cuando 2+ archivos lo comparten. Los archivos con prefijos únicos van a "General". Nota: el algoritmo corta en el primer `-`, así que los dominios de varias palabras (p. ej., `gestion-producto`) deben usar el layout de subdirectorios:
-
-```
-agents/
-├── ingenieria-ingeniero-seguridad.md
-├── ingenieria-arquitecto-software.md
-├── marketing-especialista-seo.md
-├── marketing-estratega-contenido.md
-├── ventas-coach-descubrimiento.md
-└── ventas-estratega-outbound.md
-```
-
-## Configuración
-
-Los agentes se descubren leyendo archivos markdown de estas ubicaciones, fusionados y deduplicados por nombre de agente:
-
-1. `./agents/**/*.md` + `./agents/*.md` — agentes locales del proyecto.
-2. `~/.theus/agents/**/*.md` + `~/.theus/agents/*.md` — agentes globales del usuario.
-3. Los agentes de plugins instalados (p. ej., el directorio `agents/` de theus-arsenal: `revisor-seguridad`, `especialista-seo`, `arquitecto-codigo`, ...) — usa el nombre del plugin como dominio.
-
-Cuando los nombres colisionan, las fuentes anteriores tienen precedencia: agentes del usuario > agentes de plugins. Si el usuario especifica una ruta propia, úsala en su lugar.
-
-## Cómo funciona
-
-### Paso 1: descubre los agentes disponibles
-
-Recorre las ubicaciones de configuración y construye la lista completa. Para cada agente markdown:
-
-- **Layout con subdirectorios**: extrae el dominio del nombre de la carpeta padre.
-- **Layout plano**: recopila los prefijos de los nombres de archivo (texto antes del primer `-`). Un prefijo califica como dominio solo si aparece en 2 o más archivos (p. ej., `ingenieria-ingeniero-seguridad.md` e `ingenieria-arquitecto-software.md` empiezan ambos con `ingenieria` → dominio Ingeniería). Los archivos con prefijos únicos (p. ej., `revisor-codigo.md`, `guia-tdd.md`) se agrupan en "General".
-- Extrae el nombre del agente del primer `# Encabezado`. Si no hay encabezado, deriva el nombre del archivo (quita `.md`, reemplaza guiones por espacios, capitaliza).
-- Extrae un resumen de una línea del primer párrafo tras el encabezado (o del `description` del frontmatter si existe).
-- Los agentes integrados del CLI (exploración, planificación) se omiten salvo que el usuario pida incluirlos explícitamente.
-
-Si tras sondear todas las ubicaciones no se encuentra ningún agente, informa al usuario: "No se encontraron agentes. Verifica que existan archivos markdown de agente en ./agents/ o ~/.theus/agents/." Y detente.
-
-### Paso 2: presenta el menú de dominios
-
-```
-Dominios de agentes disponibles:
-1. Ingeniería — Arquitecto de Software, Ingeniero de Seguridad
-2. Marketing — Especialista SEO
-3. Ventas — Coach de Descubrimiento
-
-Elige dominios o nombra agentes concretos (p. ej., "1,3" o "seguridad + seo"):
-```
-
-- Omite los dominios con cero agentes (directorios vacíos).
-- Muestra el número de agentes por dominio.
-
-### Paso 3: gestiona la selección
-
-Acepta entradas flexibles:
-- Números: "1,3" selecciona todos los agentes de Ingeniería y Ventas.
-- Nombres: "seguridad + seo" hace coincidencia difusa contra los agentes descubiertos.
-- "todos los de ingeniería" selecciona cada agente de ese dominio.
-
-Si se seleccionan más de 5 agentes, lístalos alfabéticamente y pide acotar: "Seleccionaste N agentes (máx. 5). Elige cuáles conservar, o di 'los primeros 5' para usar los cinco primeros por orden alfabético."
-
-Confirma la selección:
-```
-Seleccionados: Ingeniero de Seguridad + Especialista SEO
-¿En qué deben trabajar? (describe la tarea):
-```
-
-### Paso 4: lanza los agentes en paralelo
-
-1. Lee el archivo markdown de cada agente seleccionado.
-2. Pide la descripción de la tarea si aún no la tienes.
-3. Lanza todos los agentes en paralelo con la herramienta Agent:
-   - `subagent_type: "general-purpose"`
-   - `prompt: "{contenido del archivo del agente}\n\nTarea: {descripción de la tarea}"`
-   - Cada agente corre de forma independiente — no hace falta comunicación entre agentes.
-4. Si un agente falla (error, timeout o salida vacía), anota el fallo inline (p. ej., "Ingeniero de Seguridad: falló — [motivo]") y continúa con los resultados de los agentes que sí terminaron.
-
-### Paso 5: sintetiza los resultados
-
-Reúne todas las salidas y presenta un informe unificado:
-- Resultados agrupados por agente.
-- Sección de síntesis destacando:
-  - Acuerdos entre agentes.
-  - Conflictos o tensiones entre recomendaciones.
-  - Próximos pasos recomendados.
-
-Si solo se seleccionó 1 agente, omite la síntesis y presenta su salida directamente.
-
-## Reglas
-
-- **Descubrimiento dinámico siempre.** Nunca hardcodees listas de agentes. Los archivos nuevos del directorio aparecen solos en el menú.
-- **Máximo 5 agentes por equipo.** Más de 5 produce rendimientos decrecientes y consumo excesivo de tokens. Aplícalo en el momento de la selección.
-- **Despacho en paralelo.** Todos los agentes corren simultáneamente — usa el patrón de invocación paralela de la herramienta Agent.
-- **Llamadas paralelas independientes, no diálogo.** Esta skill usa llamadas paralelas a la herramienta Agent para trabajo independiente. Los mecanismos de diálogo multiagente solo tienen sentido cuando los agentes deben debatir o responderse entre sí.
-
-## Ejemplos
-
-```
-Usuario: constructor de equipos
-
-Theus:
-Dominios de agentes disponibles:
-1. Ingeniería (2) — Arquitecto de Software, Ingeniero de Seguridad
-2. Marketing (1) — Especialista SEO
-3. Ventas (4) — Coach de Descubrimiento, Estratega Outbound, Estratega de Propuestas, Ingeniero de Ventas
-4. Soporte (1) — Resumen Ejecutivo
-
-Elige dominios o nombra agentes concretos:
-
-Usuario: seguridad + seo
-
-Theus:
-Seleccionados: Ingeniero de Seguridad + Especialista SEO
-¿En qué deben trabajar?
-
-Usuario: Revisar mi e-commerce en Next.js antes del lanzamiento
-
-[Ambos agentes se lanzan en paralelo, cada uno aplicando su especialidad al código]
-
-Theus:
-## Hallazgos del Ingeniero de Seguridad
-- [hallazgos...]
-
-## Hallazgos del Especialista SEO
-- [hallazgos...]
-
-## Síntesis
-Ambos agentes coinciden en: [...]
-Tensión: Seguridad recomienda un CSP que bloquea estilos inline, SEO necesita schema markup inline. Resolución: [...]
-Próximos pasos: [...]
-```
-
-## Skills relacionadas
-
-- `orquestacion-equipos-agentes`
-- `harness-agente-autonomo`

package/vendor/theus-arsenal/skills/consulta-documentacion/SKILL.md

@@ -1,92 +0,0 @@
----
-name: consulta-documentacion
-description: Consulta documentación actualizada de librerías y frameworks vía el MCP Context7
-  en lugar de depender de los datos de entrenamiento. Actívala ante preguntas de configuración,
-  referencias de API, ejemplos de código, o cuando el usuario menciona un framework (p. ej.
-  React, Next.js, Prisma).
----
-
-# Consulta de documentación (Context7)
-
-Cuando el usuario pregunte sobre librerías, frameworks o APIs, obtén documentación actual vía el MCP Context7 (tools `resolve-library-id` y `query-docs`) en lugar de confiar en los datos de entrenamiento del modelo.
-
-## Conceptos clave
-
-- **Context7**: servidor MCP que expone documentación viva; úsalo en lugar de los datos de entrenamiento para librerías y APIs.
-- **resolve-library-id**: devuelve IDs de librería compatibles con Context7 (p. ej. `/vercel/next.js`) a partir del nombre de la librería y una consulta.
-- **query-docs**: obtiene documentación y fragmentos de código para un ID de librería y una pregunta. Llama siempre primero a resolve-library-id para obtener un ID válido.
-
-## Cuándo usarla
-
-Actívala cuando el usuario:
-
-- Hace preguntas de configuración o setup (p. ej. "¿Cómo configuro el middleware de Next.js?").
-- Pide código que depende de una librería ("Escribe una consulta de Prisma para...").
-- Necesita información de API o referencia ("¿Cuáles son los métodos de auth de Supabase?").
-- Menciona frameworks o librerías concretas (React, Vue, Svelte, Express, Tailwind, Prisma, Supabase, etc.).
-
-Usa esta skill siempre que la petición dependa del comportamiento preciso y actualizado de una librería, framework o API. Aplica en cualquier entorno que tenga el MCP Context7 configurado; si Context7 no está disponible, indícalo y responde con la mejor información disponible señalando su posible desactualización.
-
-## Cómo funciona
-
-### Paso 1: resuelve el ID de la librería
-
-Llama a la tool MCP **resolve-library-id** con:
-
-- **libraryName**: el nombre de la librería o producto tomado de la pregunta del usuario (p. ej. `Next.js`, `Prisma`, `Supabase`).
-- **query**: la pregunta completa del usuario. Mejora el ranking de relevancia de los resultados.
-
-Debes obtener un ID de librería compatible con Context7 (formato `/org/proyecto` o `/org/proyecto/version`) antes de consultar la documentación. No llames a query-docs sin un ID válido salido de este paso.
-
-### Paso 2: selecciona la mejor coincidencia
-
-De los resultados de la resolución, elige uno usando:
-
-- **Coincidencia de nombre**: prefiere la coincidencia exacta o más cercana a lo que pidió el usuario.
-- **Puntuación de benchmark**: puntuaciones más altas indican mejor calidad de documentación (100 es el máximo).
-- **Reputación de la fuente**: prefiere reputación High o Medium cuando esté disponible.
-- **Versión**: si el usuario especificó una versión (p. ej. "React 19", "Next.js 15"), prefiere un ID específico de versión si aparece listado (p. ej. `/org/proyecto/v1.2.0`).
-
-### Paso 3: obtén la documentación
-
-Llama a la tool MCP **query-docs** con:
-
-- **libraryId**: el ID de Context7 seleccionado en el paso 2 (p. ej. `/vercel/next.js`).
-- **query**: la pregunta o tarea concreta del usuario. Sé específico para obtener fragmentos relevantes.
-
-Límite: no llames a query-docs (ni a resolve-library-id) más de 3 veces por pregunta. Si tras 3 llamadas la respuesta sigue sin estar clara, declara la incertidumbre y usa la mejor información disponible en lugar de adivinar.
-
-### Paso 4: usa la documentación
-
-- Responde a la pregunta del usuario con la información actual obtenida.
-- Incluye ejemplos de código relevantes de la documentación cuando ayuden.
-- Cita la librería o versión cuando sea importante (p. ej. "En Next.js 15...").
-
-## Ejemplos
-
-### Ejemplo: middleware de Next.js
-
-1. Llama a **resolve-library-id** con `libraryName: "Next.js"`, `query: "¿Cómo configuro el middleware de Next.js?"`.
-2. De los resultados, elige la mejor coincidencia (p. ej. `/vercel/next.js`) por nombre y puntuación de benchmark.
-3. Llama a **query-docs** con `libraryId: "/vercel/next.js"` y esa misma consulta.
-4. Usa los fragmentos y el texto devueltos para responder; incluye un `middleware.ts` mínimo de la documentación si es relevante.
-
-### Ejemplo: consulta de Prisma
-
-1. Llama a **resolve-library-id** con `libraryName: "Prisma"`, `query: "¿Cómo consulto con relaciones?"`.
-2. Selecciona el ID oficial de Prisma (p. ej. `/prisma/prisma`).
-3. Llama a **query-docs** con ese `libraryId` y la consulta.
-4. Devuelve el patrón de Prisma Client (p. ej. `include` o `select`) con un fragmento breve de la documentación.
-
-### Ejemplo: métodos de auth de Supabase
-
-1. Llama a **resolve-library-id** con `libraryName: "Supabase"`, `query: "¿Cuáles son los métodos de autenticación?"`.
-2. Elige el ID de la documentación de Supabase.
-3. Llama a **query-docs**; resume los métodos de auth y muestra ejemplos mínimos de la documentación obtenida.
-
-## Buenas prácticas
-
-- **Sé específico**: usa la pregunta completa del usuario como consulta siempre que sea posible, para mejorar la relevancia.
-- **Atención a las versiones**: cuando el usuario mencione versiones, usa IDs específicos de versión del paso de resolución si están disponibles.
-- **Prefiere fuentes oficiales**: ante varias coincidencias, prefiere los paquetes oficiales o principales frente a forks de la comunidad.
-- **Sin datos sensibles**: elimina claves de API, contraseñas, tokens y otros secretos de cualquier consulta enviada a Context7. Trata la pregunta del usuario como potencial portadora de secretos antes de pasarla a resolve-library-id o query-docs.