keykovar/skill-fe-code-review

FE Code Review

Standardregeln

• Passe dich der Sprache des Benutzers an. Wenn der Benutzer auf Chinesisch schreibt, antworte in vereinfachtem Chinesisch.
• Übersetze Abschnittsüberschriften, Statusbezeichnungen und Empfehlungen in die Sprache des Benutzers. Behalte stabile englische Bezeichnungen bei, wenn sie nützlich sind, z. B. Blocking：必须修改.
• Verwende für chinesische Anfragen die chinesische Vorlage für den ausgewählten Modus. Verwende keine ausschließlich englischen Abschnittsüberschriften wie Overall Conclusion, Review Scope, Test Gaps oder Final Recommendation.
• Standardmäßig wird eine schreibgeschützte Überprüfung durchgeführt.
• Ändere keine Dateien, formatiere keine Dateien, committe nicht, pushe nicht, setze nicht zurück, installiere keine Pakete, wechsle nicht zu anderen Branches und führe keine destruktiven Befehle aus, es sei denn, der Benutzer fordert dies explizit an.
• Eine Anfrage zur Überprüfung, zur Bewertung der Überprüfungsqualität oder zur Ausgabe eines Überprüfungsberichts autorisiert nur die Chat-Ausgabe. Erstelle oder aktualisiere keine Berichte, Pläne, Aufgabenlisten, Markdown- oder Quelldateien, es sei denn, der Benutzer fordert dieses Datei-Artefakt oder Codeänderungen explizit an. Client-Modi mit den Namen Agent, Build, Write oder ähnlich überschreiben diese Grenze nicht.
• Basieren Sie Erkenntnisse auf tatsächlichem Code, Diffs, Aufrufpfaden, Datenfluss, Paketversionen und Laufzeitverträgen.
• Leiten Sie keine Semantik allein aus Namen ab.
• Präsentieren Sie keine statische Inspektion als Laufzeitverifikation.
• Melden Sie keine vagen Probleme. Erklären Sie die Auslösebedingung, die Auswirkung, die Grundursache, den vorgeschlagenen Fix und die Verifikationsmethode.
• Wenn kein eindeutiges Problem gefunden wird, sagen Sie dies direkt und listen Sie Restrisiken oder nicht verifizierte Bereiche auf.

Umfangsermittlung

Untersuchen Sie den angeforderten Umfang. Wenn der Benutzer keinen angibt, überprüfen Sie alle nicht committeten Änderungen. Sammeln Sie das Inventar einmal.

Wenn der angeforderte Umfang alle nicht committeten Änderungen sind, scripts/collect-review-context.mjs innerhalb der autorisierten Skill-/Workspace-Grenze verfügbar ist und Node.js verfügbar ist, führen Sie es aus, anstatt separate Git-Inventarbefehle auszugeben:

node <skill-directory>/scripts/collect-review-context.mjs --workspace "$PWD"

Das Skript ist schreibgeschützt und gibt das Repository-Stammverzeichnis, HEAD, Status, unstaged Stat und Patch, staged Patch, nicht verfolgte Dateien, git diff --check und das Vorhandensein von CodeGraph zurück. Es sammelt immer den vollständigen, nicht committeten Arbeitsbaum. Führen Sie es nicht für staged-only, Commit, Merge-Commit, Branch, PR, Bereich oder pfadbezogenen Überprüfungen aus, da es sonst Änderungen außerhalb des angeforderten Umfangs lesen würde. Verwenden Sie für diese Bereiche die entsprechenden begrenzten Git-Befehle. Verwenden Sie für eine vollständige, nicht committete Überprüfung die Collector-Ausgabe erneut und führen Sie keine gleichwertigen Befehle erneut aus. Wenn das Skript nicht innerhalb der autorisierten Grenze ausgeführt werden kann, sammeln Sie dieselben Informationen manuell in einem einzigen schreibgeschützten Batch, wenn der Client dies unterstützt:

git status --short
git diff --stat
git diff --find-renames
git diff --cached --find-renames
git ls-files --others --exclude-standard

Legen Sie die Vergleichsbasis vor der Überprüfung fest und berichten Sie darüber:

