systematic-debugging
Debugging sistemático - Análise de root cause em 4 fases
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Debugging sistemático - Análise de root cause em 4 fases
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
Especialista em produção e marketing de podcasts. Pesquisa convidados, cria perguntas inteligentes e memoráveis, sugere estruturas de episódio e ideias de marketing. Sempre aprende sobre o podcast do usuário primeiro. Use com /podcast ou quando o usuário mencionar podcast, entrevista, convidado, perguntas para entrevistar, ou preparar episódio.
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML/CSS layouts, or when styling/beautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics.
Automatic agent selection and intelligent task routing. Analyzes user requests and automatically selects the best specialist agent(s) without requiring explicit user mentions.
API Design - Princípios RESTful e boas práticas
Padrões de arquitetura de software - Decisões OBJETIVAS sobre design de sistemas
SOC 직업 분류 기준
| name | systematic-debugging |
| description | Debugging sistemático - Análise de root cause em 4 fases |
| version | 1.0.0 |
| category | workflow |
| triggers | ["debug","debugging","bug","erro","error","não funciona","quebrou","broken","fix","root cause","investigar"] |
| tools | [] |
| author | liquid-ai |
| based_on | obra/superpowers |
Esta skill implementa um processo sistemático de debugging em 4 fases para encontrar e corrigir bugs de forma eficiente.
Debugging não é adivinhar. É um processo científico de eliminação.
┌─────────────────────────────────────────────────────────────┐
│ NUNCA: "Acho que o problema é X, vou mudar e ver" │
│ SEMPRE: "Vou coletar evidências para confirmar a causa" │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ 🎯 OBJETIVO: Conseguir reproduzir o bug consistentemente │
└─────────────────────────────────────────────────────────────┘
Checklist:
Perguntas Críticas:
Output Esperado:
## Reprodução do Bug
- **Passos:** [1, 2, 3...]
- **Frequência:** [sempre | às vezes | raro]
- **Ambiente:** [dev | staging | prod]
- **Primeiro relato:** [data/commit]
┌─────────────────────────────────────────────────────────────┐
│ 🎯 OBJETIVO: Reduzir o espaço de busca ao mínimo │
└─────────────────────────────────────────────────────────────┘
Técnicas de Isolamento:
| Técnica | Quando Usar | Como |
|---|---|---|
| Binary Search | Bug em fluxo longo | Divida o fluxo ao meio, teste cada metade |
| Git Bisect | Bug em commit recente | git bisect para encontrar commit culpado |
| Feature Flags | Bug em feature específica | Desabilite features até isolar |
| Simplificação | Bug em dados complexos | Reduza dados ao mínimo que reproduz |
Perguntas para Isolamento:
Comando Útil - Git Bisect:
git bisect start
git bisect bad HEAD
git bisect good <commit-que-funcionava>
# Git vai fazer binary search nos commits
┌─────────────────────────────────────────────────────────────┐
│ 🎯 OBJETIVO: Entender POR QUE o bug acontece │
└─────────────────────────────────────────────────────────────┘
Ferramentas de Diagnóstico:
| Ferramenta | Propósito |
|---|---|
| Console.log / Print | Rastrear fluxo de execução |
| Debugger (breakpoints) | Inspecionar estado em tempo real |
| Stack trace | Entender cadeia de chamadas |
| Logs de produção | Contexto do erro real |
| Network tab | Verificar requests/responses |
Framework de Análise:
┌─────────────────────────────────────────────────────────────┐
│ 1. WHAT: O que está acontecendo de errado? │
│ 2. WHERE: Onde no código o erro ocorre? │
│ 3. WHEN: Quando/sob quais condições? │
│ 4. WHY: Por que o código se comporta assim? │
│ 5. HOW: Como o estado chegou a esse ponto? │
└─────────────────────────────────────────────────────────────┘
5 Whys Technique:
Bug: Usuário não consegue salvar
Why 1: API retorna 500
Why 2: Database query falha
Why 3: Coluna não existe
Why 4: Migration não foi aplicada
Why 5: Deploy script não roda migrations
ROOT CAUSE: Deploy script incompleto
┌─────────────────────────────────────────────────────────────┐
│ 🎯 OBJETIVO: Corrigir o bug E prevenir recorrência │
└─────────────────────────────────────────────────────────────┘
Checklist de Correção:
Template de Fix:
## Bug Fix: [Título]
### Root Cause
[Explicação do que causava o bug]
### Solução
[O que foi mudado e por quê]
### Testes Adicionados
- [ ] Teste que reproduz o bug original
- [ ] Teste de regressão
### Prevenção Futura
[O que fazer para evitar bugs similares]
Sintoma: Bug intermitente, difícil de reproduzir
Causa: Operações assíncronas sem sincronização
Solução: Locks, transações, ou sequenciamento
Sintoma: Funciona para maioria, falha em edge cases
Causa: Índices ou limites incorretos
Solução: Revisar loops, arrays, e condições de borda
Sintoma: "Cannot read property X of undefined"
Causa: Dados ausentes não tratados
Solução: Validação defensiva, optional chaining
Sintoma: Estado inconsistente após operações
Causa: Mutação direta, falta de imutabilidade
Solução: Imutabilidade, transações
Sintoma: Funciona local, falha em prod
Causa: Diferenças de ambiente (vars, versões, dados)
Solução: Padronizar ambientes, containerização
| Anti-Pattern | Problema | Solução |
|---|---|---|
| Shotgun Debugging | Mudar coisas aleatoriamente | Seguir as 4 fases |
| Printf Everywhere | Logs sem estratégia | Logs direcionados pela hipótese |
| Blame Game | Culpar outros/libs | Assumir que o bug é seu até provar contrário |
| Quick Fix | Corrigir sintoma, não causa | Sempre buscar root cause |
| Solo Debugging | Debugar sozinho por horas | Pedir ajuda após 30min travado |
┌─────────────────────────────────────────────────────────────┐
│ Se você está travado no mesmo bug por mais de 30 minutos: │
│ │
│ 1. Pare e documente o que você sabe │
│ 2. Peça uma segunda opinião (rubber duck ou colega) │
│ 3. Faça uma pausa de 10 minutos │
│ 4. Volte com perspectiva fresca │
└─────────────────────────────────────────────────────────────┘
Esta skill ativa AUTOMATICAMENTE quando: