> 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/best-practices.md).

# Best Practices

Praktische Hinweise zum Erstellen zuverlässiger Playbooks

Nutze diese Best Practices, um Playbooks einfacher auszuführen, zu überprüfen und zu verbessern.

## Beginne mit Brand Kit und Prompt-Abdeckung

Ein aktuelles Brand Kit und eine vollständige Prompt-Abdeckung sind die beiden größten Qualitätshebel. Bestätige beides, bevor du die Playbook-Struktur optimierst.

## Beginne mit weniger Anweisungen

Gib dem Agenten genügend Orientierung, damit er das Ziel versteht, und füge dann dort Einschränkungen hinzu, wo du ein vorhersagbares Verhalten brauchst. Zu stark vorgeschriebene Anweisungen können die Fähigkeit des Agenten verringern, Randfälle eigenständig zu durchdenken.

## Strukturiere Sections nach Phase

Verwende Phasen wie **Recherche**, **Entwurf**und **Prüfen**. Vermeide es, Sections um Personen herum zu organisieren, etwa als "Strategist Section" oder "Editor Section." Eine phasenbasierte Struktur ist leichter wiederzuverwenden und leichter zu überprüfen.

## Formatiere jede Section einheitlich

Gib jeder Section eine vorhersehbare interne Struktur, damit der Agent das Ziel versteht, der Prüfer die Arbeit schnell erfassen kann und nachfolgende Sections wissen, welches Artifact verwendet werden soll.

Eine starke Section umfasst in der Regel:

* **Ziel:** Ein oder zwei Sätze, die festlegen, was diese Section erreichen soll.
* **Eingaben und Referenzen:** Die Inputs, Artifacts, Brand Kit-Felder, Tools oder Knowledge Bases, die die Section verwenden soll. Füge diese nach Möglichkeit über das Schrägstrich-Menü ein.
* **Anweisungen:** Nummerierte Schritte für die Arbeit, die der Agent ausführen soll. Halte sie auf Entscheidungen, Einschränkungen und Quellpräferenzen fokussiert.
* **Ausgabe:** Das Artifact, das die Section schreiben soll, plus das erforderliche Format, etwa ein Markdown-Report, ein JSON-Map oder ein fertiger Artikel.

Verwende dasselbe Muster über alle Sections hinweg. Eine Recherche-Section könnte zum Beispiel das Ziel nennen, den Ziel-Prompt und das Brand Kit referenzieren, die Rechercheschritte auflisten und die Ergebnisse dann in **AI & Google Results.md**. Eine Schreib-Section könnte **Content Outline.md** und **Topic Research.md**, die Schreibanforderungen auflisten und dann den Entwurf schreiben in **Article Draft.md**.

## Verwende Sections als Kontrollpunkte

Füge eine Section hinzu, wenn du Folgendes brauchst:

* Ein separates Artifact.
* Eine Pause für die menschliche Prüfung.
* Einen klaren Bezugspunkt für spätere Sections.

## Schreibe Artifacts nur, wenn du Persistenz brauchst

Kontext wird automatisch zwischen Sections weitergegeben. Verwende Artifacts, wenn ein Ergebnis gespeichert, geteilt oder später referenziert werden muss.

## Verweise auf Knowledge Bases mit Namen

Wähle die spezifische Knowledge Base im Knowledge-Base-Auswahldialog des Schritts aus. Eine automatische Auswahl oder eine Suche über alle Knowledge Bases kann aus der falschen Quelle abrufen.

## Verweise auf Artifacts mit Namen

Artifact-Namen sind stabil. Dateinamen können sich ändern. Verwende das Schrägstrich-Menü, um Artifact-Referenzen in nachfolgenden Sections mit Namen einzufügen.

## Halte Veröffentlichung und Inhaltserstellung getrennt

Nutze Playbooks, um Inhalte zu erstellen, zu aktualisieren, zu prüfen und vorzubereiten. Veröffentliche aus einer Grid-Spalte, einem separaten Veröffentlichungs-Playbook oder nach der Prüfung über ein CMS-MCP. So lassen sich redaktionelle Prüfung, die Zuordnung von CMS-Feldern und das Tracking der Veröffentlichung leichter steuern.

Wenn ein Playbook oder ein CMS MCP eine Seite veröffentlicht oder aktualisiert, verwende das AirOps MCP `track_aeo_page_content_update` tool mit der Seiten-URL und dem Aktualisierungstyp, damit AirOps Insights zukünftige Änderungen bei KI-Sichtbarkeit, Zitaten, Erwähnungen und Traffic mit diesem Content-Update verknüpfen kann.

## Kombiniere Playbooks zum Finden von Chancen und zum Erstellen von Ergebnissen

Lass ein Playbook Daten überwachen und Chancen finden, und lass dann ein separates Aktions-Playbook das Ergebnis erstellen. So ist jedes Playbook leichter zu verstehen, zu überprüfen und iterativ zu verbessern.

## Bitte Quill, Workflow-Prompts zu übersetzen

Wenn du einen Workflow migrierst, füge den ursprünglichen Prompt mit vollem Kontext ein und bitte [Quill](/docs/de/quill.md) ihn, ihn in eine knappe Agentenanweisung zu übersetzen. Kürze das Ergebnis danach.

## Vorgeschlagene Änderungen menschlich prüfen lassen

Gut gestaltete Playbooks schlagen Änderungen zur Freigabe durch Menschen vor, anstatt sie automatisch anzuwenden, wenn ein Urteil erforderlich ist. Dieses Muster schafft Vertrauen, deckt Randfälle auf und hält die Beteiligten auf dem Laufenden.


---

# 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/best-practices.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.
