Ein Ordner, mit dem ein Nicht-Entwickler seine Automatisierungen selbst bedient

Letztens wieder gehört: „🙄 Der CEO hat sich jetzt 'ne Claude-Subscription geholt."

Dieses Augenrollen kenne ich. Als Entwickler ist der Reflex fast eingebaut — sobald jemand „von außen" in unserem Bereich rummacht, gehen wir in Verteidigung. Ich seh das anders: Ich hab die IT immer als offene, hilfsbereite Branche erlebt. Und genau jetzt, wo KI die Hürde so weit senkt, dass auch der Geschäftsführer oder die Office-Managerin selbst etwas bewegen kann, ist der richtige Moment, die Tür aufzuhalten.

Auf LinkedIn habe ich dazu bewusst auf die Technik verzichtet. Hier ist die ausführliche Version: wie so ein Werkzeugkasten konkret aussieht, mit allem Drum und Dran — Agents, Commands, Wissensbasis, und dem Teil, den ich am spannendsten finde: den Hooks.

Die Ausgangslage

Ein Kunde, kein IT-Mensch, hat echtes Interesse und eine Claude-Subscription. Sein Unternehmen läuft auf einem Automatisierungs-Stack: eine Automatisierungs-Engine (n8n), ein CRM, eine Tabellen-Datenbank, ein KI-Telefon-Agent, ein paar Formulare auf der Website. Bisher musste für jede kleine Änderung jemand Technisches ran.

Das Ziel: ihn befähigen, diese Abläufe selbst zu verstehen, anzupassen, neu zu bauen und zu reparieren — sicher, ohne dass er etwas kaputt machen kann, und ohne dass er „API" oder „Webhook" buchstabieren können muss.

Die Lösung ist kein Tool und kein Dashboard. Es ist ein Ordner, den er in Claude Code öffnet und in normalem Deutsch bedient.

Das Prinzip: ein Ordner = Werkzeugkasten + Lehrbuch

Der Ordner liegt versioniert auf GitLab. Er enthält alles, was die KI braucht, um in diesem Unternehmen sicher zu arbeiten — und alles, was der Mensch braucht, um zu verstehen, was passiert. Grob:

automations/
├── START-HIER.md         ← Einstieg für den Menschen
├── EINRICHTUNG.md        ← einmaliges Setup
├── TERRITORIEN.md        ← was die KI frei / mit-Bestätigung / gar-nicht darf
├── AKTUALISIEREN.md      ← Updates holen, versionieren, zurücksetzen
├── wissen/               ← das "Lehrbuch": ein Dokument pro Tool
├── rezepte/              ← Schritt-für-Schritt-Anleitungen
├── backups/              ← Sicherungskopien vor jeder Änderung
└── .claude/
    ├── agents/           ← spezialisierte Helfer
    ├── commands/         ← "Fertig-Knöpfe" (Slash-Commands)
    ├── hooks/            ← die Schutzgitter & Regel-Erinnerungen
    └── settings.json     ← schaltet die Hooks ein

Der Mensch tippt claude in diesem Ordner und sagt, was er will — zum Beispiel: „Ich will, dass beim Formular zusätzlich eine E-Mail ans Team rausgeht." Den Rest übernimmt die KI, mit dem Wissen und den Leitplanken aus dem Ordner.

Gehen wir die Teile durch.

1. CLAUDE.md — die Verfassung

CLAUDE.md wird bei jeder Sitzung automatisch gelesen und hat Vorrang vor allem anderen. Hier steht das Verhalten, kompromisslos und in Klartext:

• Sprich Deutsch, in normaler Sprache. Fachbegriffe nur mit Halbsatz-Erklärung.
• Erkläre, was du vorhast, bevor du es tust — in 1–3 Sätzen. Dann mach es.
• Frag nach bei allem mit Außenwirkung (echte Kunden, echte Anrufe, echtes Geld, Live-Schalten, Löschen).
• Im Zweifel fail-safe: lieber einmal zu viel fragen als etwas Unumkehrbares tun.
• Entferne niemals eigenmächtig bestehende Logik oder „verschönere" sie. Fass nur an, was gefordert ist.

Der letzte Punkt ist eine teuer bezahlte Lektion: Ungefragtes „Aufräumen" eines laufenden Workflows hat einmal Schaden angerichtet. Solche Lektionen stehen jetzt schwarz auf weiß im Ordner — die KI liest sie bei jeder Aufgabe mit.

2. Territorien — die Landkarte aus Grün, Gelb, Rot

Die zentrale Idee, damit ein Laie echte Macht bekommt, ohne sich zu verbrennen: drei klar getrennte Zonen.

• 🟢 GRÜN — frei: anschauen, verstehen, lokal vorbereiten, sichern. Workflows lesen, Deals lesen, Datenbank abfragen, Backups schreiben, lokal committen.
• 🟡 GELB — nur mit Bestätigung: alles mit Außenwirkung. Einen Workflow speichern oder aktivieren, CRM-Daten ändern, eine einzelne Test-Mail auslösen, ein Website-Widget ausliefern, etwas pushen.
• 🔴 ROT — gar nicht, eskalieren: Massen-/Live-Auslöser (viele echte Anrufe oder Mails auf einmal), Daten löschen, fremde Repos anfassen, Geheimnisse ausgeben, git push --force. Die KI führt das nicht aus, sondern erklärt es und gibt es an einen Entwickler weiter.

Diese Landkarte steht in TERRITORIEN.md und in CLAUDE.md — und die Hooks erinnern automatisch daran (dazu gleich).

3. wissen/ — das Lehrbuch

Pro Tool ein Dokument, in einfacher Sprache: wie es funktioniert, die wichtigsten IDs und Zugänge (Werte aus .env, nie im Klartext), und vor allem die Fallstricke. Beispiele aus der Praxis, die als Regeln drinstehen:

• Ein Workflow wird immer so geändert: Backup → Live-Stand holen → umbauen → zurückschreiben → erneut holen und verifizieren. Niemals blind eine lokale Datei deployen, der Live-Stand kann abweichen.
• Beim Speichern nur die erlaubten Felder schicken, sonst antwortet die API mit Fehler 400.
• Massen-Aufrufe drosseln (~9 Sekunden Abstand), sonst kommt „429 — zu viele Anfragen".
• Annahmen gegen echte Live-Daten prüfen, nicht gegen die Doku.

Das ist Wissen, das man sich sonst über Monate erarbeitet. Hier liest es die KI in Sekunden mit — und der Mensch kann jederzeit „erklär mir das wie für einen Laien" sagen.

4. rezepte/ — Kochrezepte für wiederkehrende Aufgaben

Für die immer gleichen Aufgaben gibt es Schritt-für-Schritt-Rezepte: „Workflow ändern", „Workflow neu bauen", „warum lief eine Automatisierung nicht", „Website-Widget aktualisieren". Die KI folgt ihnen, der Mensch kann mitlesen.

5. Agents — spezialisierte Helfer statt eines Alleskönners

Im .claude/agents/-Ordner liegen mehrere kleine, fokussierte Experten — jeder mit klarer Rolle und nur den Werkzeugen, die er braucht:

• Architekt — denkt eine neue Automatisierung durch, bevor gebaut wird. Stellt Klärungsfragen (Auslöser? Schritte? Welche Fälle sollen nicht verarbeitet werden? Obergrenze für Wiederholungen?) und übergibt einen klaren Bauplan. Plant, baut aber nicht.
• Bauer — setzt den Bauplan in der Automatisierungs-Engine um.
• Detektiv — diagnostiziert, warum etwas nicht lief: liest den vollständigen Fehlertext, schaut sich die Ausführung an, erklärt die Ursache.

So ein Agent ist eine Markdown-Datei mit einem kleinen Kopf:

---
name: automation-architekt
description: Denkt eine neue Automatisierung durch, BEVOR sie gebaut wird.
             Stellt Klärungsfragen, modelliert den Ablauf samt Sonderfällen
             und Limits, übergibt einen Bauplan. Plant, baut aber nicht.
tools: Bash, Read, Glob, Grep
---

Du bist der Automation-Architekt. Deine Grundhaltung: Deutsch, einfache
Sprache. Du stellst Fragen, du baust nicht. Lies zuerst das Lehrbuch …

Die Aufteilung in Rollen hält jeden Helfer einfach, verständlich und in seiner Spur.

6. Commands — die „Fertig-Knöpfe"

Damit der Mensch sich nichts merken muss, gibt es Slash-Commands in Klartext-Deutsch:

Jeder Command ist wieder nur eine Markdown-Datei mit einer klaren Anweisung. Tippt der Mensch /, sieht er die Liste. Oder er redet einfach frei.

Das Highlight: Hooks

Jetzt der Teil, den ich am spannendsten finde. Agents und Commands sind das, was die KI tun kann. Die Hooks sind das, was bei jeder Sitzung und vor jeder riskanten Aktion automatisch passiert — egal, was der Mensch tippt. Sie sind kleine Skripte, die Claude Code zu bestimmten Zeitpunkten selbst ausführt. Eingeschaltet werden sie in settings.json, und die liegt im Git — die Schutzgitter reisen also mit dem Ordner mit.

{
  "hooks": {
    "SessionStart": [
      { "hooks": [{ "type": "command",
        "command": "bash \"$CLAUDE_PROJECT_DIR/.claude/hooks/regeln-in-kontext.sh\"" }] }
    ],
    "PreToolUse": [
      { "matcher": "Bash", "hooks": [{ "type": "command",
        "command": "python3 \"$CLAUDE_PROJECT_DIR/.claude/hooks/wachter.py\"" }] }
    ]
  }
}

Zwei Hooks, zwei Aufgaben.

Hook 1 — die Regeln immer im Kopf (SessionStart)

Bei jedem Sitzungsstart läuft ein winziges Shell-Skript. Sein einziger Job: die wichtigsten Kernregeln in den Kontext schreiben, damit die KI sie garantiert „im Kopf" hat — auch wenn CLAUDE.md lang ist und die wichtigen Sätze mal untergehen.

#!/usr/bin/env bash
# SessionStart-Hook: bringt die Kernregeln bei jedem Start in den Kontext.
# Rein informativ — blockiert nie. Die stdout-Ausgabe landet im Kontext.
cat <<'EOF'
[Automatisierungen — Kernregeln, die immer gelten]
1. Nichts Produktives ohne Backup ändern: Backup → holen → umbauen → zurückschreiben → verifizieren.
2. Außenwirkung (Anrufe, Mails, CRM-Daten, Workflow aktivieren, push, live) = erst erklären, dann Bestätigung.
3. KEINE Massen-/Live-Auslöser aus diesem Werkzeugkasten → erklären und an einen Entwickler eskalieren.
4. Bestehende Workflow-Logik nicht eigenmächtig entfernen oder „aufräumen".
5. Geheimnisse aus .env nie im Klartext ausgeben.
Territorien (GRÜN/GELB/ROT): siehe TERRITORIEN.md.
EOF
exit 0

Ja, das kostet bei jeder Sitzung ein paar zusätzliche Tokens. Der Preis ist es absolut wert. Diese fünf Sätze sind genau die, deren Missachtung echten Schaden anrichtet. Sie jedes Mal frisch in den Kontext zu legen, ist die billigste Versicherung, die es gibt.

Hook 2 — der Wächter (PreToolUse, fail-open)

Der zweite Hook ist mein Liebling. Er läuft vor jedem Shell-Befehl, schaut sich den Befehl an und hebt bei klar riskanten Mustern die Hand. Die Philosophie dahinter ist entscheidend: fail-open. Im Zweifel lässt er durch. Er blockiert nie hart. Er setzt nur permissionDecision: "ask" — die Person bekommt eine klare Begründung und entscheidet selbst.

#!/usr/bin/env python3
# PreToolUse-Hook (matcher: Bash). Schaut Shell-Befehle an und bittet bei klar
# riskanten Mustern um eine bewusste Bestätigung (permissionDecision "ask").
# Philosophie: FAIL-OPEN. Im Zweifel durchlassen. Nichts wird hart blockiert.
import sys, json, re

def main():
    try:
        data = json.load(sys.stdin)
    except Exception:
        sys.exit(0)  # nicht parsebar -> durchlassen

    cmd = ((data.get("tool_input") or {}).get("command") or "")
    if not cmd:
        sys.exit(0)
    low = cmd.lower()
    reasons = []

    # Massen-/Bulk-Auslösung (Schleife über einen Webhook-Aufruf)
    loop = re.search(r"(^|\s)(for |while |xargs|seq |parallel )", low) is not None
    if loop and "/webhook/" in low:
        reasons.append("Sieht nach Massen-/Bulk-Auslösung aus (Schleife über einen Webhook). "
                       "Gehört nicht in diesen Laien-Werkzeugkasten — an einen Entwickler eskalieren.")

    # Gefährliche Git-Operationen
    if re.search(r"git\s+push\b.*--force|git\s+push\s+-f\b|git\s+reset\s+--hard", low):
        reasons.append("Riskante Git-Operation (force-push / hard reset) kann Arbeit "
                       "unwiderruflich vernichten. Nur nach ausdrücklicher Ansage.")

    if reasons:
        print(json.dumps({"hookSpecificOutput": {
            "hookEventName": "PreToolUse",
            "permissionDecision": "ask",
            "permissionDecisionReason": "⚠️ " + " | ".join(reasons),
        }}))
    sys.exit(0)

if __name__ == "__main__":
    main()

Warum fail-open und nicht hart blockieren? Weil ein Werkzeugkasten, der legitime Arbeit ständig fälschlich ausbremst, schnell weggeklickt oder umgangen wird. Ein Wächter, der selten, aber gezielt die Hand hebt und dann gut begründet, wird ernst genommen. Versteht er einen Befehl nicht, lässt er ihn durch. Er fängt lieber ein Muster mal nicht, als gute Arbeit zu blockieren. Die harten Grenzen (Rot) stehen ohnehin in den Regeln und im Verhalten der KI — der Wächter ist das zusätzliche Netz für die Fälle, die wirklich wehtun.

Neue Muster ergänzt man in zwei Minuten: eine Regel, die immer gelten soll → eine Zeile im SessionStart-Skript. Ein riskantes Muster, das abgefangen werden soll → ein Block im Wächter. Mehr Mechanik braucht es nicht.

Der Rückkanal — der Werkzeugkasten verbessert sich selbst

Das Stück, das aus einem einmaligen Setup ein lebendes Produkt macht: ein Rückmeldungs-Loop.

Wenn in der Arbeit etwas hakt — eine Regel passt nicht, eine Anleitung ist unklar, ein Ablauf läuft anders als gedacht — bietet die KI von sich aus an, das festzuhalten (/rueckmeldung). Die Rückmeldung landet strukturiert an einer zentralen Stelle (bei uns: ein Notion-Logbuch), mit Schweregrad, betroffenem Bereich und einem konkreten Verbesserungsvorschlag.

Ich als Betreuer sehe diese Rückmeldungen, verbessere den Werkzeugkasten strukturell — eine neue Regel, ein neues Rezept, ein geschärfter Agent — und der Kunde holt sich die Verbesserung mit einem git pull. Der Werkzeugkasten wird mit jeder Reibung besser, zentral gepflegt, und rollt zu allen aus.

Sicherheit ist eingebaut, nicht angeklebt

Alles zusammen ergibt ein System, dem man echte Macht anvertrauen kann:

• Backups vor jeder produktiven Änderung — die Rückfahrkarte ist immer da.
• Eine lokale Spielwiese (der Ordner selbst) für Zwischenstände, getrennt vom Live-System.
• Fail-safe als Grundhaltung — im Zweifel fragt die KI und der Mensch entscheidet.
• Geheimnisse bleiben in .env und werden nie im Klartext ausgegeben.

Der Mensch muss kein Entwickler werden. Er muss nur seinen Laden bedienen können.

Das lässt sich nicht als Template verkaufen

Dieser Ordner sieht aus wie eine Vorlage, die man einmal baut und bei jedem Kunden ausrollt. Das täuscht.

Jede Zeile in wissen/, jedes Rezept, jede Regel im Wächter ist hochspezifisch für genau dieses eine Unternehmen — seine Tools, seine Eigenheiten, seine teuer bezahlten Fehler. So etwas entsteht erst, wenn man vorher wirklich am Unternehmen und seinen Prozessen gearbeitet hat.

Bei mir waren das rund fünf Monate, in denen ich „von Hand, mit KI" automatisiert, gebaut und repariert habe. Diese Monate sind das eigentliche Rohmaterial.

Der Ordner selbst war danach eine Sache von etwa sechs Stunden: Ich habe die KI einmal durch die gesammelten Sessions der Vergangenheit laufen lassen und das Gelernte zu Wissen, Regeln, Rezepten und Guardrails verdichten lassen. Die Monate stecken da drin, kristallisiert.

Genau deshalb halte ich wenig vom Teilen generischer „Templates" und „Prompt-Sammlungen". Jedes Unternehmen hat andere Anforderungen, andere Tools, andere Stolperfallen — ein Schema-F-Paket trifft davon kaum etwas. Der Wert steckt in der eingearbeiteten Realität.

Es sieht nach Schema F aus. Es ist die Stufe danach.

Warum das Ganze

Die Hürde fällt gerade für alle. Wir können uns davorstellen und über die Claude-Subscription des CEOs die Augen rollen — oder wir bauen ihm etwas, mit dem er wirklich arbeiten kann, mit Leitplanken, die es sicher machen. Genau das ist die Fortsetzung einer Branche, die immer vom Teilen und Helfen gelebt hat.

Ich halte die Tür auf. Und ein Werkzeugkasten wie dieser ist, wie das in der Praxis aussieht.

Du willst so etwas für dein Unternehmen? Genau das baue ich bei OrgOps — KI operativ machen, für Menschen ohne IT-Abteilung. Schreib mir.