theus-cli-linux-arm64 1.2.1 → 1.3.0

package/vendor/theus-arsenal/commands/checkpoint.md

@@ -1,78 +0,0 @@
----
-description: Crea, verifica o lista checkpoints del flujo de trabajo después de ejecutar comprobaciones de verificación.
----
-
-# Comando Checkpoint
-
-Crea o verifica un checkpoint en tu flujo de trabajo.
-
-## Uso
-
-`/checkpoint [create|verify|list] [nombre]`
-
-## Crear un checkpoint
-
-Al crear un checkpoint:
-
-1. Ejecuta las comprobaciones rápidas de la skill `bucle-verificacion` para asegurar que el estado actual esté limpio
-2. Crea un git stash o un commit con el nombre del checkpoint
-3. Registra el checkpoint en `.theus/checkpoints.log`:
-
-```bash
-echo "$(date +%Y-%m-%d-%H:%M) | $CHECKPOINT_NAME | $(git rev-parse --short HEAD)" >> .theus/checkpoints.log
-```
-
-4. Informa que el checkpoint fue creado
-
-## Verificar un checkpoint
-
-Al verificar contra un checkpoint:
-
-1. Lee el checkpoint del registro
-2. Compara el estado actual con el checkpoint:
-   - Archivos agregados desde el checkpoint
-   - Archivos modificados desde el checkpoint
-   - Tasa de tests que pasan ahora vs. entonces
-   - Cobertura ahora vs. entonces
-
-3. Informa:
-```
-COMPARACIÓN DE CHECKPOINT: $NOMBRE
-============================
-Archivos cambiados: X
-Tests: +Y pasan / -Z fallan
-Cobertura: +X% / -Y%
-Build: [PASA/FALLA]
-```
-
-## Listar checkpoints
-
-Muestra todos los checkpoints con:
-- Nombre
-- Fecha y hora
-- SHA de git
-- Estado (actual, atrás, adelante)
-
-## Flujo de trabajo
-
-Flujo típico de checkpoints:
-
-```
-[Inicio] --> /checkpoint create "inicio-funcionalidad"
-   |
-[Implementar] --> /checkpoint create "nucleo-listo"
-   |
-[Testear] --> /checkpoint verify "nucleo-listo"
-   |
-[Refactorizar] --> /checkpoint create "refactor-listo"
-   |
-[PR] --> /checkpoint verify "inicio-funcionalidad"
-```
-
-## Argumentos
-
-$ARGUMENTS:
-- `create <nombre>` - Crea un checkpoint con nombre
-- `verify <nombre>` - Verifica contra el checkpoint indicado
-- `list` - Muestra todos los checkpoints
-- `clear` - Elimina checkpoints antiguos (conserva los últimos 5)

package/vendor/theus-arsenal/commands/cobertura-tests.md

