theus-cli-darwin-x64 0.2.84

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

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

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

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

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

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