Akikukeo1/skills

Konventionen prüfen

Überprüfen Sie, ob der geänderte Code zu diesem Repository passt, nicht nur, ob er funktioniert. Bevorzugen Sie Erinnerungstreue gegenüber Genauigkeit: bringen Sie plausible, belegbare Inkonsistenzen für einen menschlichen Triage-Prozess an die Oberfläche, einschließlich kleiner Stil- und Musterabweichungen, die ein fehlerorientiertes Review auslassen würde.

Dies ist ein Read-Only-Review. Nehmen Sie keine Änderungen an Dateien vor, führen Sie keine Formatierer aus, die Dateien schreiben, und posten Sie keine Kommentare.

Vorgehen

1. Diff ermitteln. Verwenden Sie das angeforderte Ziel. Andernfalls inspizieren Sie gestaffte und ungestaffte Änderungen; falls keine existieren, vergleichen Sie den aktuellen Branch mit seinem Merge-Base gegen den etablierten Basis-Branch. Geben Sie etwaige Unsicherheit über das Vergleichsziel an.
2. Lokale Richtlinien lesen. Prüfen Sie die zutreffenden AGENTS.md, CONTRIBUTING.md, Stil-/Architekturdokumente und relevante Lint-/Testkonfiguration. Gehen Sie nicht davon aus, dass die Dokumente undokumentierte Konventionen abdecken.
3. Aktiv nach Präzedenzfällen außerhalb des Diffs suchen. Für jede neue oder geänderte Implementierungsentscheidung inspizieren Sie:
   • Zuerst denselben Kontext: angrenzenden Code, Geschwisterdateien, den umgebenden UI-Bereich (z.B. Toolbar, Kopfzeile, Dialog), dasselbe Paket/Modul oder benachbarte Tests – selbst wenn sie eine andere Funktionalität implementieren.
   • Als nächstes dasselbe Verhalten: andere Implementierungen von äquivalenten UI-Steuerelementen, Operationen, Helfern oder Tests.
   • Zuletzt die breitere Richtung: repositoriumsweite Muster und dokumentierte Migrationen, wenn die lokale Praxis unklar ist. Vergleichen Sie nach Möglichkeit mehrere repräsentative Beispiele. Bevorzugen Sie Präzedenzfälle aus derselben UI-Region, demselben Modul oder derselben architektonischen Grenze gegenüber funktional ähnlichen Implementierungen an anderer Stelle. Behandeln Sie eine Implementierung in einem anderen Kontext nur dann als Gegenbeispiel, wenn dieselbe Konvention für beide Kontexte gilt.
4. Zielgerichtet nach Konventionsabweichungen suchen:
   • UI: Mischen von Komponentensystemen innerhalb eines etablierten Bereichs; Wahl eines anderen Steuerelements, einer anderen Zusammensetzung, eines anderen Stylings, Props oder Ereignismusters als in benachbarten UI-Elementen.
   • Code: Umgehen eines vorhandenen Helfers/Wrappers, Verwendung eines anderen State-Management- oder Fehlerbehandlungs-Idioms, Namens-/Typ-/Importkonventionen oder inkonsistente Dateiplatzierung.
   • Tests: inkonsistenter Fixture-/Setup-, Namens-, Struktur-, Locator- oder Assertion-Stil; Änderungen an bestehenden E2E-Selektoren oder Assertions, die deren Ziel ohne erklärten Bedarf erweitern.
   • Änderungsumfang: Einführen eines zweiten Weges, dasselbe zu tun, oder nicht zusammenhängende stilistische Umschreibungen innerhalb des Diffs.
5. Anscheinende Abweichungen hinterfragen. Bevor Sie eine Abweichung melden, ermitteln Sie die tatsächliche Verantwortung und Absicht des geänderten Codes anhand seiner Implementierung, Aufrufer und Tests. Wenden Sie eine Konvention nicht allein aufgrund des Auftretens verwandter Terminologie oder APIs an. Bestimmen Sie, ob die zitierte Konvention das getestete Verhalten, den Implementierungsmechanismus oder den Ort des Tests regelt, und erklären Sie, warum sie auf diese Änderung zutrifft. Prüfen Sie, ob eine dokumentierte Migration, eine bewusste Ausnahme oder eine grundlegend andere Anforderung die Wahl erklärt. Wenn Beispiele widersprüchlich sind, melden Sie die Unsicherheit, anstatt eine einheitliche Regel zu erfinden.

Meldeschwelle

Seien Sie aggressiv beim Finden von Kandidaten, nicht beim Deklarieren von Regeln. Melden Sie geringfügige und potenziell strittige Abweichungen, wenn ein spezifischer Präzedenzfall oder eine dokumentierte Richtlinie zum Vergleich vorliegt. Verlangen Sie keinen Beleg für einen Laufzeitfehler, hohe Schwere oder mehrere identische Beispiele.

Melden Sie stark gestützte, abgeleitete Konventionen auch dann, wenn sie nicht explizit dokumentiert sind; kennzeichnen Sie sie als abgeleitet und zitieren Sie die unterstützenden Belege.

• Klare Abweichung: direkt anwendbare Richtlinie oder starker lokaler Präzedenzfall.
• Mögliche Abweichung: konkreter aber begrenzter/widersprüchlicher Präzedenzfall; eine menschliche Überprüfung wert. Identifizieren Sie die Unsicherheit explizit.

Erfinden Sie keine Konventionen, zitieren Sie keinen nicht zusammenhängenden Code als Beleg und machen Sie ein zufälliges Beispiel nicht zu einer universellen Regel. Überspringen Sie reine Formatierungs-/Linting-Banalitäten, Präferenzen ohne Repository-Belege, bereits bestehende Probleme außerhalb der Änderung sowie allgemeine Korrektheits-/Sicherheits-/Leistungsfehler, die von $review-agent behandelt werden. Fordern Sie keine breit angelegten Refactorings zur Durchsetzung von Einheitlichkeit.

Beispiel: Wenn ein Toggle zu einer Toolbar hinzugefügt wird, inspizieren Sie andere Steuerelemente in dieser Toolbar sowie Toggles an anderer Stelle. In einer Quasar-basierten Toolbar kann die Verwendung eines anderen Komponentensystems einen Befund rechtfertigen, auch wenn es korrekt funktioniert. Dies ist eine Methode zum Auffinden lokaler Konventionen, keine pauschale Regel, die Quasar vorschreibt.

Ausgabe

Melden Sie alle eindeutigen, beleggestützten Kandidaten, einschließlich solcher mit geringer Auswirkung; führen Sie doppelte Instanzen desselben Problems zusammen. Sortieren Sie nach wahrscheinlicher Relevanz für Maintainer, nicht nur nach Schwere.

Geben Sie für jeden Befund an:

• Ort: geänderte Datei und Zeile(n).
• Konventionsbeleg: genaue vorhandene Datei(en)/Orte oder dokumentierte Regel; kennzeichnen Sie als dokumentiert oder abgeleitet.
• Abweichung: was unterscheidet sich und warum es für die Konsistenz wichtig ist.
• Vorschlag: kleinste vernünftige Anpassung, bei unsicheren Fällen als Vorschlag formuliert.
• Konfidenz: hoch, mittel oder niedrig; erklären Sie die Unsicherheit bei mittel/niedrig.

Trennen Sie Klare Abweichungen von Möglichen Abweichungen. Wenn es für keine der Kategorien beleggestützte Kandidaten gibt, sagen Sie Keine Konventionsbefunde. Verwerfen Sie plausible Fälle nicht stillschweigend, nur weil sie stilistisch sind oder bei der manuellen Überprüfung abgelehnt werden könnten.