FĂ€higkeiten receiving-code-review
📩

receiving-code-review

Sicher

Code-Review-Feedback mit technischer Sorgfalt behandeln

Auch verfĂŒgbar von: Cygnusfear,ZhanlinCui,DYAI2025,obra,davila7,CodingCossack,Cycleaddict

Code-Review erfordert technische Bewertung, keine emotionale Darbietung. Dieser Skill leitet KI-Assistenten an, Feedback vor der Implementierung zu verifizieren, klĂ€rende Fragen zu stellen und begrĂŒndeten Widerstand zu leisten, wenn VorschlĂ€ge technisch unsound sind.

UnterstĂŒtzt: Claude Codex Code(CC)
đŸ„‰ 72 Bronze
1

Die Skill-ZIP herunterladen

2

In Claude hochladen

Gehe zu Einstellungen → FĂ€higkeiten → Skills → Skill hochladen

3

Einschalten und loslegen

Teste es

Verwendung von "receiving-code-review". Reviewer: Remove the legacy code path for old API versions

Erwartetes Ergebnis:

PrĂŒfe KompatibilitĂ€tsanforderungen... Build-Ziel ist 10.15+, aber diese API benötigt 13+. Der Legacy-Pfad ist weiterhin fĂŒr AbwĂ€rtskompatibilitĂ€t erforderlich. Die aktuelle Implementierung hat jedoch die falsche Bundle-ID. Ich kann die Bundle-ID korrigieren oder wir können die UnterstĂŒtzung fĂŒr Versionen vor 13 entfernen. Welche Richtung bevorzugen Sie?

Verwendung von "receiving-code-review". Reviewer: Fix items 1-6 in the PR

Erwartetes Ergebnis:

Ich verstehe die Punkte 1, 2, 3 und 6. Ich benötige vor der Implementierung KlĂ€rung zu den Punkten 4 und 5. Können Sie nĂ€her erlĂ€utern, welche Änderungen Sie sich bei diesen beiden Punkten wĂŒnschen?

Verwendung von "receiving-code-review". Reviewer: Add proper error handling with retry logic and exponential backoff

Erwartetes Ergebnis:

Korrigiert. Try/Catch mit Wiederholungslogik (3 Versuche, exponentieller Backoff starting at 100ms) zum API-Aufruf in api_service.rb:42-58 hinzugefĂŒgt. Tests bestehen.

Sicherheitsaudit

Sicher
v1 ‱ 2/24/2026

Static analysis flagged 24 instances of backtick patterns and 4 blocker patterns, but all are FALSE POSITIVES. The skill file (SKILL.md) is documentation-only markdown containing instructional text for AI behavior. No executable code, network calls, file operations, or cryptographic functions exist. The backtick patterns are markdown code blocks showing workflow examples, not shell execution. Blocker patterns are misidentified text fragments in documentation.

1
Gescannte Dateien
219
Analysierte Zeilen
0
befunde
1
Gesamtzahl Audits
Keine Sicherheitsprobleme gefunden
Auditiert von: claude

QualitÀtsbewertung

38
Architektur
100
Wartbarkeit
87
Inhalt
32
Community
100
Sicherheit
100
SpezifikationskonformitÀt

Was du bauen kannst

KI-Assistent erhÀlt menschliches Review

Ein KI-Assistent erhĂ€lt Code-Review-Feedback von einem menschlichen Entwickler und muss feststellen, welche Elemente er implementieren, welche geklĂ€rt werden mĂŒssen und bei welchen er mit technischer BegrĂŒndung Gegenargumente vorbringen soll.

Junior-Entwickler lernt Review-Antwort

Ein Junior-Entwickler lernt, wie er auf Feedback von Senior-Entwicklern mit technischer Sorgfalt statt performanter Zustimmung reagiert, indem er VorschlÀge vor blinder Implementierung verifiziert.

Externer Contributor bearbeitet Maintainer-Feedback

Ein externer Contributor erhÀlt Feedback von Projekt-Maintainern und muss bewerten, ob VorschlÀge in die Projektarchitektur passen, bevor er sie implementiert.

Probiere diese Prompts

