Cursor Automations: Ein Praxisguide für Always-on-Coding-Agenten

Der eigentliche Engpass in der Softwareentwicklung ist nicht mehr das Code-Schreiben. Inzwischen hat fast jede Entwicklerin und jeder Entwickler in Teams jeder Größe mindestens einen Agenten, der beim Ausliefern unterstützt. Coding-Agenten sind fester Bestandteil des Alltags, und die Implementierung ist nicht mehr der langsamste Teil des Systems.

Cursor Automations schließt genau diese Lücke. Statt einen Agenten immer wieder manuell anzustoßen, definierst du, wann er aktiv werden soll. Ein Trigger feuert, Anweisungen legen fest, was passiert, und der Agent läuft selbstständig. Ein Pull Request geht auf – er wird geprüft. Ein Bug-Report landet in Slack – er wird bearbeitet. Ein Zeitplan startet – ein Report wird erstellt.

In diesem Tutorial zeige ich dir Schritt für Schritt, wie du Cursor Automations von Ende zu Ende einrichtest. Du baust zwei Automationen: ein PR-Review und einen geplanten Monitor für Testabdeckung. Unterwegs erkläre ich, wie du Anweisungen strukturierst und Tools sowie MCP verbindest, damit sich die Automationen genau wie erwartet verhalten.

Ein Hinweis vorab: Automations befindet sich noch in Entwicklung, und das Dashboard unter cursor.com/automations entwickelt sich weiter. Falls sich bis zu deinem Lesen ein Menülabel oder Button geändert hat, bleibt die zugrunde liegende Logik dennoch dieselbe.

Was sind Cursor Automations?

Cursor Automations ist ein System, mit dem die Cloud-Agenten von Cursor automatisch laufen – ausgelöst durch Ereignisse in deinen Entwicklungstools oder nach einem von dir definierten Zeitplan.

Im Agent-Modus von Cursor, wie in unserem Software Development with Cursor Kurs behandelt, startest du jede Session mit einem Chat und einem Prompt, und der Agent läuft auf deinem lokalen Rechner, solange du dabei bist.

Bei Automations kommt das Startsignal von anderswo in deinem Stack, und der Agent erledigt seine Arbeit in einer Cloud-Sandbox – ohne dass du ihn beaufsichtigen musst.

Automations beinhalten Trigger-Ereignisse, die ich in der Tabelle unten zusammengefasst habe. Du kannst aber auch eigene Trigger per Webhook einrichten. Eine Automation kann mehrere Trigger haben und läuft, sobald einer davon feuert.

Jeder dieser Trigger ersetzt einen Moment in deinem Tag, in dem du sonst etwas bemerken, in den Cursor-Agent-Modus wechseln und um Hilfe bitten müsstest. 

Der Pull-Request-Trigger ist wahrscheinlich dein erster Anwendungsfall. So sieht der Lebenszyklus eines einzelnen PRs vor und nach dem Hinzufügen einer Automation aus, die dein Repository überwacht.

Was sich in der zweiten Spalte ändert, ist nicht die Geschwindigkeit einzelner Schritte, sondern dass deine Aufmerksamkeit nicht länger der Taktgeber für den gesamten Prozess ist.

So funktionieren Cursor Automations unter der Haube

Jede Automation folgt der gleichen Pipeline. Wenn dein definierter Trigger feuert, startet Cursor eine frische Cloud-Sandbox, klont dein Repository hinein und startet einen Agenten, der deinen Anweisungen folgt – mit den konfigurierten Tools, MCP-Verbindungen und dem Modell. Das Repository muss nicht auf GitHub liegen: Repositories auf Cursor Origin, Cursors eigener Git-Forge, funktionieren ebenfalls mit Cloud-Agenten und Automations.

Der Agent verifiziert sein Ergebnis vor dem Abschluss und postet es dorthin, wo du es konfiguriert hast – als PR-Kommentar, Slack-Nachricht, Linear-Ticket oder indem er einen neuen Pull Request öffnet.

Zwei Eigenschaften prägen jede Automation, die du baust:

• Die Sandbox läuft komplett in der Cursor-Cloud, nicht auf deinem Laptop. Sie läuft weiter, auch wenn dein Rechner aus ist.
• Jeder Lauf ist isoliert. Mehrere Automationen können parallel laufen, ohne sich zu stören. Cursor gibt außerdem an, intern Hunderte Automationen pro Stunde auszuführen.

Außerdem gibt es ein Memory-Tool, wie in der Vorschau unten zu sehen, mit dem deine Automation Zustand zwischen Läufen persistieren kann – das wird später beim geplanten Coverage-Monitor wichtig.

Darauf komme ich zurück, wenn du den geplanten Coverage-Monitor baust.

Cursor Automations versus Agent-Modus

Wenn du Cursor bereits regelmäßig nutzt, ist die zentrale Frage: Wann Automations statt Agent-Modus? Für einmalige Aufgaben würde ich Automations nicht verwenden. Sie sind für wiederkehrende Arbeit oder externe Ereignisse gedacht.

Wenn die Wahl nicht eindeutig ist, hilft dieser Vergleich:

Meine Faustregel: Beginnt eine Aufgabe mit „immer wenn“ oder „jedes Mal“, gehört sie in Automations.

Zum Beispiel: „Jedes Mal, wenn ein PR geöffnet wird, oder wenn ein Bug-Report in #support landet, erstelle ein Linear-Ticket.“ Der Trigger ist wiederkehrend und vorhersehbar.

Beginnt es mit „Ich muss jetzt dieses Modul refactoren“, gehört es in den Agent-Modus. Du entscheidest, wann „jetzt“ ist.

Wenn du Cursor zuerst erkunden willst, bevor du in Automations einsteigst: Unser vollständiger Cursor-2.0-Guide führt dich durch die Agents-Oberfläche, den Composer und den Multi-Agent-Workflow anhand eines vollständigen Python-Projekts.

Zugriff auf das Automations-Dashboard

Das Cursor-Automations-Dashboard findest du unter cursor.com/automations. Melde dich mit deinem Cursor-Account an – dann landest du auf dem Haupt-Dashboard, wie unten zu sehen:

Schauen wir uns an, was auf dem Dashboard zu sehen ist.

Übersichtskarten bzw. Statusanzeige oben

Die Kacheln geben dir einen Health-Überblick über alles, was gelaufen ist. Sie umfassen:

• Gesamtzahl der Automationen (wie viele konfiguriert sind) 
• Erfolgreich (abgeschlossene Läufe, inkl. Erfolgsquote)
• Fehlgeschlagen (Läufe mit Fehlern)
• Ausführungshistorie (zeigt bei Klick dein Laufvolumen über die Zeit)

Das Eingabefeld für Anweisungen

Das Eingabefeld ist der schnellste Weg, eine neue Automation zu erstellen, ohne das komplette Formular zu öffnen. Beschreibe die Aufgabe, und Cursor generiert die Struktur der Automation.

Wenn du gerade erst anfängst, würde ich dir empfehlen, hier zu starten. Überlege dir, was du automatisieren willst, und schreibe dann eine strukturierte Anleitung, der der Agent bei jedem Trigger folgt. 

Sobald du auf den Pfeil klickst, nutzt Cursor diese Anweisungen, um die Automation für dich zu erzeugen – Name, Trigger und benötigte Tools werden vorausgefüllt.

Behandle diese Anweisungen nicht wie einen normalen Prompt, sondern wie eine Spezifikation, die der Agent jedes Mal ausführt. Darauf komme ich zurück, wenn wir die erste Automation bauen.

Umschalter „mine / team“ und + Neue Automation

Der Umschalter filtert zwischen deinen Automationen und denen des Teams. 

Der + Neu-Button öffnet eine Konfigurationsseite, um eine neue Automation einzurichten:

Der Button + New Automation ist die ausführlichere Alternative zum Inline-Eingabefeld, wenn du Trigger, Anweisungen und Tool-Verbindungen manuell von Grund auf konfigurieren möchtest.

Deine Liste bestehender Automationen

Die Tabelle zeigt alle erstellten Automationen, inklusive verwendeter Tools und Ausführungshistorie.

Ein Klick öffnet die Einstellungen und die Laufhistorie der jeweiligen Automation:

Bereich mit vorgeschlagenen Vorlagen

Unter der Liste vorheriger Automationen findest du ein Raster mit Vorlagenkarten. Vorlagen liefern vorgebaute Automationen, die du anpassen kannst, statt bei null zu starten.

Cursor-Automations-Vorlagen sind der schnellste Weg, am ersten Tag eine Automation aufzusetzen. Wenn du deine erste Automation baust, prüfe, ob es eine passende Vorlage gibt, und starte damit.

Die Vorlagen zeigen dir, wie gute Anweisungen aussehen und welche Tool- bzw. MCP-Verbindungen du brauchst.

Account- und Kostenaspekte

Cursor Automations laufen auf der Cursor-Cloud-Infrastruktur und benötigen Zugriff auf Cloud-Agenten, der in kostenpflichtigen Plänen enthalten ist. Jeder Lauf verbraucht Credits – abhängig von Modellnutzung und Ausführungszeit.

Automations unterstützen drei Sichtbarkeitsstufen gemäß dem Berechtigungsmodell:

• Privat: Nur du siehst sie, abgerechnet wird über deinen Account.
• Team sichtbar: Andere können Automationen und Laufhistorie sehen, die Abrechnung läuft weiterhin über dich.
• Team-Ownership: Abrechnung über den gemeinsamen Pool des Teams, Verwaltung durch Team-Admins.

Die richtige Stufe ist wichtig, weil sie bestimmt, wessen Credits bei jedem Lauf genutzt werden. Lass Experimente privat, bis du dem Output vertraust. Wird eine Automation Teil eures Team-Workflows, wechsle in die Team-Stufe.

Das häufigste Problem ist, dass eine Automation zu früh zu breit läuft. Wenn sie bei jedem Push in einem belebten Repo triggert, kann die Nutzung schnell steigen, ohne dass du es bemerkst. Starte eng gefasst, lass sie ein paar Tage laufen, prüfe die Frequenz und entscheide dann, ob du ausweitest oder skalierst.

Deine erste Cursor-Automation: Automatisiertes PR-Code-Review

PR-Code-Review ist ein idealer erster Anwendungsfall: Der Feedback-Loop ist kurz, und die Folgen eines schlechten Laufs sind gering. Postet der Agent einen hilfreichen Kommentar, siehst du ihn sofort im PR. Liegt er daneben, ignorierst du ihn – und es wird nichts ausgeliefert.

Ich führe dich in fünf Schritten durch den Aufbau deiner ersten Automation:

1. GitHub-Repository verbinden
2. GitHub-Trigger setzen
3. Agent-Anweisungen schreiben (klare Struktur und No-Gos)
4. GitHub-Tool für Pull-Request-Kommentare hinzufügen
5. Automation deployen

Schritt 1: Dein GitHub-Repository verbinden

Bevor der Agent einen Pull Request prüfen kann, braucht er Zugriff auf ein Repository. Cursor greift über eine native GitHub-App-Integration zu. Ohne diese Verbindung sieht der Agent deinen Code nicht, kann PR-Diffs nicht lesen und kein Feedback posten – kurz: Es funktioniert nichts.

Falls du das noch nicht eingerichtet hast:

1. Installiere die Cursor GitHub App in deinem GitHub-Account oder deiner Organisation und erteile Zugriff auf die Repositories, die überwacht werden sollen.
2. Verbinde deinen GitHub-Account im Dashboard unter dem Tab „Integrations“. 

Sobald die Verbindung aktiv ist, stehen deine Repositories bei der Trigger-Konfiguration zur Auswahl.

Schritt 2: Trigger einrichten

Im Automations-Dashboard:

1. Klicke auf + New Automation, um eine neue Automation zu erstellen.
2. Benenne die Automation. Zum Beispiel PR Code Review – Open & Push – Comment Only
3. Unter Triggern auf Trigger hinzufügen klicken und GitHub wählen. Dann PR opened und PR pushed als Trigger-Ereignisse auswählen.
4. Ziel-Repository auswählen.