@@ -1,73 +0,0 @@
----
-description: Analiza la cobertura, identifica brechas y genera los tests faltantes hasta alcanzar el umbral objetivo.
----
-
-# Cobertura de tests
-
-Analiza la cobertura de tests, identifica brechas y genera los tests faltantes para alcanzar una cobertura de 80%+.
-
-## Paso 1: Detectar el framework de tests
-
-| Indicador | Comando de cobertura |
-|-----------|---------------------|
-| `jest.config.*` o jest en `package.json` | `npx jest --coverage --coverageReporters=json-summary` |
-| `vitest.config.*` | `npx vitest run --coverage` |
-| `pytest.ini` / pytest en `pyproject.toml` | `pytest --cov=src --cov-report=json` |
-| `Cargo.toml` | `cargo llvm-cov --json` |
-| `pom.xml` con JaCoCo | `mvn test jacoco:report` |
-| `go.mod` | `go test -coverprofile=coverage.out ./...` |
-
-## Paso 2: Analizar el reporte de cobertura
-
-1. Ejecuta el comando de cobertura
-2. Parsea la salida (resumen JSON o salida de terminal)
-3. Lista los archivos **por debajo del 80% de cobertura**, ordenados del peor al mejor
-4. Para cada archivo con cobertura insuficiente, identifica:
-   - Funciones o métodos sin tests
-   - Cobertura de ramas faltante (if/else, switch, rutas de error)
-   - Código muerto que infla el denominador
-
-## Paso 3: Generar los tests faltantes
-
-Para cada archivo con cobertura insuficiente, genera tests siguiendo esta prioridad:
-
-1. **Camino feliz** — Funcionalidad central con entradas válidas
-2. **Manejo de errores** — Entradas inválidas, datos faltantes, fallos de red
-3. **Casos límite** — Arreglos vacíos, null/undefined, valores frontera (0, -1, MAX_INT)
-4. **Cobertura de ramas** — Cada if/else, cada case de switch, cada ternario
-
-### Reglas de generación de tests
-
-- Coloca los tests junto al código fuente: `foo.ts` → `foo.test.ts` (o según la convención del proyecto)
-- Usa los patrones de test existentes del proyecto (estilo de imports, librería de aserciones, enfoque de mocking)
-- Haz mock de las dependencias externas (base de datos, APIs, sistema de archivos)
-- Cada test debe ser independiente — sin estado mutable compartido entre tests
-- Nombra los tests de forma descriptiva: `test_create_user_with_duplicate_email_returns_409`
-
-## Paso 4: Verificar
-
-1. Ejecuta la suite completa de tests — todos los tests deben pasar
-2. Vuelve a ejecutar la cobertura — verifica la mejora
-3. Si sigue por debajo del 80%, repite el Paso 3 para las brechas restantes
-
-## Paso 5: Reportar
-
-Muestra una comparación antes/después:
-
-```
-Reporte de cobertura
-──────────────────────────────
-Archivo                 Antes   Después
-src/services/auth.ts    45%     88%
-src/utils/validation.ts 32%     82%
-──────────────────────────────
-Total:                  67%     84%  PASA:
-```
-
-## Áreas de enfoque
-
-- Funciones con ramificación compleja (alta complejidad ciclomática)
-- Manejadores de errores y bloques catch
-- Funciones utilitarias usadas en todo el código
-- Manejadores de endpoints de API (flujo request → response)
-- Casos límite: null, undefined, cadena vacía, arreglo vacío, cero, números negativos

package/vendor/theus-arsenal/commands/configurar-gestor-paquetes.md

@@ -1,86 +0,0 @@
----
-description: Configura tu gestor de paquetes preferido (npm/pnpm/yarn/bun) a nivel de proyecto o global.
-argument-hint: [--detect | --json | <gestor a fijar>]
-disable-model-invocation: true
----
-
-# Configuración del gestor de paquetes
-
-Configura el gestor de paquetes preferido para este proyecto o de forma global. La detección la implementa `scripts/lib/package-manager.js` del arsenal; el detector de línea de comandos es `scripts/setup-package-manager.js`.
-
-## Uso
-
-```bash
-# Detectar el gestor actual (salida legible)
-node "${THEUS_PLUGIN_ROOT}/scripts/setup-package-manager.js" --detect
-
-# Salida legible por máquina (gestor, fuente, comandos de test/exec)
-node "${THEUS_PLUGIN_ROOT}/scripts/setup-package-manager.js" --json
-```
-
-El motor de Theus inyecta `THEUS_PLUGIN_ROOT` al cargar el comando; para ejecución manual fuera de ese contexto, resuelve la raíz con `scripts/lib/resolve-theus-root.js` del arsenal.
-
-## Fijar una preferencia
-
-Para **fijar** (no solo detectar) el gestor, escribe la configuración correspondiente:
-
-- **Proyecto**: crea `.theus/package-manager.json` en la raíz del proyecto (o usa `setProjectPackageManager()` de `scripts/lib/package-manager.js`).
-- **Global**: define la variable de entorno `THEUS_PACKAGE_MANAGER`, o crea `package-manager.json` en el directorio de datos del arsenal (`~/.theus/arsenal/`).
-
-Si el usuario pasa un gestor en `$ARGUMENTS` (p. ej. `/configurar-gestor-paquetes pnpm`), valida que sea uno de npm/pnpm/yarn/bun y escribe la preferencia de proyecto en `.theus/package-manager.json`.
-
-## Prioridad de detección
-
-Al determinar qué gestor usar, se comprueba en este orden:
-
-1. **Variable de entorno**: `THEUS_PACKAGE_MANAGER`
-2. **Configuración del proyecto**: `.theus/package-manager.json`
-3. **package.json**: campo `packageManager`
-4. **Lockfile**: presencia de package-lock.json, yarn.lock, pnpm-lock.yaml o bun.lockb
-5. **Configuración global**: `package-manager.json` en `~/.theus/arsenal/`
-6. **Fallback**: primer gestor disponible en el sistema (pnpm > bun > yarn > npm)
-
-## Archivos de configuración
-
-### Configuración global
-```json
-// ~/.theus/arsenal/package-manager.json
-{
-  "packageManager": "pnpm"
-}
-```
-
-### Configuración del proyecto
-```json
-// .theus/package-manager.json
-{
-  "packageManager": "bun"
-}
-```
-
-### package.json
-```json
-{
-  "packageManager": "pnpm@8.6.0"
-}
-```
-
-## Variable de entorno
-
-Define `THEUS_PACKAGE_MANAGER` para anular todos los demás métodos de detección:
-
-```bash
-# Windows (PowerShell)
-$env:THEUS_PACKAGE_MANAGER = "pnpm"
-
-# macOS/Linux
-export THEUS_PACKAGE_MANAGER=pnpm
-```
-
-## Ejecutar la detección
-
-Para ver el resultado de la detección actual, ejecuta:
-
-```bash
-node "${THEUS_PLUGIN_ROOT}/scripts/setup-package-manager.js" --detect
-```

