> For the complete documentation index, see [llms.txt](https://docs.airops.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.airops.com/docs/de/aktionen/playbooks.md).

# Playbooks

Playbooks mit Anweisungen in natürlicher Sprache erstellen und ausführen

Playbooks ermöglichen es dir, Arbeit als Anweisungen in natürlicher Sprache zu beschreiben, Kontext wie ein Brand Kit anzuhängen und den Prozess von Anfang bis Ende auszuführen, während Prüfer eingebunden bleiben.

{% hint style="warning" %}
Playbooks können nicht innerhalb von Workflows verwendet werden. Du kannst zwar ein Playbook aus einem vorhandenen Workflow erstellen, aber du kannst kein Playbook als Workflow-Schritt hinzufügen.
{% endhint %}

Ein Playbook besteht aus:

* **Ein Playbook im Dokumentstil** das beschreibt, was der Agent tun soll.
* **Eingaben** die das Playbook zur Laufzeit akzeptiert, z. B. Text, Zahlen, Dateien oder ein Brand Kit.
* **Abschnitte** die Anweisungen, Tool-Aufrufe und Kontrollpunkte für die menschliche Prüfung enthalten.
* **Tools** die der Agent verwenden kann, einschließlich SEO-Recherche, Web-Recherche, Bild und Video, MCP-Konnektoren und mehr.
* **Artefakte** die das Playbook erzeugt, z. B. Markdown-, HTML-, JSON-, CSV-, PNG-, JPG- oder GIF-Dateien.
* **Trigger** die festlegen, wie ein Playbook startet, einschließlich Zeitplan, Webhook, Monitor und AEO Insight, wenn aktiviert.

## Wichtige Konzepte

| Begriff                  | Definition                                                                                                                                                         |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Playbook                 | Die Agentendefinition mit Eingaben, Abschnitten, Tools, Artefakten und einem Trigger. Das Ausführen eines Playbooks erzeugt eine Session.                          |
| Abschnitt                | Eine Arbeitseinheit in einem Playbook. Jeder Abschnitt kann Anweisungen, Tool-Aufrufe und einen Block für die menschliche Prüfung enthalten.                       |
| Eingabe                  | Informationen, die du bereitstellst, wenn ein Playbook ausgeführt wird, z. B. ein Keyword, eine Ziel-URL, ein Datei-Upload oder ein Brand Kit.                     |
| Tool                     | Eine Aktion, die der Agent ausführen kann, von Web- und SEO-Recherche bis hin zu nativen Tools wie Slack und Tools, die von MCP-Konnektoren bereitgestellt werden. |
| Artefakt                 | Eine dauerhafte Ausgabe, die das Playbook erzeugt, z. B. einen Blogbeitrag, ein Bild, eine Analyse oder strukturierte Daten.                                       |
| Trigger                  | Eine Bedingung, die ein Playbook automatisch startet. Trigger-Typen sind Zeitplan, Webhook, Monitor und AEO Insight, wenn aktiviert.                               |
| Session                  | Ein einzelner Playbook-Lauf. Jede Session erzeugt Artefakte und protokolliert die Arbeit, die der Agent ausgeführt hat.                                            |
| Posteingang              | Die Warteschlange auf Workspace-Ebene, in der Prüfer ausstehende Schritte der menschlichen Prüfung und Session-Ausgaben sehen, die Aufmerksamkeit erfordern.       |
| Verlauf der Ausführungen | Die Aufzeichnung jeder Session, die ein Playbook erzeugt hat.                                                                                                      |
| Menschliche Prüfung      | Ein Haltepunkt, an dem eine Person die Arbeit des Agenten genehmigen oder bearbeiten muss, bevor es weitergeht.                                                    |
| Quill                    | Der AirOps-Agentenkapitän, der dir hilft, Playbooks aus Eingaben in natürlicher Sprache zu erstellen und zu bearbeiten. Siehe [Quill](/docs/de/quill.md).          |
| Speicher                 | Persistenz über Sessions hinweg, verwendet, wenn sich ein Playbook daran erinnern muss, was es bereits aufgedeckt oder abgeschlossen hat.                          |

## Die beiden Kontextquellen, die die Qualität steuern

Bevor du ein Playbook erstellst, stelle sicher, dass AirOps Insights und dein Brand Kit aktuell sind. Diese beiden Kontextquellen prägen die Qualität jeder Session.

### AirOps Insights konfigurieren

AirOps Insights ist die Quelle für Daten zur KI-Suchsichtbarkeit, einschließlich getrackter Prompts, LLM-Suchergebnisse, Zitate, Wettbewerberpräsenz und Inhaltschancen. Wenn ein Playbook AEO-Chancen oder LLM-Suchergebnisse recherchiert, sollte es die in AirOps Insights erfassten Daten verwenden, statt die KI-Suche als allgemeine Webrecherche zu behandeln.

Decke die Themen, Personas, Regionen und Funnel-Phasen ab, die dir wichtig sind. Erweitere die Abdeckung um Quellen wie Google-Search-Console-Abfragen, Formulierungen aus Verkaufsgesprächen, Support-Tickets und Lücken bei Wettbewerber-Zitaten.

Das gängige Muster ist: AirOps Insights verfolgt Prompts und LLM-Suchergebnisse, ein Playbook überwacht diese Daten und findet Chancen, dann nimmt ein zweites Playbook Maßnahmen vor und erstellt oder aktualisiert die Ausgabe.

### Halte dein Brand Kit aktuell

Jedes Playbook kann dein Brand Kit übernehmen, sodass Änderungen an Tonalität, Schreibregeln, Zielgruppen, Regionen, Produktlinien, visuellen Richtlinien und Wettbewerberkontext in die Ausgabe des Playbooks einfließen. Ein veraltetes Brand Kit verschlechtert die nachgelagerte Ausgabe.

Überprüfe das Brand Kit in regelmäßigen Abständen. Aktualisiere es, wenn du ein Produkt einführst, die Positionierung änderst, eine neue Zielgruppe hinzufügst oder in eine neue Region expandierst.

Verwenden [Brand Kit-Aktualisierung](/docs/de/kontext/brand-kit/refresh.md) um Live-Quellen zu überwachen und Änderungen am Brand Kit zur menschlichen Genehmigung vorzuschlagen.

{% hint style="warning" %}
Verwende das neue Brand-Kit-Format mit Playbooks. Legacy-Brand-Kits funktionieren mit Playbooks nicht so gut und können die Ausgabequalität verringern.
{% endhint %}

## Aufbau eines Playbooks

Wenn du den Playbook-Editor öffnest, siehst du:

* Eine Kopfzeilen-Leiste über dem ersten Abschnitt, die Tools, Eingaben, Artefakte und **Trigger hinzufügen**.
* Aktionen oben rechts für **Playbook ausführen**, **Veröffentlichen**und **Verlauf der Ausführungen**.
* **Quill, der AirOps-Agentenkapitän,** als grüner schwebender Button unten rechts im Editor.
* Referenz-Pills inline, während du schreibst. Eingaben und Brand Kits erscheinen als grüne Pills. Tools erscheinen als graue Pills mit Symbolen.

Gib `/` in einem beliebigen Abschnitt, um das Slash-Menü zu öffnen. Das Slash-Menü zeigt Tools, Eingaben, Artefakte und andere Referenzen an, die du in deine Anweisungen einfügen kannst.

## Playbook-Leitfäden

* [Ein Playbook erstellen](/docs/de/aktionen/playbooks/create-a-playbook.md)
* [Ein Playbook aufbauen](/docs/de/aktionen/playbooks/build-a-playbook.md)
* [Mit Artefakten arbeiten](/docs/de/aktionen/playbooks/artifacts.md)
* [Tools](/docs/de/aktionen/playbooks/tools.md)
* [Ein Playbook ausführen](/docs/de/aktionen/playbooks/run-a-playbook.md)
* [Playbook-Trigger](/docs/de/aktionen/playbooks/triggers.md)
* [Playbooks mit anderen Tools verbinden](/docs/de/aktionen/playbooks/integrations.md)
* [Best Practices für Playbooks anwenden](/docs/de/aktionen/playbooks/best-practices.md)
* [Playbooks beheben](/docs/de/aktionen/playbooks/troubleshooting.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.airops.com/docs/de/aktionen/playbooks.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