Wenn du Schritt 1 übersprungen hast oder GitHub zum ersten Mal mit Cursor Automations verbindest, wirst du zur Authentifizierung aufgefordert. 

In der Vorschau unten siehst du, wie du das konfigurierst und nach der Autorisierung das Ziel-Repository auswählst:

Hinweis: Wir können mehrere Trigger-Ereignisse in einer Automation bündeln, wenn sich die Anweisungen nicht je nach Ereignis unterscheiden. Ändern sich Tiefe oder Zweck des Reviews je nach Event, erstellen wir separate Automationen.

Die Automation weiß jetzt, wann sie laufen soll. Als Nächstes sagen wir ihr, was sie tun soll.

Schritt 3: Effektive Anweisungen schreiben

Die Anweisungen sind der größte Hebel für nützliche Ergebnisse. Der Agent lernt daraus, wie „gut“ aussieht. Vage Anweisungen führen zu inkonsistenten Resultaten.

Bevor wir schreiben, müssen wir verstehen, was wir festlegen: Es ist kein einmaliger Prompt. Wir definieren ein Verhalten, dem der Agent bei jedem Trigger folgt. Die Qualität der Automation hängt davon ab, wie klar wir dieses Verhalten spezifiziert haben.

Diese Struktur empfehle ich:

• Rolle definieren: Legt Perspektive und Ton fest. Zum Beispiel: „Du bist Security-Reviewer für Pull Requests.“
• Ziel definieren: Klar sagen, wie Erfolg aussieht. Zum Beispiel: „Echte Schwachstellen erkennen und verständlich erklären.“
• Scope eingrenzen: Worauf soll sich der Agent konzentrieren? Zum Beispiel: „Nur hinzugefügten oder geänderten Code prüfen.“
• Ablauf skizzieren: Einen klaren Vorgehensweg geben. Zum Beispiel: „Änderungen inspizieren, Inputs nachverfolgen, Schutzmechanismen verifizieren.“
• Ausschlüsse setzen: Explizit festlegen, was ignoriert wird, um Lärm zu reduzieren.
• Verhalten und Output definieren. Wie soll der Agent agieren, wie soll das Ergebnis aussehen?
• Grenzen setzen: Was er auf keinen Fall tun darf.

Schreibe Automations-Anweisungen wie ein Runbook: spezifisch, geordnet, mit klaren Akzeptanzkriterien und expliziten Grenzen.

Beispiel für gute Anweisungen

Hier ist die Anleitung, die ich für diese PR-Review-Automation verwendet habe. Du kannst sie in dein Anweisungsfeld kopieren und für deinen Use Case anpassen:

You are a code reviewer for pull requests triggered on PR open and push. Focus on identifying real issues that could introduce bugs, security vulnerabilities, or maintainability problems if merged. Review only added or modified code, and use surrounding context only when required to validate impact.

Check for:
- Logic errors such as incorrect conditions, edge cases, null handling, or wrong return values
- Security issues including injection, XSS, auth flaws, unsafe deserialization, or hardcoded secrets
- Contract changes such as modified APIs, response shapes, or schemas without corresponding updates
- Missing error handling or tests introduced by the change

Ignore style, formatting, naming preferences, and any pre-existing issues not introduced by this PR. Report only concrete findings with evidence from the diff, and post inline comments directly on changed lines. If no issues are found, respond: “Automated review complete: no issues found in this diff.” Do not approve, merge, push, or open PRs.Bereitgestellt von

So sieht die Anleitung im Eingabefeld aus:

Dieses Prompt ist knapp gehalten, folgt aber einer klaren, spezifischen Struktur. 

Beispiel für schlechte Anweisungen

Vermeide vage Anweisungen wie:

Review this PR and give feedback on any issues you notice.Bereitgestellt von

Ohne Struktur, Constraints und Prioritäten muss der Agent raten, was „Issues“ bedeutet – das führt zu generischem, oberflächlichem Feedback statt verlässlichen Ergebnissen.

Schritt 4: Tools hinzufügen