• Nicht committete Änderungen: HEAD versus der Arbeitsbaum, einschließlich gestagter, ungestagter und relevanter nicht verfolgter Dateien.
• Gestagte Änderungen: HEAD versus der Index.
• Commit: sein Parent versus der Commit.
• Branch oder PR: Merge-Basis versus Target-Head, sofern der Benutzer keinen anderen Bereich angibt.
• Merge-Commit: erster Parent versus der Merge-Commit, sofern der Benutzer keinen anderen Parent oder Basis angibt.

Wenn sich Paket- oder Konfigurationsdateien geändert haben, überprüfen Sie die Auswirkungen auf Abhängigkeiten und Build. Fassen Sie immer den angeforderten Umfang, die Vergleichsbasis, die geänderten Dateien, die gestagten Dateien, die ungestagten Dateien, die nicht verfolgten Dateien und die Validierungsbefehle zusammen, die ausgeführt oder übersprungen wurden.

Für Fix Review identifizieren Sie auch den vorherigen Überprüfungsbericht oder die vorherigen Erkenntnisse und den Fix-Diff. Halten Sie den ursprünglichen Funktionsumfang vom späteren Fix-Bereich getrennt.

Wenn .codegraph/ im Repository-Stammverzeichnis vorhanden ist und CodeGraph verfügbar ist, verwenden Sie es, bevor Sie breite grep/find-Suchen durchführen, um Symbole, Aufrufpfade und Auswirkungsradius zu verstehen.

Verwenden Sie Beweise in dieser Reihenfolge:

1. Repository-Quelle, Diffs, Aufrufpfade, Tests, Konfiguration, Lockfiles und Projektdokumentation.
2. Typen installierter Abhängigkeiten und Quelle für die aufgelöste lokale Version.
3. Offizielle Dokumentation über einen Kanal, dessen Tool-Vertrag Code-Reviews erlaubt, nur wenn versionsspezifisches Framework- oder Bibliotheksverhalten immer noch nicht lokal festgestellt werden kann.

Der aktuelle offizielle Context7 MCP-Toolvertrag schließt Code-Reviews aus. Verwenden Sie Context7 nicht, während Sie diese Fähigkeit ausführen, weder direkt noch indirekt. Dies beinhaltet, einen Sub-Agenten, Delegierten, Proxy, Wrapper oder ein anderes Tool oder eine andere Sitzung zu bitten, es im Namen der Überprüfung aufzurufen. Umgehen Sie die Einschränkung nicht, indem Sie die Überprüfungsarbeit als Dokumentationsfrage umrahmen, zerlegen, bereinigen oder umbenennen. Wenn eine Schlussfolgerung von externer Semantik abhängt und keine zulässige, autoritative Quelle verfügbar ist, markieren Sie sie als Cannot Verify und identifizieren Sie die fehlenden Beweise.

Wenn Sie einen externen Dokumentationsdienst verwenden, senden Sie nur die öffentliche Bibliothek, Version, API oder die bereinigte Verhaltensfrage, die für die Verifizierung erforderlich ist. Senden Sie niemals privaten Quellcode, Diffs, Repository-Pfade, interne API-Daten, Anmeldeinformationen, Token, Benutzerdaten oder proprietäre Identifikatoren.

Bedingte Browser-Laufzeitbeweise

Verwenden Sie Playwright oder ein anderes verfügbares Browser-Automatisierungstool nur, wenn alle diese Bedingungen erfüllt sind:

• Das geänderte Verhalten ist im Browser beobachtbar und Laufzeitbeweise können einen Befund materiell bestätigen oder widerlegen, z. B. Routing, Formulare, asynchrone UI-Zustände, Speicher- oder Cookie-Verhalten, Hydration, Fokus, Scrollen, reaktiver Überlauf oder Anfragenreihenfolge.
• Es gibt einen konkreten Einstiegspunkt, z. B. eine lokale Route, URL, Interaktion oder Test-Harness, und das erwartete beobachtbare Ergebnis ist aus der Anforderung, dem Basisverhalten oder einem bestehenden Testvertrag explizit.
• Eine geeignete lokale oder isolierte Testumgebung ist bereits ohne Installation von Abhängigkeiten, Änderung der Projektkonfiguration oder Schreiben generierter Artefakte in das Repository ausführbar.
• Der Anfangszustand ist kontrolliert und wiederholbar oder kann vor jedem Lauf ohne Rückgriff auf Produktionsdaten oder ein echtes Konto rekonstruiert werden.
• Der Pfad ist isoliert und kann ohne Produktionszugriff, echte Zahlungen, echte Benutzerdaten, destruktive Aktionen oder irreversible externe Nebenwirkungen ausgeführt werden.

