pydantic/pydantic-ai

Pre-push Review

Simuliere den automatisierten CI-Review-Job lokal, bevor du pushst oder einen PR eröffnest.

Funktionsweise

Die Review-Kriterien sind im CI-Workflow definiert, nicht hier dupliziert. Lies den Review-Prompt direkt aus der Quelle der Wahrheit:

• .github/workflows/bots.yml — finde das prompt:-Feld des review-Jobs (den YAML-Block, der mit Review this pull request beginnt). Dies enthält die vollständigen Review-Kriterien, Prioritäten und Richtlinien, die CI verwendet.

Passe diese Kriterien für einen lokalen (Pre-PR) Review wie unten beschrieben an.

Schritte

1. Lies den CI-Review-Prompt

Lies .github/workflows/bots.yml und extrahiere den Review-Prompt aus dem anthropics/claude-code-action-Schritt im review-Job. Dies ist deine primäre Referenz dafür, worauf du achten und wie du Ergebnisse priorisieren sollst.

2. Sammle lokalen Kontext

Da es noch keinen PR gibt, sammle gleichwertigen Kontext lokal:

# Bestimme den Basis-Branch (Standard: main)
git merge-base main HEAD

# Geänderte Dateien
git diff main...HEAD --stat

# Funktion-Kontext-Diffs (gleiches -W-Flag wie das CI-Skript)
git diff main...HEAD -W

Lies den Diff in überschaubaren Blöcken — versuche nicht, alles auf einmal zu laden, wenn er groß ist. Priorisiere „Core-Implementierungs“-Dateien gegenüber Tests und generierten Dateien (wie uv.lock und Cassetten).

3. Lies relevante AGENTS.md-Dateien

Lies die root-CLAUDE.md (bereits in deinem System-Prompt) sowie alle verzeichnisspezifischen AGENTS.md-Dateien für Verzeichnisse, die geänderte Dateien enthalten. Das CI-Skript prüft diese Pfade:

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

Lies nur diejenigen, die für die geänderten Verzeichnisse relevant sind.

4. Review

Wende die Review-Kriterien aus dem CI-Prompt an, mit diesen lokalen Anpassungen:

• Überspringe PR-spezifische Prüfungen: keine PR-Beschreibung, verknüpfte Issues, doppelte PR-Prüfungen oder vorherige Review-Kommentare zu berücksichtigen.
• Überspringe die „Sollte dieser PR existieren?“-Prüfung: gehe davon aus, dass der Benutzer diese Änderungen beabsichtigt.
• Gib Ergebnisse als Text aus, anstatt Inline-Kommentare zu posten.

Fokusbereiche (in Prioritätsreihenfolge, gemäß CI-Prompt):

1. Öffentliche API — Abstraktionen, Klassenhierarchie, Methodensignaturen, Typsicherheit, Abwärtskompatibilität
2. Konzepte & Verhalten — Designentscheidungen, Kompromisse, die diskutiert werden müssen
3. Dokumentation — Stimme, Muster, Vollständigkeit
4. Tests — Abdeckung, Stil, Integration vs. Unit-Tests
5. Code-Stil — Einhaltung der AGENTS.md-Regeln, idiomatisches Python

Wenn es grundlegende Probleme gibt, die erhebliche Nacharbeit erfordern würden, konzentriere dich auf diese und halte dich mit niedrigeren Nörgeleien zurück.

5. Präsentiere die Ergebnisse

Ordne die Ergebnisse nach Prioritätsstufe. Für jedes Ergebnis:

• Referenziere die spezifische Datei und Zeile (datei:zeile)
• Erkläre das Problem prägnant
• Schlage eine Korrektur vor, falls angemessen

Wenn es keine Ergebnisse gibt, sage das.

Kommentarqualität

Jedes Ergebnis muss sich seinen Platz verdienen. Dein Review sollte niemals Rauschen hinzufügen:

• Nur umsetzbar: jedes Ergebnis muss eine bestimmte Änderung anfordern, ein Problem markieren, das diskutiert werden muss, oder eine konkrete Verbesserung vorschlagen. Kommentiere nicht zu positiven Aspekten („hervorragendes Design“, „gute Wahl“) — das ist Rauschen.
• Prägnant: 1–3 Sätze pro Ergebnis sind fast immer ausreichend. Keine unnötigen Listen, Unterüberschriften oder Emojis.
• Nicht wiederholend: markiere dasselbe Problem nicht mehrmals, es sei denn, es tritt in bedeutend unterschiedlichen Kontexten auf.
• Keine Füllsätze: blase den Review nicht mit Beobachtungen auf, die kein Handeln erfordern. Wenn eine Entscheidung richtig ist, erwähne sie nicht. Wenn Code den Projektmustern folgt, lobe ihn nicht. Konzentriere dich ausschließlich darauf, was geändert oder diskutiert werden muss.
• Freundlich, aber nicht unterwürfig: verwende den Ton eines hilfsbereiten Projektbetreuers. Keine Komplimente, kein „gute Arbeit“, nur klares, direktes Feedback.

Wenn es grundlegende Probleme gibt, die erhebliche Nacharbeit erfordern würden, konzentriere dich auf diese und überspringe niedrigere Nörgeleien vollständig — sie müssten ohnehin noch einmal überarbeitet werden.