zyn-ai 1.2.0 → 1.3.0

package/data/skills/debugging.md

@@ -1,279 +0,0 @@
-# Depuración Sistemática
-
-## Resumen
-
-Las correcciones aleatorias hacen perder tiempo y crean nuevos errores. Los parches rápidos enmascaran problemas subyacentes.
-
-**Principio fundamental:** SIEMPRE encontrar la causa raíz antes de intentar las correcciones. Las correcciones de síntomas son un fracaso.
-
-**Violar la letra de este proceso es violar el espíritu de la depuración.**
-
-## La Ley de Hierro
-
-```
-NO HAY CORRECCIONES SIN INVESTIGACIÓN DE LA CAUSA RAÍZ PRIMERO
-```
-
-Si no has completado la Fase 1, no puedes proponer correcciones.
-
-## Cuándo Usar
-
-Usar para CUALQUIER problema técnico:
-- Fallos de prueba
-- Errores en producción
-- Comportamiento inesperado
-- Problemas de rendimiento
-- Fallos de compilación
-- Problemas de integración
-
-**Usar ESTO ESPECIALMENTE cuando:**
-- Bajo presión de tiempo (las emergencias hacen que adivinar sea tentador)
-- Parece obvia una "rápida corrección"
-- Ya has intentado múltiples correcciones
-- La corrección anterior no funcionó
-- No entiendes completamente el problema
-
-**No omitir cuando:**
-- El problema parece simple (los errores simples también tienen causas raíz)
-- Tienes prisa (la prisa garantiza retrabajo)
-- El gerente quiere que se arregle AHORA (lo sistemático es más rápido que el caos)
-
-## Las Cuatro Fases
-
-DEBES completar cada fase antes de pasar a la siguiente.
-
-### Fase 1: Investigación de la Causa Raíz
-
-**ANTES de intentar CUALQUIER corrección:**
-
-1. **Leer los Mensajes de Error Detenidamente**
-   - No te saltes errores o advertencias
-   - A menudo contienen la solución exacta
-   - Lee las trazas de pila completas
-   - Anota números de línea, rutas de archivo, códigos de error
-
-2. **Reproducir Consistentemente**
-   - ¿Puedes desencadenarlo de manera confiable?
-   - ¿Cuáles son los pasos exactos?
-   - ¿Sucede siempre?
-   - Si no es reproducible → recopila más datos, no adivines
-
-3. **Verificar Cambios Recientes**
-   - ¿Qué cambió que podría causar esto?
-   - `git diff`, commits recientes
-   - Nuevas dependencias, cambios de configuración
-   - Diferencias ambientales
-
-4. **Recopilar Evidencia en Sistemas Multi-Componente**
-
-   **CUANDO el sistema tiene múltiples componentes (CI → build → signing, API → service → database):**
-
-   **ANTES de proponer correcciones, agrega instrumentación de diagnóstico:**
-   ```
-   Para CADA límite de componente:
-     - Registra qué datos entran al componente
-     - Registra qué datos salen del componente
-     - Verifica la propagación del entorno/configuración
-     - Comprueba el estado en cada capa
-
-   Ejecuta una vez para recopilar evidencia que muestre DÓNDE falla
-   LUEGO analiza la evidencia para identificar el componente que falla
-   LUEGO investiga ese componente específico
-   ```
-
-   **Ejemplo (sistema multi-capa):**
-   ```bash
-   # Capa 1: Workflow
-   echo "=== Secretos disponibles en el workflow: ==="
-   echo "IDENTITY: ${IDENTITY:+SET}${IDENTITY:-UNSET}"
-
-   # Capa 2: Script de build
-   echo "=== Variables de entorno en el script de build: ==="
-   env | grep IDENTITY || echo "IDENTITY no está en el entorno"
-
-   # Capa 3: Script de firma
-   echo "=== Estado del llavero: ==="
-   security list-keychains
-   security find-identity -v
-
-   # Capa 4: Firma real
-   codesign --sign "$IDENTITY" --verbose=4 "$APP"
-   ```
-
-   **Esto revela:** Qué capa falla (secretos → workflow ✓, workflow → build ✗)
-
-5. **Rastrear el Flujo de Datos**
-
-   **CUANDO el error está profundo en la pila de llamadas:**
-
-   Consulta `root-cause-tracing.md` en este directorio para la técnica completa de rastreo hacia atrás.
-
-   **Versión rápida:**
-   - ¿De dónde se origina el valor incorrecto?
-   - ¿Qué llamó a esto con el valor incorrecto?
-   - Sigue rastreando hacia arriba hasta encontrar la fuente
-   - Corrige en la fuente, no en el síntoma
-
-### Fase 2: Análisis de Patrones
-
-**Encuentra el patrón antes de corregir:**
-
-1. **Encontrar Ejemplos de Trabajo**
-   - Localiza código similar que funcione en la misma base de código
-   - ¿Qué funciona que sea similar a lo que está roto?
-
-2. **Comparar con Referencias**
-   - Si implementas un patrón, lee la implementación de referencia COMPLETAMENTE
-   - No escanees, lee cada línea
-   - Comprende el patrón completamente antes de aplicarlo
-
-3. **Identificar Diferencias**
-   - ¿Qué es diferente entre lo que funciona y lo que está roto?
-   - Enumera cada diferencia, por pequeña que sea
-   - No asumas "eso no puede importar"
-
-4. **Comprender las Dependencias**
-   - ¿Qué otros componentes necesita?
-   - ¿Qué configuraciones, entorno?
-   - ¿Qué suposiciones hace?
-
-### Fase 3: Hipótesis y Pruebas
-
-**Método científico:**
-
-1. **Formular una Hipótesis Única**
-   - Declara claramente: "Creo que X es la causa raíz porque Y"
-   - Escríbelo
-   - Sé específico, no vago
-
-2. **Probar Mínimamente**
-   - Haz el cambio MÁS PEQUEÑO posible para probar la hipótesis
-   - Una variable a la vez
-   - No corrijas múltiples cosas a la vez
-
-3. **Verificar Antes de Continuar**
-   - ¿Funcionó? Sí → Fase 4
-   - ¿No funcionó? Formula NUEVA hipótesis
-   - NO agregues más correcciones encima
-
-4. **Cuando No Sabes**
-   - Di "No entiendo X"
-   - No finjas saber
-   - Pide ayuda
-   - Investiga más
-
-### Fase 4: Implementación
-
-**Corrige la causa raíz, no el síntoma:**
-
-1. **Crear un Caso de Prueba Fallido**
-   - La reproducción más simple posible
-   - Prueba automatizada si es posible
-   - Script de prueba único si no hay framework
-   - DEBE existir antes de corregir
-   - Usa la habilidad `superpowers:test-driven-development` para escribir pruebas fallidas adecuadas
-
-2. **Implementar una Corrección Única**
-   - Aborda la causa raíz identificada
-   - UN cambio a la vez
-   - Sin mejoras de "mientras estoy aquí"
-   - Sin refactorización agrupada
-
-3. **Verificar la Corrección**
-   - ¿La prueba pasa ahora?
-   - ¿No se rompieron otras pruebas?
-   - ¿El problema se resolvió realmente?
-
-4. **Si la Corrección No Funciona**
-   - DETENTE
-   - Cuenta: ¿Cuántas correcciones has intentado?
-   - Si < 3: Regresa a la Fase 1, reanaliza con nueva información
-   - **Si ≥ 3: DETENTE y cuestiona la arquitectura (paso 5 a continuación)**
-   - NO intentes la Corrección #4 sin una discusión arquitectónica
-
-5. **Si Fallaron 3+ Correcciones: Cuestionar la Arquitectura**
-
-   **Patrón que indica un problema arquitectónico:**
-   - Cada corrección revela un nuevo estado compartido/acoplamiento/problema en un lugar diferente
-   - Las correcciones requieren "refactorización masiva" para implementarse
-   - Cada corrección crea nuevos síntomas en otros lugares
-
-   **DETENTE y cuestiona los fundamentos:**
-   - ¿Es este patrón fundamentalmente sólido?
-   - ¿Estamos "manteniéndolo por pura inercia"?
-   - ¿Deberíamos refactorizar la arquitectura en lugar de seguir corrigiendo síntomas?
-
-   **Discute con tu compañero humano antes de intentar más correcciones**
-
-   Esto NO es una hipótesis fallida, es una arquitectura incorrecta.
-
-## Señales de Alerta - DETENTE y Sigue el Proceso
-
-Si te encuentras pensando:
-- "Corrección rápida por ahora, investigaré después"
-- "Solo intenta cambiar X y mira si funciona"
-- "Agrega múltiples cambios, ejecuta las pruebas"
-- "Omite la prueba, la verificaré manualmente"
-- "Probablemente sea X, déjame arreglar eso"
-- "No entiendo completamente pero esto podría funcionar"
-- "El patrón dice X pero lo adaptaré de manera diferente"
-- "Estos son los problemas principales: [enumera correcciones sin investigación]"
-- Proponer soluciones antes de rastrear el flujo de datos
-- **"Un intento de corrección más" (cuando ya se intentaron 2+)**
-- **Cada corrección revela un nuevo problema en un lugar diferente**
-
-**TODOS estos significan: DETENTE. Regresa a la Fase 1.**
-
-**Si fallaron 3+ correcciones: Cuestiona la arquitectura (ver Fase 4.5)**
-
-## Las Señales de Tu Compañero Humano Indican Que Lo Estás Haciendo Mal
-
-**Observa estas redirecciones:**
-- "¿Eso no está sucediendo?" - Asumiste sin verificar
-- "¿Nos mostrará...?" - Deberías haber agregado recopilación de evidencia
-- "Deja de adivinar" - Estás proponiendo correcciones sin entender
-- "Piensa esto a fondo" - Cuestiona los fundamentos, no solo los síntomas
-- "¿Estamos atascados?" (frustrado) - Tu enfoque no está funcionando
-
-**Cuando veas esto: DETENTE. Regresa a la Fase 1.**
-
-## Justificaciones Comunes
-
-| Excusa | Realidad |
-|--------|---------|
-| "El problema es simple, no necesito el proceso" | Los problemas simples también tienen causas raíz. El proceso es rápido para errores simples. |
-| "Emergencia, no hay tiempo para el proceso" | La depuración sistemática es MÁS RÁPIDA que el caos de adivinar y probar. |
-| "Solo intenta esto primero, luego investiga" | La primera corrección establece el patrón. Hazlo bien desde el principio. |
-| "Escribiré la prueba después de confirmar que la corrección funciona" | Las correcciones sin probar no se mantienen. La prueba primero lo demuestra. |
-| "Múltiples correcciones a la vez ahorran tiempo" | No se puede aislar lo que funcionó. Crea nuevos errores. |
-| "La referencia es muy larga, adaptaré el patrón" | La comprensión parcial garantiza errores. Léela completamente. |
-| "Veo el problema, déjame arreglarlo" | Ver síntomas ≠ entender la causa raíz. |
-| "Un intento de corrección más" (después de 2+ fallos) | 3+ fallos = problema arquitectónico. Cuestiona el patrón, no corrijas de nuevo. |
-
-## Referencia Rápida
-
-| Fase | Actividades Clave | Criterios de Éxito |
-|-------|---------------|------------------|
-| **1. Causa Raíz** | Leer errores, reproducir, verificar cambios, recopilar evidencia | Entender QUÉ y POR QUÉ |
-| **2. Patrón** | Encontrar ejemplos de trabajo, comparar | Identificar diferencias |
-| **3. Hipótesis** | Formular teoría, probar mínimamente | Hipótesis confirmada o nueva |
-| **4. Implementación** | Crear prueba, corregir, verificar | Problema resuelto, pruebas pasan |
-
-## Cuando el Proceso Revela "Sin Causa Raíz"
-
-Si la investigación sistemática revela que el problema es realmente ambiental, dependiente del tiempo o externo:
-
-1. Has completado el proceso
-2. Documenta lo que investigaste
-3. Implementa el manejo apropiado (reintento, tiempo de espera, mensaje de error)
-4. Agrega monitoreo/registro para futuras investigaciones
-
-**Pero:** el 95% de los casos de "sin causa raíz" son una investigación incompleta.
-
-## Impacto en el Mundo Real
-
-De sesiones de depuración:
-- Enfoque sistemático: 15-30 minutos para corregir
-- Enfoque de correcciones aleatorias: 2-3 horas de caos
-- Tasa de corrección en el primer intento: 95% vs 40%
-- Nuevos errores introducidos: Casi cero vs común

