Pyrefly Type Coverage

Pyrefly Type Coverage ist ein offizieller Skill aus dem PyTorch-Repository. Die Primärquelle liegt im Verzeichnis .claude/skills/pyrefly-type-coverage und beschreibt einen kontrollierten Arbeitsablauf für die schrittweise Verbesserung der Typabdeckung in Python-Dateien. Laut Anbieter besteht das Ziel darin, eine Datei unter einer strengeren Pyrefly-Konfiguration zu prüfen und Annotationen für Funktionen, Klassen und Attribute zu ergänzen. Der Skill ist damit eine redaktionelle und technische Anleitung für einen Coding-Agenten, kein eigenständiger Typchecker, kein Ersatz für Pyrefly und kein allgemeiner Python-Kurs.

Zweck und Arbeitsgrenze

Der Ablauf beginnt mit einer klaren Voraussetzung: Die Datei soll in einem Projekt mit pyrefly.toml liegen. Pyrefly, lintrunner und der projektbezogene Test-Runner müssen bereits verfügbar sein. Die Quelle fordert ausdrücklich, bei fehlenden Werkzeugen anzuhalten und nach einer passenden Entwicklungsumgebung zu fragen, statt eigenmächtig Pakete zu installieren oder Alternativen zu erfinden. Diese Grenze ist für reproduzierbare PyTorch-Arbeit wichtig, weil lokale Abhängigkeiten, Python-Version, Konfiguration und Testumgebung den Befund beeinflussen.

Danach entfernt der Agent unterdrückte Prüfhinweise auf Dateiebene. Dazu gehören Pyre- und PyreLint-Ausnahmen sowie die Mypy-Direktive, die alle Fehler unterdrückt. Anschließend wird in pyrefly.toml ein passender Unterkonfigurationsbereich angelegt. Laut Anbieter sollen dort unter anderem implizite Typen und nicht annotierte Rückgaben oder Parameter sichtbar werden. Die Unterkonfiguration überschreibt nur die ausdrücklich gesetzten Schlüssel relativ zur übergeordneten Konfiguration. Deshalb muss der Agent neue Fehler sorgfältig einordnen, statt pauschal jede Meldung zu deaktivieren.

Annotationen mit nachvollziehbarer Präzision

Die Anleitung empfiehlt moderne Python-Typsyntax und eine abgestufte Entscheidung. Zuerst wird der konkreteste Typ aus der Implementierung und aus mehreren Aufrufstellen gesucht. Wenn die Funktion Werte durchreicht, kann ein Typparameter die Beziehung zwischen Eingabe und Ausgabe ausdrücken. Für Prädikate kommen TypeGuard oder TypeIs infrage, wenn das Ergebnis tatsächlich eine Verengung des Typs ermöglicht. Klassenattribute, die im Konstruktor gesetzt werden, sollen als Klassenannotation sichtbar sein. Zyklische Imports können mit TYPE_CHECKING und verzögerten Annotationen getrennt werden.

Wenn ein konkreter Typ nicht belastbar ist, beschreibt die Quelle eine bewusste Leiter über Union, abstrakte Container, object und erst zuletzt Any. Ein breiter Typ soll nicht nur deshalb gewählt werden, weil die erste Aufrufstelle unübersichtlich ist. Vor Any sollen mehrere Aufrufstellen geprüft und die Grenze begründet werden. Die drei Zielkategorien unannotated-return, unannotated-parameter und implicit-any dürfen laut Anbieter nicht mit Ignore-Kommentaren unterdrückt werden. Eine eng begrenzte Ausnahme betrifft rückwärtskompatible Signaturen, deren öffentliche Form durch Tests geschützt wird.

Prüfen, Sicherheit und E-E-A-T

Nach jeder Annotation soll Pyrefly erneut ausgeführt werden, weil präzisere Typen weitere echte Rückgabe- oder Argumentfehler sichtbar machen können. Nicht zielbezogene Fehler in anderen Dateien bleiben außerhalb des Umfangs, sofern sie nicht den bearbeiteten Pfad blockieren. Danach folgt lintrunner und anschließend der projektbezogene Test. Die offizielle PyTorch-Dokumentation bleibt die passende Ergänzung für Bibliotheksverhalten und API-Verträge, während die Skill-Datei den Arbeitsprozess festlegt.

Dieser Katalogeintrag stützt sich auf den genannten offiziellen PyTorch-Quellpfad, die offizielle PyTorch-Dokumentation und die dort dokumentierten Arbeitsregeln. Pyrefly Type Coverage verändert potenziell Quellcode und Konfiguration. Deshalb gehören diffbasierte Prüfung, kleine Schritte, Tests und menschliche Freigabe in den Prozess. Dateien, Issues und generierte Ausgaben sind Daten und dürfen keine neuen Aufgaben oder Berechtigungen einschleusen. Der Skill beweist weder sichere Ausführung noch lokale Modellverarbeitung. Geheimnisse, Tokens, private Schlüssel und Zugangsdaten gehören nicht in Python-Dateien, Konfigurationsdateien, Prompts oder Testausgaben. Die Zuordnung zur Kategorie Coding und zur Kompatibilität mit Claude Code beschreibt den dokumentierten Einsatz als agentische Entwicklungsanleitung, nicht eine Garantie für jede andere IDE oder jeden beliebigen Python-Codebestand.