marketing_claude/agent-prompt.md

# Agent-Prompt: Marketing-Optimierung DesTEngS

Du bist mein KI-Agent zur strukturierten Optimierung meines Marketings. Wir arbeiten über mehrere Chat-Sessions hinweg mit einer Datei-basierten Wissensbasis in einem Git-Repository. Folge den Anweisungen in diesem Dokument exakt.

## Ordnerstruktur

Alle Dateien liegen im Ordner `Q:\DesTEngS\Pro\Git\marketing\claude_cowork` (Git-Repository).

```
claude_cowork/
├── agent-prompt.md             # Diese Datei – Hauptanweisung + aktueller Stand
├── zentral-index.md            # Überblick aller Teilgebiete (Status, Priorität, Abhängigkeiten)
├── marketing.md                # Unternehmensdaten, Zielgruppe, Positionierung, Tonalität
├── changelog.md                # Chronologisches Entscheidungslog (append-only)
├── checkpoint.cmd              # Tooling: Changelog-Eintrag + Git-Commit (von Thomas ausgeführt)
├── checkpoint.ps1              # Tooling: PowerShell-Logik hinter checkpoint.cmd
├── .checkpoint-pending.txt     # Temporäre Übergabedatei vom Agent an checkpoint.cmd
├── teilgebiete/                # Pro Teilgebiet eine Detail-Datei (NN-<name>.md)
└── artefakte/                  # Pro Teilgebiet ein Unterordner mit fertigen Materialien
```

## Session-Start: Lesereihenfolge

Lies zu Beginn jeder neuen Session in dieser Reihenfolge:
1. `agent-prompt.md` (diese Datei) – Prozessanweisungen und aktueller Stand
2. `zentral-index.md` – welche Teilgebiete existieren und deren Status
3. `marketing.md` – Wissensbasis über das Unternehmen
4. `changelog.md` – letzte Einträge, um den Kontext der letzten Sessions zu verstehen
5. Die für die aktuelle Aufgabe relevante Teilgebiet-Datei (falls anwendbar)

Bestätige Thomas kurz, was du gelesen hast und welche Aufgabe laut "Aktueller Stand" ansteht, bevor du loslegst. Ermittle außerdem aus dem letzten Eintrag in `changelog.md` die neue Session-Nummer (z.B. nach S03 → S04) und verwende sie durchgängig in dieser Session.

## Prozessregeln

**R1 — Append-only Changelog.** Neue Einträge in `changelog.md` werden ausschließlich über den Checkpoint-Workflow (siehe unten) angehängt. Bestehende Einträge werden niemals verändert oder gelöscht. Jeder Eintrag enthält Timestamp und Session-Nummer (S01, S02, …).

**R2 — Status/Priorität/Abhängigkeiten nur mit OK.** Änderungen an Status, Priorität oder Abhängigkeiten eines Teilgebiets im `zentral-index.md` sind ausschließlich nach explizitem OK von Thomas erlaubt. Du triffst diese Entscheidungen nie eigenständig. Du darfst Änderungen vorschlagen.

**R3 — Session-Nummerierung.** Beim Session-Start ermittelst du aus der letzten Zeile von `changelog.md` die nächste Session-Nummer und verwendest sie für alle Checkpoints dieser Session.

**R4 — Fragen vor Taten.** Bei Unklarheiten fragst du Thomas, bevor du Annahmen triffst. Inhaltliche Marketing-Entscheidungen (Zielgruppe, Kanäle, Positionierung etc.) werden immer mit Thomas abgestimmt.

**R5 — Artefakte getrennt halten.** Fertige Materialien (Texte, Pläne, Vorlagen) werden in `artefakte/NN-<teilgebiet>/` abgelegt, nicht in der Teilgebiet-Datei selbst. Die Teilgebiet-Datei referenziert die Artefakte.

**R6 — Dateinamen.** Teilgebiet-Dateien folgen dem Schema `NN-<kurzname>.md` (z.B. `01-positionierung.md`). Die Nummer NN entspricht dem Eintrag im Zentral-Index.

**R7 — Kein direkter Git-Commit und kein direkter Changelog-Edit.** Du editierst `changelog.md` nicht direkt und führst auch keinen `git commit` aus. Beides geschieht ausschließlich über den Checkpoint-Workflow.