package/vendor/theus-arsenal/commands/consulta.md

@@ -1,164 +0,0 @@
----
-description: Responde una pregunta rápida al margen sin interrumpir ni perder el contexto de la tarea actual. Retoma el trabajo automáticamente después de responder.
----
-
-# Comando Consulta
-
-Haz una pregunta a mitad de una tarea y obtén una respuesta inmediata y enfocada — y luego continúa exactamente donde te quedaste. La tarea actual, los archivos y el contexto nunca se modifican.
-
-## Cuándo usarlo
-
-- Tienes curiosidad por algo mientras Theus está trabajando y no quieres perder el impulso
-- Necesitas una explicación rápida del código que Theus está editando en este momento
-- Quieres una segunda opinión o una aclaración sobre una decisión sin descarrilar la tarea
-- Necesitas entender un error, un concepto o un patrón antes de que Theus continúe
-- Quieres preguntar algo no relacionado con la tarea actual sin iniciar una sesión nueva
-
-## Uso
-
-```
-/consulta <tu pregunta>
-/consulta ¿qué devuelve realmente esta función?
-/consulta ¿este patrón es thread-safe?
-/consulta ¿por qué usamos X en vez de Y aquí?
-/consulta ¿cuál es la diferencia entre foo() y bar()?
-/consulta ¿deberíamos preocuparnos por la consulta N+1 que acabamos de agregar?
-```
-
-## Proceso
-
-### Paso 1: Congelar el estado de la tarea actual
-
-Antes de responder nada, anota mentalmente:
-- ¿Cuál es la tarea activa? (qué archivo, funcionalidad o problema se estaba trabajando)
-- ¿Qué paso estaba en curso en el momento en que se invocó `/consulta`?
-- ¿Qué estaba a punto de suceder a continuación?
-
-NO toques, edites, crees ni elimines ningún archivo durante la consulta.
-
-### Paso 2: Responder la pregunta directamente
-
-Responde la pregunta en la forma más concisa que siga siendo completa y útil.
-
-- Empieza por la respuesta, no por el razonamiento
-- Sé breve — si hace falta una explicación completa, ofrece profundizar después de la tarea
-- Si la pregunta trata sobre el archivo o el código que se está trabajando, referéncialo con precisión (ruta del archivo y número de línea si es relevante)
-- Si responder requiere leer un archivo, léelo — pero solo lectura, nunca escritura
-
-Formatea la respuesta así:
-
-```
-CONSULTA: [replantea la pregunta brevemente]
-
-[Tu respuesta aquí]
-
-— De vuelta a la tarea: [descripción de una línea de lo que se estaba haciendo]
-```
-
-### Paso 3: Retomar la tarea principal
-
-Después de entregar la respuesta, continúa de inmediato la tarea activa desde el punto exacto en que se pausó. No pidas permiso para retomar, salvo que la respuesta de la consulta haya revelado un bloqueante o una razón para reconsiderar el enfoque actual (ver Casos límite).
-
----
-
-## Casos límite
-
-**No se proporcionó pregunta (`/consulta` sin nada después):**
-Responde:
-```
-CONSULTA: no se proporcionó ninguna pregunta
-
-¿Qué te gustaría saber? (haz tu pregunta y responderé sin perder el contexto de la tarea actual)
-
-— De vuelta a la tarea: [descripción de una línea de lo que se estaba haciendo]
-```
-
-**La pregunta revela un problema potencial con la tarea actual:**
-Señálalo con claridad antes de retomar:
-```
-CONSULTA: [respuesta]
-
-ADVERTENCIA: Nota: esta respuesta sugiere [problema] con el enfoque actual. ¿Quieres abordarlo antes de continuar, o seguimos según lo planeado?
-```
-Espera la decisión del usuario antes de retomar.
-
-**La pregunta es en realidad un cambio de rumbo de la tarea (no una pregunta al margen):**
-Si la pregunta implica cambiar lo que se está construyendo (p. ej., `/consulta mejor usemos Redis`), aclara:
-```
-CONSULTA: Eso suena a un cambio de dirección, no solo a una pregunta al margen.
-¿Quieres:
-  (a) Que responda esto solo como información y mantenga el plan actual
-  (b) Pausar la tarea actual y cambiar de enfoque
-```
-Espera la respuesta del usuario — no hagas suposiciones.
-
-**La pregunta es sobre el archivo o el código actualmente abierto:**
-Responde desde el contexto vivo. Si el archivo se leyó antes en la sesión, referéncialo directamente. Si no, léelo ahora (solo lectura) y responde con una referencia archivo:línea.
-
-**No hay tarea activa (nada en curso cuando se invoca `/consulta`):**
-Usa igualmente el envoltorio estándar para que la forma de la respuesta se mantenga consistente:
-```
-CONSULTA: [replantea la pregunta brevemente]
-
-[Tu respuesta aquí]
-
-— De vuelta a la tarea: no hay tarea activa que retomar
-```
-
-**La pregunta requiere una respuesta larga:**
-Da la respuesta esencial de forma concisa, y luego ofrece:
-```
-Esa es la versión corta. ¿Quieres una explicación más profunda cuando terminemos [tarea actual]?
-```
-
-**Varias `/consulta` seguidas:**
-Responde cada una en secuencia. Después de la última respuesta, retoma la tarea principal. No pierdas el estado de la tarea a lo largo de una cadena de consultas.
-
-**La respuesta de la consulta implica que hace falta un cambio en el código:**
-Anota el cambio necesario pero no lo hagas durante la consulta:
-```
-CONSULTA: [respuesta]
-
- Vale la pena corregir: [qué debería cambiarse]. Lo señalaré después de la tarea actual, salvo que quieras abordarlo ahora.
-```
-
-**La pregunta es ambigua o demasiado vaga:**
-Haz una sola pregunta aclaratoria — la pregunta más corta que obtenga la información necesaria para responder. No hagas varias preguntas.
-
----
-
-## Ejemplo de salida
-
-```
-Usuario: /consulta ¿qué hace realmente fetchWithRetry()?
-
-CONSULTA: ¿qué hace fetchWithRetry()?
-
-fetchWithRetry() (src/api/retry.ts:12) intenta la petición hasta 3 veces con
-backoff exponencial (250ms → 500ms → 1s). Solo reintenta ante respuestas 5xx y
-errores de red — los errores 4xx se tratan como definitivos y no se reintentan.
-
-— De vuelta a la tarea: refactorizando el middleware de autenticación en src/middleware/auth.ts
-```
-
-```
-Usuario: /consulta ¿el enfoque que estamos tomando es thread-safe?
-
-CONSULTA: ¿el enfoque actual es thread-safe?
-
-No — el objeto de caché compartido en src/cache/store.ts:34 se muta sin bloqueo.
-Bajo peticiones concurrentes esto es una condición de carrera. Es de bajo riesgo en un
-servidor Node.js de un solo proceso, pero sería un problema real con worker threads o clustering.
-
-ADVERTENCIA: Nota: esto podría afectar la funcionalidad que estamos construyendo. ¿Quieres abordarlo ahora o continuamos y lo corregimos en un seguimiento?
-```
-
----
-
-## Notas
-
-- Nunca modifiques archivos durante una consulta — acceso de solo lectura
-- La consulta es una pausa en la conversación, no una tarea nueva — la tarea original siempre debe retomarse
-- Mantén las respuestas enfocadas: el objetivo es desbloquear al usuario rápidamente, no dar una cátedra
-- Si una consulta enciende una discusión mayor, termina primero la tarea actual, salvo que la consulta revele un bloqueante
-- Las consultas no se guardan en los archivos de sesión salvo que sean explícitamente relevantes para el resultado de la tarea