Grundlegende KlÀrungsanfrage 
Ich habe Code-Review-Feedback mit 6 Punkten erhalten. Ich verstehe die Punkte 1, 2, 3 und 6, benötige aber vor dem Fortfahren KlĂ€rung zu den Punkten 4 und 5. Können Sie erklĂ€ren, welche Änderungen Sie sich bei diesen spezifischen Punkten wĂŒnschen?
Technischer Widerstand mit Belegen 
Ihr Vorschlag, die Legacy-KompatibilitĂ€tsschicht zu entfernen, wĂŒrde die UnterstĂŒtzung fĂŒr macOS 10.15 brechen. Die aktuelle Implementierung zielt auf 10.15+ ab, verwendet jedoch APIs, die 13+ benötigen. Soll ich die Bundle-ID korrigieren, um die AbwĂ€rtskompatibilitĂ€t zu erhalten, oder die UnterstĂŒtzung fĂŒr Versionen vor 13 vollstĂ€ndig entfernen?
YAGNI-PrĂŒfung vor der Implementierung 
Der Reviewer schlug vor, ein vollstĂ€ndiges-Metrikan-Tracking mit Datenbankspeicherung, Datumsfiltern und CSV-Export zu implementieren. Ich habe die Codebasis durchsucht und keine Aufrufer fĂŒr diesen Endpunkt gefunden. Soll ich ihn gemĂ€ĂŸ YAGNI entfernen oder gibt es Nutzung, die ich ĂŒbersehe?
Gelassene Korrektur nach falschem Gegenargument 
Ich habe gegen Ihren Vorschlag argumentiert, aber nach ÜberprĂŒfung der Testergebnisse hatten Sie recht. Mein VerstĂ€ndnis war falsch, weil ich den Integrationstestfehler ĂŒbersehen hatte. Implementiere die Korrektur jetzt.

BewÀhrte Verfahren

  • Feedback immer vor der Implementierung von Änderungen gegen die tatsĂ€chliche Codebasis verifizieren
  • Änderungen einzeln implementieren und jede einzeln testen, um Regressionen frĂŒhzeitig zu erkennen
  • Mit technischer BegrĂŒndung argumentieren, wenn VorschlĂ€ge die bestehende FunktionalitĂ€t brechen wĂŒrden

Vermeiden

  • Sagen 'Sie haben absolut recht!' oder 'Guter Punkt!' vor der Verifizierung des Feedbacks
  • Feedback blind implementieren, ohne zu prĂŒfen, ob es die bestehende FunktionalitĂ€t bricht
  • Punkte 1-3 und 6 implementieren, wĂ€hrend unklare Punkte 4-5 ĂŒbersprungen werden, ohne vorher zu fragen

HĂ€ufig gestellte Fragen

Was soll ich tun, wenn Code-Review-Feedback unklar ist?
Halte an und bitte um KlĂ€rung, bevor du etwas implementierst. Punkte könnten zusammenhĂ€ngen, und partielles VerstĂ€ndnis fĂŒhrt zur falschen Implementierung. Gib klar an, welche Punkte du verstehst und welche geklĂ€rt werden mĂŒssen.
Wann ist es angebracht, gegen Reviewer-Feedback zu argumentieren?
Argumentiere, wenn der Vorschlag die bestehende FunktionalitĂ€t bricht, dem Reviewer der vollstĂ€ndige Kontext fehlt, er gegen YAGNI fĂŒr ungenutzte Features verstĂ¶ĂŸt, er technisch falsch fĂŒr deinen Stack ist oder er mit architektonischen Entscheidungen kollidiert.
Wie argumentiere ich, ohne defensiv zu sein?
Verwende technische BegrĂŒndung, stelle spezifische Fragen, verweise auf funktionierende Tests oder bestehenden Code und ziehe deinen menschlichen Partner hinzu, wenn das Problem architektonisch ist. Gib Fakten an, keine Emotionen.
Was ist, wenn ich argumentiert habe und spÀter falsch lag?
Erkenne die Korrektur sachlich an: 'Sie hatten recht – ich habe X geprĂŒft und es tut Y. Implementiere jetzt.' Vermeide lange Entschuldigungen oder Verteidigungen, warum du ursprĂŒnglich argumentiert hast.
Warum sollte ich vermeiden, Danke zu sagen oder performativ zu sein?
Taten sagen mehr als Worte. Korrigiere das Problem einfach und zeige die Änderung im Code. Performative Zustimmung verschwendet Zeit und kann tatsĂ€chliche technische Bedenken verdecken, die angegangen werden mĂŒssen.
Wie behandle ich Feedback von externen Reviewern anders als von meinem menschlichen Partner?
Sei skeptischer gegenĂŒber externen Reviewern. PrĂŒfe, ob VorschlĂ€ge technisch korrekt fĂŒr deine Codebasis sind, nicht die bestehende FunktionalitĂ€t brechen und der Reviewer den vollstĂ€ndigen Kontext versteht. Argumentiere bei Bedarf mit BegrĂŒndung.

Entwicklerdetails

Autor

sickn33

Lizenz

MIT

Repository

https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/receiving-code-review

Ref

main

Dateistruktur

📄 SKILL.md