theus-cli-linux-arm64 1.2.2 → 1.3.0

package/vendor/theus-arsenal/skills/optimizador-prompts/SKILL.md

@@ -1,374 +0,0 @@
----
-name: optimizador-prompts
-description: >-
-  Analiza prompts en borrador, identifica intención y vacíos, empareja
-  componentes del arsenal (skills/comandos/agentes) y produce un prompt
-  optimizado listo para pegar. Rol únicamente asesor — nunca ejecuta la
-  tarea. ACTIVAR cuando el usuario dice "optimiza este prompt", "mejora mi
-  prompt", "cómo escribo un prompt para", "ayúdame a promptear" o "reescribe
-  este prompt". NO ACTIVAR cuando el usuario quiere que la tarea se ejecute
-  directamente, ni cuando dice "optimiza el código" u "optimiza el
-  rendimiento" — eso es refactorización/rendimiento, no optimización de
-  prompts.
----
-
-# Optimizador de prompts
-
-Analiza un prompt en borrador, critícalo, emparéjalo con los componentes del ecosistema del arsenal y produce un prompt optimizado completo que el usuario pueda pegar y ejecutar.
-
-## Cuándo usarla
-
-- El usuario dice "optimiza este prompt", "mejora mi prompt", "reescribe este prompt"
-- El usuario dice "ayúdame a escribir un mejor prompt para..."
-- El usuario dice "¿cuál es la mejor forma de pedirle al CLI que...?"
-- El usuario pega un prompt en borrador y pide feedback o mejoras
-- El usuario dice "no sé cómo promptear esto"
-- El usuario dice "¿cómo debería usar el arsenal para...?"
-
-### No usarla cuando
-
-- El usuario quiere que la tarea se haga directamente (solo ejecútala)
-- El usuario dice "optimiza el código" u "optimiza el rendimiento" — son tareas de refactorización, no de optimización de prompts
-- El usuario pregunta por la configuración del plugin (responde directamente sobre la configuración)
-- El usuario quiere un inventario de skills (usa `inventario-skills` en su lugar)
-- El usuario dice "solo hazlo"
-
-## Cómo funciona
-
-**Solo asesoría — no ejecutes la tarea del usuario.**
-
-NO escribas código, crees archivos, ejecutes comandos ni tomes ninguna acción de implementación. Tu ÚNICA salida es un análisis más un prompt optimizado.
-
-Si el usuario dice "solo hazlo" o "no optimices, ejecuta", no cambies a modo implementación dentro de esta skill. Dile que esta skill solo produce prompts optimizados e indícale que haga una petición de tarea normal si quiere ejecución.
-
-Ejecuta este pipeline de 6 fases en secuencia. Presenta los resultados con el Formato de salida de abajo.
-
-### Pipeline de análisis
-
-### Fase 0: detección del proyecto
-
-Antes de analizar el prompt, detecta el contexto del proyecto actual:
-
-1. Verifica si existe un `AGENTS.md` en el directorio de trabajo — léelo para conocer las convenciones del proyecto
-2. Detecta el stack tecnológico desde los archivos del proyecto:
-   - `package.json` → Node.js / TypeScript / React / Next.js
-   - `go.mod` → Go
-   - `pyproject.toml` / `requirements.txt` → Python
-   - `Cargo.toml` → Rust
-   - `build.gradle` / `pom.xml` → Java / Kotlin (luego busca `quarkus` en el archivo de build → Quarkus, o `spring-boot` → Spring Boot)
-   - `Package.swift` → Swift
-   - `Gemfile` → Ruby
-   - `composer.json` → PHP
-   - `*.csproj` / `*.sln` → .NET
-   - `Makefile` / `CMakeLists.txt` → C / C++
-   - `cpanfile` / `Makefile.PL` → Perl
-3. Anota el stack detectado para usarlo en las fases 3 y 4
-
-Si no se encuentran archivos de proyecto (p. ej., el prompt es abstracto o para un proyecto nuevo), omite la detección y marca "stack desconocido" en la Fase 4.
-
-### Fase 1: detección de intención
-
-Clasifica la tarea del usuario en una o más categorías:
-
-| Categoría | Palabras señal | Ejemplo |
-|-----------|----------------|---------|
-| Nueva funcionalidad | construir, crear, agregar, implementar | "Construye una página de login" |
-| Corrección de bug | arreglar, roto, no funciona, error | "Arregla el flujo de auth" |
-| Refactorización | refactorizar, limpiar, reestructurar | "Refactoriza la capa de API" |
-| Investigación | cómo, qué es, explorar, investigar | "Cómo agregar SSO" |
-| Testing | test, cobertura, verificar | "Agrega tests al carrito" |
-| Revisión | revisar, auditar, comprobar | "Revisa mi PR" |
-| Documentación | documentar, actualizar docs | "Actualiza los docs de la API" |
-| Infraestructura | desplegar, CI, docker, base de datos | "Configura el pipeline de CI/CD" |
-| Diseño | diseñar, arquitectura, plan | "Diseña el modelo de datos" |
-
-### Fase 2: evaluación de alcance
-
-Si la Fase 0 detectó un proyecto, usa el tamaño del código como señal. Si no, estima solo desde la descripción del prompt y marca la estimación como incierta.
-
-| Alcance | Heurística | Orquestación |
-|---------|------------|--------------|
-| TRIVIAL | Un archivo, < 50 líneas | Ejecución directa |
-| BAJO | Un componente o módulo | Un comando o skill |
-| MEDIO | Varios componentes, mismo dominio | Cadena de comandos + `bucle-verificacion` |
-| ALTO | Transversal a dominios, 5+ archivos | `/plan` primero, luego ejecución por fases |
-| ÉPICO | Multi-sesión, multi-PR, cambio arquitectónico | Usa la skill `plano-tecnico` para un plan multi-sesión |
-
-### Fase 3: emparejamiento con componentes del arsenal
-
-Mapea intención + alcance + stack (de la Fase 0) a componentes concretos del arsenal.
-
-#### Por tipo de intención
-
-| Intención | Comandos | Skills | Agentes |
-|-----------|----------|--------|---------|
-| Nueva funcionalidad | /plan, /revisar-codigo | flujo-tdd, bucle-verificacion | planificador, guia-tdd, revisor-codigo |
-| Corrección de bug | /arreglar-build | flujo-tdd, bucle-verificacion | guia-tdd, resolutor-builds |
-| Refactorización | /limpiar-refactor, /revisar-codigo | bucle-verificacion | limpiador-refactors, revisor-codigo |
-| Investigación | /plan | buscar-primero, recuperacion-iterativa | — |
-| Testing | /cobertura-tests | flujo-tdd, testing-e2e | guia-tdd, ejecutor-e2e |
-| Revisión | /revisar-codigo | revision-seguridad | revisor-codigo, revisor-seguridad |
-| Documentación | /actualizar-docs, /actualizar-mapas-codigo | — | actualizador-docs |
-| Infraestructura | /plan | patrones-docker, patrones-despliegue, migraciones-bd, bucle-verificacion | arquitecto-sistemas |
-| Diseño (MEDIO-ALTO) | /plan | — | planificador, arquitecto-sistemas |
-| Diseño (ÉPICO) | — | plano-tecnico (invocar como skill) | planificador, arquitecto-sistemas |
-
-#### Por stack tecnológico
-
-| Stack | Skills a añadir | Agente |
-|-------|-----------------|--------|
-| Python / Django | patrones-django, tdd-django, seguridad-django, verificacion-django, patrones-python, testing-python | revisor-python |
-| Go | patrones-go, testing-go | revisor-go, resolutor-builds-go |
-| Spring Boot / Java | patrones-springboot, tdd-springboot, seguridad-springboot, verificacion-springboot, estandares-java, patrones-jpa | revisor-java |
-| Quarkus / Java | patrones-quarkus, tdd-quarkus, seguridad-quarkus, verificacion-quarkus, estandares-java, patrones-jpa | revisor-java |
-| Kotlin / Android | corrutinas-flows-kotlin, patrones-compose-multiplatform, arquitectura-limpia-android | revisor-kotlin |
-| TypeScript / React | patrones-frontend, patrones-backend, estandares-codigo | revisor-codigo |
-| Swift / iOS | patrones-swiftui, concurrencia-swift-6-2, persistencia-actores-swift, testing-protocolos-di-swift | revisor-codigo |
-| PostgreSQL | patrones-postgres, migraciones-bd | revisor-bd |
-| Perl | patrones-perl, testing-perl, seguridad-perl | revisor-codigo |
-| C++ | estandares-cpp, testing-cpp | revisor-codigo |
-| Otro / no listado | estandares-codigo (universal) | revisor-codigo |
-
-### Fase 4: detección de contexto faltante
-
-Escanea el prompt en busca de información crítica ausente. Revisa cada ítem y marca si la Fase 0 lo autodetectó o si el usuario debe proporcionarlo:
-
-- [ ] **Stack tecnológico** — ¿detectado en la Fase 0, o debe especificarlo el usuario?
-- [ ] **Alcance objetivo** — ¿se mencionan archivos, directorios o módulos?
-- [ ] **Criterios de aceptación** — ¿cómo se sabe que la tarea terminó?
-- [ ] **Manejo de errores** — ¿se cubren casos límite y modos de fallo?
-- [ ] **Requisitos de seguridad** — ¿auth, validación de entrada, secretos?
-- [ ] **Expectativas de testing** — ¿unitario, integración, E2E?
-- [ ] **Restricciones de rendimiento** — ¿carga, latencia, límites de recursos?
-- [ ] **Requisitos de UI/UX** — ¿specs de diseño, responsive, a11y? (si es frontend)
-- [ ] **Cambios de base de datos** — ¿esquema, migraciones, índices? (si toca la capa de datos)
-- [ ] **Patrones existentes** — ¿archivos de referencia o convenciones a seguir?
-- [ ] **Límites del alcance** — ¿qué NO hacer?
-
-**Si faltan 3+ ítems críticos**, haz al usuario hasta 3 preguntas de aclaración antes de generar el prompt optimizado. Luego incorpora las respuestas al prompt.
-
-### Fase 5: recomendación de flujo y de modelo
-
-Determina en qué punto del ciclo de desarrollo está el prompt:
-
-```
-Investigar → Planificar → Implementar (TDD) → Revisar → Verificar → Commit
-```
-
-Para tareas de alcance MEDIO o superior, empieza siempre con `/plan`. Para las ÉPICAS, usa la skill `plano-tecnico`.
-
-**Recomendación de modelo** (inclúyela en la salida). Theus es multimodelo: no recomiendes marcas, recomienda el perfil de modelo y deja la elección concreta a `/enrutar-modelo`:
-
-| Alcance | Perfil de modelo recomendado | Justificación |
-|---------|------------------------------|---------------|
-| TRIVIAL-BAJO | Modelo rápido/económico | Suficiente para tareas simples, menor costo |
-| MEDIO | Modelo equilibrado de código | El mejor balance para trabajo estándar |
-| ALTO | Equilibrado (ejecución) + razonamiento profundo (planificación) | Razonamiento para la arquitectura, equilibrado para implementar |
-| ÉPICO | Razonamiento profundo (plano) + equilibrado (ejecución) | Planificación multi-sesión exige razonamiento profundo |
-
-**División multi-prompt** (para alcance ALTO/ÉPICO):
-
-Para tareas que exceden una sesión, divide en prompts secuenciales:
-- Prompt 1: investigación + plan (skill `buscar-primero`, luego `/plan`)
-- Prompts 2-N: implementar una fase por prompt (cada uno termina verificando con `bucle-verificacion`)
-- Prompt final: tests de integración + `/revisar-codigo` sobre todas las fases
-- Usa `/guardar-sesion` y `/reanudar-sesion` para preservar contexto entre sesiones
-
----
-
-## Formato de salida
-
-Presenta el análisis con esta estructura exacta. Responde en el mismo idioma que la entrada del usuario.
-
-### Sección 1: diagnóstico del prompt
-
-**Fortalezas:** lista lo que el prompt original hace bien.
-
-**Problemas:**
-
-| Problema | Impacto | Arreglo sugerido |
-|----------|---------|------------------|
-| (problema) | (consecuencia) | (cómo corregirlo) |
-
-**Necesita aclaración:** lista numerada de preguntas que el usuario debe responder. Si la Fase 0 autodetectó la respuesta, indícala en lugar de preguntar.
-
-### Sección 2: componentes del arsenal recomendados
-
-| Tipo | Componente | Propósito |
-|------|------------|-----------|
-| Comando | /plan | Planificar la arquitectura antes de codificar |
-| Skill | flujo-tdd | Guía de metodología TDD |
-| Agente | revisor-codigo | Revisión posterior a la implementación |
-| Modelo | Equilibrado de código | Recomendado para este alcance |
-
-### Sección 3: prompt optimizado — versión completa
-
-Presenta el prompt optimizado completo dentro de un solo bloque de código cercado. Debe ser autocontenido y listo para copiar y pegar. Incluye:
-- Descripción clara de la tarea con contexto
-- Stack tecnológico (detectado o especificado)
-- Invocaciones de /comandos en las etapas correctas del flujo
-- Criterios de aceptación
-- Pasos de verificación
-- Límites del alcance (qué NO hacer)
-
-Para ítems que referencien el plano técnico, escribe: "Usa la skill plano-tecnico para..." (no `/plano-tecnico`, porque es una skill, no un comando).
-
-### Sección 4: prompt optimizado — versión rápida
-
-Una versión compacta para usuarios experimentados del arsenal. Varía según la intención:
-
-| Intención | Patrón rápido |
-|-----------|---------------|
-| Nueva funcionalidad | `/plan [funcionalidad]. Implementa con la skill flujo-tdd. /revisar-codigo. Verifica con bucle-verificacion.` |
-| Corrección de bug | `Con flujo-tdd, escribe el test que falla para [bug]. Corrige hasta verde. Verifica con bucle-verificacion.` |
-| Refactorización | `/limpiar-refactor [alcance]. /revisar-codigo. Verifica con bucle-verificacion.` |
-| Investigación | `Usa la skill buscar-primero para [tema]. /plan con los hallazgos.` |
-| Testing | `Con flujo-tdd cubre [módulo]. testing-e2e para los flujos críticos. /cobertura-tests.` |
-| Revisión | `/revisar-codigo. Luego usa el agente revisor-seguridad.` |
-| Docs | `/actualizar-docs. /actualizar-mapas-codigo.` |
-| ÉPICO | `Usa la skill plano-tecnico para "[objetivo]". Ejecuta las fases con compuertas de bucle-verificacion.` |
-
-### Sección 5: justificación de las mejoras
-
-| Mejora | Razón |
-|--------|-------|
-| (qué se añadió) | (por qué importa) |
-
-### Pie
-
-> ¿No es lo que necesitas? Dime qué ajustar, o haz una petición de tarea normal si quieres ejecución en lugar de optimización del prompt.
-
----
-
-## Ejemplos
-
-### Ejemplos de activación
-
-- "Optimiza este prompt para el arsenal"
-- "Reescribe este prompt para que el CLI use los comandos correctos"
-- "Ayúdame a mejorar esta instrucción"
-- "¿Cómo debería promptear esta tarea?"
-
-### Ejemplo 1: prompt vago (proyecto detectado)
-
-**Entrada del usuario:**
-```
-Hazme una página de login de usuarios
-```
-
-**La Fase 0 detecta:** `package.json` con Next.js 15, TypeScript, Tailwind CSS
-
-**Prompt optimizado (completo):**
-```
-Implementa la página de login de usuarios con el stack existente del proyecto (Next.js 15 + TypeScript + Tailwind CSS).
-
-Requisitos técnicos:
-- Sigue la estructura de componentes y las convenciones de rutas existentes
-- Validación de formularios con la solución ya presente en el proyecto (verifica si ya se usa Zod/Yup/otra)
-- Autenticación: reutiliza el esquema de auth existente (si no hay, JWT por defecto)
-- Incluye: formulario de email/contraseña, validación, mensajes de error, estado de carga, layout responsive
-
-Flujo de trabajo:
-1. /plan para estructurar componentes y flujo de auth, tomando como referencia los patrones de páginas existentes
-2. Con la skill flujo-tdd, tests primero: unitarios del formulario e integración del flujo de auth
-3. Implementa la página y la lógica de autenticación
-4. /revisar-codigo sobre la implementación
-5. Verifica con bucle-verificacion que todos los tests pasan y la página renderiza bien
-
-Requisitos de seguridad:
-- La contraseña no viaja en claro
-- Protección contra fuerza bruta (rate limiting)
-- Protección XSS
-- Token CSRF
-
-Criterios de aceptación:
-- Todos los tests pasan, cobertura 80%+
-- La página renderiza bien en móvil y escritorio
-- Login exitoso redirige al dashboard; fallo muestra el error
-
-No hacer:
-- No implementar la página de registro
-- No implementar "olvidé mi contraseña"
-- No modificar la estructura de rutas existente
-```
-
-### Ejemplo 2: prompt intermedio
-
-**Entrada del usuario:**
-```
-Agrega un endpoint REST para actualizar perfiles de usuario con validación
-```
-
-**La Fase 0 detecta:** `go.mod` con Go 1.22, router Chi
-
-**Prompt optimizado (completo):**
-```
-Agrega un endpoint REST para actualizar perfiles de usuario (PATCH /api/users/:id).
-
-Stack: Go 1.22 + router Chi (detectado del proyecto)
-
-Requisitos:
-- PATCH /api/users/:id — actualización parcial del perfil
-- Validación de entrada para: name, email, avatar_url, bio
-- Auth: exigir token válido; cada usuario solo actualiza su propio perfil
-- Devolver 200 con el usuario actualizado en éxito
-- Devolver 400 con errores de validación ante entrada inválida
-- Devolver 401/403 en fallos de autenticación
-- Seguir los patrones de API existentes en el código
-
-Flujo de trabajo:
-1. /plan para la estructura del endpoint, la cadena de middleware y la lógica de validación
-2. Con la skill flujo-tdd, escribe tests de tabla para: éxito, fallo de validación, fallo de auth, no encontrado
-3. Implementa siguiendo los patrones de handlers existentes
-4. /revisar-go
-5. Verifica con bucle-verificacion — corre la suite completa y confirma que no hay regresiones
-
-No hacer:
-- No modificar endpoints existentes
-- No cambiar el esquema de la base de datos (usa la tabla de usuarios existente)
-- No añadir dependencias nuevas sin revisar primero las existentes (skill buscar-primero)
-```
-
-### Ejemplo 3: proyecto ÉPICO
-
-**Entrada del usuario:**
-```
-Migra nuestro monolito a microservicios
-```
-
-**Prompt optimizado (completo):**
-```
-Usa la skill plano-tecnico para planificar: "Migrar el monolito a arquitectura de microservicios"
-
-Antes de ejecutar, responde estas preguntas en el plano:
-1. ¿Qué límites de dominio existen en el monolito actual?
-2. ¿Qué servicio extraer primero (menor acoplamiento)?
-3. Patrón de comunicación: APIs REST, gRPC o dirigido por eventos (Kafka/RabbitMQ)?
-4. Estrategia de base de datos: ¿BD compartida al inicio o base-por-servicio desde el principio?
-5. Destino de despliegue: ¿Kubernetes, Docker Compose o serverless?
-
-El plano debe producir fases como:
-- Fase 1: identificar límites de servicios y crear el mapa de dominios
-- Fase 2: montar infraestructura (API gateway, service mesh, CI/CD por servicio)
-- Fase 3: extraer el primer servicio (patrón strangler fig)
-- Fase 4: verificar con tests de integración y extraer el siguiente servicio
-- Fase N: retirar el monolito
-
-Cada fase = 1 PR, con compuertas de bucle-verificacion entre fases.
-Usa /guardar-sesion entre fases y /reanudar-sesion para continuar.
-Usa worktrees de git para extraer servicios en paralelo cuando las dependencias lo permitan.
-
-Modelo recomendado: razonamiento profundo para el plano, equilibrado para ejecutar las fases (elige con /enrutar-modelo).
-```
-
----
-
-## Componentes relacionados
-
-| Componente | Cuándo referenciarlo |
-|------------|----------------------|
-| `inventario-skills` | Auditar qué componentes están instalados (úsalo en lugar de un catálogo fijo) |
-| `buscar-primero` | Fase de investigación en los prompts optimizados |
-| `plano-tecnico` | Prompts optimizados de alcance ÉPICO (invocar como skill, no como comando) |
-| `compactacion-estrategica` | Gestión de contexto en sesiones largas |
-| `optimizacion-costos-llm` | Recomendaciones de optimización de tokens |