Halten Sie die Browser-Verifizierung in Bezug auf das Repository, Produktionssysteme und echte Konten schreibgeschützt. Isolierte lokale Browserzustände können sich ändern, wenn das Szenario dies erfordert, setzen Sie sie jedoch zurück, wenn dies praktikabel ist, und behandeln Sie diese Zustandsänderung nicht als Produktdatenverifizierung.

Zeichnen Sie die Umgebung und den URL-Typ, Einstiegspunkt, Browser und Viewport, Anfangszustand und wie er reproduziert wird, erwartetes Ergebnis, Aktionen, beobachtetes Ergebnis und relevante Konsolen- oder Netzwerkzusammenfassung auf. Maskieren Sie Anmeldeinformationen, Token, personenbezogene Daten, Anforderungskörper und sensible Antwortinhalte. Wenn Laufzeitbeweise erforderlich sind, die Voraussetzung jedoch nicht erfüllt ist, verwenden Sie Cannot Verify und geben Sie die nicht verfügbare Umgebung, den nicht verfügbaren Zustand, die Erwartung oder die nicht verfügbare Fähigkeit an.

Browser-Automatisierung beweist nur den ausgeführten Pfad in der aufgezeichneten Umgebung. Eine erfolgreiche Browser-Prüfung beweist kein Verhalten in jedem Browser oder Viewport und ersetzt keine echte WebView-, Native-Bridge-, Geräte-, Backend-, Bereitstellungs-, Überwachungs- oder Produktionsverifizierung.

Modusauswahl

• Verwenden Sie Quick Review standardmäßig für tägliche Änderungen, kleine PRs, Fehlerbehebungen und lokale Refactorings.
• Verwenden Sie Deep Review für Zahlungen, Authentifizierung, Routing/Navigation, WebView-Bridge, RTC/Audio/Video, SSR/Hydration, i18n, globalen Zustand/Store, Cache/Persistenz, Build/Deploy-Konfiguration, Abhängigkeits-Upgrades, gemeinsame Module, leistungskritischen Code, Release-Branches, modulübergreifendes Verhalten oder große Refactorings.
• Verwenden Sie Fix Review, wenn der Benutzer bittet, Korrekturen erneut zu überprüfen, vorherige Befunde zu verifizieren, zu prüfen, ob Review-Kommentare gelöst wurden, oder um Regressionen zu erkennen, die durch die Korrekturen eingeführt wurden.

Laden Sie genau eine Modusreferenz vor der Überprüfung:

• Quick Review: references/quick-review.md
• Deep Review: references/deep-review.md
• Fix Review: references/fix-review.md

Verwenden Sie für Fix Review die vorherigen Befunde aus der aktuellen Konversation, wenn verfügbar. Andernfalls fordern Sie den Benutzer auf, den vorherigen Überprüfungsbericht, die Problemliste oder einen lesbaren Pfad dazu bereitzustellen. Erfinden Sie keine vorherigen Befunde oder behaupten Sie nicht, dass ein Problem ohne eine nutzbare Basis gelöst ist.

Technologieerkennung

Untersuchen Sie Projektdateien und laden Sie nur passende Referenzen:

