菜单
Use quando encontrar qualquer bug, teste falhando, comportamento inesperado, erro de compilação persistente ou container que não sobe. Processo de 4 fases: investigar → analisar → hipótese → implementar. Proibido pular fases ou fazer tentativas aleatórias.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/marquesmarcelo/dev-team --skill systematic-debugging命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
Use ao criar gráficos, dashboards ou qualquer visualização de dados. Ativa com "gráfico", "dashboard", "visualizar", "chart", "plot", "relatório visual". Incorpora princípios de Tufte, NYT Graphics e Linear. Escolhe a biblioteca pela stack e pelo propósito — Recharts (Next.js/React), ECharts (Angular), Chart.js (universal). Distingue storytelling (uma tese, um gráfico) de dashboard (exploração de dados).
Use ao implementar frontend em Angular, quando project.config.md indicar esta stack. Cobre estrutura de projeto Angular 17+, standalone components, signals, biblioteca de componentes padrão (Angular Material ou PrimeNG), acessibilidade WCAG 2.2 AA, e padrão de UI assíncrona.
Use ao implementar frontend em Next.js com shadcn/ui, quando project.config.md indicar esta stack. Cobre estrutura de pastas, convenção de hooks, uso de componentes shadcn/ui, e padrões específicos do App Router.
基于 SOC 职业分类
| name | systematic-debugging |
| description | Use quando encontrar qualquer bug, teste falhando, comportamento inesperado, erro de compilação persistente ou container que não sobe. Processo de 4 fases: investigar → analisar → hipótese → implementar. Proibido pular fases ou fazer tentativas aleatórias. |
Derivado do
systematic-debuggingdo Superpowers (Jesse Vincent / obra), adaptado para as stacks e contexto deste projeto.
Regra central: nunca fazer mudança aleatória esperando que resolva. Cada mudança deve ter hipótese clara e verificação do resultado. Pular fase = investigação incompleta = bug volta ou piora.
Antes de qualquer diagnóstico, reproduza o problema de forma consistente.
# Rodar o teste que falha isoladamente
docker compose run --rm backend <comando-teste> -run TestNomeExato
# Se for problema de container
docker compose logs backend --tail=50
docker compose ps
# Se for erro de frontend
# Abrir DevTools → Console → reproduzir o comportamento
Critérios para avançar:
Se não conseguir reproduzir consistentemente: documentar as condições em que aparece (flaky test? só em CI? só com dados específicos?) antes de avançar.
Erro: tratar o sintoma. Se o log diz "connection refused", o sintoma é "conexão recusada" — a causa pode ser container não iniciado, porta errada, variável de ambiente vazia, ou banco ainda inicializando.
Correto: rastrear até a origem.
# Ler o erro completo, não só a última linha
docker compose logs backend 2>&1 | head -100
# Verificar variáveis de ambiente
docker compose run --rm backend env | grep DATABASE
# Verificar se o serviço dependente está saudável
docker compose exec postgres pg_isready
# Verificar se a migration rodou
docker compose run --rm backend <comando-migrate-status>
# Git: o que mudou recentemente que pode ter causado isso?
git log --oneline -10
git diff HEAD~1 -- <arquivo-suspeito>
Técnicas específicas por tipo de problema:
| Tipo | Onde olhar primeiro |
|---|---|
| Teste unitário falhando | Mock configurado errado? Interface do port mudou? |
| Teste E2E falhando | Estado do DOM assíncrono? Selector quebrou? Dados diferentes? |
| Container não sobe | docker compose logs <serviço> — ler as primeiras linhas do erro |
| 500 no backend | Stack trace completo nos logs + request que disparou |
| Frontend não renderiza | Console do browser → erros de rede → response da API |
| Migration falha | Conflito com migration anterior? Coluna já existe? |
| Build quebrado | Primeiro erro, não o último — compiladores encadeiam erros |
Critérios para avançar:
Antes de modificar qualquer código, formule uma hipótese explícita:
Hipótese: "O erro ocorre porque [causa específica].
Se eu [mudança mínima], o comportamento deve mudar para [resultado esperado]."
Teste mínimo primeiro: faça a menor mudança possível que valida ou refuta a hipótese. Não corrija e refatore ao mesmo tempo.
# Exemplo: suspeita que a variável DATABASE_URL está vazia
# Teste mínimo: imprimir o valor antes de usar
docker compose run --rm backend env | grep DATABASE_URL
# → confirma ou refuta a hipótese sem mudar código de produção
# Exemplo: suspeita de race condition em teste assíncrono
# Teste mínimo: adicionar wait explícito
# → se resolver, confirma a hipótese de timing
Se a hipótese for refutada: volte à Fase 2 com a nova informação. Não construa sobre uma hipótese errada.
Critérios para avançar:
Com a causa raiz confirmada, implemente a correção:
Corrija apenas o que causou o problema. Não refatore código adjacente enquanto corrige um bug — isso mistura responsabilidades e dificulta o review. Se notar algo errado por perto, anote para uma tarefa separada.
Escreva ou atualize o teste que teria capturado este bug. Bug sem teste = bug que pode voltar silenciosamente.
Verifique defense-in-depth: o bug poderia ocorrer em outro lugar pelo mesmo motivo? Se sim, corrija todos os pontos ou documente o padrão.
Verificação final:
# O teste que falhava agora passa?
docker compose run --rm backend <comando-teste> -run TestNomeExato
# Nenhum outro teste quebrou?
docker compose run --rm backend <comando-teste-completo>
# O comportamento esperado no sistema está correto?
# (re-executar o cenário que originou o bug)
Critérios de conclusão:
| Armadilha | O que fazer em vez disso |
|---|---|
| Mudar configuração aleatória esperando que resolva | Fase 2 — identificar a causa antes de mudar qualquer coisa |
| "Acho que é X, vou corrigir X" sem verificar | Fase 3 — formular hipótese e testar com mudança mínima |
| Corrigir e refatorar na mesma mudança | Separar em dois commits: fix + refactor |
| Deletar e reescrever quando há bug | O reescrito vai ter os mesmos bugs se a causa raiz não for entendida |
| Pedir ao LLM "tenta outra abordagem" em loop | Voltar à Fase 2 — mais informação, não mais tentativas |
| Marcar como resolvido antes de verificar | Fase 4 sempre inclui verificação explícita |
Quando testes E2E falham por timing (elemento não encontrado, estado ainda carregando):
// ❌ Nunca: sleep arbitrário
await page.waitForTimeout(2000)
// ✅ Sempre: esperar pela condição real
await page.waitForSelector('[data-testid="grid-results"]')
await expect(page.getByRole('button', { name: 'Salvar' })).toBeEnabled()
await page.waitForResponse(resp => resp.url().includes('/api/v1/processos'))
A condição de espera deve ser o estado real que indica que a operação completou — nunca um tempo fixo.