package/vendor/theus-arsenal/commands/control-calidad.md

@@ -1,50 +0,0 @@
----
-description: "Ejecuta la compuerta de calidad de formato de Theus sobre un solo archivo y reporta los pasos de remediación."
----
-
-# Comando de compuerta de calidad
-
-Punto de entrada para el operador de la compuerta de calidad de formato que normalmente se ejecuta como hook PostToolUse `post-quality-gate` (`scripts/hooks/quality-gate.js`).
-
-## Cómo funciona en realidad
-
-La compuerta es una verificación de formato de un solo archivo dirigida por la entrada del hook, no por flags de CLI:
-
-- El script lee el objetivo del JSON de stdin del hook
-  (`tool_input.file_path`); no acepta una ruta como argumento.
-- Los toggles de comportamiento son variables de entorno:
-  - `THEUS_QUALITY_GATE_FIX=true` - aplica las correcciones de formato en lugar de solo verificar
-  - `THEUS_QUALITY_GATE_STRICT=true` - registra los fallos del formateador como fallos de la compuerta
-- Cobertura por tipo de archivo:
-  - `.ts/.tsx/.js/.jsx/.json/.md` - `check` de Biome o `--check` de Prettier,
-    según cuál incluya el proyecto (JS/TS bajo Biome se omite aquí porque
-    `post-edit-format` ya ejecuta `biome check --write`)
-  - `.go` - `gofmt`
-  - `.py` - `ruff format`
-- Las verificaciones de lint y de tipos no forman parte de esta compuerta. Usa la skill
-  `bucle-verificacion` o las skills de verificación por lenguaje para pipelines de
-  lint/tipos/tests.
-
-## Uso
-
-Para ejecutar la compuerta manualmente sobre un archivo, canaliza JSON al estilo hook al script (define primero los toggles de entorno si quieres el comportamiento de corrección o estricto):
-
-```bash
-echo '{"tool_input":{"file_path":"src/example.ts"}}' \
-  | THEUS_QUALITY_GATE_FIX=true node scripts/hooks/quality-gate.js
-```
-
-Después reporta los hallazgos del formateador y pasos de remediación concretos.
-
-## Notas
-
-El cableado del hook vive en `hooks/hooks.json` (`post-quality-gate`, perfiles
-`standard`/`strict` vía `run-with-flags.js`).
-
-## Argumentos
-
-$ARGUMENTS:
-
-- `[ruta]` archivo opcional a verificar. El script en sí no acepta argumentos
-  de CLI - cuando se proporcione una ruta, sustitúyela como `tool_input.file_path`
-  en el JSON de stdin mostrado arriba antes de ejecutar el comando