package/vendor/theus-arsenal/skills/orq-agregar-funcionalidad/SKILL.md

@@ -1,37 +0,0 @@
----
-name: orq-agregar-funcionalidad
-description: Orquesta la construcción de una funcionalidad totalmente nueva de punta a punta — investigación, plan, implementación TDD, revisión y commit con puertas de control — delegando cada fase al agente correspondiente. Úsala cuando se pide una capacidad que aún no existe.
----
-
-# orq-agregar-funcionalidad
-
-Actor · acción · objetivo: **orquestador · agregar · funcionalidad**. Wrapper delgado sobre el motor compartido de [`orq-pipeline`](../orq-pipeline/SKILL.md).
-
-## Cuándo usarla
-
-- El usuario quiere una capacidad que **aún no existe** ("agrega", "construye", "implementa", "soporta …").
-- Es comportamiento neto nuevo — no una corrección (`orq-corregir-defecto`) ni una alteración de comportamiento existente (`orq-cambiar-funcionalidad`).
-
-## Parámetros de operación
-
-- **Tamaño mínimo por defecto:** estándar — ejecuta Investigación + Plan salvo que sea claramente pequeño.
-- **Máscara de fases:** 0 → 1 → 2 → 4 → 5 → 6 (se omite la 3, Scaffold; esa es solo para MVP).
-- **Primer movimiento (fase 4):** escribe tests *nuevos* en rojo para el comportamiento nuevo, luego implementa hasta verde.
-
-## Cómo funciona
-
-1. Ejecuta el motor `orq-pipeline` con los parámetros anteriores.
-2. Clasifica primero el tamaño; las funcionalidades pequeñas o triviales colapsan hacia 4 → 5 → 6.
-3. Detente en la **Puerta 1** (aprobación del plan) y en la **Puerta 2** (pre-commit).
-4. Añade `revisor-seguridad` si la funcionalidad toca un disparador de seguridad.
-
-> Relacionado: `/funcionalidad` es una versión autónoma de este flujo. `orq-agregar-funcionalidad` se diferencia en que comparte el motor `orq-pipeline` — el clasificador de tamaño y las dos puertas — con el resto de la familia, de modo que dimensiona las funcionalidades triviales a 4 → 5 → 6.
-
-## Ejemplo
-
-```
-orq-agregar-funcionalidad: agregar login OAuth2 a nws-poller
-→ investigar librerías de auth existentes → planificar task_list  [PUERTA 1: aprobar]
-→ TDD por tarea → revisor-codigo (+ revisor-seguridad: ruta de auth)
-→ commit  [PUERTA 2: confirmar]
-```

