pydantic/pydantic-ai

Um framework agnóstico a modelos para desenvolvedores que exigem alta segurança de tipos e controle em pipelines de agentes.

O que é pydantic-ai?

Esta skill, baseada no repositório pydantic/pydantic-ai, simula o trabalho de revisão automatizada de CI localmente, antes de um push ou abertura de PR. Ela permite que o agente AI leia os critérios de revisão diretamente do workflow do CI (`.github/workflows/bots.yml`), colete contexto local (como diff de arquivos alterados e arquivos AGENTS.md relevantes) e aplique esses critérios adaptados para um ambiente pré-PR. A skill prioriza a qualidade dos comentários: cada achado deve ser acionável, conciso e não repetitivo, focando em API pública, conceitos/design, documentação, testes e estilo de código. É particularmente útil para desenvolvedores que trabalham com Python e frameworks de alta segurança de tipos, como os do ecossistema Pydantic, garantindo que as revisões sejam precisas e sem ruído.

Funciona com✓Claude Code~Codex CLI~Cursor✓Antigravity
npx skills add pydantic/pydantic-ai

Installed? Explore more Programação e Desenvolvimento skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

Perguntar na sua IA favorita

Abre um novo chat com esta habilidade de agente já pré-carregada.

Documentação

Revisão Pré-Push

Simule o trabalho de revisão automatizada de CI localmente antes de fazer push ou abrir um PR.

Como funciona

Os critérios de revisão são definidos no workflow de CI, não duplicados aqui. Leia o prompt de revisão diretamente da fonte da verdade:

  • .github/workflows/bots.yml — encontre o campo prompt: do job review (o bloco YAML iniciando com Review this pull request). Este contém os critérios completos de revisão, prioridades e diretrizes que o CI usa.

Adapte esses critérios para uma revisão local (pré-PR) conforme descrito abaixo.

Passos

1. Leia o prompt de revisão do CI

Leia .github/workflows/bots.yml e extraia o prompt de revisão do passo anthropics/claude-code-action no job review. Esta é sua referência principal para o que procurar e como priorizar os achados.

2. Reúna o contexto local

Como ainda não há PR, reúna o contexto equivalente localmente:

# Determine a branch base (padrão: main)
git merge-base main HEAD

# Arquivos alterados
git diff main...HEAD --stat

# Diffs com contexto de função (mesmo flag -W usado pelo script de CI)
git diff main...HEAD -W

Para o diff, leia em partes gerenciáveis — não tente carregar tudo de uma vez se for grande. Priorize arquivos de "implementação principal" sobre testes e arquivos gerados (como uv.lock e cassetes).

3. Leia arquivos AGENTS.md relevantes

Leia o CLAUDE.md raiz (já está no seu prompt de sistema) mais quaisquer arquivos AGENTS.md específicos de diretórios que contenham arquivos alterados. O script de CI verifica estes caminhos:

  • docs/AGENTS.md
  • pydantic_ai_slim/pydantic_ai/models/AGENTS.md
  • tests/AGENTS.md

Leia apenas os relevantes para os diretórios alterados.

4. Revise

Aplique os critérios de revisão do prompt de CI, com estas adaptações locais:

  • Pule verificações específicas de PR: sem descrição de PR, issues vinculadas, verificações de PR duplicado ou comentários de revisão anteriores a considerar.
  • Pule a verificação "este PR deveria existir": assuma que o usuário pretende fazer essas alterações.
  • Produza achados como texto em vez de postar comentários inline.

Áreas de foco (em ordem de prioridade, conforme o prompt de CI):

  1. API pública — abstrações, hierarquia de classes, assinaturas de métodos, segurança de tipos, compatibilidade retroativa
  2. Conceitos e comportamento — decisões de design, trade-offs que precisam de discussão
  3. Documentação — tom, padrões, completeza
  4. Testes — cobertura, estilo, integração vs unitários
  5. Estilo de código — conformidade com regras do AGENTS.md, Python idiomático

Se houver problemas de alto nível que exijam retrabalho significativo, foque neles e segure os detalhes de nível inferior.

5. Apresente os achados

Organize os achados por nível de prioridade. Para cada achado:

  • Referencie o arquivo e linha específicos (file:line)
  • Explique o problema de forma concisa
  • Sugira uma correção, se apropriado

Se não houver achados, diga isso.

Qualidade do comentário

Cada achado deve merecer seu lugar. Sua revisão nunca deve adicionar ruído:

  • Apenas acionável: cada achado deve solicitar uma alteração específica, sinalizar uma preocupação que precisa de discussão ou sugerir uma melhoria concreta. Não comente aspectos positivos ("design excelente", "boa escolha") — isso é ruído.
  • Conciso: 1 a 3 frases por achado é quase sempre suficiente. Sem listas desnecessárias, subtítulos ou emojis.
  • Não repetitivo: não sinalize o mesmo problema várias vezes, a menos que apareça em contextos significativamente diferentes.
  • Sem enchimento: não encha a revisão com observações que não exigem ação. Se uma escolha está correta, não a mencione. Se o código segue os padrões do projeto, não o elogie. Foque exclusivamente no que precisa mudar ou ser discutido.
  • Amigável, mas não bajulador: use o tom de um mantenedor de projeto prestativo. Sem elogios, sem "ótimo trabalho", apenas feedback claro e direto.

Se houver problemas de alto nível que exijam retrabalho significativo, foque neles e pule completamente os detalhes de nível inferior — eles precisarão ser revisitados de qualquer forma.

Habilidades Relacionadas