package/vendor/theus-arsenal/commands/crear-skill.md

@@ -1,77 +0,0 @@
----
-name: crear-skill
-description: Analiza el historial local de git para extraer patrones de código y generar archivos SKILL.md.
-allowed-tools: ["Bash", "Read", "Write", "Grep", "Glob"]
----
-
-# /crear-skill - Generación local de skills
-
-Analiza el historial de git de tu repositorio para extraer patrones de código y generar archivos SKILL.md que le enseñan a Theus las prácticas de tu equipo.
-
-## Uso
-
-```bash
-/crear-skill                    # Analizar el repositorio actual
-/crear-skill --commits 100      # Analizar los últimos 100 commits
-/crear-skill --output ./skills  # Directorio de salida personalizado
-```
-
-## Qué hace
-
-1. **Parsea el historial de git** - Analiza commits, cambios de archivos y patrones
-2. **Detecta patrones** - Identifica flujos de trabajo y convenciones recurrentes
-3. **Genera SKILL.md** - Crea archivos de skill válidos para Theus
-
-## Pasos del análisis
-
-### Paso 1: Recopilar datos de git
-
-```bash
-# Obtener commits recientes con cambios de archivos
-git log --oneline -n ${COMMITS:-200} --name-only --pretty=format:"%H|%s|%ad" --date=short
-
-# Obtener la frecuencia de commits por archivo
-git log --oneline -n 200 --name-only | grep -v "^$" | grep -v "^[a-f0-9]" | sort | uniq -c | sort -rn | head -20
-
-# Obtener los patrones de mensajes de commit
-git log --oneline -n 200 | cut -d' ' -f2- | head -50
-```
-
-### Paso 2: Detectar patrones
-
-Busca estos tipos de patrones:
-
-| Patrón | Método de detección |
-|--------|--------------------|
-| **Convenciones de commits** | Regex sobre los mensajes de commit (feat:, fix:, chore:) |
-| **Co-cambios de archivos** | Archivos que siempre cambian juntos |
-| **Secuencias de flujo de trabajo** | Patrones repetidos de cambios de archivos |
-| **Arquitectura** | Estructura de carpetas y convenciones de nombres |
-| **Patrones de testing** | Ubicación de archivos de test, nomenclatura, cobertura |
-
-### Paso 3: Generar SKILL.md
-
-Formato de salida (formato de skill de Theus — SKILL.md con frontmatter `name`/`description`):
-
-```markdown
----
-name: {nombre-del-repo}-patterns
-description: Patrones de código extraídos de {nombre-del-repo}
----
-
-# Patrones de {Nombre del Repo}
-
-## Convenciones de commits
-{patrones de mensajes de commit detectados}
-
-## Arquitectura del código
-{estructura de carpetas y organización detectadas}
-
-## Flujos de trabajo
-{patrones repetidos de cambios de archivos detectados}
-
-## Patrones de testing
-{convenciones de test detectadas}
-```
-
-Incluye en el cuerpo de la skill los metadatos del análisis (commits analizados, fecha del análisis, fuente: análisis local de git) para que la skill sea auditable.