## Checkpoint-Workflow

Ein **Checkpoint** fasst einen abgeschlossenen Arbeitsschritt zusammen und besteht aus zwei gekoppelten Aktionen: einem Eintrag in `changelog.md` und einem Git-Commit. Checkpoints können **mehrfach pro Session** erfolgen – jedes Mal, wenn ein logischer Zwischenstand erreicht ist (z.B. ein Teilgebiet-Abschnitt fertig, ein Artefakt erstellt). Sie sollen aber auch **immer am Session-Ende** erfolgen, um den Stand zu sichern.

**Ablauf:**

1. Der Agent hat inhaltliche Änderungen an `marketing.md`, `zentral-index.md`, Teilgebiet-Dateien oder Artefakten vorgenommen.
2. Vor dem letzten Checkpoint einer Session zusätzlich: Aktualisiere den Abschnitt "Aktueller Stand / Nächste Aufgabe" am Ende dieser `agent-prompt.md`-Datei, sodass die nächste Session nahtlos starten kann.
3. Der Agent schreibt die Datei `.checkpoint-pending.txt` im Repo-Root mit **exakt** diesem Format:
   ```
   S<NN>
   <kompakte Zusammenfassung in einer oder mehreren Zeilen>
   ```
   Zeile 1: Session-Nummer (z.B. `S02`).
   Zeile 2 und folgende: Zusammenfassung. Mehrere Zeilen werden von `checkpoint.ps1` zu einem Satz zusammengeführt (Leerzeichen getrennt). Keine Pipes (`|`) in der Zusammenfassung, sie kollidieren mit dem Changelog-Format.
4. Der Agent teilt Thomas mit: "Bitte `checkpoint.cmd` ausführen."
5. Thomas doppelklickt `checkpoint.cmd`. Das Skript:
   - liest `.checkpoint-pending.txt`
   - hängt die Zeile `YYYY-MM-DD HH:MM | S<NN> | <summary>` an `changelog.md` an (Timestamp vom lokalen PC)
   - führt `git add -A && git commit -m "S<NN>: <summary>"` aus
   - löscht `.checkpoint-pending.txt`
6. Thomas bestätigt im Chat, dass der Checkpoint gelaufen ist. Erst danach arbeitet der Agent weiter.

**Fehlerfall:** Scheitert `checkpoint.cmd` (z.B. git commit fehlgeschlagen), bleibt `.checkpoint-pending.txt` liegen. Thomas gibt das Problem an den Agenten zurück, der Diagnose und Korrektur vorschlägt.

## Erste Aufgaben (nur beim allerersten Start relevant)

Falls `marketing.md` noch leere Platzhalter enthält und `zentral-index.md` noch keine Teilgebiete listet:

1. **`marketing.md` interaktiv befüllen.** Stelle Thomas gezielte Fragen zu: Unternehmensdaten, Angebot, Zielgruppe(n), aktueller Positionierung, gewünschter Tonalität, vorhandenen Marketing-Aktivitäten, Zielen. Arbeite Abschnitt für Abschnitt, nicht alles auf einmal.
2. **Teilgebiete gemeinsam definieren.** Schlage auf Basis von `marketing.md` eine Liste von Teilgebieten vor (z.B. Positionierung, Zielgruppenanalyse, Website, Content-Strategie, Social Media, Newsletter, SEO, Messen, …). Stimme Priorität und Abhängigkeiten mit Thomas ab und trage sie nach seiner Freigabe in `zentral-index.md` ein.
3. **Erste Teilgebiet-Datei anlegen** für das priorisierte Thema und Einstieg in die Bearbeitung.

Setze zwischen sinnvollen Zwischenständen Checkpoints (z.B. nach "Marketing.md Abschnitte 1-3 befüllt", nach "Teilgebiete-Liste festgelegt").

---

## Aktueller Stand / Nächste Aufgabe

**Letzte Session:** S08 (2026-04-26)

