CommunityCodierung & Entwicklunggithub.com

duongphuhiep/dakubo-skills

Wird verwendet, wenn der Benutzer auf einen Code-Review-Kommentar reagieren möchte, indem er einen klärenden Kommentar zum Quellcode hinzufügt – damit der Reviewer das Verständnis nachvollziehen kann und denselben Hinweis nicht erneut aufgreift. Ausgelöst durch „Antworte auf Bemerkung #N“, „Kommentar hinzufügen, um Bedenken des Reviewers zu adressieren“, „Dokumentiere, warum wir X gemacht haben“ oder jede Anfrage, einen Review-Befund durch eine Erklärung im Code anstelle einer Code-Änderung zu beheben.

Was ist dakubo-skills?

Diese Fähigkeit ermöglicht es einem KI-Agenten, einen Code-Review-Kommentar zu beantworten, indem ein klärender Kommentar an der entsprechenden Stelle im Quellcode eingefügt wird. Sie ist besonders nützlich, wenn ein Entwickler die Logik oder Designentscheidung hinter einem Codeabschnitt erklären möchte, ohne den Code selbst zu ändern. Die Fähigkeit unterstützt Plattformen, die mit `dakubo-display-pr-remarks` oder `dakubo-review-commit-range` Skills integriert sind, und nutzt Kontext aus Unterhaltungen, um die genaue Beanstandung und die gewünschte Erklärung zu identifizieren. Der generierte Kommentar sollte prägnant (1-4 Zeilen) sein, sich nicht auf den Review oder die PR-Nummer beziehen und nur das „Warum“ erklären, das nicht offensichtlich aus dem Code hervorgeht. Dies hilft, zukünftige Review-Zyklen zu vermeiden und verbessert die Code-Dokumentation.

Funktioniert mit~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/duongphuhiep/dakubo-skills/tree/HEAD/package/skills/dakubo-answer-review-remark-in-code

Installed? Explore more Codierung & Entwicklung skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

Review-Bemerkung beantworten

Behebe eine Code-Review-Bemerkung, indem ein klärender Kommentar an der richtigen Stelle im Quellcode eingefügt wird, der die Begründung festhält, damit zukünftige Reviewer denselben Einwand nicht erheben.

Eingaben

Leite beide Eingaben aus dem Gesprächskontext ab. Frage nur nach, wenn sie mehrdeutig sind.

Eingabe 1 — Die Bemerkung. Ein Befund des Reviewers: meist eine Tabellenzeile mit einem Ort (Datei:Zeile) und einer Beschreibung des Anliegens. Die Tabelle stammt normalerweise aus dem Skill dakubo-display-pr-remarks oder dakubo-review-commit-range. Wenn keine Tabelle im Gespräch vorhanden ist und einer dieser Skills verfügbar ist, verwende ihn, um die Tabelle zu erstellen. Wenn nicht, frage den Benutzer nach der Bemerkung.

Eingabe 2 — Die Erklärung. Die Antwort des Entwicklers: warum der Code so wie er ist korrekt ist, die Designentscheidung dahinter, der akzeptierte Kompromiss oder der Gesamtkontext, den der Reviewer übersehen hat. Dies muss die Bemerkung nicht direkt widerlegen – es kann lediglich die Perspektive des Reviewers verschieben.

Prozess

  1. Lies die Datei an dem Ort aus Eingabe 1.
  2. Identifiziere das genaue Konstrukt, das die Bemerkung betrifft (Methode, Block, Feld, Zeile).
  3. Verfasse einen Kommentar, der:
    • Den Kern von Eingabe 2 erfasst (die Begründung / Entscheidung / den Kontext).
    • Prägnant ist – maximal ein bis vier Zeilen.
    • Den Reviewer, die PR oder die Bemerkungsnummer nicht erwähnt (Kommentare überdauern Reviews).
    • Nicht wiederholt, was der Code bereits sagt – füge nur das WARUM hinzu, das beim Lesen nicht offensichtlich ist.
    • Das Anliegen der Bemerkung adressiert, wenn dies die Erklärung klarer macht, aber dies ist optional.
  4. Platziere den Kommentar unmittelbar über dem betroffenen Konstrukt oder inline, wenn ein abschließender Kommentar natürlich passt.
  5. Wende die Bearbeitung an.

Ausgabe

Bestätige die Datei und Zeile, an der der Kommentar hinzugefügt wurde. Ein Satz reicht.

Was NICHT zu tun ist

  • Schreibe den Code nicht um, es sei denn, der Benutzer bittet explizit darum.
  • Schreibe keinen Kommentar, der lediglich wiederholt, was der Code tut.
  • Verweise im Kommentar nicht auf „der Reviewer sagte…“ oder „PR #N“.
  • Füge keinen Kommentar hinzu, der länger als ~4 Zeilen ist; wenn die Erklärung mehr braucht, gehört sie in ein Design-Dokument oder eine Commit-Nachricht, nicht inline.

Individual skills in this repo

This repo contains 4 individual skills — each has its own dedicated page.

Verwandte Skills