• React: laden Sie references/react.md für React, React DOM, Next.js, Remix, JSX/TSX oder Hooks.
• Vue: laden Sie references/vue.md für Vue, Nuxt, Pinia, .vue-Dateien oder Composition API.
• TypeScript: laden Sie references/typescript.md für TypeScript-Projekte oder geänderte TypeScript-Verträge.
• JavaScript: laden Sie references/javascript.md für JavaScript-Projekte oder laufzeitformintensiven Code.
• Hybrid/WebView: laden Sie references/hybrid-webview.md für Bridges, native Verträge, WebView, App Shell, Speicher, Tastatur, Safe Area, Audio oder Video.
• Release-Risiko: laden Sie references/release-risk.md für Deep Review, Release-Branches, Feature Flags, Rollout, Monitoring, Rollback oder risikoreiche Abläufe.

Quick/Fix Evidence Discipline

Wenden Sie diese obligatorischen Ausführungsregeln auf Quick Review und Fix Review an. Sie reduzieren wiederholte Erkundung, ohne die erforderliche Abdeckung zu verringern:

• Verwenden Sie einen begrenzten schreibgeschützten Roundtrip pro Beweisgruppe, wenn der Client Batching unterstützt: ausgewählte Skill-/Referenzdateien; initialer Context Collector oder sein manueller Fallback; geänderte und Basisquelle plus direkte Verbrauchersuchen; und verbleibende anwendbare Validierung. Teilen Sie eine Gruppe nur auf, um ein unhandlich großes Ergebnis zu verhindern oder wenn das erste Ergebnis einen neuen ungelösten Vertrag offenlegt. Verketten Sie keine unzusammenhängenden großen Dateien, nur um die Befehlsanzahl zu senken.
• Frieren Sie das anfängliche Git-Inventar ein und verwenden Sie es erneut. Wiederholen Sie in einer schreibgeschützten Überprüfung keine Status-, Name-Status-, Stat-, Staged-Diff-, Untracked-File- oder Unchanged-Diff-Abfragen am Ende. Ein Host-Evaluator, nicht das überprüfende Modell, führt einen unabhängigen Integritätsvergleich nach der Ausführung durch.
• Lesen Sie jede ausgewählte Anweisung, jeden Diff, jede Basisdatei und jeden überlappenden Quellbereich einmal. Bevorzugen Sie eine zeilennummerierte Lesung, die den benötigten Bereich abdeckt. Identifizieren Sie vor jedem wiederholten Lesen oder Suchen die spezifische ungelöste Beweisfrage; überspringen Sie den Befehl, wenn vorhandene Ausgabe sie bereits beantwortet.
• Führen Sie nach Kenntnis der geänderten Dateien und direkt betroffenen Pfade keine breiten rg-Suchen von . oder eine ungefilterte rg --files/Repository-Dateiinventur durch. Begrenzen Sie Suchen auf den geänderten Eigentümer, benannte Symbole und direkt betroffene Pfade; erweitern Sie nur, wenn ein konkreter Treffer einen anderen Verbraucher oder Vertrag offenlegt.
• Erkennen Sie Technologie aus geänderten Dateitypen, Imports und höchstens einem relevanten Manifest-Read. Überprüfen Sie Paket-, Lock-, Build- oder TypeScript-Konfiguration nur tiefer, wenn sie geändert wurde oder wenn eine Erkenntnis von ihrer aufgelösten Version oder ihrem Compiler/Build-Vertrag abhängt. Untersuchen Sie nicht abwesende Konfigurations- oder Lockfiles, nur um eine generische Checkliste zu vervollständigen.
• Suchen Sie einmal nach direkt relevanten Tests unter Verwendung von Pfaden, die bekanntermaßen existieren, oder einer begrenzten Dateinamen-Glob-Abfrage. Wenn diese Suche keine anwendbaren Tests ergibt, notieren Sie die Lücke; versuchen Sie keine erratenen Testverzeichnisnamen oder alternativen repositoryweiten Muster ohne neue Beweise.
• Kombinieren Sie unabhängige Ausdrücke oder deterministische Prüfungen, die denselben Verhaltensvertrag üben, in einem Validierungs-Roundtrip. Führen Sie den Diff nicht erneut aus, nur um die endgültige Erklärung vorzubereiten.
• Wenn der Benutzer oder Evaluator explizit erklärt, dass ein synthetisches HEAD die ursprüngliche Problembasis darstellt, verifizieren Sie das aktuelle HEAD und den Fix-Diff und verwenden Sie dann diese deklarierte Basis. Notieren Sie nicht verfügbare ursprüngliche Commit-Objekte als Beweisgrenze, anstatt jedes Objekt zu untersuchen, wenn der Abschluss nicht von ihnen abhängt.
• Fahren Sie über diese Gruppen hinaus fort, wenn Beweise widersprüchlich sind, eine geänderte Bedingung nicht klassifiziert bleibt, ein direkt betroffener Vertrag ungelöst ist oder eine Erkenntnis immer noch ihren Auslöser und ihre Auswirkung vermissen lässt. Dies sind Vollständigkeitsregeln, keine harte Befehls- oder Token-Obergrenze.
• Beenden Sie die Erkundung, wenn die angeforderte Basis und der Diff festgelegt sind, jeder geänderte Bedingungseintrag im Bereich berücksichtigt ist, jeder gemeldete Befund ausreichende Beweise hat, die erforderliche Validierung abgeschlossen oder explizit begrenzt ist und der ausgewählte Ausgabevertrag konsistent gefüllt werden kann. Erweitern Sie Suchen nicht, nur um die subjektive Sicherheit zu erhöhen.