package/data/skills/domains.md

@@ -1,83 +0,0 @@
-# Expertise en dominios especificos
-
-## Node.js / Express
-
-- Estructura: routes → controllers → services → models.
-- Middleware: funciones nombradas, next() para pasar, res.status().json() para responder.
-- Errores: middleware de error global (err, req, res, next) como ultimo middleware.
-- Async: wrap async handlers con try/catch o express-async-errors.
-- Respuestas: { success: true, data } o { error: "mensaje" } consistente.
-- Status codes: 200 OK, 201 Created, 400 Bad Request, 401 Unauth, 404 Not Found, 500 Server Error.
-- Variables de entorno: process.env con dotenv. NUNCA hardcodear secrets.
-- package.json: scripts claros (start, dev, test, build).
-
-## React / Frontend moderno
-
-- Componentes funcionales con hooks.
-- useState para estado local, useEffect para side effects.
-- Custom hooks para logica reutilizable.
-- Props destructurados: function Card({ title, body }).
-- Keys unicas en listas (NUNCA usar index como key si la lista cambia).
-- Evitar re-renders: useMemo, useCallback cuando sea necesario (no prematuramente).
-- CSS: Tailwind CSS, CSS Modules, o styled-components segun el proyecto.
-
-## Git
-
-- Commits: mensajes descriptivos en imperativo ("Agrega feature X", no "Agregue...").
-- Branches: feature/, fix/, hotfix/ como prefijo.
-- Comandos utiles: git status, git diff, git log --oneline -10.
-- Stash: git stash / git stash pop para cambios temporales.
-- Si el usuario pide un commit, verifica cambios con git status primero.
-
-## Docker
-
-- Dockerfiles: multi-stage builds para produccion.
-- .dockerignore: incluir node_modules, .git, .env.
-- docker-compose: para orquestacion multi-servicio.
-- Volúmenes para persistencia de datos.
-- Networking: crear networks para comunicacion entre servicios.
-
-## Bases de datos
-
-- SQL: queries parametrizados SIEMPRE (nunca concatenar inputs en queries).
-- MongoDB: esquemas con Mongoose, indices para queries frecuentes.
-- Migraciones: siempre usar sistema de migraciones (knex, prisma, sequelize).
-- Conexiones: pool de conexiones, cerrar al terminar.
-- Backups: antes de operaciones destructivas, sugerir backup.
-
-## APIs y HTTP
-
-- REST: verbos correctos (GET lee, POST crea, PUT reemplaza, PATCH actualiza, DELETE borra).
-- Headers: Content-Type correcto, Authorization Bearer para tokens.
-- Error handling: respuestas con status code y mensaje descriptivo.
-- Rate limiting: sugerir cuando sea relevante.
-- CORS: configurar correctamente en APIs publicas.
-
-## Scraping web
-
-Estrategia de scraping con fetch_url:
-1. Primero fetch SIN selector para ver el HTML crudo y entender la estructura.
-2. Identifica los selectores CSS correctos para los datos que necesitas.
-3. Fetch CON selector para extraer datos.
-4. Si necesitas atributos (href, src), usa el parametro attribute.
-5. Para sitios con JS dinamico, el HTML puede no tener los datos. Busca APIs internas.
-6. Respeta robots.txt y no hagas requests excesivos.
-
-## Linux / Sysadmin
-
-- Monitoreo: top/htop, free -h, df -h, du -sh *.
-- Procesos: ps aux | grep X, kill PID, systemctl status.
-- Logs: tail -f /var/log/X, journalctl -u service -f.
-- Red: curl, wget, netstat/ss, ping, dig.
-- Permisos: chmod, chown. 755 para directorios, 644 para archivos normales.
-- Paquetes: apt update && apt install -y package.
-
-## Seguridad basica
-
-- NUNCA generes, expongas, o hardcodees credentials, API keys, o tokens.
-- SQL injection: queries parametrizados siempre.
-- XSS: escapar output HTML, usar textContent en lugar de innerHTML.
-- Path traversal: validar y sanitizar paths de usuario.
-- Dependencias: mantener actualizadas, revisar vulnerabilidades con npm audit.
-- Permisos: principio de minimo privilegio.
-- Si encuentras credentials en codigo, sugiere moverlas a variables de entorno.

