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

Was wurde in S10 gemacht:

S10 — Aufgabe 1 (DOCX-Heading-Farbe und H1+H2-Bold).

• Farb-Audit: DesTEngS-Primärfarbe ist #3C68AE, nicht #0B5394. In vier Dateien korrigiert (agent-prompt.md, teilgebiete/01-lebenslauf.md, build/build-reference-docx.py, templates/template.tex). changelog.md (append-only) und cv-debug.tex (Build-Output) ausgenommen.
• Diagnose der nicht-greifenden Heading-Farbe im DOCX: Pandoc-3.x-Default-Reference enthält Linked Character Styles Heading1Char/2Char/3Char mit eigener <w:color val="0F4761" themeColor="accent1" themeShade="BF"/> (Aptos-Petrol). Char-Styles haben in Word Vorrang vor Para-Styles bei Run-Eigenschaften (Schrift, Farbe). Pandoc 2.9 (Sandbox) hat diese Char-Styles nicht — daher war das Problem in der Sandbox nicht reproduzierbar.
• Fix in build/build-reference-docx.py: HEADING_COLOR_STYLES-Tuple um Heading1Char/2Char/3Char erweitert. Zusatzanforderung Thomas: H1+H2 fett. Neue Funktion set_heading_bold mit Konstante HEADING_BOLD_STYLES (Heading1+2 Para- und Char-Stil). H3 bleibt unverändert.
• Visuelle Bestätigung im DOCX: alle Headings in #3C68AE, H1+H2 fett, H3 normal.

S10 — Aufgabe 2 (cv.md Sinn-Korrekturen).

• Diff alter CV (archiv/Lebenslauf_Thomas_Langer_2025-03-21.docx) vs. aktueller cv.md vorbereitet: cv-old-plain.txt, cv-new-plain.txt, cv-diff-unified.txt, cv-diff-report.md in output/.
• 18 Sprach-/Stilkorrekturen umgesetzt (atomar via Python-aus-Disk):
  • Thomas-Funde: „Digitales"→„digitales Dämpfungsglied", „Leiterplattenherstellern"→„Leiterplattenhersteller", Komma-Konsistenz Toshiba-Spezifikation, „Detaillierte Analysen elektrischer IC-Gehäuse"→„Detaillierte elektrische Analysen von IC-Gehäusen", „Dotierungsprofile und dessen Implementierung"→„… und Implementierung".
  • Agent-Funde: „inclusive"→„inklusive", „Faseroptische"→„faseroptische", „10 KHz"→„10 kHz", PyAutoGui→PyAutoGUI, Halbgeviertstrich + Komposita-Fix bei Transimpedanzverstärker-GaAs-MMICs, „2.5 GHz"→„2,5 GHz", „Evaluierungsboard Redesigns"→„-Redesigns", Komma vor „abgeschlossen 2001", Mixed-Mode-S-Parameter mit Bindestrich, Realtime-Oszilloskopen, Objektorientierte/ereignisorientierte ohne Bindestrich.
  • Methodik-Liste umsortiert (Projekt-Lifecycle): Konzepterstellung → Machbarkeitsstudien → Technologie-Evaluierung und -Auswahl → Spezifikationserstellung → Technische Dokumentation → Systematische Fehleranalyse → Projektmanagement.

S10 — Aufgabe 3 (Buzzword-Erweiterung KI-Block).

• KI-Sektion umstrukturiert nach Thomas-Layout: Service-Begriffe (Potenzialanalyse, Schulung, Implementierung, Prompt Engineering, Multimodale KI, DSGVO) → KI Software (Office/Marketing-Tools) → GenAI/LLMs mit Sub-Bullet MoE/Reasoning/Function-Calling → Agentic AI mit Sub-Bullet MCP → NLP → RAG mit Sub-Bullet Chunk-Strategien → „Edge AI / On-Premise KI-Infrastruktur" als gebündeltes Stack-Kapitel am Ende (Hardware NVIDIA Blackwell + CUDA → Quantisierung FP8/MXFP4 → Modell-Formate GGUF/Safetensors → Software-Stack Ollama/Hugging Face Transformers/PyTorch/llama.cpp/Open WebUI).

