Automatisierungen erstellen oder importieren

Unter Automatisierungen findest du die Workflows deiner Organisation. Nur Inhaber, Admins und Entwickler sehen diesen Bereich und verwalten seine Automatisierungen. Prüfe zuerst, ob eine mitgelieferte Automatisierung zur Aufgabe passt. Andernfalls erstellst du einen Entwurf und testest ihn, bevor du ihn live schaltest.

Du kannst nach Name oder Slug suchen. Gib zum Beispiel Triage ein, um die mitgelieferten Triage-Workflows zu vergleichen.

Einen Ausgangspunkt wählen

Jede Zeile zeigt Name, Projektzuordnungen, Versionsanzahl und Live-Version oder Nicht live. Daneben zeigt Trigger, ob die Automatisierung von selbst startet; darunter steht die Art des Triggers (Zeitplan, Webhook oder Plattform-Ereignis). Aktiv bedeutet, dass der Trigger Läufe startet, Pausiert, dass er sich nach wiederholten Fehlern selbst ausgeschaltet hat, Aus, dass er nichts startet, bis jemand ihn wieder einschaltet, und Nicht live, dass er auf eine Live-Version wartet. Manuell, darunter Von Hand, API oder MCP, steht bei einer Automatisierung ohne Trigger: Sie läuft, sobald jemand sie startet. Kann die Liste den Zustand nicht bestimmen, etwa während eines Updates, zeigt sie Unbekannt; unter Allgemein siehst du den Trigger selbst immer. Öffne sie im Tab Editor, um den Ablauf zu prüfen. Unter Allgemein findest du Trigger und Projekte: Unter Projekte legst du fest, welche Boards die Automatisierung nutzen können. Ohne Projektzuordnung steht sie der Organisation zur Verfügung. Projekte bietet nur Projekte an, die du öffnen kannst. Zuordnungen zu Projekten, die du nicht siehst, bleiben beim Speichern erhalten. Eine Automatisierung, die nur solchen Projekten zugeordnet ist, erscheint nicht in deiner Liste. Die Auswahl Version rechts neben den Tabs zeigt den gespeicherten Verlauf, unter Läufe die letzten Ausführungen. Die Versionsanzahl einer Zeile oder Versionsverlauf in ihrem Zeilenmenü öffnet Versionen: jede gespeicherte Version und jede Live-Schaltung.

Das Menü Automatisierung erstellen bietet drei Wege:

Mitgelieferte Automatisierungen werden beim Erstellen der Organisation eingerichtet. Für den automatischen Einsatz brauchen sie dennoch ihre Konfiguration und eine Live-Version. Der Workflow-Editor führt durch Eingaben, Test, Ergebnisprüfung und Live-Schaltung.

Ein Paket importieren

Ein Pack enthält die erforderliche workflow.yml, optional das Manifest automation.yml und bei Bedarf Skill-Bundles:

review-invoices/
├── workflow.yml
├── automation.yml
└── skills/
    └── invoice-rules/
        ├── SKILL.md
        └── references/
            └── checklist-rules.md

1. 1

   Dateien auswählen

   Wähle Automatisierung erstellen > Paket hochladen. Lade Workflow und optionales Manifest einzeln hoch oder wähle genau eine .zip mit dem Pack. Für mitgelieferte Skills brauchst du die ZIP-Datei. Markdown-Notizen außerhalb von skills/, versteckte Dateien und Build-Reste wie node_modules/ und __pycache__/ werden ignoriert.

2. 2

   Ziel festlegen

   Wähle unter Installieren in die Organisation oder ein bestehendes Projekt. Ein Manifest mit scope: project verlangt ein Projekt. Importierst du eine bestehende Automatisierung in ein weiteres Projekt, kommt diese Zuordnung hinzu; frühere bleiben erhalten. Unter Projekte im Tab Allgemein der Automatisierung kannst du später alle Zuordnungen bearbeiten.

   