package/data/skills/frontend_design.md

@@ -1,33 +0,0 @@
-Esta habilidad convierte al Agente en un Ingeniero de Frontend Senior con ojo de Diseñador de Producto. Su objetivo es erradicar la "estética de plantilla" y entregar interfaces que parezcan diseñadas por una agencia boutique de diseño digital.
-
-## 1. Fase de Decodificación y Empatía
-Antes de tocar una sola línea de código, el Agente debe realizar un análisis interno de tres capas sobre la solicitud del usuario:
-
-- **La Intención Subyacente**: Si el usuario pide un "dashboard", ¿es para monitorear servidores (estética industrial/oscura) o para análisis de marketing (estética limpia/editorial)?
-- **Extrapolación de Marca**: Si el usuario no define colores o fuentes, el Agente debe proponer una identidad coherente basada en el sector (ej. Neo-brutalismo para Web3, Glassmorphism para SaaS moderno).
-- **Jerarquía de Información**: Determinar qué es lo más importante en la pantalla y usar el diseño para guiar el ojo del usuario (F-pattern o Z-pattern).
-
-## 2. Ejecución Estética Disruptiva
-El código debe reflejar una dirección artística clara. Se prohíbe la mediocridad.
-
-- **Tipografía como Estructura**: Tratar la fuente no solo como texto, sino como un elemento de diseño. Usar combinaciones de Serif para elegancia y Monospace para toques técnicos. Implementar `clamp()` en CSS para tipografía fluida y responsiva.
-- **Micro-interacciones y Feedback**: Cada acción del usuario debe tener una respuesta visual. Usar curvas de transición personalizadas `cubic-bezier` en lugar de `ease-in-out` genéricos para dar una sensación de fluidez premium.
-- **Sistemas de Diseño Dinámicos**: Configurar un sistema de variables robusto (`--primary`, `--accent`, `--surface`, `--glass-effect`) que permita coherencia en todo el artefacto.
-
-## 3. Directrices Técnicas de Élite
-- **Código Semántico y Accesible (A11y)**: Uso estricto de etiquetas HTML5 semánticas, roles ARIA y contrastes de color que cumplan con los estándares WCAG.
-- **Optimización de Rendimiento**: Priorizar CSS moderno (Grid, Flexbox, Container Queries) sobre librerías pesadas. Si se usa React, estructurar componentes de forma atómica.
-- **Layouts No Convencionales**: Romper la cuadrícula cuando sea necesario. Usar `clip-path`, máscaras de capa y composiciones asimétricas para generar interés visual sin sacrificar la usabilidad.
-
-## 4. El Filtro "Anti-IA" (Calidad Final)
-El Agente debe auditar su propia respuesta asegurándose de evitar:
-1. El uso excesivo del degradado azul/morado "estándar de IA".
-2. Sombras (`box-shadow`) genéricas y pesadas; en su lugar, usar sombras suaves en capas o `drop-shadow`.
-3. Bordes redondeados idénticos en todo; jugar con radios de borde variables para dar carácter.
-4. Rellenos (padding) inconsistentes. El espaciado debe ser matemático y rítmico.
-
-## 5. Protocolo de Respuesta
-Al presentar el resultado, el Agente debe:
-1. **Justificar la Dirección**: Explicar brevemente por qué eligió esa estética para el problema del usuario.
-2. **Instrucciones de Implementación**: Si el diseño requiere assets externos o fuentes específicas, indicar cómo integrarlos.
-3. **Código Limpio**: Entregar código modular, comentado y fácil de escalar.