**Was wurde gemacht:** Iteration B fuer das DOCX abgeschlossen, plus zwei zusätzliche Anpassungen:
- **B4.1 — Heading-Farben in destengsblue** (`build/build-reference-docx.py` Funktion `set_heading_colors`, color val=`0B5394`, themeColor accent1 entfernt). H1, H2, H3 alle in destengsblue.
- **B4.2 — Heading-Trennlinien direkt am Stil verworfen.** Bottom-Border + Indent-Trick (`hanging`) erzeugte in Word linksbündige statt zentrierte Linien. Wichtige Lehre: Words `right`-Indent begrenzt sowohl Text als auch Border — eine Border *schmaler als der Heading-Text* ist über den Stil selbst nicht abbildbar.
- **B4.3 — Markdown-HRs aus cv.md entfernt** (21 alleinstehende `---`-Zeilen). Quelle der wahrgenommenen „Doppellinien": Pandoc-DOCX-Konvertierung von `---` zu VML-`<v:rect ... o:hr="t"/>` (Embossed-Look). Tabellen-Strich-Zeilen blieben unangetastet. **Vorfall:** Sandbox-NTFS-Stale-Read der cv.md (20043 statt 20201 Bytes) hätte fast die Live-Datei truncated, sofortige Wiederherstellung aus `git show HEAD` + HR-Removal erneut mit der git-Version als Input.
- **B4.4 — H2-Trennlinien via Post-Processing** (`build/post-process-docx.py` um Funktion erweitert): nach jedem H2-Absatz ein leerer Trenn-Absatz mit linksbündiger Bottom-Border, schwarz (`000000`), 8,6 cm Linienlänge (right-Indent 4196 dxa), 1,25 pt dick (sz=10).
- **B5 — Trainings als Tabelle** (cv.md): Trainings-Bullet-Liste durch Pandoc-Multiline-Tabelle ersetzt (analog Ausbildung), Inhalte normal nicht fett.
- **B6 — Bullet-Einzüge verkleinert** (`build/post-process-docx.py` modifiziert `numbering.xml` direkt; Pandoc IGNORIERT die `numbering.xml`-Werte der reference.docx, daher MUSS das im Post-Processing passieren). E1: Einzug 0,25 cm + Sondereinzug 0,35 cm (left=340/hanging=198 dxa); E2: Einzug 0,80 cm + Sondereinzug 0,40 cm (left=681/hanging=227 dxa). Word-Konvention: „Einzug links" = `(left - hanging)` = Bullet-Position; „Sondereinzug Hängend" = `hanging`.

**Nächste Aufgabe:** Teilgebiet 01 — verbleibende Iterationen:
1. **C — Foto-Einbindung** in cv.md mit Pandoc-Image-Syntax und Template-Anpassung für Position/Größe (z.B. oben rechts neben Name, ca. 3 cm).
2. **D — Hyphenation-Feintuning für PDF** — kurze Wortteile am Zeilenanfang mit höherer Penalty oder `\hyphenation`-Ausnahmen reduzieren.

Nach D): Status von Teilgebiet 01 in `zentral-index.md` auf „abgeschlossen" setzen (R2-OK von Thomas). Anschließend nächstes Teilgebiet nach Priorität (laut Index Teilgebiet 02 „Zeugnis von ASMPT").

**Offene Punkte (unverändert seit S04):** Zuschnitt und Festpreise der KI-Produkte (marketing.md Abschnitt 2), KMU-Direkthonorarsatz festlegen (marketing.md Abschnitt 2), Vergütungsmodell-Wahl bei erstem konkreten Fall (Notiz in marketing.md Abschnitt 2).

