Code Review Skills

Rigor Run skill for README-first deep learning repo reproduction. Use when the task is specifically to capture or normalize evidence from the selected smoke test or documented inference or evaluation command and write standardized `repro_outputs/` files, including patch notes when repository files changed. Do not use for training execution, initial repo intake, generic environment setup, paper lookup, target selection, hidden scientific-meaning changes, or end-to-end orchestration by itself.

Erkunden und verstehen Sie Nx-Workspaces. VERWENDEN SIE DIES, wenn Sie Fragen zum Workspace, zu Projekten oder Aufgaben beantworten. VERWENDEN SIE DIES AUCH, wenn ein nx-Befehl fehlschlägt oder Sie verfügbare Ziele/Konfigurationen überprüfen müssen, bevor Sie eine Aufgabe ausführen. BEISPIELE: „Welche Projekte gibt es in diesem Workspace?“, „Wie ist Projekt X konfiguriert?“, „Was hängt von Bibliothek Y ab?“, „Welche Ziele kann ich ausführen?“, „Konfiguration für Aufgabe nicht gefunden“, „Debuggen eines fehlgeschlagenen nx-Tasks“.

Erzwingt die faulste Lösung, die tatsächlich funktioniert – einfachste, kürzeste, minimalste. Kanaliert einen Senior-Entwickler, der alles gesehen hat: hinterfragt, ob die Aufgabe überhaupt nötig ist (YAGNI), greift zur Standardbibliothek statt zu eigenem Code, zu nativen Plattformfunktionen statt Abhängigkeiten, zu einer Zeile statt fünfzig. Unterstützt Intensitätsstufen: lite, full (Standard), ultra. Verwende, wenn der Benutzer "ponytail", "be lazy", "lazy mode", "simplest solution", "minimal solution", "yagni", "do less" oder... sagt.

Gesamtrepo-Audit auf Überengineering. Wie ponytail-review, scannt aber die gesamte Codebasis statt eines Diffs: eine sortierte Liste, was gelöscht, vereinfacht oder durch stdlib/native Äquivalente ersetzt werden soll. Verwenden, wenn der Benutzer sagt "audit this codebase", "audit for over-engineering", "what can I delete from this repo", "find bloat", "ponytail-audit" oder "/ponytail-audit". Einmaliger Bericht, wendet keine Korrekturen an.

Harvest every `ponytail:` comment in the codebase into a debt ledger, so the deliberate shortcuts and deferrals ponytail leaves behind get tracked instead of rotting into "later means never". Use when the user says "ponytail debt", "/ponytail-debt", "what did ponytail defer", "list the shortcuts", "ponytail ledger", or "what did we mark to do later". One-shot report, changes nothing.

Code-Review, das sich ausschließlich auf Over-Engineering konzentriert. Findet, was gelöscht werden kann: neu erfundene Standardbibliothek, unnötige Abhängigkeiten, spekulative Abstraktionen, tote Flexibilität. Eine Zeile pro Fund: Ort, was entfernt werden soll, was es ersetzt. Verwenden, wenn der Benutzer „review for over-engineering“, „what can we delete“, „is this over-engineered“, „simplify review“ sagt oder /ponytail-review aufruft. Ergänzt die korrektheitsorientierte Review, diese jagt nur Komplexität.

