PyTorch Issue-Triage
Strukturiert PyTorch-GitHub-Issues, leitet sie weiter, vergibt erlaubte Labels und markiert sie nachvollziehbar.
- Skill Road
- PyTorch Issue-Triage
Kategorien
PyTorch Issue-Triage ist ein offizieller Skill aus dem PyTorch-Repository. Er unterstützt Maintainer und Oncall-Teams dabei, GitHub-Issues nach einem festgelegten Ablauf zu prüfen, zuständige Bereiche zu erkennen, zulässige Labels auszuwählen und geeignete nächste Schritte vorzubereiten. Laut Anbieter richtet sich der Skill an die Bearbeitung neuer PyTorch-Issues und beschreibt insbesondere Routing, Rückfragen, Label-Auswahl und das Markieren abgeschlossener Triage. Er ist kein eigenständiges Ticketsystem, keine automatische Fehlerdiagnose und keine Zusicherung, dass eine einzelne Modellantwort eine menschliche Maintainer-Entscheidung ersetzen kann.
Ablauf und Eingangskontext
Der Prozess beginnt mit dem vollständigen Issue und seinen bereits vorhandenen Labels. Ein Issue mit irgendeinem Oncall-Label wird laut Anbieter übersprungen, weil es bereits einer zuständigen Warteschlange gehört. Bei Fragen ohne Bug- oder Feature-Charakter sieht der Workflow eine Weiterleitung zum Forum und das Schließen mit einer passenden Antwortvorlage vor. Wenn die Situation unklar ist, soll zunächst eine Rückfrage nach zusätzlichen Informationen erfolgen. Der Skill unterscheidet außerdem externe Dateien und nicht reproduzierbare Szenarien. Download-Links zu Dateien oder Modellartefakten sollen aus Sicherheitsgründen entfernt werden, während eine selbstständige, reproduzierbare Darstellung angefordert wird. Ein Hardwareproblem, ein nicht öffentlich ausführbares Modell oder eine komplexe verteilte Umgebung kann ebenfalls eine Reproduktion vor einer weiteren Einstufung erfordern.
Routing und fachliche Labels
Für Issues aus anderen PyTorch-Projekten beschreibt der Skill eine Weiterleitung an das passende Repository. Für bestimmte Fachbereiche gibt es Oncall-Ziele wie JIT, Distributed, Export, Quantization, Mobile, Profiler oder Visualization. PT2 wird ausdrücklich anders behandelt: Das Label oncall: pt2 beendet die allgemeine Triage nicht, sondern verlangt zusätzlich ein passendes Modul-Label und weitere Schritte. Die Dokumentation warnt vor typischen Verwechslungen. MPS ist beispielsweise nicht Mobile, DTensor gehört zur Distributed-Zuständigkeit und ONNX erhält ein Modul-Label statt eines nicht vorgesehenen Oncall-Ziels. Die Ursache soll anhand der Frage bestimmt werden, wo eine Korrektur nötig wäre, nicht anhand eines einzelnen Schlagworts in einer Fehlermeldung.
Sicherheit und Entscheidungsgrenzen
Laut Anbieter dürfen nur in der Label-Referenz vorhandene Labels verwendet werden. CI-Steuerungen, veraltete Labels, menschlich reservierte Schweregrade und nicht zugelassene Oncall-Namen sollen nicht erfunden oder ergänzt werden. Menschlich gesetzte Labels werden nicht überschrieben. Bei Segmentation Faults, stillen falschen Ergebnissen, Regressionen, internen Assertions oder vielen Betroffenen ist zunächst triage review für eine menschliche Prüfung vorgesehen; high priority soll nicht eigenmächtig gesetzt werden. Der Skill unterscheidet außerdem Sicherheits-, Datenschutz- und Datenexpositionsrisiken von gewöhnlichen Bearbeitungsschritten. Änderungen an Issues, Kommentare, Transfers und Schließungen sind externe Aktionen und müssen vor ihrer Ausführung gegen Repository, Issue-Nummer, Berechtigungen und die aktuelle Situation geprüft werden. Die mitgelieferten Hooks validieren Ziele und Labels, aber sie ersetzen keine verantwortliche Kontrolle.
Praktischer Nutzen und Grenzen
Der Skill ist besonders nützlich als konsistente Checkliste für ein großes Open-Source-Projekt mit vielen Modulen und spezialisierten Teams. Er kann neue Maintainer dabei unterstützen, bekannte Routing-Regeln nicht zu übersehen und die Reihenfolge der Entscheidungen einzuhalten. Er kennt jedoch nur die Informationen, die über den verbundenen GitHub-Kontext verfügbar sind. Ähnliche Issues, Reproduktionen, externe Dateien und aktuelle Zuständigkeiten müssen tatsächlich geprüft werden. Labels können sich ändern, weshalb labels.json und die übrigen Referenzdateien im selben Quellstand maßgeblich bleiben. PyTorch veröffentlicht den Quellcode unter BSD-3-Clause. Diese Beschreibung wurde am 9. September 2026 anhand der offiziellen Skill-Datei und der offiziellen PyTorch-Dokumentationsseite geprüft. Die Angabe beschreibt den Anbieterstand und ist keine Garantie für richtige Triage, Verfügbarkeit oder Sicherheit in jeder Umgebung. GitHub-Sterne werden nicht gespeichert, weil das Skill-Modell kein github_stars-Feld besitzt.
- Anbieter
- PyTorch
- Lizenz
- BSD-3-Clause
- Zuletzt geprüft
- 09.09.2026
Repository und Dokumentation
Kategorien
Kompatibel mit
Passende Ratgeber
Anleitungen und Hintergrund, die zu diesem Eintrag passen.
Fakechat-Plugin für Claude Code einrichten
Das Fakechat-Plugin installieren, Claude Code mit Channels-Schalter starten und über eine lokale Browser-Oberfläche Nachrichten und Dateien testen.
30.09.2026
Laravel Boost einrichten
Laravel Boost in einer Laravel-Anwendung installieren und mit Claude Code, Cursor oder Codex verbinden.
29.09.2026
Azure DevOps MCP Server einrichten
Azure DevOps MCP Server einrichten mit geprüften Links, minimalen Rechten und sicherem ersten Test starten.
25.09.2026
Ein Claude-Code-Plugin installieren
Ein Plugin aus dem offiziellen Anthropic-Marketplace installieren – am Beispiel des Code-Review-Plugins.
24.09.2026