package/vendor/theus-arsenal/skills/orq-cambiar-funcionalidad/SKILL.md

@@ -1,36 +0,0 @@
----
-name: orq-cambiar-funcionalidad
-description: Orquesta la alteración de una funcionalidad existente y operativa hacia un nuevo comportamiento deseado — actualiza sus tests a la nueva especificación, cambia la implementación para que coincida, revisa y hace commit con puertas de control. Úsala cuando el comportamiento no está roto pero debería ser distinto.
----
-
-# orq-cambiar-funcionalidad
-
-Actor · acción · objetivo: **orquestador · cambiar · funcionalidad**. Wrapper delgado sobre el motor compartido de [`orq-pipeline`](../orq-pipeline/SKILL.md).
-
-## Cuándo usarla
-
-- Una funcionalidad existente **funciona**, pero el comportamiento deseado es otro ("cambia", "ajusta", "haz que también …", "en vez de X haz Y").
-- Distínguela de sus hermanas:
-  - **no** está rota → no es `orq-corregir-defecto` (no hay bug que reproducir).
-  - **no** es nueva → no es `orq-agregar-funcionalidad` (la capacidad ya existe).
-
-## Parámetros de operación
-
-- **Tamaño mínimo por defecto:** pequeño — la mayoría de los ajustes son una o dos funciones.
-- **Máscara de fases:** 0 → (1 solo si el nuevo comportamiento requiere investigación) → 2 ligera → 4 → 5 → 6.
-- **Primer movimiento (fase 4):** actualiza los tests *existentes* para expresar el nuevo comportamiento deseado y luego cambia la implementación hasta que pasen. Cambiar los tests primero es lo que separa un ajuste de una corrección.
-
-## Cómo funciona
-
-1. Ejecuta el motor `orq-pipeline` con los parámetros anteriores.
-2. Mantén el plan ligero — solo el tamaño `estándar` o superior amerita la pasada completa de `planificador`.
-3. Detente en la **Puerta 1** (aprobación del plan / de los tests modificados) y en la **Puerta 2** (pre-commit).
-4. Añade `revisor-seguridad` si el cambio toca un disparador de seguridad.
-
-## Ejemplo
-
-```
-orq-cambiar-funcionalidad: que nws-poller alerte a las 2 advertencias en vez de 3
-→ actualizar los tests de umbral a la nueva spec → cambiar la implementación hasta verde
-→ revisor-codigo → commit  [PUERTA 2: confirmar]
-```