Öffne das Tool-Panel im Automations-Editor. Für diese Automation gehen wir in den GitHub-Bereich und wählen das Tool Comment on Pull Request. Stelle sicher, dass die PR-Genehmigung deaktiviert ist (siehe Vorschau unten), damit die Automation nur kommentieren, aber nicht freigeben kann.

Mit dem Tool Comment on Pull Request kann der Agent seine Findings im PR posten. Eine separate Verbindung ist nicht nötig, da es über dieselbe Cursor-GitHub-App läuft, die du in Schritt 1 autorisiert hast.

Wenn wir Ergebnisse an andere Dienste senden wollen (z. B. Slack), wählen wir das passende Tool oder fügen eine MCP-Verbindung hinzu. Für diese Automation reicht das Kommentar-Tool.

Schritt 5: Deployen und ersten Lauf überwachen

Wenn Trigger, Anweisungen und Tools stehen, klicken wir auf Create, um die Automation zu speichern. Dadurch öffnet sich die Einstellungsseite der Automation, wie unten zu sehen:

Jetzt müssen wir einen Lauf auslösen und beobachten, was der Agent produziert.

Öffne einen Draft-Pull-Request in deinem verbundenen Repository. Dadurch feuert der Trigger „PR opened“, und innerhalb weniger Sekunden sollte ein neuer Eintrag in der Run-Historie erscheinen, wie du unten siehst:

Öffne den Lauf und prüfe drei Dinge:

• Ausführungszeit: Wie lange der Lauf dauert. Variiert je nach Diff-Größe, Modell und Komplexität der Anweisungen.
• Tool-Aufrufe: Welche Dateien und Tools wurden verwendet? Liest der Agent irrelevante Dateien, verfeinere deine Anweisungen.
• Output: Was wurde auf GitHub gepostet? Vergleiche es mit deinen Anweisungen.

Unten siehst du die Übersicht meines Laufs. Er lief sechs Minuten, führte Aktionen aus und postete das Review mit dem Tool PostReviewCommentOnPr:

Hier ein Beispielkommentar, den der Agent in meinem PR gepostet hat:

Manchmal liegt der Output daneben – meist liegt es dann an den Anweisungen. Passe die Passage an, die das gewünschte Verhalten steuert, pushe einen neuen Commit, um einen weiteren Lauf auszulösen, und prüfe das Ergebnis.

Für die ersten Läufe solltest du es einfach halten und das Risiko gering. Hier beschränken wir uns auf Kommentare, um das Verhalten sicher zu verifizieren. Wenn die Ergebnisse konsistent sind, geht es in den echten Einsatz – und wir binden weitere Tools über GitHub hinaus an, um den Funktionsumfang zu erweitern.

Weitere Tools mit MCP verbinden

Die PR-Review-Automation läuft auf GitHub. Sie liest den Diff und postet Kommentare per GitHub-Tool „Comment on Pull Request“. Wenn der Agent mehr tun soll als Code zu reviewen, brauchen wir weitere Tools. Dafür ist der Model Context Protocol (MCP) da.

MCP ist eine Standardschnittstelle, mit der Agenten externe Tools ohne individuelle Integrationen nutzen können. Ohne MCP bräuchte jedes Tool eine eigene Einrichtung und Wartung. 

Mit MCP kann der Agent ein verbundenes Tool im Tools-Panel der Automation über dieselbe Oberfläche verwenden.

MCP macht dieselbe Automation vielseitiger, sodass sie auch in anderen Tools handeln kann. Deine PR-Review-Automation kommentiert bereits auf GitHub. Mit Slack kann sie Updates in einen Channel posten. Mit Linear kann sie Tickets anlegen. Mit Datadog Logs abrufen. Jede Verbindung erweitert, was die Automation kann – ohne ihre Kernlogik zu ändern.

Cursor Automations enthalten ein integriertes Set an MCP-Integrationen wie Slack, Linear, ClickUp, Datadog, Notion und mehr. Da MCP ein offener Standard ist, können wir jedes kompatible Tool auf dieselbe Weise anbinden.

