systematic-debugging ou diagnosing-bugs para achar a causa?
As duas impedem o agente de chutar correções, mas entram no problema por pontas diferentes. systematic-debugging sustenta um processo até a causa ser provada. diagnosing-bugs se parece mais com uma investigação prática da falha à sua frente.
A skill systematic-debugging do superpowers roda uma análise de causa raiz em quatro fases em vez de tentar correções até o erro parar de aparecer. Use em bugs que já sobreviveram a uma tentativa e em qualquer coisa intermitente, onde chutar não é só lento e sim enganoso.
Ideal para
Falhas intermitentes, heisenbugs e defeitos que voltaram depois de uma correção.
Pule se
A causa é óbvia no stack trace e a correção é de uma linha.
Qual instalar
Escolha systematic-debugging quando a falha é intermitente ou ninguém consegue reproduzir com confiança, porque o valor está em recusar uma causa não provada. É a que impede uma sessão de terminar com uma correção plausível que nunca foi verificada.
A skill diagnosing-bugs separa diagnóstico de reparo: entender o que acontece, provar, e só então mudar código. Ela ataca diretamente a falha mais cara da depuração assistida por agentes, que é um patch confiante em um sintoma que esconde o defeito real.
Ideal para
Bugs que já sobreviveram a uma tentativa de correção, e qualquer coisa intermitente.
Pule se
A falha é óbvia e local, onde a cerimônia custa mais do que economiza.
Qual instalar
Escolha diagnosing-bugs quando existe uma falha concreta que você consegue disparar e você quer a investigação andando em vez de formalizada. É a opção leve para o caso comum, com o bug ali na frente.
As duas se sobrepõem o bastante para disputar a mesma tarefa, então manter ambas normalmente significa que uma nunca dispara. Se quiser as duas disponíveis, estreite uma descrição até ela nomear a situação a que serve, e não a atividade.