machichdigital

IDE-Tools · Foto: Homedust, CC BY 2.0

RuleWindsurf Rules & Cross-IDE-RulesLizenz: MITfrei kopierbar

analyze-issue.mdc

Zuletzt aktualisiert:

⬇ Als Datei laden

⧉ –× kopiert⬇ –× heruntergeladenBewertung:

Typ

Rule

Lizenz

MIT

Anwendungsfeld

Windsurf Rules & Cross-IDE-Rules

Issue-getriebene Teams

Voraussetzungen

  • GitHub-Issues mit ausreichender Beschreibung und ggf. Kommentaren
  • Zugriff auf das betroffene Repository

Einordnung

AufwandEinrichtung & Einarbeitung2/5 · eher geringNutzenErtrag im Alltag3/5 · mittelVoraussetzungenWas vorher da sein muss3/5 · mittel1 = gering5 = hoch

Spart Missverständnisse bei größeren Issues, ist für kleine Bugfixes aber ein unnötiger Zusatzschritt.

GitHub-Issue analysieren und Implementierungs-Spezifikation erstellen

Für wen: Issue-getriebene Teams

Im Detail

Diese Regel wandelt ein rohes GitHub-Issue in eine strukturierte Implementierungs-Spezifikation um, bevor Code geschrieben wird. Der Agent liest Issue-Text, verlinkte Kommentare und Projektkontext und leitet daraus Akzeptanzkriterien, betroffene Dateien und einen Umsetzungsplan ab. Das verhindert, dass man mitten in der Implementierung merkt, dass Anforderungen unklar waren. Besonders lohnend für Teams, die viele Issues über mehrere Repos oder Entwickler hinweg bearbeiten und eine einheitliche Vorstufe vor dem eigentlichen Coding brauchen. Für einzelne, sehr kleine Bugfixes ist der Zusatzschritt oft überdimensioniert.

Schritt für Schritt

  1. Issue mit möglichst vollständiger Beschreibung und relevanten Kommentaren verlinken
  2. Generierte Akzeptanzkriterien und die vorgeschlagenen betroffenen Dateien gegen das eigene Wissen prüfen
  3. Den erstellten Umsetzungsplan im Team oder mit Reviewer abstimmen, bevor das eigentliche Coding beginnt
  4. Bei Bezügen über mehrere Repositories kontrollieren, ob diese Zusammenhänge korrekt erkannt wurden
  5. Für sehr kleine, eindeutige Bugfixes die Regel weglassen, da der Zusatzschritt dort wenig bringt

Beispiel aus der Praxis

Zum Issue „Exportfunktion crasht bei leerem Datensatz“ mit mehreren Diskussionskommentaren leitet die Regel ein Akzeptanzkriterium, betroffene Dateien wie export.py und einen Umsetzungsplan ab, bevor jemand mit dem eigentlichen Coding beginnt.

Praxis-Tipp

Nutzen Sie die Regel direkt nach dem Verlinken eines Issues, z. B. mit “Analysiere Issue #482 und erstelle die Spec”, bevor Sie implement-task.mdc aufrufen.

Stolperfallen

Unklar oder knapp formulierte Issues führen zu ebenso unpräzisen Spezifikationen – die Ausgabe ist immer nur so gut wie der Issue-Text und die verlinkten Kommentare. Bei trivialen Ein-Zeilen-Fixes lohnt sich der Zwischenschritt meist nicht und kostet nur Zeit.

Siehe auch

Lizenz & Quelle

Häufige Fragen.

Ersetzt das die eigentliche Implementierung?

Nein, die Regel erstellt nur die Spezifikation vorab; das eigentliche Coding erfolgt danach separat.

Funktioniert das auch bei Issues ohne Kommentare?

Es funktioniert, liefert dann aber weniger Kontext, da verlinkte Diskussionen eine wichtige Quelle für die Ableitung der Kriterien sind.

Für welche Teamgröße ist das sinnvoll?

Besonders für Teams, die viele Issues über mehrere Repositories oder Entwickler hinweg bearbeiten und eine einheitliche Vorstufe vor dem Coding brauchen.

Inhalt ansehen (analyze-issue.mdc)
Lade …

Erfahrungen & Kommentare.

Funktioniert der Rule bei Ihnen? Tipps, Stolperfallen, Varianten — teilen Sie es mit der Community.

Lade Kommentare …

Ihre IP-Adresse wird zum Schutz vor Missbrauch gespeichert und nach 14 Tagen automatisch entfernt (Datenschutz).

Passt dazu.

v5.md

Basis-Regelwerk: Task-Klassifizierung (leicht/standard/kritisch), Tool-Nutzung, Antwortstil

MIT♥ –⧉ –