WordPress mit KI-Agent verbinden: OpenCode, SSH und WP-CLI

Einleitung

Das WordPress-Backend ist eine Ansammlung von Formularen. Für einen Menschen ist das bequem. Für einen KI-Agenten ist es eine Wand: Er sieht Buttons, aber keine Daten. Wer einem Agenten beibringen will, Beiträge anzulegen, Medien zu importieren oder den Plugin-Stand zu prüfen, sollte ihm deshalb nicht das Backend zeigen – sondern die Shell.

Genau hier liegt der Trick. WordPress bringt mit WP-CLI eine offizielle Kommandozeilenschnittstelle mit, die praktisch alles kann, was das Backend kann – nur in Text. Und Text ist das, was Sprachmodelle am besten verarbeiten. Ein Agent, der WP-CLI aufrufen darf, braucht also keine magische WordPress-Integration. Er braucht SSH und eine Handvoll klar definierter Befehle.

In diesem Artikel verbinde ich WordPress mit dem KI-Agenten OpenCode. Der Weg, den ich dabei beschreite, ist kein konstruiertes Beispiel: Es ist exakt der Aufbau, mit dem ich diese Website selbst pflege. Wir richten einen SSH-Zugang mit Schlüssel ein, installieren WP-CLI auf dem Server, lösen unterwegs die Falle, über die fast jeder beim ersten Versuch stolpert, und bringen dem Agenten bei, was er über das Projekt wissen muss. Am Ende steht ein Agent, der einen fertigen Entwurf anlegt – und nicht mehr anfassen darf als erlaubt.

Alle Befehle in diesem Artikel habe ich auf einem Shared-Hosting-Paket mit PHP 8.4, WordPress 7.1 und WP-CLI 2.12 durchgespielt. Einzige Ausnahme: die Variante mit sudo, die auf Shared Hosting schlicht nicht zur Verfügung steht.

Quick-Checklist:

[ ] SSH-Zugang zum Server (Shell, nicht nur SFTP)
[ ] SSH-Key erzeugt und hinterlegt
[ ] Alias in ~/.ssh/config angelegt
[ ] WP-CLI auf dem Server installiert
[ ] Datenbank-Verbindung für die CLI gelöst
[ ] Wrapper-Skript für den Agenten
[ ] AGENTS.md mit Projektwissen
[ ] Rechte in opencode.jsonc begrenzt
[ ] Backup-Strategie geklärt
[ ] Veröffentlichen bleibt Handarbeit

1. Warum die Shell und nicht das Backend

Es gibt zwei Arten, WordPress fernzusteuern. Die eine ist die REST-API: sauber dokumentiert, HTTP-basiert, offizieller Teil des Cores. Die andere ist die Kommandozeile. Beide funktionieren, aber sie lösen unterschiedliche Probleme.

Für einen Agenten ist die Shell aus drei Gründen meist der bessere Weg. Erstens ist alles Text: Befehl rein, Ausgabe raus, keine Zwischenzustände im Browser. Zweitens reicht der Umfang weiter – WP-CLI kann Plugins installieren, Datenbanken sichern, Caches leeren, Nutzer anlegen und Cron-Events prüfen. Drittens ist es idempotent kontrollierbar: Ein Befehl wie wp post list verändert nichts, und man sieht sofort, was passiert ist.

Der Nachteil: Die Shell ist mächtig. Ein Agent mit SSH-Zugang ist kein Inhaltseditor, sondern ein Administrator mit Tastatur. Deshalb ist die zweite Hälfte dieses Artikels genauso wichtig wie die erste – es geht um Grenzen.

2. Drei Wege zum Ziel

Bevor du irgendetwas installierst, lohnt der Blick auf die Landkarte. Im Wesentlichen gibt es drei Wege, einen Agenten an WordPress anzuschließen:

Weg	Voraussetzung	Gut für	Grenzen
SSH + WP-CLI	Shell-Zugang, PHP CLI	Alles: Inhalte, Medien, Plugins, Themes, Datenbank, Diagnose	Nicht jeder Hoster erlaubt SSH
REST-API	HTTPS, Anwendungspasswort	Inhalte anlegen und ändern, Medien hochladen	Kein Zugriff auf Plugins, Themes oder Systemebene
MCP-Server	MCP-fähiger Client	Standardisierte Anbindung an mehrere Agenten	Junge Technik, jeder Server kann etwas anderes