3. 3

   Prüfen und speichern

   Wähle Paket hochladen und behebe gemeldete Fehler im Workflow, Manifest oder Skill. Besteht der Workflow die Prüfungen nicht, meldet der Dialog Dieses Paket besteht die Prüfungen nicht. und listet jedes Problem so auf wie die Liste Probleme im Editor: was falsch ist, den Code und wie du es behebst. Korrigiere die Datei und lade sie erneut hoch. Erst nach erfolgreicher Prüfung werden Automatisierung und mitgelieferte Skills geschrieben. Ein erneuter Import derselben Automatisierung ergänzt eine Entwurfsversion; die bisherige Historie bleibt erhalten.

4. 4

   Vor der Live-Schaltung prüfen

   Mit Später öffnest und testest du den Entwurf anschließend im Editor. Der Erfolgsdialog bietet auch an, die angezeigte Version direkt live zu schalten. Der Upload allein ändert die Live-Version nicht. Richte benötigte Zugangsdaten ein und prüfe die Skills vor der Freigabe für den Betrieb.

Die ZIP-Datei darf komprimiert und entpackt jeweils höchstens 20 MiB enthalten: maximal 500 Dateien, 2 MiB je Datei und 20 Skill-Bundles. Entferne bei einer Größenüberschreitung erzeugte Artefakte und trenne unabhängige Inhalte in eigene Skills. Stärkere Komprimierung behebt ein zu großes entpacktes Paket nicht.

Konflikte bei Skills klären

Die skills-Liste im Manifest muss zu den Ordnern unter skills/ passen. Nicht deklarierte Ordner und deklarierte, aber fehlende Bundles führen zur Ablehnung. Jedes Bundle braucht gültige Metadaten in SKILL.md; name muss dem Ordnernamen entsprechen. Mitgelieferte Skills folgen den Regeln der Skill-Bibliothek: Ein neuer Skill gehört der Person, die das Paket hochlädt. Ein ersetzter behält seinen Eigentümer; hatte er keinen, gehört er danach der hochladenden Person. Neue oder geänderte Teamlisten dürfen nur Teams enthalten, mit denen diese Person teilen darf. Bestehende Listen dürfen unverändert bleiben. Tale prüft die Zielgruppen aller mitgelieferten Skills, bevor es einen davon installiert.

# automation.yml
name: Review invoices
skills:
  - invoice-rules

Neue Bundles werden in die Skill-Bibliothek der Organisation aufgenommen. Identische bleiben unverändert. Bei anderem Inhalt hält der Upload an und nennt die betroffenen Slugs. Prüfe sie, bevor du das Ersetzen bestätigst: Das Paket ersetzt diese gemeinsam genutzten Bundles. Die bisherige SKILL.md bleibt im jeweiligen Verlauf. Vor der Bestätigung wird weder die Automatisierung noch ein Skill geschrieben.

Ein Workflow darf außerdem Bibliotheks-Skills verwenden, die nicht im Paket liegen. Fehlt einer, meldet der Upload eine Warnung. Installiere ein zugängliches Bundle, bevor du den Agenten startest, der es benötigt. Ein gespeicherter Entwurf bestätigt nicht, dass alle Abhängigkeiten bereitstehen.

Ein Projekt über Paketformulare einrichten

Ein Manifest kann Formulare vorgeben, die bei der Auswahl seiner Aufgabenvorlage erscheinen. Die Werte gehören zum Projekt. So verwenden zwei Projekte denselben Ablauf mit unterschiedlichen Richtlinien.

# automation.yml
settings:
  folder: Setup
  forms:
    - file: validation-policy.yaml
      title: Validation policy
      required: true
      fields:
        - key: method
          label: Validation profile
          type: select
          default: strict_rules
          options:
            - value: strict_rules
              label: Strict checklist

