Zum Hauptinhalt springen
Markiere Devin in einem GitHub-Issue genauso, wie du einen Teamkollegen markieren würdest. Wenn ein Nutzer in einem Issue /devin kommentiert, startet diese Automatisierung eine Sitzung, die den vollständigen Kontext des Issues liest, die Codebase nach relevanten Dateien durchsucht, den Fix mit Tests implementiert und einen Pull Request öffnet, der auf das Issue verweist — und so den Kreis vom Fehlerbericht bis zur Codeänderung schließt.

Diese Vorlage verwenden

Öffne /devin Issue Fix in Devin und erstelle die Automatisierung mit der Standardkonfiguration. Du kannst sie vor dem Speichern anpassen.

​
Was diese Automatisierung macht

Der Befehl /devin verwandelt Ihre Liste mit GitHub-Issues in eine Warteschlange konkreter Aufgaben. Statt Tickets zu triagieren, Aufwände zu schätzen und zuzuweisen, kann ein Entwickler (oder sogar jemand ohne technischen Hintergrund) einen einzeiligen Kommentar hinterlassen und sich dann anderen Dingen widmen. Devin übernimmt Analyse, Implementierung, Testabdeckung und das Erstellen von Pull Requests (PRs) vollständig end-to-end.

​
So funktioniert es

Auslöser: GitHub-Ereignis — issue.comment
  • Ereignis: github:issue_comment
    • Bedingungen:
      • action eq created
      • comment.body starts_with /devin
      • comment.user.login neq devin-ai-integration[bot]
      • repository.full_name eq your-org/your-repo
Was Devin tut: Startet eine Sitzung mit dem vollständigen Ereigniskontext, führt den folgenden Prompt aus und benachrichtigt Sie optional im Fehlerfall.

​
Voraussetzungen

​
Beispiel-Prompt

Die Vorlage wird mit diesem Prompt ausgeliefert. Du kannst ihn bearbeiten, nachdem du auf Vorlage verwenden geklickt hast, oder ihn unverändert lassen.

​
Einrichtung

  1. Öffnen Sie Automations → Templates in Devin.
  2. Klicken Sie auf /devin Issue Fix. Die Erstellungsseite öffnet sich mit dieser vorausgefüllten Vorlage.
  3. Verbinden Sie alle erforderlichen Integrationen und installieren Sie MCP-Server, falls Sie das noch nicht getan haben.
  4. Ersetzen Sie alle Platzhalterwerte in den Trigger-Bedingungen (zum Beispiel your-org/your-repo durch Ihr tatsächliches Repo).
  5. Prüfen Sie den Prompt und passen Sie ihn an die Sprache, Konventionen und Guardrails Ihres Teams an.
  6. Klicken Sie auf Create automation.
Die meisten Automatisierungsvorlagen enthalten empfohlene ACU- und Aufruflimits, um die Kosten während des anfänglichen Rollouts zu begrenzen. Belassen Sie diese zunächst unverändert, bis Sie sicher sind, wie sich die Automatisierung verhält, und erhöhen Sie sie dann entsprechend Ihrer Auslastung.

​
Wann Sie diese Vorlage verwenden sollten

  • Von der Community gemeldete Fehler mit einem klaren Reproduktionsschritt
  • Kleine Feature-Anfragen mit klar definierten Akzeptanzkriterien
  • Fixes in der Dokumentation, Tippfehler und geringfügige stilistische Änderungen
  • Teammitgliedern ohne Engineering-Hintergrund einen reibungslosen Weg bieten, Fixes bereitzustellen

​
Ideen zur Anpassung

  • Auf eine bestimmte Gruppe von Repositories oder GitHub-Organisationen beschränken
  • Voraussetzen, dass die kommentierende Person Mitwirkende*r ist (eine Bedingung für comment.author_association hinzufügen)
  • An ein Playbook weiterleiten, das die Fix-Konventionen Ihres Teams festhält
  • Mit Bug Report Triage kombinieren, damit Fehler aus Linear denselben Fix-Ablauf durchlaufen

​
Siehe auch