Wir konzentrieren uns auf den ersten Weg, weil er am weitesten trägt und am wenigsten von Drittanbietern abhängt. Die REST-API bekommst du am Ende trotzdem gezeigt – als Plan B für Umgebungen, in denen du keine Shell hast.

3. Voraussetzungen prüfen

Du brauchst drei Dinge: einen SSH-Zugang zum Server, PHP als Kommandozeilenprogramm und Schreibrechte auf die WordPress-Installation. Ob SSH drin ist, verrät ein einzelner Befehl:

ssh dein-user@dein-server.de 'php -v'

Kommt eine PHP-Version zurück, bist du praktisch fertig. Erscheint command not found, fehlt die PHP-CLI – bei manchen Managed-Hosting-Paketen ist sie nicht installiert. Und wenn der Hoster dich nur per SFTP ohne Shell durchlässt, ist dieser Artikel der falsche Weg; spring dann direkt zum Kapitel über die REST-API.

Wirf außerdem einen Blick auf die wp-config.php. Du brauchst sie gleich für den Datenbank-Teil, und es ist gut zu wissen, wo sie liegt:

ssh dein-user@dein-server.de ls -la htdocs/wp-config.php

💡 Hinweis: Auf Shared Hosting heißt der Webspace je nach Anbieter public_html, htdocs, www oder data. Finde das Verzeichnis heraus, in dem wp-config.php liegt – alle folgenden Befehle setzen voraus, dass du dich darin befindest.

4. Schritt 1: SSH-Zugang mit Schlüssel und Alias

Wenn dein Server nur Passwörter akzeptiert, ist jetzt der Moment, das zu ändern. Ein Schlüssel ist nicht nur sicherer, er ist auch die Voraussetzung dafür, dass ein Agent überhaupt arbeiten kann: Ein Passwort müsste bei jedem Befehl neu eingegeben werden, und viele Agenten kommen mit interaktiven Passwortabfragen nicht zurecht. Die Details dazu stehen im SSH-Einsteiger-Guide.

Schlüssel erzeugen und hinterlegen

ssh-keygen -t ed25519 -C "agent@mein-mac"
ssh-copy-id -i ~/.ssh/id_ed25519.pub dein-user@dein-server.de

Alias anlegen

Ein Alias spart Tipparbeit und verhindert, dass das Modell bei jedem Befehl die kompletten Zugangsdaten mitschleifen muss. In ~/.ssh/config:

Host mein-wp
    HostName dein-server.de
    User dein-user
    Port 22
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Danach genügt ssh mein-wp. Wichtig ist der Test ohne Passwortabfrage – BatchMode schlägt sofort fehl, wenn der Schlüssel nicht greift, statt still auf ein Passwort zu warten:

ssh -o BatchMode=yes mein-wp 'echo KEY_OK'

⚠️ Wichtig: Private Schlüssel haben auf dem Server nichts zu suchen, und Passwörter gehören weder in Skripte noch in Projektordner. Der Agent liest nur den Aliasnamen – alles Weitere liegt in ~/.ssh/.

5. Schritt 2: WP-CLI installieren

WP-CLI ist eine einzelne PHAR-Datei. Herunterladen, ausführbar machen, fertig:

curl -sSL -o wp-cli.phar https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
php wp-cli.phar --info

Achte auf die Zeile PHP version. WP-CLI setzt mindestens PHP 7.2.24 voraus – ältere Versionen werden nicht mehr unterstützt.

Mit Root-Rechten

chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp
wp --info

Ohne Root-Rechte

Auf Shared Hosting hast du kein sudo. Dann legst du die PHAR in ein Verzeichnis, das dir gehört, und baust dir einen eigenen Wrapper. Nimm ein eigenes Verzeichnis wie ~/tools und nicht blind ~/bin: Letzteres existiert auf manchen Hostings bereits und gehört dann root, sodass jedes Schreiben mit „Permission denied“ endet.

mkdir -p ~/tools
mv wp-cli.phar ~/tools/
printf '%s\n' '#!/bin/sh' 'exec php "$HOME/tools/wp-cli.phar" "$@"' > ~/tools/wp
chmod +x ~/tools/wp

Ein Hinweis, der später wichtig wird: Bei nicht-interaktiven SSH-Befehlen ist PATH oft nicht so gesetzt wie in deiner gewohnten Sitzung. wp allein funktioniert dann nicht, auch wenn die Datei existiert. Rufe den Wrapper deshalb immer mit vollem Pfad auf – ~/tools/wp statt wp.