pr-to-video Workflow – ein GitHub-Pull-Request (URL wie github.com/ / /pull/ , oder / # , oder „this PR“ in einem ausgecheckten Repository) -> erfasste PR-Fakten (Titel, Text, Diff, Commits, Dateien, +/- Statistiken) -> narrator_scripts.json + Audio (Sprache + Hintergrundmusik) + section_plan.md -> Code-Diff / Vorher-Nachher / Auswirkungen-Erklärvideo. Die Eingabe ist eine CODE-ÄNDERUNG. Die URL ist ein PR-Link, KEINE Marketingseite zum Scrapen; kein Text-Briefing und keine Produktwebsite. Für eine Nicht-PR-Eingabe (Produktseite, allgemeine Website, Themen-Text),...

Erstelle einen statischen interaktiven D3-Walkthrough eines Pull Requests. Verwende dies, wenn der Benutzer eine zoombare PR-Karte, eine PR-Grafik/Canvas-Orientierung oder eine alternative Visualisierung von PR-Systemkomponenten, Datenfluss, Code-Abhängigkeiten und Benutzeraktionen wünscht.

Interaktive QA-Sitzung, bei der der Benutzer Fehler oder Probleme im Gespräch meldet und der Agent GitHub-Issues erstellt. Durchsucht im Hintergrund die Codebasis nach Kontext und Fachsprache. Verwenden, wenn der Benutzer Fehler melden, QA betreiben, Issues im Gespräch erfassen oder "QA-Sitzung" erwähnen möchte.

Verwenden, wenn Code-Review-Feedback eingeht, bevor Vorschläge umgesetzt werden, insbesondere wenn das Feedback unklar oder technisch fragwürdig erscheint – erfordert technische Strenge und Überprüfung, keine bloße Zustimmung oder blinde Umsetzung.

Upgradet bestehende Websites und Apps auf Premium-Qualität. Prüft das aktuelle Design, identifiziert generische KI-Muster und wendet hochwertige Designstandards an, ohne die Funktionalität zu beeinträchtigen. Funktioniert mit jedem CSS-Framework oder Vanilla-CSS.

Erstellen Sie einen detaillierten Refactoring-Plan mit kleinen Commits durch ein Benutzergespräch und legen Sie ihn als GitHub-Issue ab. Verwenden Sie dies, wenn der Benutzer einen Refactoring planen, ein Refactoring-RFC erstellen oder einen Refactoring in sichere, schrittweise Schritte aufteilen möchte.

Verwenden, wenn Aufgaben abgeschlossen, größere Funktionen implementiert oder vor dem Zusammenführen, um zu überprüfen, ob die Arbeit den Anforderungen entspricht.

Git-Mergekonflikte auflösen, indem nur ungelöste Pfade, Konflikt-Hunks und kompakte Diffs extrahiert werden, anstatt ganze Dateien in den Kontext zu laden. Verwenden, wenn ein Merge, Rebase, Cherry-Pick oder Stash Pop bei Konflikten stoppt, wenn git status ungemergte Pfade anzeigt oder wenn Dateien Konfliktmarker enthalten.

Verwenden Sie, wenn Sie einen laufenden Git-Merge/Rebase-Konflikt lösen müssen.

Überprüfe ein Pull-Request-Diff und schreibe strukturiertes Feedback in review.json, das der Workflow veröffentlichen kann. Verwende dies, wenn ein ausgecheckter PR aus lokalen Artefakten wie pr_diff.txt und pr_description.txt überprüft wird und maschinenlesbare Review-Ausgabe erstellt werden soll, anstatt direkt auf GitHub zu posten.

Rigor Debug / Rigor Audit-Fähigkeit für Deep-Learning-Forschung. Verwenden, wenn der Benutzer einen Traceback, Terminalfehler, CUDA OOM, Checkpoint-Ladefehler, Shape-Mismatch, NaN-Verlustsymptom oder Trainingsfehler einfügt und eine konservative Diagnose vor jeglichem Patchen wünscht, wobei Debug-Fixes klar von Forschungsbeiträgen getrennt sind. Nicht verwenden für breites Refactoring, spekulative Anpassung, automatisches exploratives Patchen oder allgemeine Repository-Einarbeitung.

Richte Husky Pre-Commit-Hooks mit lint-staged (Prettier), Typprüfung und Tests im aktuellen Repository ein. Verwende dies, wenn der Benutzer Pre-Commit-Hooks hinzufügen, Husky einrichten, lint-staged konfigurieren oder Formatierungs-/Typprüfungs-/Testfunktionen zur Commit-Zeit hinzufügen möchte.

Compliance-Experte für snyk-agent-scan – den Agent-Skill-Datei-Scanner – NICHT für andere Snyk-CLI-Tools (snyk test, snyk code SAST, snyk iac, snyk container). Behebt Warnungen durch inhaltliche Umstrukturierung, niemals durch Unterdrücken oder Löschen von Informationen. Deckt jede Datei in einem Skill-Verzeichnis ab: SKILL.md, references/, assets/ und jedes sekundäre Markdown. Anwenden beim Erstellen eines neuen Skills, Bearbeiten eines bestehenden, Beheben eines fehlgeschlagenen snyk-agent-scan-Laufs lokal oder in CI oder beim Entsperren eines durch den Agenten blockierten PR...

Fundiert jede Implementierungsentscheidung mit offizieller Dokumentation. Verwenden Sie dies, wenn Sie autoritativen, quellzitierten Code ohne veraltete Muster wünschen. Verwenden Sie dies beim Erstellen mit einem Framework oder einer Bibliothek, bei dem Korrektheit wichtig ist.

Verwenden, wenn ein Fehler, Testfehler oder unerwartetes Verhalten auftritt, bevor Korrekturen vorgeschlagen werden.

Verwenden bei der Implementierung eines Features oder Bugfixes, bevor der Implementierungscode geschrieben wird.

Beherrsche das erweiterte Typsystem von TypeScript, einschließlich Generics, Conditional Types, Mapped Types, Template Literals und Utility Types, um typsichere Anwendungen zu erstellen. Verwende dies bei der Implementierung komplexer Typlogik, der Erstellung wiederverwendbarer Typ-Hilfsprogramme oder der Sicherstellung von Typsicherheit zur Kompilierzeit in TypeScript-Projekten.

Validieren, dass die Implementierung eines Branches oder Pull Requests mit den eingeführten Produkt-, technischen, Sicherheits- und zugehörigen Spezifikationen übereinstimmt. Verwenden Sie dies bei der Überprüfung oder Fertigstellung einer spezifikationsgesteuerten Änderung und beim Beheben von Abweichungen zwischen eingecheckten Spezifikationen und der Implementierung.

Verwenden, wenn behauptet werden soll, dass Arbeit abgeschlossen, behoben oder bestanden ist, vor dem Committen oder Erstellen von PRs – erfordert das Ausführen von Verifikationsbefehlen und das Bestätigen der Ausgabe, bevor Erfolgsbehauptungen aufgestellt werden; Beweise vor Behauptungen immer.