IDE-Tools · Foto: Homedust, CC BY 2.0
analyze-issue.mdc
Zuletzt aktualisiert:
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
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
- Issue mit möglichst vollständiger Beschreibung und relevanten Kommentaren verlinken
- Generierte Akzeptanzkriterien und die vorgeschlagenen betroffenen Dateien gegen das eigene Wissen prüfen
- Den erstellten Umsetzungsplan im Team oder mit Reviewer abstimmen, bevor das eigentliche Coding beginnt
- Bei Bezügen über mehrere Repositories kontrollieren, ob diese Zusammenhänge korrekt erkannt wurden
- 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
- Lizenz: MIT
- Quelle: github.com/steipete/agent-rules
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 …
Passt dazu.
v5.md
Basis-Regelwerk: Task-Klassifizierung (leicht/standard/kritisch), Tool-Nutzung, Antwortstil
prompt-injection-guard.md
Schutz vor Prompt-Injection aus externem Kontext (Web/RAG/Dateien): Stopp + Rückfrage bei gefährlichen Aktionen
commit-message-format.md
Commit-Messages nach Conventional Commits (Prefix + Summary + Bullet-Body)