Funktionstest

cd htdocs
wp core version
wp core is-installed && echo "WordPress erkannt"

Wenn hier die WordPress-Version erscheint, ist der halbe Weg geschafft. Wenn stattdessen Error establishing a database connection kommt, bist du genau in der Falle, um die es jetzt geht.

6. Schritt 3: Die Falle mit dem Datenbank-Socket

Die Website läuft im Browser einwandfrei, aber die Kommandozeile behauptet steif und fest, sie käme nicht an die Datenbank. Klassisches Symptom bei Shared Hosting:

Error: Error establishing a database connection. This either means that the
username and password information in your `wp-config.php` file is incorrect...

Die Zugangsdaten sind aber korrekt – im Browser funktionieren sie ja. Die Ursache liegt woanders: In einer Jail oder einem Chroot sieht der SSH-Benutzer nur einen Teil des Dateisystems. Der MySQL-Socket, den PHP CLI standardmäßig benutzt (typisch /var/run/mysqld/mysqld.sock), liegt außerhalb dieses Bereichs. Der Webserver kommt dran, die CLI nicht.

Diagnose

Prüfe zuerst, ob die Datenbank über TCP erreichbar ist. Das ist sie meistens – nur eben nicht über den Socket:

php -r '$f=@fsockopen("127.0.0.1",3306,$e,$s,3); echo $f ? "Port offen\n" : "zu: $s\n";'

Und schau nach, welchen Socket PHP überhaupt erwartet:

php -r 'echo ini_get("mysqli.default_socket"), "\n";'

Wenn diese Datei nicht existiert, der Port 3306 aber offen ist, hast du die Ursache gefunden.

Lösung: nur für die CLI auf TCP umschalten

Der naheliegende Griff – DB_HOST einfach auf 127.0.0.1 ändern – ist die falsche Lösung. Er kann die Website kaputt machen, wenn der Webserver den Socket braucht. Besser ist eine Weiche, die nur greift, wenn tatsächlich WP-CLI läuft:

/* Nur fuer die Kommandozeile: in einer Jail fehlt oft der MySQL-Socket */
if ( defined( 'WP_CLI' ) && WP_CLI ) {
    define( 'DB_HOST', '127.0.0.1' );
} else {
    define( 'DB_HOST', 'localhost' );
}

Vorher die Originaldatei sichern – und zwar nach außerhalb des Web-Verzeichnisses. Ein wp-config.php.backup im Webroot ist im schlimmsten Fall per HTTP abrufbar und enthält deine Datenbankzugänge:

cp wp-config.php ../wp-config.php.backup

Verzichte dabei auf $(date +%F) im Dateinamen: Auf minimal ausgestatteten Hostings fehlt date gelegentlich, dann heißt die Sicherung plötzlich nur noch wp-config.php.backup-. Ein fester Name ist unspektakulär, aber zuverlässig.

Danach sollte wp core is-installed durchlaufen. Der Webserver benutzt weiterhin localhost und merkt vom Eingriff nichts.

💡 Hinweis: Manche Hoster vergeben den Datenbanknamen mit Präfix und erlauben Verbindungen nur von localhost. Wenn der TCP-Test fehlschlägt, frag beim Support nach dem richtigen Host für CLI-Zugriffe. Das ist eine Standardfrage, keine Ausnahmesituation.

7. Schritt 4: Ein Wrapper-Skript für den Agenten

Der Agent soll nicht jedes Mal ssh mein-wp 'cd htdocs && wp …' tippen müssen. Ein kleines Skript im Projektordner macht daraus ./wp.sh … – kürzer, weniger Fehlerquellen und leichter zu erlauben oder zu verbieten.

#!/usr/bin/env bash
# wp.sh - WP-CLI auf dem Server ausfuehren, als waere es lokal
set -euo pipefail

REMOTE="mein-wp"
WPPATH="htdocs"
WPBIN="/usr/local/bin/wp"      # oder ~/tools/wp