package/vendor/theus-arsenal/skills/orq-construir-mvp/SKILL.md

@@ -1,38 +0,0 @@
----
-name: orq-construir-mvp
-description: Orquesta el arranque de un MVP funcional a partir de un documento de diseño o especificación — ingiere el documento, planifica rebanadas verticales delgadas, hace scaffold de la primera rebanada de punta a punta y luego implementa con TDD, revisa y hace commit con puertas de control. Úsala para convertir un SDD/PRD en un punto de partida ejecutable.
----
-
-# orq-construir-mvp
-
-Actor · acción · objetivo: **orquestador · construir · mvp**. Wrapper delgado sobre el motor compartido de [`orq-pipeline`](../orq-pipeline/SKILL.md).
-
-## Cuándo usarla
-
-- El usuario tiene un **documento de diseño / especificación** (SDD, PRD, system_design) y quiere una rebanada vertical funcional arrancada desde él.
-- Recibe como argumento la ruta del documento, p. ej. `civicpulse/docs/SDD-v0.6.md`.
-
-## Parámetros de operación
-
-- **Tamaño mínimo por defecto:** grande — este es el pipeline completo, incluido el Scaffold.
-- **Máscara de fases:** 0 (leer la especificación) → 1 → 2 (pesada) → 3 (scaffold) → 4 → 5 → 6.
-- **Primer movimiento (fases 0 → 2):** lee el documento; extrae el alcance, las decisiones ya fijadas y la lista de funcionalidades; ordénala en **rebanadas verticales delgadas** (primero una ruta de punta a punta, no todos-los-modelos-y-luego-todas-las-vistas). La fase 3 levanta esa primera rebanada.
-
-## Cómo funciona
-
-1. Ejecuta el motor `orq-pipeline` con los parámetros anteriores.
-2. **Reutiliza el harness generador-evaluador existente** en lugar de improvisar un bucle de iteración a mano:
-   - Traduce el SDD a `harness/spec.md` + `harness/eval-rubric.md` (esto sustituye lo que generaría `planificador-harness` — la especificación ya existe).
-   - Dirige la construcción con `/harness-build "<brief de una línea>" --skip-planner` (valores por defecto: `--max-iterations 15`, `--pass-threshold 7.0`, `--eval-mode playwright`; usa `--eval-mode code-only` para rebanadas sin UI).
-   - Ese comando ejecuta el bucle `generador-harness` → `evaluador-harness` y escribe `harness/feedback/feedback-NNN.md` hasta que la puntuación pasa el umbral o se estanca.
-3. Detente en la **Puerta 1** (plan de rebanadas) y en la **Puerta 2** (pre-commit). Haz commit del scaffold y de cada rebanada como commits `feat:` separados.
-4. Añade `revisor-seguridad` para cualquier rebanada que toque un disparador de seguridad.
-
-## Ejemplo
-
-```
-orq-construir-mvp: civicpulse/docs/SDD-v0.6.md
-→ leer SDD → lista de rebanadas (verticales) → scaffold de la rebanada 1  [PUERTA 1: aprobar]
-→ /harness-build --skip-planner (bucle generador → evaluador) puntúa contra la spec → revisión
-→ commit feat:  [PUERTA 2: confirmar] → siguiente rebanada
-```

