systematic-debugging
Depurar sistemáticamente para encontrar las causas raíz antes de corregir
También disponible en: Cygnusfear,Cycleaddict,Doyajin174,DMJGilbert,Asmayaseen,DYAI2025,davila7,CodingCossack,obra,ChrisWiles
Las correcciones aleatorias desperdician tiempo y crean nuevos errores. Esta habilidad proporciona un marco de depuración de cuatro fases que encuentra las causas raíz antes de implementar soluciones, evitando el esfuerzo desperdiciado en correcciones basadas en síntomas.
Descargar el ZIP de la skill
Subir en Claude
Ve a Configuración → Capacidades → Skills → Subir skill
Activa y empieza a usar
Pruébalo
Usando "systematic-debugging". La prueba falla con error de git init en el directorio incorrecto
Resultado esperado:
- Fase 1 - Investigación de Causa Raíz:
- 1. El error muestra que git init se ejecuta en /source/code no en /tmp
- 2. Rastreado hacia atrás: git init <- WorktreeManager <- Session.create <- test
- 3. Encontrado: projectDir era una cadena vacía, se resolvió a process.cwd()
- 4. Causa raíz: la prueba accedió a context.tempDir antes de que beforeEach lo inicializara
- Causa raíz identificada: problema de orden de inicialización de variables
Usando "systematic-debugging". Prueba inestable que a veces pierde resultados de herramientas
Resultado esperado:
- Diagnóstico: La prueba usa esperas arbitrarias con setTimeout en lugar de verificación de condiciones
- Solución: Reemplazar tiempos de espera con espera basada en condiciones
- ANTES: await new Promise(r => setTimeout(r, 300))
- DESPUÉS: await waitForEventCount(threadManager, id, 'TOOL_RESULT', 2)
- Resultado: Tasa de aprobación del 60% mejoró al 100%
Auditoría de seguridad
Riesgo bajoStatic analyzer flagged 126 patterns but 125 are false positives from markdown documentation (backticks are code formatting, not shell execution). One legitimate shell script (find-polluter.sh) uses npm test for test debugging - acceptable for a debugging skill. No cryptographic code exists despite scanner claims. Skill teaches debugging methodology safely.
Problemas de riesgo bajo (1)
Factores de riesgo
⚙️ Comandos externos (1)
Puntuación de calidad
Lo que puedes crear
Investigación de Fallos de Pruebas
Cuando las pruebas fallan de manera intermitente o inesperada, usa esta habilidad para rastrear sistemáticamente el fallo hasta su causa raíz en lugar de aplicar correcciones rápidas.
Resolución de Errores en Producción
Cuando aparecen errores en producción, sigue el proceso de cuatro fases para entender la causa raíz antes de implementar correcciones que podrían crear nuevos problemas.
Depuración de Múltiples Componentes
Al depurar sistemas complejos con múltiples capas, usa diagnósticos de defensa en profundidad para identificar exactamente qué componente está fallando.
Prueba estos prompts
Estoy viendo este error: [pegar error]. Quiero corregirlo rápidamente, pero sé que debería investigar primero. Ayúdame a seguir la Fase 1 de depuración sistemática para entender la causa raíz antes de proponer cualquier corrección.
Esta prueba falla de manera intermitente: [pegar prueba]. A veces pasa, a veces falla. Guíame a través de la depuración sistemática para encontrar qué está causando la inestabilidad, incluyendo cómo agregar instrumentación de diagnóstico.
Mi sistema tiene [describir capas: por ejemplo, flujo de trabajo CI, script de firma, proceso de firma]. Algo se está rompiendo pero no sé qué capa. Muéstrame cómo agregar instrumentación de recopilación de evidencia en cada límite para aislar el componente que falla.
Ya he intentado [N] correcciones y ninguna funcionó. Cada corrección reveló un nuevo problema. Ayúdame a detenerme y cuestionar si hay un problema arquitectónico antes de intentar otra corrección. Guíame a través de re-analizar desde la Fase 1.
Mejores prácticas
- Siempre completa la investigación de la Fase 1 antes de proponer cualquier corrección - entender la causa raíz es más rápido que luchar con correcciones aleatorias
- Rastrear errores hacia atrás a través de la pila de llamadas para encontrar el disparador original, no solo donde aparece el error
- Después de 3 intentos de corrección fallidos, detente y cuestiona la arquitectura en lugar de intentar más correcciones de síntomas
Evitar
- Proponer correcciones antes de completar la investigación de causa raíz - esto trata síntomas, no causas
- Hacer múltiples cambios a la vez - no puedes aislar qué funcionó y puedes introducir nuevos errores
- Omitir la creación de la prueba que falla - las correcciones sin pruebas no se mantienen y las regresiones pasan desapercibidas
Preguntas frecuentes
¿No es la depuración sistemática más lenta que intentar correcciones rápidas?
¿Qué pasa si estoy en una emergencia y necesito una corrección ahora?
¿Cómo sé cuándo he encontrado la causa raíz real?
¿Qué pasa si mi primera hipótesis es incorrecta?
¿Cuándo debería cuestionar la arquitectura versus seguir depurando?
¿Esto funciona para errores no relacionados con código, como problemas de configuración?
Detalles del desarrollador
Autor
ZhanlinCuiLicencia
MIT
Repositorio
https://github.com/ZhanlinCui/Ultimate-Agent-Skills-Collection/tree/main/systematic-debuggingRef.
main
Estructura de archivos