165 lines
15 KiB
Markdown
165 lines
15 KiB
Markdown
# 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).
|