package/vendor/theus-arsenal/skills/orq-corregir-defecto/SKILL.md

@@ -1,36 +0,0 @@
----
-name: orq-corregir-defecto
-description: Orquesta la corrección de un bug — lo reproduce como test de regresión en rojo, corrige hasta verde, revisa y hace commit con puertas de control — delegando cada fase al agente correspondiente. Úsala cuando el comportamiento existente está roto o es incorrecto.
----
-
-# orq-corregir-defecto
-
-Actor · acción · objetivo: **orquestador · corregir · defecto**. Wrapper delgado sobre el motor compartido de [`orq-pipeline`](../orq-pipeline/SKILL.md).
-
-## Cuándo usarla
-
-- Algo está **roto**: salida incorrecta, un error, un crash, una regresión.
-- Distínguela de sus hermanas:
-  - el comportamiento es correcto pero lo quieres distinto → `orq-cambiar-funcionalidad`.
-  - la capacidad aún no existe → `orq-agregar-funcionalidad`.
-
-## Parámetros de operación
-
-- **Tamaño mínimo por defecto:** pequeño (a menudo trivial).
-- **Máscara de fases:** 0 → (2 ligera solo si la causa raíz no es obvia o el tamaño es estándar o superior) → 4 → 5 → 6. La Investigación (1) normalmente se omite.
-- **Primer movimiento (fase 4):** reproduce el bug como un test **nuevo en rojo** (test de regresión) y luego corrige hasta que pase a verde. Probar primero que el bug existe es lo que separa una corrección de un ajuste.
-
-## Cómo funciona
-
-1. Ejecuta el motor `orq-pipeline` con los parámetros anteriores.
-2. Si la causa raíz no está clara, acótala con `explorador-codigo` antes del test en rojo; escala las roturas de build a `resolutor-builds` / `/arreglar-build`.
-3. Detente en la **Puerta 1** (solo si se produjo un plan) y en la **Puerta 2** (pre-commit).
-4. Añade `revisor-seguridad` si el defecto está en una ruta sensible a la seguridad.
-
-## Ejemplo
-
-```
-orq-corregir-defecto: el poller crashea con una respuesta NWS vacía
-→ escribir un test en rojo que reproduce el crash → corregir hasta verde
-→ revisor-codigo → commit  [PUERTA 2: confirmar]   (commit: fix:)
-```

