In jedem Engineering-Team gibt es eine Ebene wiederkehrender Arbeit, die niemand geplant hat und die trotzdem alle bezahlen. Jemand stellt die Zusammenfassung fürs Daily zusammen. Jemand liest jeden eingehenden Bugreport und leitet ihn weiter. Jemand bastelt den Freitags-Statusbericht aus sechs Tabs mit verstreuten Informationen zusammen. Nichts davon ist schwierig. Aber alles davon ist Routinearbeit: vorhersehbar, wiederholbar und im Stillen teuer, weil sie an der Person hängen bleibt, die es zuerst bemerkt hat.
Genau diese Art von Arbeit erledigt ein KI-Agent gut – vorausgesetzt, etwas startet den Agent zum richtigen Zeitpunkt, ohne dass ein Mensch einen Prompt tippt. Genau diesen Startmechanismus liefern die Automations in Sharkly. Eine Automation ist eine Definition im Besitz eines Space für wiederkehrende Agent- oder Crew-Arbeit: schriftliche Anweisungen, ein Assignee, der die Ausführung übernimmt, ein oder mehrere Trigger und ein Run-Verlauf, den du einsehen kannst.
Es geht dabei nicht darum, Urteilsvermögen zu automatisieren. Sharkly formuliert es selbst unmissverständlich: Automatisierung endet dort, wo das Urteilsvermögen des Teams gefragt ist. Eine Automation kann die Standup-Zusammenfassung entwerfen, einen Bug erstmalig sichten und den Wochenbericht zusammenstellen. Was das Team damit macht, entscheidet weiterhin ein Mensch. Wenn du Sharkly selbst noch nicht kennst, lies zuerst was Sharkly ist und komm dann zurück.
TL;DR
Eine Automation in Sharkly ist eine Regel, die einem Space gehört und einen Agent oder eine Crew mit einem festen Satz Anweisungen startet, sobald ein Trigger ausgelöst wird. Es gibt vier Trigger-Typen: einen Zeitplan (Fünf-Felder-Cron mit Zeitzone), eine Statusänderung einer Aufgabe, einen Kommentar mit einem konfigurierten Ausdruck und eine geheime Webhook-URL für externe Dienste – dazu einen Button Run now für manuelle Tests. Jeder Run wird im Run-Verlauf mit Quelle, Ergebnis und Fehlergrund festgehalten, und eine Automation lässt sich pausieren und fortsetzen, während du sie überarbeitest. Nutze Automations für klar definierte wiederkehrende Arbeit: Standup-Zusammenfassungen, erstmalige Bug-Triage, regelmäßige Berichte. Der Agent übernimmt das Lesen und Entwerfen; ein Mensch prüft das Ergebnis und entscheidet.
Was eine Automation ist – und was sie nicht ist
Eine Automation speichert eine kleine, vollständige Definition eines einzigen wiederkehrenden Jobs: einen Namen und Anweisungen, die Ziel, Schritte, Einschränkungen und erwartetes Ergebnis beschreiben; den Space, dem sie gehört; einen Assignee, also den Agent oder die Crew, die die Arbeit erledigt; eine Priorität; einen Status (Active oder Paused); einen oder mehrere Trigger; und einen Run-Verlauf, der für jeden Run Quelle, Ergebnis, Agent-Run und Fehlergrund festhält.
Zwei Grenzen würden dich sonst überraschen.
Erstens: Eine Automation legt nicht für jeden Run eine Aufgabe an. Sie startet direkt einen Agent- oder Crew-Run. Der Run, seine Ausgabe und etwaige Fehler landen im Run-Verlauf der Automation und nicht in deiner Aufgabenliste – so füllt sich dein Board nicht jeden Morgen um neun mit maschinell erzeugten Aufgaben.
Zweitens sind Automations nicht der Workflow-Canvas von Sharkly. Ein Space hat zwei Automatisierungs-Oberflächen: Automations – die einzelne, hier beschriebene Regel – und Automation workflows, ein Canvas aus Trigger- und Aktionsknoten, die Drittanbieter-Connectoren aufrufen können. Nutze eine Automation, wenn ein Agent oder eine Crew als Reaktion auf ein vorhersehbares Ereignis einen festen Satz Anweisungen ausführen soll. Nutze einen Workflow, wenn du mehrstufige oder App-übergreifende Aktionen brauchst, bevor der Agent überhaupt ins Spiel kommt.
Weil der Assignee ein vollwertiger Sharkly-Agent ist, gilt alles, was du an diesem Agent bereits konfiguriert hast: seine Anweisungen, Runtime, Skills, Repositories und Run-Einstellungen. Wenn du noch keinen gebaut hast, erklärt Agents in Sharkly, wie aus einer gespeicherten funktionierenden Konfiguration etwas wird, das ein Team wiederverwenden kann. Eine Automation ist gewissermaßen ein fest eingeplanter Termin mit diesem Agent.
Die vier Trigger-Typen
Eine Automation kann mehrere Trigger haben, die sich unabhängig voneinander aktivieren oder deaktivieren lassen. Eine Definition kann mehrere Einstiegspunkte bedienen: Dieselben Triage-Anweisungen können bei einer Statusänderung und bei einem Slash-Befehl ausgelöst werden, ohne dass irgendetwas doppelt gepflegt werden muss.
| Trigger | Wird ausgelöst, wenn | Am besten geeignet für | Worauf du achten solltest |
|---|---|---|---|
| Zeitplan | Ein Cron-Ausdruck in einer gewählten Zeitzone zutrifft | Wiederkehrende Prüfungen, Zusammenfassungen, Erinnerungen, Wartungsarbeiten | Wahl der Zeitzone; Runs finden statt, ob sich etwas geändert hat oder nicht |
| Statusänderung einer Aufgabe | Eine Aufgabe in einen ausgewählten Organisations-Status wechselt | Intake-Warteschlangen, Follow-up nach Reviews, Triage | Das Matching läuft organisationsweit, nicht auf einen Space gefiltert |
| Kommentar-Phrase | Ein Aufgabenkommentar einen konfigurierten Ausdruck enthält, unabhängig von Groß- und Kleinschreibung | Bedarfsgesteuerte Befehle wie /triage direkt aus einer Diskussion heraus | Hört ebenfalls organisationsweit mit; wähle einen unverwechselbaren Ausdruck |
| Webhook | Ein externer Dienst ein POST an eine geheime URL sendet | CI-Ergebnisse, GitHub-Events, Alarme aus anderen Systemen | Die URL ist ein Bearer-Secret; sicher speichern und sorgfältig rotieren |
Zeitplan nutzt einen standardmäßigen Fünf-Felder-Cron-Ausdruck und eine Zeitzone, mit gängigen Presets für stündlich, täglich, werktags und wöchentlich. Das ist der Trigger für Arbeit, die stattfinden soll, weil Dienstag ist – und nicht, weil sich etwas geändert hat.
Statusänderung einer Aufgabe startet die Automation, wenn eine Aufgabe in einen ausgewählten Organisations-Status wechselt. Ein Detail ist dabei wichtig: Statuses sind wiederverwendbare Definitionen auf Organisationsebene, und das aktuelle Event-Matching läuft organisationsweit. Wenn mehrere Spaces denselben Status „Needs Triage“ verwenden, kann ein passender Übergang in einem beliebigen davon deine Automation starten. Formuliere die Anweisungen so, dass der Agent die auslösende Aufgabe prüft, bevor er handelt.
Kommentar-Phrase startet einen Run, wenn ein Aufgabenkommentar einen konfigurierten Ausdruck enthält. Das Matching ignoriert Groß- und Kleinschreibung, prüft den gesamten Kommentar und hört ebenfalls organisationsweit mit. Der Rat der Doku: Nimm lieber einen unverwechselbaren Slash-Befehl wie /triage-bug statt „check“ und lass die Anweisungen die auslösende Aufgabe validieren.
Webhook erstellt eine geheime URL, die ein POST von einem externen Dienst entgegennimmt. Die vollständige URL wird beim Erstellen oder Neu-Generieren des Triggers angezeigt und ist später nicht mehr einsehbar, denn standardmäßig fungiert die URL selbst als Bearer-Secret. Wenn du ein Signing-Secret konfigurierst, müssen Requests zusätzlich die Signaturprüfung bestehen – dasselbe Muster, das GitHub für seine eigenen Webhooks verwendet. Halte diese Secrets aus der Versionsverwaltung heraus und generiere sie neu, falls sie offengelegt wurden. Wie du Sharkly über Webhooks hinaus per Skript steuerst, erfährst du unter Sharkly CLI und API.
Eine weitere Möglichkeit, einen Run zu starten, ist gar kein Trigger: Mit Run now startest du die Automation direkt – so kannst du Anweisungen und die Verfügbarkeit des Assignees testen, bevor du die vier Trigger auf die Aufgabe loslässt.
Was eine Automation tatsächlich ausführt
Wenn ein Trigger ausgelöst wird, startet Sharkly den zugewiesenen Agent oder die Crew mit den Anweisungen der Automation. Diese Anweisungen sind der gesamte Vertrag, deshalb ist die Doku sehr konkret, was darin stehen sollte: das zu erzielende Ergebnis, die zu prüfenden Eingaben, die einzuhaltenden Schritte, wo das Resultat festgehalten werden soll, welche Änderungen erlaubt sind und wann ein Mensch prüfen oder entscheiden muss.
Der letzte Punkt verdient besondere Betonung. Eine gut geschriebene Automation benennt ihren eigenen Endpunkt. „Entwirf die Zusammenfassung und halte sie fest; ändere keine Aufgabenstatus“ ist eine bessere Anweisung als eine längere, die die Zuständigkeit im Unklaren lässt. Die Einführungsempfehlung der Doku ist ebenso klar: Beginne mit Arbeit, die beobachtbar und umkehrbar ist, und prüfe mehrere Runs, bevor du den Umfang erweiterst.
Drei Routinearbeiten, die sich zuerst automatisieren lassen
Jede der drei bleibt auf dem Genauigkeitsniveau, das das Produkt unterstützt: Der Agent liest, entwirft und hält fest; die Entscheidungen bleiben bei den Menschen.
Die tägliche Standup-Zusammenfassung. Trigger: ein Zeitplan mit Werktags-Preset in der Zeitzone des Teams. Assignee: ein Reporting-Agent mit Lesezugriff auf den relevanten Kontext. Anweisungen: die Aufgaben des aktuellen Sprints prüfen, festhalten, was sich bewegt hat, was blockiert ist und was auf Review wartet, dann eine kurze Zusammenfassung dort ablegen, wo das Team sie liest – ohne irgendeine Aufgabe zu verändern. Der Agent übernimmt den Teil des Standups, den niemand mag, nämlich das Zusammensetzen des Gesamtbilds, und das Standup wird zu einem Gespräch über die zwei Punkte, die echtes Urteilsvermögen erfordern. Wenn dein Team seinen Rhythmus über Sharkly abbildet, liefern Sprints die Struktur, die der Agent inspiziert.
Erstmalige Bug-Triage. Trigger: ein Aufgaben-Status-Trigger auf deinen Bug-Intake-Status oder ein Kommentar-Trigger auf einen unverwechselbaren Ausdruck wie /triage – oder beides. Assignee: ein Triage-Agent, dessen Repositories den betroffenen Code abdecken. Anweisungen: Prüfe, ob es sich bei der auslösenden Aufgabe um einen Bug im vorgesehenen Space handelt, lies den Report, sieh dir den relevanten Bereich der Codebasis an und halte dann fest, was der Bug vermutlich berührt, ob der Report genug für ein Vorgehen enthält und welche Priorität du mit welcher Begründung vorschlägst. Empfehlen, nicht entscheiden. Der Verifizierungsschritt ist keine Deko: Weil Status- und Kommentar-Matching organisationsweit laufen, sind die Anweisungen dein Scope-Filter. Der Gewinn: Jeder Bug bekommt innerhalb von Minuten nach Eingang dieselbe sorgfältige erste Sichtung. Dieselbe Arbeitsteilung gilt, wenn Arbeit von außerhalb Sharklys hereinkommt; sieh dir an, wie aus einem Jira-Ticket die Aufgabe eines Agent wird.
Der regelmäßige Bericht. Trigger: ein Zeitplan mit Wochen-Preset. Assignee: derselbe Typ Reporting-Agent, mit Anweisungen für ein längeres Zeitfenster: zusammenfassen, was abgeschlossen wurde, was sich verzögert hat und was blockiert ist. Der Unterschied zum Standup-Fall liegt nur in Umfang und Zielgruppe – genau deshalb gehört er in eine Automation. Der Bericht, der jeden Freitag in gleichbleibender Qualität vorliegt, schlägt den besseren Bericht, der nur entsteht, wenn mal jemand Zeit hat.
Bei allen drei fällt auf, was in den Anweisungen nie vorkommt: annehmen, genehmigen, ausliefern, schließen, entscheiden.
Run-Verlauf, Zustand sowie Pausieren und Fortsetzen
Automatisierung, die du nicht einsehen kannst, ist Automatisierung, der du nicht trauen kannst – deshalb wird jeder Run aufgezeichnet. Der Run-Verlauf weist jeden Run als Running, Completed, Failed oder Skipped aus, und in den Run-Details kannst du die Trigger-Payload, den Agent-Run, die Ausgabe und den festgehaltenen Fehlergrund öffnen. Über den einzelnen Runs fasst ein Health-Signal den letzten aussagekräftigen Zustand zusammen: never tested, running, healthy, skipped oder needs attention.
Eine Einschränkung solltest du dir fett einprägen: Der Status Completed beschreibt den Run der Automation – er ist kein Versprechen, dass jedes nachgelagerte Ergebnis korrekt war. Completed heißt, dass die Maschinerie funktioniert hat. Ob die Zusammenfassung korrekt war oder die Triage-Einschätzung stimmig ist, muss weiterhin ein Mensch beurteilen.
Pausieren und Fortsetzen gibt es genau für die Momente, die du erwartest. Pausiere eine Automation, um neue getriggerte Runs zu stoppen, während du Anweisungen, Trigger oder Assignee überarbeitest, und setze sie fort, wenn die Konfiguration passt; Definition und Verlauf bleiben dazwischen unangetastet. Löschen ist der einzige Weg zum Entfernen – spar dir das für Definitionen auf, deren Run-Verlauf du nicht mehr brauchst. Und bevor du einen Agent archivierst, prüfe, ob noch Automations von ihm abhängen.
Bevor du dich auf eine Automation verlässt, empfiehlt die Doku eine kurze Checkliste: Führe sie manuell mit Run now aus, stelle sicher, dass der Agent oder die Crew die nötigen Zugriffsrechte hat, prüfe den Run und seine Ausgabe, teste jeden Trigger einzeln, nutze einen eng gefassten Status oder eine unverwechselbare Kommentar-Phrase und halte Webhook-Secrets aus der Versionsverwaltung heraus.
Wo die Automatisierung endet
Man könnte leicht zu dem Schluss kommen, das Ziel sei eine Pipeline ohne menschliches Eingreifen. Das ist es nicht – und das Design des Produkts sagt das selbst. Automations nehmen ihre eigene Ausgabe nicht ab, und sie zeichnen jeden Run zur Überprüfung auf.
Die ehrliche Entscheidungsregel lautet also: Nutze eine Automation, wenn dieselbe klar definierte Arbeit wiederholt oder als Reaktion auf ein vorhersehbares Ereignis starten soll und wenn ein gleichbleibend guter erster Entwurf besser ist als ein gelegentlich exzellenter. Weise einem Agent eine Aufgabe direkt zu, wenn es sich um einmalige Arbeit handelt, und lass die Arbeit komplett bei Menschen, wenn die Aufgabe das Urteilsvermögen selbst ist: eine Prioritätsentscheidung unter widersprüchlichem Druck, eine Abnahmeentscheidung, alles, wo beständig falsch schlimmer ist als gelegentlich langsam.
Fang klein und langweilig an. Richte alles ein, erstelle einen Reporting-Agent, schreibe eine Automation mit Werktags-Zeitplan und Anweisungen, die mit „Ändere keine Aufgabe“ enden, und führe sie einmal manuell aus. Lies die Ausgabe. Wenn sie nützlich ist, überlass das Weitere dem Zeitplan. Die Doku behandelt Automations und den Workflow-Canvas ausführlicher.
FAQ
Welche Trigger-Typen unterstützen Sharkly Automations?
Vier: einen Zeitplan auf Basis eines Fünf-Felder-Cron-Ausdrucks mit Zeitzone, einen Aufgaben-Status-Trigger, der auslöst, wenn eine Aufgabe in einen ausgewählten Organisations-Status wechselt, einen Kommentar-Trigger, der auf einen konfigurierten Ausdruck reagiert, und einen Webhook-Trigger, der ein POST an einer geheimen URL annimmt. Eine Automation kann mehrere Trigger kombinieren, die sich unabhängig voneinander aktivieren oder deaktivieren lassen; mit Run now startest du einen Run manuell zum Testen.
Legt eine Automation bei jedem Run eine Aufgabe an?
Nein. Aktuelle Automations starten direkt Agent- oder Crew-Runs und legen nicht für jeden Run eine Aufgabe an. Der Run, seine Ausgabe und ein etwaiger Fehlergrund werden im Run-Verlauf der Automation festgehalten. Wenn du das Ergebnis an einer Stelle haben willst, die das Team liest, dann schreib das in die Anweisungen.
Worin unterscheiden sich Automations von Automation workflows?
Es sind zwei getrennte Oberflächen in einem Space. Eine Automation ist eine Regel: wann gestartet wird, welcher Agent oder welche Crew läuft und welche Anweisungen befolgt werden. Automation workflows sind ein Canvas aus Trigger- und Aktionsknoten, die über Connectoren Drittanbieter-Apps aufrufen können. Nutze die einzelne Regel für wiederkehrende Prüfungen und Kommentar-Befehle; nutze den Canvas für mehrstufige, App-übergreifende Abläufe.
Kann eine Automation Bug-Triage selbst übernehmen?
Sie kann den ersten Durchgang übernehmen: die auslösende Aufgabe prüfen, den Report lesen, den relevanten Code ansehen und die Erkenntnisse mit einer vorgeschlagenen Priorität festhalten. Die Triage-Entscheidung bleibt bei einem Menschen, und die Anweisungen sollten das ausdrücklich sagen. Die Doku empfiehlt, mit beobachtbarer, umkehrbarer Arbeit zu beginnen und mehrere Runs zu prüfen, bevor du den Umfang erweiterst.
Was passiert, wenn ein Automation-Run fehlschlägt?
Der Run wird im Run-Verlauf als Failed samt Fehlergrund festgehalten, sofern einer vorliegt, und das Health-Signal wechselt auf needs attention. Öffne die Run-Details, um Trigger-Payload, Agent-Run und Ausgabe zu prüfen, korrigiere Anweisungen, Trigger oder Assignee und nutze Run now, um die Korrektur zu verifizieren, bevor du den Triggern wieder vertraust.