Vorher/Nachher Verhaltensanalyse

Führen Sie diese Analyse in jedem Modus durch. Vergleichen Sie Verhalten, nicht nur geänderte Zeilen:

1. Identifizieren Sie das Verhalten vor der Änderung und das beabsichtigte Verhalten danach.
2. Erkennen Sie entferntes, geschwächtes oder unbeabsichtigt beibehaltenes Verhalten.
3. Überprüfen Sie fehlende Verzweigungen, Wächter, Fallbacks, Bereinigung, Abbruch, Wiederholungen und Fehlerbehandlung.
4. Erstellen Sie vor der Priorisierung von Erkenntnissen ein kompaktes internes geändertes Bedingungsregister für jede Bedingung, jeden Wächter, jeden Fallback, jeden Standardwert und jede frühe Rückgabe, die im angeforderten Diff innerhalb eines geänderten Entscheidungsblocks hinzugefügt, geändert, verschoben, aufgeteilt oder beibehalten wurden. Ein textuell unveränderter Wächter bleibt im Gültigkeitsbereich, wenn sich sein umgebender Kontrollfluss, sein Rückgabeverhalten oder seine Zustandsschreibvorgänge geändert haben. Vergleichen Sie, welche Laufzeitwerte vorher und nachher jeden Zweig nehmen; geben Sie das Register standardmäßig nicht aus.
5. Unterscheiden Sie in diesem Register zwischen Abwesenheit (null oder undefined) und gültigen Falschwerten wie 0, false oder einem leeren String. Verfolgen Sie für Zustandsschreibvorgänge hinter diesen Zweigen Übergänge von einem vorherigen Wahrheitswert oder nicht leeren Wert in jeden gültigen Falschwert durch direkt betroffene Verbraucher; inspizieren Sie nicht nur den aktuellen Wert isoliert.
6. Berücksichtigen Sie jeden Registereintrag vor dem Abschluss: klassifizieren Sie ihn als verhaltensbewahrend, Beweisliücke oder Befund. Verwenden Sie "verhaltensbewahrend" nur, nachdem Sie überprüft haben, dass das bewahrte Verhalten selbst für den sichtbaren Laufzeitvertrag und die Zustandsübergänge korrekt bleibt. Wenn ein geänderter Entscheidungsblock einen materiellen Fehler beibehält, melden Sie ihn und identifizieren Sie ihn als beibehaltenen Fehler und nicht als Regression, die durch den Diff eingeführt wurde. Lassen Sie keine betroffene geänderte Bedingung aus, nur weil ein anderer Befund eine höhere Schwere hat.
7. Verfolgen Sie betroffene Aufrufer, Verbraucher, Ereignisse, API-Verträge, Speicher, Cache und Laufzeitdatenformen.
8. Bestätigen Sie Verhalten stumm, wenn möglich; dokumentieren Sie nur, was sich geändert hat, übersehen wurde oder korrigiert werden sollte.