package/vendor/theus-arsenal/skills/orq-pipeline/SKILL.md

@@ -1,134 +0,0 @@
----
-name: orq-pipeline
-description: Motor de orquestación compartido de la familia de skills orq-*. Define el pipeline con puertas Investigación-Plan-TDD-Revisión-Commit, el clasificador de tamaño, el mapa de agentes y las dos puertas humanas a las que delegan las skills de operación orq-*. No suele invocarse directamente.
----
-
-# Pipeline del orquestador (motor compartido)
-
-Las skills `orq-*` son wrappers delgados. No reimplementan ningún trabajo:
-clasifican la petición, eligen qué fases de *este* pipeline se ejecutan y
-delegan cada fase a un agente o comando existente del arsenal. Este archivo es
-ese pipeline.
-
-> Invoca una skill de operación (`orq-agregar-funcionalidad`,
-> `orq-corregir-defecto`, …) en lugar de este motor directamente. Este archivo
-> es la referencia a la que ellas apuntan.
-
-## Cuándo usarla
-
-- Se carga indirectamente cada vez que se ejecuta una skill de operación `orq-*`.
-- Léela directamente solo al añadir una nueva operación a la familia o al
-  ajustar las fases compartidas, las puertas o el mapa de agentes.
-
-## La familia de operaciones
-
-| Skill | Operación | Disparador | Primer movimiento |
-|-------|-----------|------------|-------------------|
-| `orq-agregar-funcionalidad` | funcionalidad | la capacidad aún no existe | investigar + planificar una rebanada nueva |
-| `orq-cambiar-funcionalidad` | ajuste | funciona, pero el comportamiento deseado difiere | modificar el comportamiento existente *y sus tests* |
-| `orq-corregir-defecto` | corrección | roto; el comportamiento es incorrecto | reproducir como test en rojo y luego corregir |
-| `orq-refinar-codigo` | refactor | el comportamiento se mantiene, la estructura mejora | reestructurar manteniendo los tests en verde |
-| `orq-construir-mvp` | mvp | arrancar desde un documento de diseño/spec | ingerir doc → rebanadas verticales |
-
-> Estos wrappers **componen** comandos existentes del arsenal en lugar de
-> reemplazarlos: `/funcionalidad`, `/plan`, `/revisar-codigo`,
-> `/arreglar-build`, `/limpiar-refactor` y `/harness-build`, más la skill
-> `flujo-tdd`. La familia orq-* añade sobre ellos el clasificador de tamaño
-> compartido y las dos puertas, de modo que un solo paraguas cubre las cinco
-> operaciones de forma consistente.
-
-## Paso 0 — Clasificar el tamaño (dimensionamiento)
-
-La ceremonia escala con el radio de impacto. Puntúa la petición según tres
-señales, toma el nivel **más alto** que alcance cualquiera de ellas y declara el
-resultado en una línea para que el usuario pueda corregirlo:
-
-| Nivel | Archivos tocados | Dependencia / contrato nuevo | Ambigüedad de diseño | Fases que se ejecutan |
-|-------|------------------|------------------------------|----------------------|-----------------------|
-| trivial | 1, pocas líneas | ninguna | ninguna — el cambio es obvio | 4 → 5 → 6 |
-| pequeño | 1 archivo / 1 función | ninguna | clara al leer el código | (1 ligera) → 4 → 5 → 6 |
-| estándar | 2–5 archivos | quizá un módulo interno nuevo | una decisión real que tomar | 1 → 2 → 4 → 5 → 6 |
-| grande | muchos / transversal | dependencia externa nueva, API pública o un doc de spec | varias preguntas abiertas | 1 → 2 → (3) → 4 → 5 → 6 |
-
-La fase 0 (Recepción) siempre se ejecuta y se omite de la columna de máscara.
-Desempate: cualquier cambio que toque un disparador de seguridad (más abajo) o
-una API pública / contrato es **como mínimo** estándar, sin importar el número
-de archivos.
-
-## Las fases
-
-Cada fase delega — no hace el trabajo en línea.
-
-- **0. Recepción** — reformula la petición. Para `orq-construir-mvp`, lee el
-  documento de spec/diseño y extrae alcance, decisiones cerradas y lista de
-  funcionalidades.
-- **1. Investigación y reutilización** — según `rules/common/development-workflow.md`:
-  `gh search repos` / `gh search code`, luego la documentación oficial del
-  proveedor de cada librería, luego los registros de paquetes y, por último, la
-  búsqueda web nativa de Theus. Prefiere adoptar una implementación probada
-  antes que escribir código nuevo.
-- **2. Plan** — delega en el agente `planificador` (o `arquitecto-sistemas` /
-  `arquitecto-codigo` para decisiones estructurales). Salida: una `task_list`
-  ordenada como rebanadas verticales delgadas. → **PUERTA 1.**
-- **3. Andamiaje** — solo `orq-construir-mvp`: levanta la primera rebanada de
-  extremo a extremo.
-- **4. Implementación (TDD)** — conduce cada tarea a través del agente
-  `guia-tdd` (o la skill `flujo-tdd`): rojo → verde → refactor. Respeta la
-  regla de primer movimiento de la operación.
-- **5. Revisión** — agente `revisor-codigo` / `/revisar-codigo`. Añade
-  `revisor-seguridad` siempre que el diff toque un disparador de seguridad
-  (más abajo).
-- **6. Commit** — commits convencionales (`feat:` / `fix:` / `refactor:` / …),
-  uno por bloque lógico. → **PUERTA 2.**
-
-## Las dos puertas
-
-Esta familia funciona **con puertas, no de forma autónoma**:
-
-1. **PUERTA 1 — después del Plan.** Presenta la `task_list`; no escribas código
-   de implementación hasta que el usuario apruebe.
-2. **PUERTA 2 — antes del Commit.** Presenta el resumen del diff y los mensajes
-   propuestos; no hagas commit hasta que el usuario confirme.
-
-Todo lo que hay entre las puertas fluye sin detenerse.
-
-## Mapa de agentes / comandos
-
-| Fase | Primario | Alternativa / escalado |
-|------|----------|------------------------|
-| Recepción / entender | `explorador-codigo` | trazar las rutas existentes antes de un ajuste, corrección o refactor |
-| Plan | `planificador` | `arquitecto-sistemas`, `arquitecto-codigo` para decisiones estructurales |
-| Implementación | `guia-tdd` (o la skill `flujo-tdd`) | `resolutor-builds` / `/arreglar-build` ante roturas de build |
-| Revisión | `revisor-codigo` / `/revisar-codigo` | revisor del lenguaje (`revisor-python`, `revisor-typescript`, …) |
-| Seguridad | `revisor-seguridad` | — |
-| Bucle interno del MVP | `/harness-build "<brief>" --skip-planner` | conduce `generador-harness` → `evaluador-harness`; ajusta `--max-iterations` / `--pass-threshold` |
-
-Elige el revisor de lenguaje que corresponda al repo (mira el `AGENTS.md` del
-propio repo).
-
-## Disparador de revisión de seguridad
-
-Incorpora `revisor-seguridad` cuando el diff toque cualquiera de:
-autenticación o autorización, manejo de entrada de usuario, consultas a base de
-datos, rutas del sistema de archivos, llamadas a APIs externas, criptografía o
-secretos / credenciales. (Según `rules/common/security.md`.)
-
-## Artefactos de traspaso
-
-El pipeline no arrastra estado oculto — los documentos de planificación *son* el
-traspaso:
-
-- La `task_list` (del Plan) dirige el bucle de Implementación.
-- El trabajo grande puede emitir además PRD / arquitectura / system_design bajo
-  el `docs/` del repo, según `rules/common/development-workflow.md`.
-- Los hallazgos de la revisión (CRÍTICO / ALTO) deben resolverse antes de la
-  Puerta 2.
-
-## Verificación
-
-- el nivel de tamaño se declaró y coincidió con el trabajo
-- se respetaron la Puerta 1 (plan) y la Puerta 2 (commit)
-- `revisor-seguridad` se ejecutó si y solo si se tocó un disparador de seguridad
-- los commits son convencionales y acotados a un cambio lógico
-- el comportamiento nuevo / cambiado tiene tests; cobertura ≥ 80 % según
-  `rules/common/testing.md`