¿systematic-debugging o diagnosing-bugs para encontrar la causa?
Ambas evitan que el agente adivine arreglos, pero entran al problema por extremos distintos. systematic-debugging sostiene un proceso hasta demostrar la causa. diagnosing-bugs se parece más a una investigación práctica del fallo que tienes delante.
La skill systematic-debugging de superpowers ejecuta un análisis de causa raíz en cuatro fases en vez de probar arreglos hasta que el error deja de aparecer. Úsala en fallos que ya sobrevivieron a un intento y en todo lo intermitente, donde adivinar no solo es lento sino directamente engañoso.
Ideal para
Fallos intermitentes, heisenbugs y defectos que volvieron tras un arreglo.
Sáltala si
La causa es obvia en la traza y el arreglo es de una línea.
Cuál instalar
Elige systematic-debugging cuando el fallo es intermitente o nadie logra reproducirlo con fiabilidad, porque su valor está en negarse a aceptar una causa no demostrada. Es la que impide que una sesión termine con un arreglo plausible que nunca se verificó.
La skill diagnosing-bugs separa el diagnóstico de la reparación: entender qué ocurre, demostrarlo y solo entonces cambiar código. Ataca directamente el fallo más caro de la depuración asistida por agentes, que es un parche confiado sobre un síntoma que esconde el defecto real.
Ideal para
Fallos que ya sobrevivieron a un intento de arreglo, y todo lo intermitente.
Sáltala si
El fallo es obvio y local, donde la ceremonia cuesta más de lo que ahorra.
Cuál instalar
Elige diagnosing-bugs cuando hay un fallo concreto que puedes provocar y quieres que la investigación avance en lugar de formalizarse. Es la opción ligera para el caso normal, con el bug delante.
Estas dos se solapan lo suficiente como para competir por la misma tarea, así que conservar ambas suele significar que una nunca se dispara. Si quieres las dos disponibles, estrecha una descripción hasta que nombre la situación a la que sirve y no la actividad.