Du findest MCP unter Tools -> MCP server auf der Einstellungsseite der Automation. Klicke auf + New Connection, um zu stöbern, und installiere bzw. verbinde das gewünschte Tool.

So fügst du sie hinzu:

Im nächsten Abschnitt zeige ich dir, wie du eine Slack-MCP-Verbindung zur PR-Review-Automation hinzufügst.

Slack-MCP-Verbindung hinzufügen

GitHub sorgt dafür, dass die Automation Code liest und kommentiert. Slack bringt die Information ins Team.

Öffne im Tools-Panel „Add Tool or MCP“, wähle MCP Server und dann „+New Connection“. Suche im sich öffnenden Panel nach Slack und wähle den Slack-MCP-Server. 

Slack ist meist schon installiert. Falls nicht, installiere es und folge dem OAuth-Flow, um deinen Workspace zu autorisieren. Nach der Verbindung erscheint es im Tools-Panel, wie unten zu sehen:

Den Ziel-Channel wählen wir nicht bei der Verbindung. Über MCP erhält der Agent Workspace-Zugriff auf öffentliche Channels. Wo genau er postet, steuern wir in den Anweisungen, zum Beispiel: „Sende eine Slack-Nachricht an #pr-alerts, wenn ein kritisches Issue gefunden wird.“

Hinweis: Slack MCP funktioniert nur mit öffentlichen Channels, und der Ziel-Channel muss den Cursor-Bot eingeladen haben, bevor gepostet werden kann. Nach dem OAuth-Flow sollte ein Cursor-Bot in deinem Workspace erscheinen. Gehe in den Channel und führe /invite @Cursor aus, um ihn hinzuzufügen.

Wenn du den Bot @Cursor nicht siehst, ist die Autorisierung möglicherweise fehlgeschlagen. Gehe zu dashboard ->  Integrations, klicke bei Slack auf Manage und starte den OAuth erneut.

Wenn du tiefer in MCP einsteigen willst, zeigt unser FastMCP 2.0 Tutorial, wie du einen eigenen MCP-Server von Grund auf baust und in Cursor integrierst.

Trigger und Tools kombinieren

Mit der Slack-MCP-Verbindung können wir die PR-Review-Automation erweitern. Wir behalten die gleichen GitHub-PR-Trigger und das GitHub-Kommentar-Tool. Zusätzlich kann der Agent kritische Findings per Slack-MCP an #pr-alerts posten.

Füge diesen Block ans Ende der Anweisungen aus Schritt 3 hinzu:

Additionally:  
If you find any issue at severity high or critical, send a Slack message to #pr-alerts containing: the PR title, the author, a one-sentence description of the most severe finding, the severity label, and a link to the PR. If no high or critical issues are found, do not post to Slack at all.Bereitgestellt von

Die letzte Zeile ist wichtiger, als sie wirkt. Ohne sie füllt sich #pr-alerts schnell mit „Alles okay“-Meldungen und verliert an Wert. Für mich ist es genauso wichtig, dem Agenten zu sagen, wann er nicht handeln soll.

Hier die Outputs eines Testlaufs in meinem Repository.

Ein Kommentar, den der Agent beim PR-Open auf GitHub gepostet hat (über das GitHub-PR-Kommentar-Tool):

Und die Slack-Benachrichtigung im Channel #pr-alerts für denselben Lauf, gesendet über die Slack-MCP-Verbindung:

An diesem Punkt hast du eine funktionierende Automation, die jeden PR reviewed, auf GitHub kommentiert und kritische Punkte an Slack eskaliert. Das ist das Grundmuster. 

Im nächsten Abschnitt bauen wir eine zweite Automation nach demselben Prinzip: Trigger, Anweisungen und die Tools, die der Agent für den Output braucht.

Zweite Automation: Geplanter Monitor für Testabdeckung

Die PR-Review-Automation reagiert auf GitHub-Ereignisse. Geplante Automationen funktionieren anders: Wir legen fest, wann der Agent laufen soll – er läuft dann unabhängig davon, was im Repo passiert ist.