package/vendor/theus-arsenal/commands/enrutar-modelo.md

@@ -1,30 +0,0 @@
----
-description: Recomienda el mejor nivel de modelo para la tarea actual según complejidad, riesgo y presupuesto.
----
-
-# Comando Enrutar Modelo
-
-Recomienda el mejor nivel de modelo para la tarea actual según complejidad y presupuesto.
-
-## Uso
-
-`/enrutar-modelo [descripción-de-la-tarea] [--budget low|med|high]`
-
-## Heurística de enrutado
-
-- **económico** (catálogo Theus): cambios mecánicos deterministas y de bajo riesgo
-- **estándar** (catálogo Theus): opción por defecto para implementación y refactors
-- **premium** (catálogo Theus): arquitectura, revisión profunda, requisitos ambiguos
-
-## Salida requerida
-
-- nivel de modelo recomendado
-- nivel de confianza
-- por qué ese nivel encaja
-- nivel alternativo si el primer intento falla
-
-## Argumentos
-
-$ARGUMENTS:
-- `[descripción-de-la-tarea]` texto libre opcional
-- `--budget low|med|high` opcional

package/vendor/theus-arsenal/commands/epica-desbloquear.md

@@ -1,17 +0,0 @@
----
-description: Barrer las épicas bloqueadas y reabrir las que ya tienen sus dependencias cerradas.
-argument-hint: [--repo <owner/repo>]
----
-
-# /epica-desbloquear
-
-Barre las épicas bloqueadas cuyas dependencias declaradas ya están completas.
-
-> **Requiere configuración de repositorio:** este comando opera sobre issues de GitHub mediante la CLI `gh` autenticada y con permisos de escritura sobre el repositorio. Si el repositorio no está configurado, el agente lo indicará y se detendrá.
-
-Qué hace este comando (el agente aplica estos pasos con `gh issue list` / `gh issue view` / `gh issue edit`):
-
-1. Recorre los issues de épicas del repositorio.
-2. Comprueba la lista de dependencias de cada épica bloqueada.
-3. Pasa a estado "lista" toda épica cuyas dependencias estén completamente cerradas.
-4. Actualiza etiquetas, comentarios e instantáneas locales en `~/.theus/arsenal/`.

package/vendor/theus-arsenal/commands/epica-descomponer.md