**Hinweise für die nächste Session:**
- **Word-Indent-Konvention (S08-Lehre):** Word zeigt im Absatz-Dialog „Einzug links" als `(left - hanging)`, NICHT als `left`. „Sondereinzug Hängend" ist `hanging`. Daher gilt: `left = (gewünschter Einzug + gewünschter Hanging-Indent)` in dxa.
- **Word-Border-Limit (S08-Lehre):** Words paragraph-Border folgt den Indents; eine Border *schmaler als der Heading-Text* geht NICHT über `<w:ind right="...">` auf dem Heading-Stil, weil der right-Indent auch den Text begrenzt. Lösung wenn nötig: separater Trenn-Absatz nach dem Heading via Post-Processing.
- **Pandoc IGNORIERT die `numbering.xml` der reference.docx (S08-Lehre).** Wer Bullet-Einzüge ändern will, muss das im Post-Processing tun, nicht in `build-reference-docx.py`.
- **Pandoc generiert für Markdown-`---` im DOCX VML-Horizontal-Lines (`<v:rect o:hr="t"/>`)** — sehen aus wie Doppellinien (Embossed). Im PDF rendert Pandoc dieselbe Quelle als saubere zentrierte Halblinie. Wenn man saubere DOCX-Trennung braucht: HRs in cv.md entfernen oder Pandoc-Lua-Filter für DOCX-Build.
- **Sandbox-NTFS-Stale-Reads sind häufiger und kritischer als gedacht (S08-Lehre).** Sandbox kann auch git-Status, Datei-Existenz und Datei-Inhalte verzerrt sehen, ohne dass die echte Datei betroffen ist. **Bei jedem Sandbox-Schreiben auf eine grössere NTFS-Mount-Datei: ERST git-Version verifizieren und als Input verwenden, NICHT blind dem Sandbox-Read trauen.** Bei seltsamen git-status-Outputs aus der Sandbox: erst Thomas auf PowerShell `git status` ausführen lassen.
- **Edit-Tool truncated regelmäßig** (mehrfach in S07 und S08 erlebt — Skript-Dateien, `.checkpoint-pending.txt`, `agent-prompt.md`, `teilgebiete/01-lebenslauf.md`). Faustregel: Bei jedem Edit auf NTFS-Mount-Datei nach `Edit` mit `wc -c` und `tail -c 80` verifizieren. Bei längeren Edits oder wenn das Risiko hoch ist: lieber per Heredoc/Python aus der git-Version neu schreiben.
- **Sandbox-Pandoc ist 2.9.x, Thomas' System läuft Pandoc 3.x.** Output-Unterschiede zwischen den Versionen können Build-Probleme verursachen. Sandbox-Pandoc emittiert weder die calc-basierten Spaltenbreiten (`p{... * \real{...}}`) noch `\def\LTcaptype{none}` — beides Pandoc-3.x-Eigenheiten. Bei Fehlern, die nur auf Thomas' System auftreten, **synthetisch das Pandoc-3.x-Output-Fragment in einer Mini-Tex-Datei nachbauen** und damit gegen das Template kompilieren.
- **Sandbox kann nichts an `.git/` schreiben** (NTFS-Permission-Issue): Lock-Files, korrupte Index — alles muss von PowerShell aus repariert werden.
- **`checkpoint.ps1` ist robust** gegen Anführungszeichen, Pipes, Whitespace-Anomalien und Index-Lock-Reste. `.checkpoint-pending.txt` darf ganz normal Sonderzeichen enthalten.
- **`build.ps1` pausiert bei Fehler 3 Sekunden pro fehlgeschlagenem Schritt.** Nicht überrascht sein, wenn ein fehlerhafter Lauf entsprechend länger braucht.
- **`build/build-reference-docx.py` muss VOR `build.ps1` manuell aufgerufen werden, wenn `templates/reference.docx` neu gebaut werden soll.** Das Skript ist nicht in `build.ps1` integriert (würde jeden Build verlangsamen und Pandoc-Default-Reference jedes Mal neu ziehen). Wenn jemand die `reference.docx` von Hand in Word editiert, gehen die Änderungen beim nächsten Skript-Lauf verloren — Stile gehören also ins Skript, nicht in Word.
- **DOCX-Pipeline ist jetzt 3-stufig mit drei Post-Processing-Modifikationen:** (1) `build/build-reference-docx.py` baut die `reference.docx` (manuell aufrufen, wenn Stile geändert werden sollen), (2) `build/build.ps1` baut PDF und DOCX, (3) `build/post-process-docx.py` wird automatisch aus `build.ps1` aufgerufen und macht: 3-3-Listen-Bullet-Regel, H2-Trennlinien-Einfügung, Bullet-Einzug-Anpassung in `numbering.xml`. Wer das Bullet-Verhalten oder Trennlinien ändern will, fasst das Post-Processing-Skript an.