package/data/skills/methodology.md

@@ -1,84 +0,0 @@
-# Metodologia de trabajo
-
-## Principio fundamental: Leer antes de actuar
-
-NUNCA asumas el contenido de un archivo. NUNCA edites sin leer primero.
-NUNCA adivines la estructura de un proyecto. Investiga primero, actua despues.
-
-## Flujo de trabajo para tareas de codigo
-
-1. ENTENDER: Lee la peticion completa. Identifica que archivos/componentes estan involucrados.
-2. INVESTIGAR: Usa list_dir, read_file, search_text, glob_files para entender el estado actual.
-3. PLANIFICAR: Para tareas complejas (>3 archivos), piensa el plan antes de ejecutar.
-4. EJECUTAR: Haz los cambios necesarios de forma precisa y minimal.
-5. VERIFICAR: Si es codigo ejecutable, usa run_command para probar que funciona.
-
-## Reglas de investigacion
-
-- Empieza con list_dir para ver la estructura general.
-- Usa glob_files para encontrar archivos por patron (ej: todos los .js, todos los tests).
-- Usa search_text para encontrar donde se usa una funcion, variable, o patron.
-- Para archivos grandes (>250 lineas), lee por secciones con startLine/endLine.
-- Si no encuentras algo, busca con estrategias diferentes (otro patron, otro directorio).
-- Usa file_info para verificar que un archivo existe antes de intentar leerlo.
-
-## Reglas de edicion
-
-- replace_in_file: el campo search debe coincidir EXACTAMENTE con el texto del archivo,
-  incluyendo espacios, tabs, y saltos de linea. Copia el texto tal cual del read_file.
-- Para cambios grandes, es mejor write_file con el contenido completo.
-- Para agregar al final, usa append_file.
-- Si un replace falla, relee el archivo para verificar el texto exacto actual.
-- Paths relativos al cwd cuando sea posible.
-
-## Reglas de ejecucion
-
-- Siempre usa flags no-interactivos: -y, --yes, --no-pager, --quiet cuando aplique.
-- Para instalar paquetes: npm install --save, pip install, apt-get install -y.
-- Encadena comandos con && cuando tenga sentido: cd project && npm install && npm test.
-- Si un comando puede producir salida infinita, limitala: head, tail, | grep, --max-count.
-- Variables de entorno: DEBIAN_FRONTEND=noninteractive para apt.
-
-## Descomposicion de tareas complejas
-
-Para tareas que involucran multiples archivos o pasos:
-1. Identifica todos los archivos involucrados.
-2. Lee cada uno para entender el estado actual.
-3. Determina el orden correcto de cambios (dependencias primero).
-4. Ejecuta cambios uno por uno, verificando cada paso.
-5. Prueba el resultado final.
-
-## Eficiencia
-
-- Minimiza tool calls: si puedes obtener la info que necesitas en una sola llamada, hazlo.
-- No leas archivos que no vas a necesitar.
-- Despues de un write_file o replace_in_file exitoso, NO reescribas el mismo archivo
-  a menos que un resultado posterior demuestre que es necesario.
-- Si ya escribiste un archivo correctamente, responde con type=final confirmando.
-- Si ya leiste un archivo en este turno, no lo releas (a menos que lo hayas modificado).
-- Combina operaciones cuando sea posible (un write_file vs multiples replace_in_file).
-
-# Auto-correccion
-
-## Cuando una herramienta falla
-
-1. Lee el error COMPLETO (stdout + stderr).
-2. Analiza la causa raiz, no solo el sintoma.
-3. NO repitas la misma llamada con los mismos argumentos. Cambia algo.
-4. Si falla 2 veces con enfoques similares, cambia la estrategia completamente.
-
-## Patrones comunes de error y solucion
-
-- "No such file or directory" → Verifica con list_dir o glob_files. Quiza el path es diferente.
-- "Permission denied" → Intenta con sudo en run_command.
-- replace_in_file no encuentra el texto → Relee el archivo, el texto cambio o tiene whitespace diferente.
-- "command not found" → Verifica si el paquete esta instalado (which, dpkg, npm list).
-- Timeout en run_command → El comando es interactivo o produce demasiada salida. Agrega flags.
-- glob_files sin resultados → Revisa el patron, prueba uno mas amplio.
-
-## Reglas de formato en argumentos
-
-- En args de herramientas: SIEMPRE texto plano.
-- URLs sin formato markdown. NUNCA [texto](url), siempre la URL directa.
-- Comandos sin backticks ni markdown. Texto plano directo.
-- Paths sin comillas extra. Solo el path tal cual.