if [[ $# -eq 0 ]]; then
  echo "Aufruf: ./wp.sh <befehl> [argumente]" >&2
  exit 1
fi

# Erstes Argument ist eine lokale Datei? Dann Inhalt per stdin schicken.
if [[ -f "$1" ]]; then
  FILE="$1"; shift
  ARGS=$(printf '%q ' "$@")
  cat "$FILE" | ssh "$REMOTE" "cd $WPPATH && $WPBIN post create - $ARGS"
  exit 0
fi

ARGS=$(printf '%q ' "$@")
ssh "$REMOTE" "cd $WPPATH && $WPBIN $ARGS"

Vier Details sind wichtig. Erstens WPBIN als absoluter Pfad: Wie oben beschrieben ist PATH in nicht-interaktiven Sitzungen unzuverlässig, ein nacktes wp scheitert dort mit „command not found“. Zweitens printf '%q ': Es maskiert Argumente mit Leerzeichen und Sonderzeichen, sonst zerlegt die Shell später den Befehl an der falschen Stelle. Drittens der explizite cd: Bei nicht-interaktiven SSH-Sitzungen startet man nicht zwingend im Home-Verzeichnis, sondern oft im Jail-Root. Verlass dich nie auf das Startverzeichnis. Viertens der Datei-Zweig: Eine Datei auf deinem Rechner existiert auf dem Server nicht – deshalb wird ihr Inhalt per stdin übergeben.

chmod +x wp.sh
./wp.sh core version
./wp.sh post list --post_type=post --fields=ID,post_title --posts_per_page=5

8. Schritt 5: Projektwissen in AGENTS.md

Ein Agent vergisst zwischen zwei Sitzungen alles. Was er nicht vergessen darf, schreibst du ihm auf: in eine AGENTS.md im Projektordner. OpenCode lädt diese Datei bei jedem Start automatisch – zusammen mit einer globalen Variante in ~/.config/opencode/AGENTS.md und allen weiteren, die auf dem Weg vom Home-Verzeichnis zum Arbeitsverzeichnis liegen.

Der Inhalt ist keine Doku für Menschen, sondern eine Betriebsanleitung. Konkret sollten fünf Dinge drinstehen: wo die Installation liegt, wie man sie erreicht, was bekannt ist (Fallen, Eigenheiten), wie ein Artikel aufgebaut ist und was tabu ist.

# system-ecke.de

## Zugang
- SSH-Alias: `mein-wp`, Webspace: `htdocs/`
- WP-CLI: `/usr/local/bin/wp`, von hier aus: `./wp.sh ...`

## Bekannte Eigenheiten
- MySQL-Socket fehlt in der Jail -> wp-config.php schaltet
  fuer WP_CLI auf 127.0.0.1 um. Nicht "aufraeumen"!
- `wp db export` scheitert: kein mysqldump vorhanden.
- Kein Cache-Plugin. Nichts zu leeren.

## Redaktion
- Beitraege sind Gutenberg-Markup, kein Page-Builder.
- Aufbau: Intro -> Separator -> H2 je Abschnitt -> Fazit.
- Kategorie Tutorials & How-Tos = ID 31.

## Tabu
- Nichts veroeffentlichen. Status bleibt `draft`.
- Keine Zugangsdaten in diesem Ordner.
- Vor Aenderungen an wp-config.php: Backup.

Diese Datei ist der größte Qualitätsunterschied überhaupt. Ohne sie tappt der Agent jede Sitzung neu im Dunkeln und schlägt dieselben falschen Wege wieder ein. Mit ihr weiß er nach zwei Zeilen, dass er mysqldump nicht aufrufen muss und dass Entwürfe Entwürfe bleiben.

Wenn du Regeln lieber getrennt halten willst, kannst du sie über das Feld instructions in der Konfiguration dazuladen – Dateien, Globs oder sogar URLs:

{
  "$schema": "https://opencode.ai/config.json",
  "instructions": ["docs/redaktion.md", "docs/seo-vorgaben.md"]
}

9. Schritt 6: Rechte begrenzen

Jetzt zum unangenehmen Teil. Ein Agent mit SSH-Zugang kann alles, was dein SSH-Benutzer kann – und das ist bei Shared Hosting oft erstaunlich viel. Die Standardkonfiguration hält ihn nicht auf: Die Basis-Policy von OpenCode steht auf allow, eine Rückfrage löst nur der Zugriff auf .env-Dateien aus. Wer sich darauf verlässt, dass schon irgendwer nachfragt, irrt. Grenzen musst du selbst setzen, in opencode.jsonc:

{
  "$schema": "https://opencode.ai/config.json",
  "permissions": [
    { "action": "shell", "resource": "*", "effect": "ask" },
    { "action": "shell", "resource": "./wp.sh post list*", "effect": "allow" },
    { "action": "shell", "resource": "./wp.sh post get*", "effect": "allow" },
    { "action": "shell", "resource": "./wp.sh plugin list*", "effect": "allow" },
    { "action": "shell", "resource": "*post_status=publish*", "effect": "deny" },
    { "action": "shell", "resource": "*wp db reset*", "effect": "deny" },
    { "action": "read", "resource": "*.env", "effect": "deny" }
  ]
}

Die Regel „die letzte passende gewinnt“ ist hier entscheidend: Erst wird alles gefragt, dann werden harmlose Lesebefehle erlaubt und ganz am Ende die gefährlichen Fälle hart verboten. Ein deny wird dabei nie von einer Freigabe überstimmt – auch nicht, wenn du im Dialog versehentlich „immer erlauben“ wählst.

Die wichtigste Zeile ist die mit publish. Sie verhindert, dass ein Agent aus eigenem Antrieb veröffentlicht. Genau das ist der Punkt, an dem KI-gestützte Redaktion entweder Vertrauen aufbaut oder spektakulär scheitert.

10. Schritt 7: Der erste Auftrag

Jetzt wird es konkret. Der Agent bekommt die Aufgabe, einen Entwurf aus einer vorbereiteten Datei anzulegen. Lege dafür einen Ordner artikel/ an und schreibe den Inhalt als Gutenberg-Markup hinein – also mit den Block-Kommentaren, nicht als reinen Text:

<!-- wp:paragraph -->
<p>Dieser Absatz kommt aus einer Datei.</p>
<!-- /wp:paragraph -->

<!-- wp:heading -->
<h2 class="wp-block-heading">Ein Abschnitt</h2>
<!-- /wp:heading -->

Daraus wird mit einem Befehl ein Beitrag. Der Wrapper erkennt eine lokale Datei als erstes Argument und schickt ihren Inhalt per stdin an den Server:

./wp.sh artikel/mein-entwurf.html \
    --post_title="Mein neuer Entwurf" \
    --post_name="mein-neuer-entwurf" \
    --post_category=31 \
    --post_status=draft \
    --porcelain

Ohne den Datei-Zweig im Wrapper geht es genauso, nur einen Schritt mehr: Datei auf den Server kopieren und dort den entfernten Pfad übergeben. --porcelain gibt am Ende nur die neue ID zurück – ideal, wenn ein Skript weiterarbeiten soll.

scp artikel/mein-entwurf.html mein-wp:/tmp/entwurf.html
./wp.sh post create /tmp/entwurf.html \
    --post_title="Mein neuer Entwurf" \
    --post_status=draft --porcelain

Bilder sind ein Sonderfall: wp media import nimmt keinen stdin entgegen, sondern braucht einen Pfad auf dem Server. Also erst kopieren, dann importieren – inklusive Beitragsbild und Alt-Text:

scp bilder/titelbild.jpg mein-wp:/tmp/titelbild.jpg
./wp.sh media import /tmp/titelbild.jpg \
    --post_id=1234 \
    --featured_image \
    --alt="Beschreibender Alt-Text"

Danach die Kontrolle, ohne die kein Agent arbeiten sollte:

./wp.sh post get 1234 --fields=ID,post_title,post_status,post_name,url

Jetzt liegt der Beitrag als Entwurf im Backend, mit Kategorie, Beitragsbild und Alt-Text – bereit zum Gegenlesen. Veröffentlicht wird von Hand.

11. Plan B: die REST-API

Ohne SSH bleibt die REST-API. Sie braucht seit WordPress 5.6 keine Plugin-Installation mehr, sondern nur ein Anwendungspasswort. Das legst du im Backend unter Benutzer → Profil an, ganz unten im Abschnitt „Anwendungspasswörter“: Namen vergeben, auf „Neues Anwendungspasswort hinzufügen“ klicken, und WordPress zeigt dir einmalig einen 24-stelligen Code. Danach nie wieder.

curl -sX POST "https://deine-domain.de/wp-json/wp/v2/posts" \
  -u "dein-user:xxxx xxxx xxxx xxxx xxxx xxxx" \
  -H "Content-Type: application/json" \
  -d '{"title":"Neuer Entwurf","status":"draft","content":"Text des Beitrags"}'

Zwei Dinge dazu. Erstens: Anwendungspasswörter funktionieren nur über HTTPS. Zweitens: Es ist ein Passwort – es gehört in einen Passwort-Manager und in eine Umgebungsvariable, nicht in eine Datei im Projekt. In der OpenCode-Konfiguration liest du es über {env:WP_APP_PASSWORD} ein, dann steht das Geheimnis nur in deiner Shell.

Der Preis für diesen Weg: Du kommst an Inhalte, aber nicht an Plugins, Themes oder Systemdiagnose. Für reine Redaktionsarbeit reicht es trotzdem oft aus.

12. Sicherheit, Grenzen und ein Reality-Check

Zum Schluss die unangenehmen Wahrheiten, die in keinem Produktvideo vorkommen.

Backups zuerst, nicht danach

wp db export ist der Standardbefehl für Datenbank-Backups – und er scheitert auf vielen Shared-Hosting-Servern, weil mysqldump schlicht nicht installiert ist. Prüf das, bevor du dem Agenten Schreibrechte gibst:

./wp.sh db export /tmp/test.sql

Kommt hier ein Fehler, brauchst du einen anderen Weg: ein Backup-Plugin (Duplicator, UpdraftPlus) oder das Backup im Hoster-Panel. Ein Agent ohne funktionierende Sicherung ist ein Experiment mit deinen Live-Daten.

Es gibt keine Vorschau-Umgebung

WP-CLI schreibt in die echte Datenbank. Es gibt keinen Sandkasten, keine Vorschau, kein git diff für Beiträge. Was hilft: immer draft, Änderungen an bestehenden Beiträgen nur nach vorherigem Lesen des aktuellen Inhalts, und bei größeren Eingriffen ein Backup. Wer eine Staging-Instanz hat, sollte sie nutzen – dieser Artikel geht vom einfacheren Fall aus.

Page-Builder sind eine Sackgasse

Gutenberg-Inhalte sind Text mit Kommentaren – dafür sind Sprachmodelle gebaut. Elementor und ähnliche Builder speichern dagegen verschachteltes JSON mit Referenzen auf interne IDs. Ein Agent kann das theoretisch schreiben, aber es ist fehleranfällig und beim nächsten Öffnen im Editor zerfällt es oft. Wenn du vorhast, Inhalte von einem Agenten erzeugen zu lassen, sind Gutenberg-Blöcke das einzige Format, das zuverlässig funktioniert.

Prüfen statt glauben

Ein Agent, der behauptet, einen Beitrag angelegt zu haben, hat vielleicht nur einen Befehl vorgeschlagen. Die Rückfrage kostet zwei Sekunden:

./wp.sh post list --post_status=draft --fields=ID,post_title,post_date

Dasselbe gilt für Inhalte: Was ein Modell über Plugin-Versionen, Sicherheitslücken oder API-Details behauptet, ist ein Vorschlag, keine Quelle. Bei allem, was in die Live-Datenbank geht, liest ein Mensch gegen.

Fazit

Die Verbindung zwischen einem KI-Agenten und WordPress braucht keine exotische Brücke. Sie braucht einen Schlüssel, ein PHAR und ein paar Zeilen Projektwissen. Der Aufwand liegt bei etwa einer Stunde – die Falle mit dem Datenbank-Socket eingerechnet, die dich sonst den ganzen Nachmittag kostet.

✅ SSH-Zugang per Schlüssel, ohne Passwortabfrage
✅ WP-CLI installiert und per Wrapper erreichbar
✅ Datenbank-Verbindung für die CLI gelöst
✅ AGENTS.md mit Zugang, Eigenheiten und Redaktionsregeln
✅ Rechte begrenzt, Veröffentlichen verboten
✅ Backup-Weg geklärt, bevor geschrieben wird

Ein letzter Gedanke: Der eigentliche Gewinn ist nicht, dass der Agent schneller tippt als du. Es ist, dass er Arbeit macht, die niemand gerne macht – Entwürfe aus vorgegebenen Strukturen bauen, Alt-Texte nachziehen, Metadaten prüfen, Plugin-Stände kontrollieren. Die Entscheidung, was veröffentlicht wird, bleibt dort, wo sie hingehört: bei dir.

Viel Erfolg beim Anschließen – und willkommen in der System-Ecke! 🖥️

Dieser Artikel ist Teil der Tutorials & How-Tos auf system-ecke.de. Fragen oder Anmerkungen? Schreib mir gerne über das Kontaktformular.