S10 — Aufgabe 4 (PDF-Layout) — TEILWEISE GELÖST mit Trade-off, Final-Lösung in S12 mit professioneller CV-LaTeX-Klasse.

• H1: keine Trennlinie mehr (analog DOCX).
• H2: schwarze Trennlinie 8,6 cm × 1,25 pt (1:1 wie DOCX-H2-Trennlinie).
• H3: in DesTEngS-Blau, nicht fett (analog DOCX).
• Erste Seite: graue Header-Trennlinie weg (\renewcommand{\headrule}{} in firstpage plus \headrulewidth=0pt); \vspace*{-1.16cm} direkt nach \thispagestyle{firstpage} rückt H1+Foto an die Top-Margin.
• Body-Spacings (H2↔Linie und Linie↔Bullets) bleiben etwas größer als im Header. Versuch der Angleichung durch parskip-Glue-Eliminierung + zweifache parskip-Kompensation im H2-after-code wurde nach Sandbox-Diagnose rückgebaut — er produzierte 2–3 zusätzliche PDF-Seiten. parskip-Glue ist essentiell für LaTeX-Pagebreak-Flexibilität. Final-Lösung der Body-Header-Konsistenz kommt mit S12 (CV-LaTeX-Klasse).
• Trainings/Kenntnisse/„Berufliche Stationen vor der Selbständigkeit": longtable-Pagebreak-Logik macht im aktuellen Setup gelegentlich unschöne Trennungen. Auch dieses Problem wird mit der CV-LaTeX-Klasse in S12 strukturell gelöst.

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

• Sandbox-Build als Pflicht für Layout-Iterationen. Iterations-Loop über Thomas ist nur sinnvoll, wenn jede Variante vorher selbst getestet wurde. Sandbox-Setup mit pdflatex + lmodern (statt lualatex + IBM Plex Sans) ist eingerichtet unter /tmp/sbxbuild (in Linux-Sandbox); Page-Counts und Pagebreak-Verhalten lassen sich dort gut beurteilen, exakte Schriftbilder weichen ab.
• Layout-Eingriffe einzeln testen. Mehrere Mechanismen (parskip-Manipulation + needspace + penalty + bodyonlyvspace) kombiniert haben Diagnose blockiert. Saubere Sandbox-Isolierung jedes Mechanismus hat den Schuldigen schnell gefunden (parskip-Glue).
• parskip-Glue ist essentiell. \setlength{\parskip}{0.5em plus 0.2em minus 0.1em} (Glue) gibt LaTeX Layout-Flexibilität. Eliminierung des Glues kostet 2+ Seiten und ist ungeeignet.
• Pandoc 3.x emittiert minipage[t] für Tabellen-Cells, in denen \@parboxrestore parskip auf 0pt setzt. Daher unterschiedliche Spacings Body vs. Header — strukturell schwer mit Custom-titlesec-Tricks anzugleichen.
• titlesec verträgt kein \par im after-code (! Paragraph ended before \ttl@format@iii was complete.). Direktes \penalty-TeX-Primitive ist sicherer.
• \nopagebreak ist in longtable-Kontext auf \noalign{...}-Form überschrieben und bricht im after-code mit ! Misplaced \noalign.. Direktes \penalty 7500 ist longtable-sicher.

Aktueller PDF-Stand am Schluss von S10:

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 (Sandbox-Schätzung 8, Thomas-Layout typischerweise eine niedriger)

DOCX-Stand: gut und einsatzbereit. Kann sofort an Recruiter/Agenturen versendet werden, falls Thomas das wünscht. Die DOCX-Pipeline wird in S12 nicht angefasst.

Nächste Aufgaben:

S11 — nur Lebenslauf-Inhalt:

1. Methodik-Sektion ergänzen. Aktuelle 7 Einträge (Konzepterstellung, Machbarkeitsstudien, Technologie-Evaluierung und -Auswahl, Spezifikationserstellung, Technische Dokumentation, Systematische Fehleranalyse, Projektmanagement) auf weitere relevante Methodik-Begriffe ausbauen.
2. Inhaltliche Kleinigkeiten verbessern. Thomas hat konkrete Detail-Verbesserungen in cv.md im Sinn, die in S11 umgesetzt 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).

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