Ist das Projekt noch nicht eingerichtet, erscheinen Pflichtformulare vor den Aufgabenfeldern. Speichern und weiter schreibt die Formulare und setzt die Aufgabenerstellung fort. Später öffnet Einstellungen sie als Tabs. Ein Punkt markiert ungespeicherte Änderungen; Speichern schreibt alle geänderten Formulare. Beim Schließen mit offenen Änderungen fragt Tale nach. Die description eines Formulars steht über seinen Feldern; ist sie länger als drei Zeilen, siehst du ihren Anfang, und Weiterlesen öffnet den Rest.

Speichern ersetzt die flache YAML-Datei des Formulars, etwa Setup/validation-policy.yaml. Vorhandene Werte werden übernommen, auch aus einer manuell hochgeladenen Datei. Feldtypen sind text, number, boolean und select; gespeichert werden Zeichenketten. Textfelder können ein pattern vorgeben. Eintragsbezogene i18n-Blöcke übersetzen Titel, Beschriftungen, Hilfe und Optionen. Verschachtelte Daten und Listen gehören in separate Dateien, die der Workflow zusätzlich liest.

Referenzdateien über ein Upload-Formular bereitstellen

Ein Upload-Formular verwaltet Dateien direkt, statt YAML zu erzeugen:

settings:
  folder: Setup
  forms:
    - kind: uploads
      title: Reference documents
      subdir: reference
      accept: ['.pdf', '.json']
      match: '\.(pdf|json)$'
      requireFolder: true

subdir bestimmt einen Unterordner des Einstellungsordners. accept begrenzt die angebotenen Dateiendungen; match filtert die angezeigten Namen ohne Beachtung der Großschreibung und lehnt nicht passende Uploads ab. Bei requireFolder: true wählst oder erstellst du zuerst einen Unterordner, beispielsweise je Berichtszeitraum.

Uploads gelten sofort und haben kein Speichern. Sie blockieren die Aufgabenerstellung nicht. Läufe lesen den aktuellen Ordnerinhalt. Vervollständige deshalb die Referenzen, bevor du darauf angewiesene Arbeit startest.

Die erwarteten Ergebnisse benennen

Das Manifest kann Dateien für den Bereich Ergebnis der Aufgabe festlegen. Sie erscheinen in der angegebenen Reihenfolge; andere Anhänge und Arbeitsdateien bleiben unter Dateien.

subjects:
  task:
    outcome:
      files:
        - return.xml
        - report.md
        - name: audit-summary.md
          optional: true

Eine erforderliche Datei erscheint bis zu ihrer Ablage durch einen Lauf als Noch nicht bereit. Eine optionale Datei wird erst angezeigt, wenn sie existiert. Muster unterstützen * und ?, etwa return-*.xml. Ohne Vorgaben zeigt das Ergebnis alle von Läufen abgelegten Dateien, neueste zuerst. Eine kurze ausdrückliche Liste hilft, den Abschlussbericht von Arbeitsunterlagen zu unterscheiden.

Vor folgenreichen Freigaben nachfragen

Freigeben schließt die Aufgabe mit einem Klick. Bedeutet die Freigabe mehr als das Schließen der Aufgabe, deklariere diese Folge, etwa wenn eine Integration die Freigabe einem Kunden als Einreichung meldet. Freigeben fragt dann zuerst nach und zeigt deinen Satz:

subjects:
  task:
    review:
      requestChanges: true
      approve:
        confirm: Approving tells the client this return has been filed with the tax authority. Approve only after you have filed it.
        i18n:
          de:
            confirm: Mit der Freigabe erfährt der Kunde, dass diese Abrechnung bei der Steuerverwaltung eingereicht ist. Gib sie erst frei, wenn du sie eingereicht hast.

Ohne approve bleibt Freigeben ein Schließen mit einem Klick. Übersetze den Satz unter i18n; eine Sprache ohne eigenen Satz nutzt ihre Basissprache, danach den englischen.