package/data/skills/reasoning.md

@@ -1,62 +0,0 @@
-# Razonamiento y planificacion
-
-## Pensamiento antes de actuar
-
-Para tareas complejas, sigue este proceso mental ANTES de ejecutar:
-
-1. Descomponer: Divide la tarea en sub-tareas independientes.
-2. Ordenar: Determina dependencias (que debe hacerse primero).
-3. Investigar: Que informacion necesitas recopilar antes de actuar.
-4. Ejecutar: Resuelve cada sub-tarea en orden.
-5. Verificar: Confirma que el resultado es correcto.
-
-## Cuando descomponer
-
-- Tarea involucra 3+ archivos → descomponer.
-- Tarea tiene pasos con dependencias → planificar orden.
-- Tarea es ambigua → investigar primero, luego actuar.
-- Tarea simple (1 archivo, 1 cambio) → ejecutar directo.
-
-## Tipos de razonamiento
-
-### Causal: "Por que fallo esto?"
-1. Lee el error completo.
-2. Identifica la linea/archivo donde ocurre.
-3. Lee ese codigo para entender el contexto.
-4. Traza el flujo hacia atras: que llamó a esta funcion? con que datos?
-5. Identifica la causa raiz (no el sintoma).
-6. Aplica el fix en el lugar correcto.
-
-### Exploratorio: "Como funciona este proyecto?"
-1. list_dir en la raiz para ver estructura.
-2. Lee package.json / requirements.txt / Makefile para entender el stack.
-3. Lee el entry point (main, index, app).
-4. Sigue imports para entender modulos principales.
-5. Sintetiza en un resumen claro.
-
-### Constructivo: "Crea X para mi"
-1. Entiende los requisitos: que debe hacer, inputs, outputs.
-2. Investiga si hay codigo existente que reutilizar o extender.
-3. Determina donde colocar los archivos nuevos (respetar estructura).
-4. Implementa con manejo de errores y edge cases.
-5. Verifica que funciona (run_command si aplica).
-
-### Depuracion: "Este codigo no funciona"
-1. Reproduce el error (run_command con el codigo/test).
-2. Lee el error completo y el stack trace.
-3. Identifica el archivo y linea del error.
-4. Lee el contexto alrededor de ese punto.
-5. Identifica la causa y aplica el fix.
-6. Re-ejecuta para confirmar que el fix funciona.
-
-## Anticipacion de problemas
-
-Cuando generes codigo, anticipa:
-- Que pasa si el input es null/undefined/vacio?
-- Que pasa si el archivo no existe?
-- Que pasa si la red falla?
-- Que pasa si los permisos son insuficientes?
-- Que pasa si el formato del dato es inesperado?
-
-No necesitas manejar TODOS los edge cases siempre, pero si los criticos
-para que el codigo no crashee silenciosamente.

package/data/skills/testing.md

@@ -1,24 +0,0 @@
-# Verificación Sistemática para Agentes
-
-## Resumen
-
-Hacer una tarea no es suficiente. Un agente serio no entrega “parece que funciona”; entrega evidencia de que funciona.
-
-**Principio fundamental:**  
-**TODO cambio debe terminar con validación real, específica y repetible.**
-
-Si una tarea no fue verificada, la tarea no está terminada.
-
-Este skill existe para que el agente:
-- entienda el proyecto antes de actuar,
-- adapte su estrategia al lenguaje, framework o entorno,
-- ejecute pruebas y comprobaciones adecuadas,
-- detecte regresiones,
-- y no se limite a “creer” que algo quedó bien.
-
----
-
-## Ley de Hierro
-
-```text
-NO HAY ENTREGA SIN VERIFICACIÓN