nexakit 0.1.0 → 0.2.0

package/skills/depurar/SKILL.md

@@ -1,69 +0,0 @@
----
-name: depurar
-license: MIT
-description: Investiga la causa raíz de fallos, pruebas en rojo, regresiones, intermitencias o comportamientos inesperados antes de proponer o aplicar correcciones. Úsala ante cualquier defecto técnico investigable; usa un ajuste directo sin esta skill solo para erratas textuales obvias o preguntas conceptuales sin fallo en ejecución.
----
-
-# Depurar por causa raíz
-
-Reúne evidencia reproducible y localiza el origen del fallo antes de proponer cambios de código. Parchear el síntoma sin entender la causa genera regresiones y retrabajo.
-
-## Cuándo aplica y cuándo usar algo más simple
-
-| Situación | Proceso |
-| --- | --- |
-| Errata evidente señalada por el usuario o fallo de sintaxis trivial recién introducido | Corregir o indicar la línea exacta y ejecutar la comprobación directa. |
-| Pregunta sobre cómo funciona un módulo sin error activo | Inspeccionar y explicar en lectura; no abrir proceso de depuración. |
-| Prueba fallida, error en ejecución, regresión, bloqueo o fallo de integración | Seguir las **4 fases** de esta skill sin saltar a parches tentativos. |
-| Fallo intermitente, carrera o problema entre múltiples capas (CLI, MCP, red, base de datos) | Seguir las 4 fases y cargar [las técnicas de diagnóstico](references/tecnicas-de-diagnostico.md). |
-
-Si en la sesión ya se aplicó `systematic-debugging` de Superpowers o el usuario ya aportó reproducción y trazas verificadas, **reutiliza esa evidencia** y retoma en la fase correspondiente sin repetir pasos resueltos.
-
-## Regla principal
-
-**Ninguna corrección propuesta o aplicada sin investigar primero la causa raíz.**
-
-Si te descubres pensando «pruebo este cambio rápido a ver si pasa» o proponiendo una lista de arreglos antes de leer la traza y el flujo de datos, detente y vuelve a la Fase 1.
-
-## Las 4 fases
-
-### Fase 1: Investigar y reproducir
-
-1. **Leer el error completo:** inspecciona mensajes, códigos de salida, rutas, líneas y trazas enteras sin ignorar advertencias previas.
-2. **Reproducir con consistencia:** ejecuta (cuando esté permitido) el comando o caso mínimo que dispara el problema. Si no es reproducible todavía, reúne más datos en lugar de adivinar.
-3. **Revisar qué cambió:** consulta `git status`, `git diff`, commits recientes, configuración local o diferencias de entorno (versión de Node, rutas de `PATH`, permisos, sistema operativo).
-4. **Rastrear hasta el origen:** cuando el error estalla al fondo de la pila, sigue hacia atrás quién pasó el valor inválido hasta encontrar el disparador real. En sistemas de varias capas, comprueba qué entra y qué sale en cada frontera antes de tocar lógica.
-
-### Fase 2: Contrastar patrones
-
-1. Localiza en el mismo repositorio un flujo parecido que sí funcione.
-2. Lee la referencia completa sin saltar líneas y enumera todas las diferencias (argumentos, entorno, permisos, orden de inicialización, tipos).
-3. Identifica los supuestos implícitos que el caso roto incumple.
-
-### Fase 3: Formular y contrastar una hipótesis
-
-1. Enuncia **una sola hipótesis concreta**: «La causa raíz es X porque la evidencia Y muestra Z».
-2. Diseña la comprobación mínima que confirma o descarta esa hipótesis cambiando **una sola variable a la vez**.
-3. Si la evidencia la descarta, revierte o descarta esa prueba sin destruir trabajo previo del usuario y formula una hipótesis nueva basada en lo observado. Nunca apiles un parche encima de otro fallido.
-
-### Fase 4: Corregir en el origen y verificar
-
-1. **Fijar el fallo en una prueba:** crea o guía la prueba mínima reproducible que falla por la causa identificada (usa `desarrollo-con-pruebas` cuando aplique). Si no cabe prueba automatizada razonable, documenta el comando exacto de reproducción.
-2. **Aplicar un único arreglo en el origen:** corrige donde nace el dato o estado inválido, no solo donde revienta. No mezcles limpiezas ni refactorizaciones ajenas.
-3. **Comprobar con evidencia fresca:** verifica que la prueba nueva pasa, que la suite relevante sigue en verde y que el síntoma original desapareció (aplica `quality-gate`).
-4. **Límite de 3 intentos:** si tras **3 correcciones** el problema reaparece o abre fallos nuevos en otros puntos, **detente**. No intentes el parche número 4: expón la evidencia al usuario y evalúa si el diseño o acoplamiento actual requiere un replanteamiento.
-
-## Modos de trabajo y permisos
-
-- Respeta las instrucciones del proyecto, el sandbox activo y los permisos del encargo. Esta skill no habilita escritura, red, commits ni cambios en la configuración personal.
-- **En modo `tutor`:** realiza solo lecturas y diagnósticos no mutantes autorizados. Si necesitas instrumentación temporal, explica qué línea diagnóstica añadir y dónde para que el usuario la pruebe y comparta la salida. Una vez confirmada la causa raíz, entrega la prueba y luego la corrección como **pasos individuales verificables** para que la persona escriba.
-- **No destruyas trabajo existente:** conserva cambios previos del usuario; si estorban para aislar la reproducción, infórmalo y acuerda cómo apartarlos antes de tocarlos.
-
-## Ejemplo verificable
-
-- **Síntoma:** una vista previa marca `blocked` en Linux mientras en CI pasa.
-- **Fase 1 (evidencia):** en lugar de cambiar la condición de bloqueo, se inspecciona `blockedReason` y el entorno filtrado: `git` vive en `~/.local/bin/git`, pero el inspector interno ejecuta `git` con un `PATH` fijo `/usr/bin:/bin`, devolviendo `ENOENT`.
-- **Fase 3 (hipótesis):** el bloqueo no proviene de la rama del proyecto sino de que el proceso de inspección no resuelve `git` desde el `PATH` del entorno cuando está fuera de `/usr/bin`.
-- **Fase 4 (corrección y prueba):** prueba con un ejecutable `git` fuera de `/usr/bin` que falla antes del cambio → resolver `git` de forma segura para la inspección sin abrir el `PATH` del cliente hijo → prueba nueva y suite en verde.
-
-Consulta [las técnicas de diagnóstico](references/tecnicas-de-diagnostico.md) para rastreo hacia atrás, validación por capas y esperas por condición. Adaptada de [obra/superpowers](https://github.com/obra/superpowers) (`7.0.1`, licencia MIT en [LICENSE.txt](LICENSE.txt)).

package/skills/depurar/agents/openai.yaml

@@ -1,7 +0,0 @@
-interface:
-  display_name: "Depurar"
-  short_description: "Investiga la causa raíz con evidencia antes de corregir"
-  default_prompt: "Usa $depurar para reproducir este fallo, reunir evidencia y confirmar la causa raíz antes de proponer una corrección."
-
-policy:
-  allow_implicit_invocation: true

package/skills/depurar/references/tecnicas-de-diagnostico.md

@@ -1,37 +0,0 @@
-# Técnicas de diagnóstico
-
-Carga esta referencia cuando el error aparezca lejos de su causa original, atraviese varios procesos o provoque fallos intermitentes en pruebas.
-
-## 1. Rastreo hacia atrás (backward tracing)
-
-Cuando un fallo ocurre en una operación profunda (por ejemplo, abrir una ruta equivocada, ejecutar un comando en el directorio raíz o recibir `undefined` en un validador interno):
-
-1. **Anota el síntoma exacto** y la línea que lanza el error.
-2. **Identifica la causa inmediata:** ¿qué variable o parámetro llegó con un valor inválido?
-3. **Sube un nivel por llamada:** ¿qué función invocó a esta y de dónde sacó ese argumento?
-4. **Repite hasta el disparador original:** busca inicializaciones incompletas, promesas sin esperar, configuraciones vacías o fixtures leídos antes de prepararse.
-5. **Corrige en la fuente:** arreglar únicamente el consumidor final oculta el defecto y deja el dato corrupto circulando por el resto del flujo.
-
-Si no basta con leer el código, captura el contexto justo **antes** de la operación peligrosa (ruta recibida, `process.cwd()`, variables relevantes y `new Error().stack`). En pruebas de Node.js usa `console.error` temporalmente si el runner silencia logs normales, y retira toda instrumentación temporal antes de cerrar.
-
-## 2. Defensa en profundidad tras hallar la causa
-
-Cuando un dato inválido atravesó varias capas sin detectarse, acompasa la corrección en el origen con validaciones proporcionales en las fronteras reales:
-
-- **Capa 1 — Entrada pública / contrato:** rechazar entradas vacías, tipos erróneos o rutas no normalizadas al cruzar la interfaz.
-- **Capa 2 — Lógica de dominio:** comprobar precondiciones propias de la operación antes de actuar.
-- **Capa 3 — Guardas de entorno:** impedir efectos peligrosos fuera del contexto previsto (por ejemplo, en pruebas rechazar escrituras o `git init` fuera del directorio temporal propio).
-
-No añadas capas redundantes sin propósito; añade aquellas donde otra ruta de llamada o un doble de prueba podría saltarse la primera validación. Comprueba que cada guarda rechaza el caso inválido esperado.
-
-## 3. Esperas basadas en condición frente a fallos intermitentes
-
-Las pruebas asíncronas que usan `setTimeout` o `sleep` con tiempos arbitrarios pasan en máquinas rápidas y fallan bajo carga o en otros sistemas operativos.
-
-- **Regla:** espera a la **condición observable** que te importa (evento emitido, estado alcanzado, archivo escrito, línea JSON recibida), nunca a una estimación de cuántos milisegundos tardará.
-- **Sondeo seguro:** si no existe evento directo, consulta el estado fresco dentro del bucle cada `10–25 ms` e incluye siempre un `timeout` explícito con un mensaje que indique qué condición no llegó a cumplirse.
-- **Única excepción para tiempos fijos:** cuando se prueba un temporizador real (`debounce`, expiración de TTL, `timeout`). En ese caso espera primero la condición de arranque y documenta en una línea por qué el intervalo elegido corresponde al contrato probado.
-
----
-
-Técnicas adaptadas al español para Agent Toolkit a partir de `systematic-debugging` en [obra/superpowers](https://github.com/obra/superpowers) (`7.0.1`, MIT).

package/skills/desarrollo-con-pruebas/SKILL.md

@@ -1,55 +0,0 @@
----
-name: desarrollo-con-pruebas
-license: MIT
-description: Aplica el ciclo rojo, verde y refactorización para implementar funciones o correcciones mediante pruebas que primero fallan por el requisito buscado. Úsala cuando se elija desarrollo guiado por pruebas en código comprobable; no la fuerces en cambios documentales, configuración pura o tareas sin prueba automatizada razonable.
----
-
-# Desarrollo con pruebas (TDD)
-
-Escribe primero una prueba que exprese el comportamiento requerido, comprueba que falla por el motivo correcto y escribe solo el código necesario para pasarla. Si nunca viste fallar la prueba, no has comprobado que detecte el defecto.
-
-## Cuándo aplica y cuándo usar otro flujo
-
-| Tipo de tarea | Qué hacer |
-| --- | --- |
-| Nueva función, cambio de lógica, validación o contrato de código | Aplicar el ciclo **Rojo → Verde → Refactorizar** de esta skill. |
-| Corrección de un fallo ya diagnosticado con `depurar` | Escribir primero la prueba de regresión que reproduce el fallo y luego corregir. |
-| Cambio documental, texto de ayuda, configuración estática o activos visuales | **No forzar TDD**: documentar y ejecutar la comprobación apropiada (enlaces, formato, validación de esquema o inspección). |
-| Prototipo descartable (`spike`) autorizado como exploración | Omitir o reducir pruebas durante la exploración; si el resultado se quiere conservar para producción, pasar entonces por especificación y pruebas reales. |
-
-Si en la sesión ya está activo `test-driven-development` de Superpowers, mantén **un único ciclo** sin duplicar pasos, respetando siempre las reglas locales de abajo sobre modo `tutor` y preservación de trabajo existente.
-
-## Ciclo Rojo → Verde → Refactorizar
-
-1. **ROJO — Escribir una prueba mínima del comportamiento:**
-   - Una sola responsabilidad por prueba, con nombre descriptivo y expectativas calculadas de forma independiente (sin reutilizar la función bajo prueba).
-   - Ejercita código real; usa dobles o mocks solo para fronteras lentas o externas inevitables. Consulta [cómo escribir buenas pruebas](references/buenas-pruebas.md).
-2. **Verificar ROJO — Observar el fallo esperado:**
-   - Ejecuta el comando de prueba pertinente y lee la salida completa.
-   - Confirma que **falla por ausencia del requisito** (aserciones o interfaz aún no implementada), no por errores de sintaxis, imports rotos o erratas en el test.
-   - Si pasa a la primera, la prueba no exige nada nuevo: corrige la prueba antes de tocar código de producción.
-3. **VERDE — Implementar el código mínimo:**
-   - Escribe la solución más simple y clara que satisfaga la prueba actual, sin anticipar opciones no pedidas ni mezclar cambios ajenos.
-4. **Verificar VERDE — Comprobar prueba y suite:**
-   - Ejecuta la prueba nueva y confirma que pasa sin errores ni advertencias inesperadas.
-   - Antes de dar el cambio por terminado, ejecuta también la **suite relevante del proyecto** (`npm test`, `node --test` o el comando del repositorio). Informa por su nombre cualquier fallo que aparezca, incluso si era previo o ajeno al alcance.
-5. **REFACTORIZAR — Limpiar manteniendo el verde:**
-   - Solo con las pruebas en verde, elimina duplicación, aclara nombres o extrae utilidades sin añadir comportamiento nuevo, y vuelve a ejecutar las pruebas.
-
-## Reglas esenciales en Agent Toolkit
-
-- **No destruir trabajo existente:** nunca borres ni descartes código ya escrito por el usuario o presente en el árbol de trabajo para imponer el orden del método. Si ya existe implementación parcial, consérvala, informa al usuario y comprueba la cobertura sobre el siguiente incremento o verifica el fallo de forma acordada y no destructiva.
-- **Modo `tutor` (escritura humana paso a paso):**
-  1. *Paso Rojo:* explica qué comportamiento protege la prueba, entrega el bloque de prueba para el archivo exacto e indica el comando y el fallo concreto que el usuario debe observar al ejecutarlo; **detente y espera**.
-  2. *Paso Verde:* tras confirmar con el usuario el fallo esperado, explica y entrega la implementación mínima y el comando para verla pasar; **detente y espera**.
-  3. *Paso Refactor (si aplica):* entrega la mejora opcional conservando las pruebas en verde.
-  En `tutor` el agente no edita archivos funcionales salvo petición explícita («escríbelo tú en este paso»).
-- **Permisos:** ejecutar comandos, editar archivos, crear commits o actualizar memoria siguen sujetos a las autorizaciones vigentes de la sesión y del proyecto.
-
-## Ejemplo verificable (modo tutor y autónomo)
-
-- **Requisito:** rechazar identificadores de perfil con saltos de ruta como `../fuera`.
-- **Rojo:** añadir prueba `assert.rejects(() => validarPerfil('../fuera'), /perfil no válido/u)` y ejecutar `node --test test/perfiles.test.js` → confirmar fallo porque `../fuera` aún no se rechaza. *(En `tutor`, el agente entrega solo este paso y espera la salida del usuario).*
-- **Verde:** validar el identificador con `/^[A-Za-z0-9][A-Za-z0-9._-]{0,63}$/u` en el módulo correspondiente → repetir `node --test test/perfiles.test.js` y después la suite del proyecto → pasa en verde.
-
-Lee [criterios para pruebas honestas](references/buenas-pruebas.md) al diseñar casos, dobles o comprobaciones de regresión. Adaptada de [obra/superpowers](https://github.com/obra/superpowers) (`7.0.1`, licencia MIT en [LICENSE.txt](LICENSE.txt)).

package/skills/desarrollo-con-pruebas/agents/openai.yaml

@@ -1,7 +0,0 @@
-interface:
-  display_name: "Desarrollo con pruebas"
-  short_description: "Implementa con ciclo rojo, verde y refactor verificable"
-  default_prompt: "Usa $desarrollo-con-pruebas para guiar o implementar este cambio mediante una prueba que falle primero por el requisito esperado."
-
-policy:
-  allow_implicit_invocation: true

package/skills/desarrollo-con-pruebas/references/buenas-pruebas.md

@@ -1,33 +0,0 @@
-# Cómo escribir buenas pruebas
-
-Carga esta referencia al redactar pruebas nuevas, revisar tests existentes o decidir si hace falta un doble (`mock` / `fixture`).
-
-## 1. Nombrar la rotura que la prueba atrapa
-
-Antes de escribir el cuerpo del test, responde: **¿qué cambio erróneo en producción haría fallar esta prueba?**
-
-- **Deriva el resultado esperado a mano:** usa literales o fixtures comprobados manualmente. Si calculas el valor esperado llamando a la misma función o helper bajo prueba, la aserción pasará incluso cuando la lógica esté rota.
-- **Prueba comportamiento observable, no detectores de cambio:** evita fijar detalles internos privados o buscar líneas literales con expresiones regulares sobre archivos de código o scripts; ejecuta el módulo o comando con entradas controladas y comprueba su salida, efecto o código de retorno.
-- **Tu frontera, no el framework:** comprueba los contratos, validaciones y efectos de tu código; no escribas pruebas para demostrar que Node.js, el router o la librería estándar funcionan como documentan sus autores.
-
-## 2. Ejercitar el componente real
-
-- **Nunca hagas aserciones sobre el propio mock:** comprobar que un mock devolvió lo que tú mismo le configuraste no demuestra nada del sistema real. Comprueba el resultado o estado real del componente bajo prueba.
-- **Sustituye solo la frontera lenta o externa:** conoce primero todos los efectos secundarios del método real y reemplaza únicamente el nivel externo necesario (red, cliente remoto, reloj o proceso pesado), manteniendo real la lógica, validación y persistencia local en directorios temporales aislados.
-- **Espeja estructuras reales completas:** cuando uses un fixture o respuesta simulada, incluye todos los campos relevantes del contrato real para no ocultar errores cuando el código lea propiedades omitidas.
-- **Mantén las utilidades de limpieza fuera de producción:** los helpers que solo existen para pruebas viven en `test/` o `test-support/`, nunca como métodos artificiales en los módulos de producción.
-
-## 3. Chequeo rápido de mutaciones
-
-Antes de cerrar un archivo de pruebas, piensa si al menos una prueba caería en rojo ante estas mutaciones realistas en producción:
-
-1. Condición invertida o rama omitida.
-2. Falta de validación para entrada vacía, nula, malformada o sin permiso.
-3. Efecto secundario ausente (no guardar, no cerrar, o modificar una ruta indebida).
-4. Valor devuelto por defecto o constante equivocada.
-
-Si una mutación importante dejaría toda la suite en verde, falta una aserción de comportamiento o una prueba de borde.
-
----
-
-Referencia adaptada al español para Agent Toolkit a partir de `writing-good-tests.md` en [obra/superpowers](https://github.com/obra/superpowers) (`7.0.1`, MIT).

package/skills/estado/SKILL.md

@@ -1,41 +0,0 @@
----
-name: estado
-description: Muestra en una tabla el estado de la revisión cruzada entre Claude y Codex en el repositorio actual (colaboraciones abiertas, encargos pendientes y últimos veredictos), sin modificar nada. Úsala solo cuando el usuario escriba /estado o $estado.
----
-
-# Estado de la revisión cruzada
-
-Solo lectura: no reclames, envíes, canceles ni cierres nada.
-
-1. `projectRoot` es la ruta absoluta de la raíz del repositorio actual.
-2. Llama `get_collaboration` sin `taskId` para listar las colaboraciones abiertas.
-3. Para cada una, llama `get_collaboration` con su `taskId`.
-4. Muestra exactamente este formato:
-
-```markdown
-**Revisión cruzada** · <proyecto> · <n> colaboraciones abiertas
-
-| Colaboración | Principal | Encargos | Pendiente ahora | Último veredicto | ¿Vigente? |
-| --- | --- | --- | --- | --- | --- |
-| Validar firma de Meta | Claude | 3 (2 completados, 1 pendiente) | Codex debe revisar | Requiere cambios | Sí |
-
-**Qué toca ahora**
-- Codex: escribir `$revisar` si no está esperando.
-```
-
-- **Encargos:** total y reparto por estado (`pending`, `claimed`, `completed`, `stale`, `cancelled`).
-- **Pendiente ahora:** quién tiene que actuar: el revisor si hay un encargo `pending` o `claimed`; el principal si el último encargo está `completed` y aún no hay otro; «Nadie» si no hay encargos.
-- **Último veredicto:** el texto que sigue a «Veredicto:» en el último informe completado; si no aparece, «Sin veredicto».
-- **¿Vigente?:** «Sí» si el último informe tiene `current: true`; «No, cambió el código» si `filesCurrent` es falso; «No, cambió el contexto» si `contextCurrent` es falso.
-- **Qué toca ahora:** una línea por acción, con el comando exacto (`/revisar`, `$revisar`, `/programar <tarea>` o `$programar <tarea>`).
-
-Si no hay colaboraciones abiertas, dilo en una línea y sugiere `/programar <tarea>` para empezar.
-
-Si el usuario pide el rendimiento de los modelos, ejecuta
-`node <toolkit>/bin/agent-toolkit-inbox.js rendimiento`
-(añade `--project-root <projectRoot>` para limitarlo a este proyecto) y muestra
-su tabla tal cual. No usa ningún modelo ni modifica nada.
-
-Resuelve `<toolkit>` desde la carpeta física de esta skill, dos directorios arriba.
-Para consumo usa `node <toolkit>/bin/agent-toolkit-inbox.js consumo --project-root <raíz>`;
-no confundas rendimiento de hallazgos con ahorro de tokens.

package/skills/programar/SKILL.md

@@ -1,19 +0,0 @@
----
-name: programar
-description: Trabaja como agente principal de la revisión cruzada entre Claude y Codex. Recibe la tarea escrita después del comando, recomienda modelo y esfuerzo, programa respetando las reglas del proyecto, se revisa y pide revisión al otro agente. Úsala solo cuando el usuario escriba /programar o $programar.
----
-
-# Programar
-
-Eres el **agente principal**: haces el trabajo y pides revisión a la otra terminal.
-
-1. Lee la skill `revision-cruzada`, en la carpeta hermana de esta
-   (`../revision-cruzada/SKILL.md`), y sigue su papel **Iniciar (agente
-   principal)**, incluida la sección **Implementar y pedir revisión**. Si el plugin
-   `niveles` está instalado, delega el código según **Delegar por nivel (Claude)**
-   en lugar de pedir al usuario que cambie `/model`.
-2. La tarea es el texto que el usuario escribió después de `/programar` o
-   `$programar`. Si no escribió nada, pídesela en una línea y espera.
-3. No preguntes qué papel tienes: ya lo eligió con este comando.
-4. Si la otra terminal no está atendiendo, recuérdale que escriba allí
-   `/revisar` (Claude) o `$revisar` (Codex).

package/skills/spec-driven-development/SKILL.md

@@ -1,48 +0,0 @@
----
-name: spec-driven-development
-license: MIT
-description: Convierte una necesidad de software en intención acordada, comparación de alternativas, especificación verificable y plan de tareas ejecutables antes de implementar. Úsala para funciones nuevas, cambios entre módulos, migraciones o rediseños; usa un flujo directo sin esta skill para preguntas simples o ajustes puntuales sin ambigüedad.
----
-
-# Desarrollo guiado por especificaciones
-
-Entiende qué quiere lograr la persona usuaria y por qué, acuerda un resultado observable y divídelo en tareas verificables antes de tocar código.
-
-## Cuándo aplica y cuándo usar algo más simple
-
-| Situación | Proceso |
-| --- | --- |
-| Pregunta conceptual o consulta de lectura | Responder directamente; no iniciar especificación ni plan. |
-| Cambio puntual e inequívoco (un texto, constante o estilo aislado) | Hacer o guiar el cambio y comprobarlo; no abrir documentos de diseño. |
-| Cambio pequeño con alguna decisión abierta | Profundidad **ligera**: nota breve con intención, enfoque elegido y comprobación. |
-| Función nueva, cambio entre módulos, datos, permisos o migración | Profundidad **estándar** o **rigurosa**: seguir el flujo completo de esta skill. |
-| Fallo, regresión o comportamiento inesperado | Investigar primero la causa raíz con `depurar` antes de especificar un rediseño. |
-
-Si el usuario pide explícitamente saltar las preguntas e ir directo a la acción, deja constancia en una línea de cualquier supuesto técnico relevante y continúa con el flujo normal del encargo.
-
-## Convivencia y reutilización
-
-Mantén **un único flujo principal**:
-- Si en la sesión o el repositorio ya existe un diseño o plan aprobado para el mismo objetivo (por ejemplo en `docs/planes/`, `docs/superpowers/specs/` o `docs/superpowers/plans/`), **reutilízalo**; comprueba solo si quedó algún hueco frente al código actual y no abras otra entrevista ni reescribas el plan desde cero.
-- Respeta siempre la jerarquía de instrucciones del proyecto, el modo `tutor` o `autonomous` declarado y los permisos vigentes. Esta skill no concede permisos de escritura, ramas, commits, memoria ni despliegue.
-
-## Flujo
-
-1. **Inspeccionar antes de preguntar:** lee los archivos citados, el código relacionado y la memoria disponible del proyecto hasta poder explicar cómo funciona hoy la parte afectada. Nunca preguntes algo que el repositorio o el contexto ya respondan.
-2. **Aclarar la intención:** resume en tus palabras qué se busca, para quién y qué tocaría en el código actual. Haz **una sola pregunta concreta** por turno sobre la mayor incógnita que cambiaría lo que se construye (o propón una opción razonable indicando el motivo para que el usuario la corrija).
-3. **Comparar alternativas:** antes de redactar la especificación, presenta en un mensaje propio las 2 o 3 formas reales de resolverlo en este proyecto, sus compensaciones y tu recomendación justificada (o explica por qué solo una encaja). Espera a que el usuario elija.
-4. **Especificar con criterios observables:** redacta un documento proporcional al tamaño (breve o completo) separando lo acordado por el usuario de las decisiones propuestas por el agente. Lee [el flujo, estructura del plan y puertas](references/workflow.md).
-5. **Obtener aprobación del diseño:** no escribas código de producto, instales dependencias ni inicies la implementación hasta que el usuario apruebe el diseño (salvo un prototipo descartable autorizado como tal).
-6. **Planificar tareas ejecutables:** descompón por responsabilidades y dependencias en tareas con resultado comprobable por sí mismo: rutas exactas, firmas/interfaces entre tareas, pasos inequívocos, casos de riesgo cubiertos y comando de verificación con resultado esperado. Revisa el plan contra la especificación antes de entregarlo.
-7. **Implementar y verificar según el modo:**
-   - En **modo `tutor`**: explica y entrega el código de **un paso verificable cada vez**; la persona usuaria escribe y tú revisas el resultado real antes de pasar al siguiente.
-   - En **modo `autonomous`** autorizado: ejecuta tarea por tarea respetando el alcance aprobado y verifica cada entrega con evidencia fresca (apoyándote en `desarrollo-con-pruebas` y `quality-gate` cuando correspondan).
-
-## Reglas
-
-- La especificación describe el comportamiento deseado; el repositorio describe el comportamiento actual.
-- Distingue siempre decisiones confirmadas por el usuario, propuestas tuyas y preguntas abiertas; no inventes acuerdos para rellenar plantillas.
-- Prohibido dejar pasos vagos en un plan (`por definir`, `manejar casos límite`, `añadir validación adecuada`) o transcribir programas enteros cuando bastan firmas, contratos y aserciones.
-- Conserva el trabajo existente en el repositorio; si el alcance crece a mitad de tarea, avísalo y reajusta el tamaño con el usuario.
-
-Usa [la plantilla](references/spec-template.md) solo si el proyecto no define una propia. Prácticas de entrevista de diseño y planificación ejecutable adaptadas parcialmente de [obra/superpowers](https://github.com/obra/superpowers) (`7.0.1`, licencia MIT en [LICENSE.txt](LICENSE.txt)).

package/skills/spec-driven-development/agents/openai.yaml

@@ -1,7 +0,0 @@
-interface:
-  display_name: "Spec-Driven Development"
-  short_description: "Alinea intención, alternativas, especificación y plan ejecutable"
-  default_prompt: "Usa $spec-driven-development para aclarar la intención, comparar alternativas y preparar una especificación y un plan verificables antes de implementar."
-
-policy:
-  allow_implicit_invocation: true

package/skills/spec-driven-development/references/spec-template.md

@@ -1,55 +0,0 @@
-# [Nombre del cambio]
-
-## Estado y modo
-
-- Estado: Propuesto | Aprobado | En implementación | Verificado | Archivado
-- Modo de ejecución previsto: `tutor` | `autonomous` (sujeto a reglas del proyecto)
-
-## Intención y problema
-
-## Objetivo, fuera de alcance y anti-objetivos
-
-## Comportamiento actual comprobado
-
-## Alternativas consideradas y elección
-
-| Opción | Resumen | Ventajas | Compensaciones |
-| --- | --- | --- | --- |
-| A | | | |
-| B | | | |
-
-- **Opción elegida y motivo:**
-
-## Decisiones del usuario frente a propuestas técnicas
-
-- **Acordado por el usuario:**
-- **Propuesto por el agente (revisable):**
-
-## Requisitos y criterios de aceptación
-
-- Dado ..., cuando ..., entonces ...
-
-## Diseño, contratos, datos y seguridad
-
-## Foco de revisión (entradas límite y modos de fallo)
-
-- [ ] Caso / entrada límite — comportamiento esperado — tarea que lo verifica
-
-## Mapa de archivos
-
-- Crear / Modificar: `ruta/exacta` — responsabilidad
-- Pruebas / Verificación: `ruta/exacta` — qué comprueba
-
-## Plan de tareas
-
-### Tarea 1: [Entregable verificable]
-
-- **Archivos:** Crear/Modificar `...` · Probar `...`
-- **Interfaces:** Consume `...` · Produce `...`
-- [ ] Paso 1 (prueba o preparación verificable): ...
-- [ ] Paso 2 (implementación mínima): ...
-- [ ] Paso 3 (verificación): ejecutar `...` → resultado esperado `...`
-
-## Evidencia de cierre y límites observados
-
-## Preguntas abiertas

package/skills/spec-driven-development/references/workflow.md

@@ -1,70 +0,0 @@
-# Flujo, planificación ejecutable y puertas de SDD
-
-## Elegir profundidad
-
-- **Ligera**: cambio pequeño, reversible y localizado (resumen corto de intención, alternativas vistas, cambio acordado y verificación).
-- **Estándar**: función que cruza módulos, contratos, estado o interfaz.
-- **Rigurosa**: seguridad, permisos, datos críticos, concurrencia, arquitectura, despliegue o migración.
-
-Si la solicitud abarca varios subsistemas independientes, proponlo al inicio y abórdalos en especificaciones y planes separados, uno a la vez.
-
-## 1. Descubrir mirando primero el proyecto
-
-Antes de formular la primera pregunta:
-1. Inspecciona el código, pruebas, esquemas y notas estables conectadas con la petición.
-2. Identifica restricciones existentes (versiones, contratos públicos, convenciones de nombres y estilo del repositorio).
-3. Refleja en ~150–250 palabras qué entendiste, cómo opera hoy esa parte y qué restricciones o caminos más sencillos observaste.
-4. Cierra con una sola pregunta abierta cuya respuesta cambie materialmente el diseño, explicando qué cambiaría según la respuesta.
-
-**Puerta:** el problema, el estado actual comprobado y el motivo del cambio pueden explicarse sin asumir acuerdos que el usuario no dio.
-
-## 2. Comparar alternativas antes de escribir la especificación
-
-1. Descarta opciones que contradigan el objetivo o las restricciones reales del repositorio.
-2. Presenta 2 o 3 alternativas viables ancladas en la arquitectura actual, indicando qué gana y qué sacrifica cada una.
-3. Recomienda una con motivo claro y pide al usuario elegir (si existe una única vía sensata, explica por qué las demás no encajan).
-4. Si un prototipo rápido (`spike`) es la forma más barata de despejar una duda técnica, ofrécelo explícitamente como descartable: lo que produzca no pasa a producción sin volver por diseño y pruebas.
-
-**Puerta:** hay un enfoque elegido por el usuario y los compromisos asumidos son explícitos.
-
-## 3. Especificar y diseñar
-
-Define:
-- Objetivo, no-objetivos y anti-objetivos (qué haría fracasar la entrega aunque técnicamente compile).
-- Comportamiento actual comprobado frente a comportamiento esperado.
-- Criterios de aceptación observables, errores y casos límite.
-- Componentes afectados, contratos, datos, privacidad y seguridad.
-- Qué decidió el usuario frente a qué propones tú como criterio técnico.
-
-**Puerta:** otra persona podría construir o revisar el cambio sin volver a adivinar requisitos esenciales, y el usuario aprobó el diseño.
-
-## 4. Planificar tareas ejecutables
-
-Escribe el plan pensando en quien implementa conociendo el lenguaje, pero sin haber estado en tu conversación:
-
-1. **Mapa de archivos y responsabilidades:** enumera antes de las tareas qué archivos se crean o modifican y qué responsabilidad única tiene cada uno, respetando la estructura del proyecto.
-2. **Tamaño correcto de tarea:** cada tarea es la unidad mínima que cierra un ciclo verificable propio (incluyendo su prueba, ajuste de configuración o documentación directa). No separes andamiaje vacío que no pueda comprobarse por sí solo.
-3. **Estructura por tarea:**
-   - **Archivos:** rutas exactas (`Crear`, `Modificar`, `Probar`).
-   - **Interfaces:** qué consume de tareas previas y qué nombres/firmas exactas produce para las siguientes.
-   - **Pasos accionables:** cada paso pide una acción concreta con resultado verificable (escribir prueba que falla con los valores de la especificación, comprobar el fallo esperado, implementar la firma acordada, ejecutar comando de verificación y confirmar salida).
-4. **Foco de revisión (casos implícitos):** identifica hasta 5 clases de entradas o fallos probables que la especificación implica (valores vacíos, rutas fuera de raíz, permisos, concurrencia, errores parciales) y añade su comprobación en la tarea dueña de ese código.
-5. **Autochequeo del plan antes de entregarlo:**
-   - *Cobertura:* cada requisito y criterio de aceptación tiene tarea asignada.
-   - *Sin huecos ni relleno:* elimina frases que no deciden nada (`TBD`, `validar adecuadamente`) y evita copiar cuerpos enteros de funciones que la firma y la prueba ya determinan.
-   - *Consistencia:* nombres de archivos, funciones, tipos y opciones coinciden entre tareas tempranas y tardías.
-
-**Puerta:** el plan está autoverificado, reutiliza planes previos si existían y el usuario confirma el plan y el modo de ejecución (`tutor` o `autonomous`).
-
-## 5. Implementar respetando el modo
-
-- **Modo `tutor`:** entrega un único paso verificable (objetivo, ruta exacta, código explicado y comando de comprobación) y espera a que la persona escriba y confirme con la salida real.
-- **Modo `autonomous`:** ejecuta una tarea a la vez dentro del alcance autorizado; si usas TDD, apóyate en `desarrollo-con-pruebas`. No amontones cambios fuera de alcance.
-
-**Puerta:** las comprobaciones de la tarea y la suite relevante del proyecto pasan en el estado actual.
-
-## 6. Verificar y cerrar
-
-Relaciona cada criterio de aceptación con evidencia fresca ejecutada o inspeccionada (usa `quality-gate`). Declara cualquier desviación o límite no comprobado; commit, PR y cierre de memoria requieren su propia autorización.
-
-**Puerta:** ningún criterio queda sin evidencia ni se afirma finalización por suposición.