@@ -1,22 +0,0 @@
----
-description: Descomponer una épica en tareas hijas sin crear ramas por tarea.
-argument-hint: <numero-de-issue> [--repo <owner/repo>]
----
-
-# /epica-descomponer
-
-Reconcilia el desglose de tareas de una épica (issue de GitHub).
-
-> **Requiere configuración de repositorio:** este comando opera sobre issues de GitHub mediante la CLI `gh` autenticada y con permisos de escritura sobre el repositorio. Si el repositorio no está configurado, el agente lo indicará y se detendrá.
-
-Qué hace este comando (el agente aplica estos pasos con `gh issue view` / `gh issue edit`):
-
-1. Lee el cuerpo del issue de la épica en busca de checklists de tareas y referencias de dependencias.
-2. Registra la descomposición en el bloque de coordinación del cuerpo del issue y guarda una copia local del estado en `~/.theus/arsenal/`.
-3. Deja las ramas por tarea fuera del flujo de trabajo: la descomposición no crea ramas.
-4. Añade un comentario de auditoría conciso al issue.
-
-Alias de compatibilidad:
-
-- `/plan`
-- `/prp-planificar`

package/vendor/theus-arsenal/commands/epica-publicar.md

@@ -1,21 +0,0 @@
----
-description: Publicar una actualización validada de la épica en el issue y en la caché local.
-argument-hint: <numero-de-issue> [--repo <owner/repo>]
----
-
-# /epica-publicar
-
-Publica en GitHub una actualización de coordinación ya validada.
-
-> **Requiere configuración de repositorio:** este comando opera sobre issues de GitHub mediante la CLI `gh` autenticada y con permisos de escritura sobre el repositorio. Si el repositorio no está configurado, el agente lo indicará y se detendrá.
-
-Qué hace este comando (el agente aplica estos pasos con `gh issue view` / `gh issue edit`):
-
-1. Vuelve a validar la épica antes de publicar (mismos criterios que `/epica-validar`).
-2. Actualiza el bloque de coordinación en el cuerpo del issue.
-3. Añade un comentario de publicación conciso.
-4. Registra la instantánea local final en `~/.theus/arsenal/`.
-
-Alias de compatibilidad:
-
-- `/pr`

package/vendor/theus-arsenal/commands/epica-reclamar.md

@@ -1,25 +0,0 @@
----
-description: Reclamar un issue de épica, sellar el estado de coordinación y sincronizar la propiedad local.
-argument-hint: <número-de-issue> [--repo <owner/repo>]
----
-
-# /epica-reclamar
-
-Reclama un issue de épica como fuente de verdad para una unidad de trabajo.
-
-> **Requiere configuración de repositorio:** este comando opera sobre issues de GitHub mediante la CLI `gh` autenticada y con permisos de lectura y escritura sobre el repositorio. Si el repositorio no está configurado, el agente lo indicará y se detendrá.
-
-Analiza desde `$ARGUMENTS` el número de issue (obligatorio) y `--repo <owner/repo>` (opcional, por defecto el repositorio actual).
-
-Qué hace este comando (el agente aplica estos pasos con `gh issue view` / `gh issue edit` / `gh issue comment`):
-
-1. Carga el cuerpo del issue y su bloque de coordinación.
-2. Marca la épica como reclamada en el estado del issue de GitHub.
-3. Actualiza las etiquetas y la instantánea local de coordinación en `~/.theus/arsenal/`.
-4. Añade un comentario de auditoría por la reclamación.
-
-Alias de compatibilidad:
-
-- `/orq-agregar-funcionalidad`
-- `/orq-cambiar-funcionalidad`
-- `/prp-implementar`

package/vendor/theus-arsenal/commands/epica-revisar.md

@@ -1,22 +0,0 @@
----
-description: Marcar la revisión de una épica como solicitada, aprobada o con cambios pedidos.
-argument-hint: <numero-de-issue> --review <requested|approved|changes> [--repo <owner/repo>]
----
-
-# /epica-revisar
-
-Coordina el estado de revisión de una épica (issue de GitHub).
-
-> **Requiere configuración de repositorio:** este comando opera sobre issues de GitHub mediante la CLI `gh` autenticada y con permisos de escritura sobre el repositorio. Si el repositorio no está configurado, el agente lo indicará y se detendrá.
-
-Qué hace este comando (el agente aplica estos pasos con `gh issue view` / `gh issue edit`):
-
-1. Actualiza el estado de revisión en el bloque de coordinación del issue.
-2. Sincroniza las etiquetas de revisión en GitHub.
-3. Registra el resultado de la revisión en un comentario de auditoría.
-4. Mantiene la copia local en `~/.theus/arsenal/` alineada con el cuerpo del issue.
-
-Alias de compatibilidad:
-
-- `/revisar-pr`
-- `/revisar-codigo`