Die Automation hier läuft täglich um 9 Uhr, prüft Code, der in den letzten 24 Stunden in den Main-Branch gemerged wurde, identifiziert Bereiche mit unzureichender Testabdeckung und postet eine Zusammenfassung in #repo-coverage auf Slack.

Cron-Trigger und Tool einrichten

Im Automations-Dashboard:

• Klicke auf + New, um eine neue Automation zu erstellen.
• Benenne sie Daily Coverage Check – Main Branch.

Trigger konfigurieren

• Unter Triggers „Scheduled“ wählen.
• „Every... > Day“ wählen und die Zeit auf 9:00 AM setzen.
• Falls du ein anderes Muster brauchst (z. B. nur Wochentage), nutze Custom (cron)
• Da geplante Trigger kein Repository implizieren, wähle Ziel-Repository und Branch (main) aus.

Das „Send to Slack“-Tool hinzufügen

Hier stelle ich dir das Tool Send to Slack vor, das in den Automationseinstellungen verfügbar ist. Es unterscheidet sich vom zuvor genutzten Slack-MCP: Damit senden wir gezielt Nachrichten in einen bestimmten Channel, während Slack MCP Workspace-Zugriff bietet und Posts an beliebige, in den Anweisungen definierte Channels ermöglicht.

Um Send to Slack hinzuzufügen, wähle es im Tools-Bereich und gib den Ziel-Channel für den Output der Automation an. So sollte es aussehen:

Anweisungen für eine geplante Aufgabe schreiben

Bei der PR-Review-Automation reagiert der Agent auf einen Pull Request und postet Feedback. Bei geplanten Automationen gibt es keinen Eingangskontext. Der Agent startet selbst – daher müssen wir klar sagen, wo er beginnt, was er prüft und was er postet.

Das Memory-Tool ist hier wichtig. Der Coverage-Vergleich funktioniert nur, wenn der Agent die Zahlen von gestern kennt. Wir müssen ihm sagen, unter welchem Key er liest, was er vergleicht und was er am Ende speichert. Bleibt das unklar, variieren die Ergebnisse zwischen den Läufen.

Hier ist das Anweisungset, das ich verwendet habe:

You are a daily test coverage monitor for this repository. Run every day at 9 AM on the main branch.
Identify PRs merged to main in the last 24 hours.For modified files, check if changed code paths have test coverage.Run tests with coverage:  pytest --cov=src --cov-report=json.Parse the report and record the overall coverage and per-file coverage for modified files.Read yesterday's coverage from memory (daily_coverage_latest: If none exists, post a green status and skip comparison.Compare coverage: If it drops by >1%, post a warning to #repo-coverage Slack Channel with today's value, yesterday's value, delta, and affected files. Otherwise, post a green status with today’s value and delta.Save today’s coverage to memory (daily_coverage_latest).Bereitgestellt von

Unten siehst du die Outputs meiner geplanten Automation um 9 Uhr.

Hier die Übersicht: In meinem Fall blieb die Coverage über dem Schwellwert, daher gab es lediglich einen grünen Status im Slack-Channel:

Hier die Slack-Nachricht. Das ist der erste Coverage-Lauf, entsprechend gering die Aussagekraft. Du siehst auch, dass der Lauf als Basis für den nächsten Vergleich ins Memory geschrieben wurde:

Zwei Teile der Anweisungen sind hier entscheidend. 

Erstens: Sowohl der Warnpfad als auch der grüne Pfad sind definiert. Der grüne Pfad ist nötig. Wenn wir nur festlegen, was bei Problemen passiert, bleibt die Automation bei „alles okay“ still. In einem Monitoring-Channel wirkt Stille wie ein Ausfall. Der grüne Status bestätigt den erfolgreichen Lauf.

Zweitens: Memory-Read und -Save sind explizit. Der Agent hat zwar ein Memory-Tool, nutzt es für Vergleiche aber nicht zuverlässig ohne klare Anweisung. Bleibt das implizit, variieren die Ergebnisse. Wir müssen genau angeben, welchen Key er liest, was er vergleicht und was er speichert.

Im Bild unten siehst du, dass der Agent meine Automation im Speicher abgelegt hat:

Im nächsten Abschnitt zeige ich dir typische Fallstricke und Best Practices, damit du mehr aus deinen Automationen herausholst.

Cursor Automations: Häufige Fallstricke und Best Practices

Die meisten Probleme bei Automationen beruhen auf wenigen, gut vorhersagbaren Fehlern. Sie sind leicht zu vermeiden, wenn du sie kennst – aber aufwendig zu debuggen, wenn nicht.

Häufige Fehler vermeiden

• Vage Anweisungen: Klassiker. Formulierungen wie „Code prüfen“, „auf Issues checken“ oder „Änderungen zusammenfassen“ zwingen den Agenten zu raten – das führt zu inkonsistentem Output. Hat ein Satz ein Verb ohne klares Objekt oder Bedingung, überarbeite ihn vor dem Deployment.
• Zu großer Scope: Kombiniere nicht Security-, Style-, Performance-Checks und Coverage in einer Automation. Das erschwert Debugging. Schlanke Automationen sind leichter zu verstehen. 
• Kalibrierungsphase überspringen: Aktiviere Einstellungen wie Auto-Approve oder Auto-Merge nicht frühzeitig. Lass frühe Läufe mindestens als „nur kommentieren“. Diese Läufe decken Edge Cases in deinem Code auf. Behandle sie als Validierung vor Produktion.
• Slack-Channel-Konfiguration: Slack-Trigger funktionieren nur in öffentlichen Channels. Wenn eine Slack-Automation scheinbar nichts tut, prüfe die Sichtbarkeit und ob der Bot @Cursor im Channel eingeladen ist.

Best Practices für verlässliche Automationen

• Eine Aufgabe pro Automation: Jede Automation sollte eine klar definierte Sache tun. So lassen sich Fehler leichter isolieren und beheben.
• Mit sauberem Zustand starten: Committe deinen Arbeitsbaum, bevor ein Agent Änderungen macht – so hast du immer einen klaren Diff zum Vergleichen.
• Erste Läufe als Kalibrierung behandeln: Erwarte anfangs etwas Rauschen, prüfe Outputs, justiere Anweisungen und wiederhole, bis sich das Verhalten stabilisiert.
• Klare, beschreibende Namen verwenden: Namen wie PR Code Review – Open & Push – Comment Only sind später hilfreicher als generische Labels.
• Run-Historie früh und oft prüfen: So entwickelst du in den ersten Wochen ein Gefühl für „normal“ – Abweichungen fallen später schneller auf.

Abschluss

Cursor Automations verlagert agentisches Coden vom interaktiven in ein ereignisgesteuertes System. Im Agent-Modus öffnen wir einen Chat und bitten den Agenten, Code zu prüfen, Funktionen zu refactoren oder Issues zu untersuchen. In Automations starten nicht wir die Arbeit – Trigger wie ein Pull Request, eine Slack-Nachricht oder ein Zeitplan starten den Agenten automatisch, und er erledigt die Aufgabe eigenständig. Die Hauptveränderung: Routinetätigkeiten wandern aus der manuellen Warteschlange in einen Hintergrundprozess.

In diesem Beitrag habe ich dir gezeigt, wie du zwei Automationen baust: ein PR-Review und einen geplanten Coverage-Monitor. Beide sind bewusst einfach gehalten – der ideale Einstieg, weil sie das System ohne zusätzliche Komplexität erlebbar machen. Wenn du dich sicher fühlst, kannst du komplexere Workflows umsetzen.

Der Kern: Starte mit einer schlanken Automation, schreibe Anweisungen wie ein Runbook, lass sie in einem risikoarmen Modus laufen und erweitere erst, wenn sie zuverlässig funktioniert. Der Wert entsteht weniger durch die Menge deiner Automationen als durch die Konsistenz jeder einzelnen.

Um weiterzumachen, empfehlen wir dir:

• Vertiefe dein Verständnis des Agent-Modus und des gesamten Cursor-Workflows mit unserem Software Development with Cursor Kurs.
• Sieh dir an, was neu ist in Cursor 3.0.