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:** S11 (2026-04-28)

**Was wurde in S11 gemacht:**

S11 — **Methodik-Sektion in `cv.md` erweitert.**

- Ausgangslage: 7 Einträge in suboptimaler Reihenfolge, mit Lücken bei Architektur/Design, Test und System Integration.
- Diskussion mit Thomas: Reordering bestätigt (Spezifikation vor Technologie-Auswahl, „Was-vor-Wie"-Logik), Software-Design-Konflikt mit der Kenntnisse-Subsection `**Software Design:**` über Variante 1 gelöst (Methodik-Eintrag heißt „SW-Architektur und -Design", Subsection-Titel bleibt unverändert), „Verifikation und Validierung" statt schlichtem „Test", „Anforderungsanalyse / Requirements Engineering" und „Spezifikationserstellung" beide drin (verschiedene Schritte), Querschnittsthemen (Risikomanagement, QS, Konfigurationsmanagement, Reviews, Vorgehensmodelle) bewusst weggelassen.
- Diskussion über Streichungs-Vorschläge: „Inbetriebnahme und Übergabe" weggelassen (kein Schwerpunkt im aktuellen Positionierungs-Kern); „Systematische Fehleranalyse" beibehalten nach Argumentation, dass V&V (entwicklungsbegleitend, Konformitätsnachweis) und SFA (reaktiv, Root Cause bei unerwartetem Fehlverhalten) verschiedene Aktivitäten sind und SFA ein Differenzierer in Thomas' Profil und Recruiter-Filter-Begriff ist.
- Finale Liste in `cv.md` (12 Einträge, Lifecycle-Reihenfolge): Konzepterstellung → Machbarkeitsstudien → Anforderungsanalyse / Requirements Engineering → Spezifikationserstellung → Technologie-Evaluierung und -Auswahl → System-Architektur und -Design → SW-Architektur und -Design → Verifikation und Validierung → System Integration → Technische Dokumentation → Systematische Fehleranalyse → Projektmanagement.
- Umsetzung atomar via Python-aus-Disk (`os.replace`), kein Edit-Tool. Ein-Treffer-Check vor Replace bestand. Verifikation per Re-Read: 12 Einträge in korrekter Reihenfolge, Vor-/Nachkontext (Software-Design-Subsection, IT-Subsection) unverändert.
- Doku-Pflege: Doppelter `## Nächste Schritte`-Block in `teilgebiete/01-lebenslauf.md` (Reste aus S10) konsolidiert.

**Was aus S10 weiterhin gilt:**

- **DOCX-Stand:** gut und einsatzbereit. Kann sofort an Recruiter/Agenturen versendet werden. DOCX-Pipeline wird in S12 nicht angefasst.
- **PDF-Stand:** funktional aber nicht typografisch perfekt. H1 + Foto Seite 1 oben ✓, Trennlinien-Stil schwarz analog DOCX ✓, H3 blau ✓, Body-Spacings etwas größer als Header (akzeptierter Trade-off), Pagebreaks bei Trainings/Kenntnisse/„Berufliche Stationen" können unschön sein, Page-Count ca. 7 Seiten. Final-Lösung kommt mit S12 (CV-LaTeX-Klasse).

**Lessons-learned aus S10 (weiterhin wichtig für Folge-Sessions):**

- **Sandbox-Build als Pflicht für Layout-Iterationen.** Setup unter `/tmp/sbxbuild` mit `pdflatex` + `lmodern` (statt `lualatex` + IBM Plex Sans) eingerichtet. Page-Layout-Tendenzen 1:1 vergleichbar zu Thomas' Setup, exakte Schriftbilder weichen ab.
- **Layout-Eingriffe einzeln testen.** Mehrere Mechanismen kombiniert blockieren Diagnose.
- **parskip-Glue ist essentiell.** `\setlength{\parskip}{0.5em plus 0.2em minus 0.1em}` (Glue) gibt LaTeX Layout-Flexibilität. Eliminierung kostet 2+ Seiten.
- **Pandoc 3.x emittiert `minipage[t]` für Tabellen-Cells**, in denen `\@parboxrestore` `parskip` auf 0pt setzt — erklärt unterschiedliche Spacings Body vs. Header.
- **`titlesec` verträgt kein `\par` im after-code** — direktes `\penalty` ist sicherer.
- **`
opagebreak` in longtable-Kontext** ist als `
oalign{...}` überschrieben — `\penalty 7500` ist longtable-sicher.

**Nächste Aufgaben:**

**S11 — Rest des Lebenslauf-Inhalts (offen):**

1. **Inhaltliche Kleinigkeiten in `cv.md`.** Thomas hat konkrete Detail-Verbesserungen im Sinn, die in S11 oder einer kurzen Folgesitzung abgearbeitet werden.

**S12 — PDF-Pipeline-Refactoring mit professioneller CV-LaTeX-Klasse:**

1. **Tool-Recherche:** `moderncv` vs. `awesome-cv` vs. typst (oder andere). Vergleich nach Optik, Aufwand, MikTeX-Integration, DesTEngS-CI-Anpassbarkeit (`#3C68AE`, IBM Plex Sans).
2. **`cv.md` bleibt single source of truth.**
3. **Daten-Extraktion aus `cv.md`** für die CV-Klasse-Features (`\cventry`/`\cvevent`/etc.):
   - Custom Pandoc-Filter (Lua oder Python) ODER
   - Erweiterung von `build.ps1` mit Python-Pre-Processor, der `cv.md` → `cv.tex` transformiert.
4. **Implementierung, Sandbox-Test, visuelle Verifikation durch Thomas.**

**Hinweise für die nächste Session:**

- **Sandbox-Build-Setup** unter `/tmp/sbxbuild`: pdflatex statt lualatex, lmodern statt IBM Plex Sans. Pandoc 2.9 vs. 3.x bei Thomas — strukturelle Differenzen bei Tabellen-Cells und Image-Wrappern bekannt, aber Page-Layout-Tendenzen 1:1 vergleichbar.
- **Live-Template-Stand** (clean S10) ist als Fallback im Git committet. Endgültige typografische Qualität kommt mit S12 (CV-LaTeX-Klasse).
- **DOCX-Pipeline ist 3-stufig** mit vier Post-Processing-Modifikationen: (1) `build/build-reference-docx.py` baut die `reference.docx` (manuell aufrufen), (2) `build/build.ps1` baut PDF und DOCX, (3) `build/post-process-docx.py` macht: 3-3-Listen-Bullet-Regel, H2-Trennlinien, Bullet-Einzüge in `numbering.xml`, Header-Tabellen-H1-Spacing-und-Foto-Spacing.
- **Edit-Tool-Truncation** auf NTFS-Mount-Dateien ist nach S07/S08/S09/S10 ein systematisches Problem — durchgehend Python-aus-git-HEAD- oder Python-aus-Disk-Pattern verwenden (atomar via `os.replace`). In S11 für `cv.md`, `teilgebiete/01-lebenslauf.md` und `agent-prompt.md` konsequent angewandt.

**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).