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:

agent-prompt.md (diese Datei) – Prozessanweisungen und aktueller Stand
zentral-index.md – welche Teilgebiete existieren und deren Status
marketing.md – Wissensbasis über das Unternehmen
changelog.md – letzte Einträge, um den Kontext der letzten Sessions zu verstehen
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:

Der Agent hat inhaltliche Änderungen an marketing.md, zentral-index.md, Teilgebiet-Dateien oder Artefakten vorgenommen.
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.
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.
Der Agent teilt Thomas mit: "Bitte checkpoint.cmd ausführen."
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
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:

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.
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.
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: S07 (2026-04-26)

Was wurde gemacht:

PDF-Build-Fehler endgültig behoben. Pandoc-3.x-\def\LTcaptype{none}-Bug (Issue #11201). Fix: \newcounter{none} im Template. Iteration A inhaltlich abgeschlossen.
Build-UX-Fix: build/build.ps1 mit Start-Sleep -Seconds 3 pro fehlschlagendem Schritt.
Iteration B durchgezogen — reference.docx programmatisch via build/build-reference-docx.py (Python-Stdlib, holt Pandoc-Default-Reference, entpackt ZIP, modifiziert XML mit ElementTree, repackt). Inhalt:
- B1 — Schriften, Tabellen: Theme major+minor auf Calibri (Pandoc-3.x-Default war Aptos Display/Aptos), Stil Table mit tblBorders=none auf allen Sides.
- B1.5 — Schriftgrößen analog PDF: DocDefault Body 11 pt, Heading 1/2/3 auf 15/13/12 pt.
- B2 — Header, Footer, Page-Setup: Header (Name links, Lebenslauf rechts) ab Seite 2, leerer Header für Seite 1 via titlePg. Footer (Seite n / m) auf allen Seiten inkl. Seite 1 (zwei footerReference-Einträge, default + first auf gleicher rId). Page-Setup A4 mit 2.2/2.5 cm Rändern, Tab-Stop 9072 dxa.
- B3 — Schusterjungen/Witwen-Schutz für Headings: DocDefault widowControl, Heading 1/2/3 und FirstParagraph (für Kenntnisse-Subsection-Labels) mit keepNext + keepLines.
Iteration B3.5 — 3-3-Regel für Listen-Bullets über neues Post-Processing-Skript build/post-process-docx.py. Erster Versuch (Compact-Stil mit keepNext) hat Listen komplett unteilbar gemacht — Folge: Job-Stationen begannen jedes Mal auf neuer Seite, ungenutzte Seitenenden. Auf Wunsch von Thomas Per-Bullet-Logik: bei Listen mit ≥ 6 Bullets bekommen die ersten 2 und die N-3-/N-2-Bullets keepNext, dazwischen darf getrennt werden (= mind. 3 Bullets vor und nach jedem Umbruch). Bei < 6 Bullets bleibt alles zusammen. build.ps1 ruft das Skript automatisch nach DOCX-Build als Schritt [3/3] auf. Sandbox-Verifikation: 26 Listen, 184 Bullets, 93 keepNext-Markierungen, Pattern z.B. KK......KK. für 11-Bullet-Liste. Auf Thomas' System visuell bestätigt: Listen werden sauber an guten Stellen getrennt, keine ungenutzten Seitenenden mehr.

Nächste Aufgabe: Teilgebiet 01 — verbleibende Iterationen:

B4 — Heading-Farben auf DesTEngS-Blau und/oder Trennlinien analog PDF. Bringt das DOCX optisch näher ans PDF (für Direktverwendung; bei Consulting-Agenturen, die das Layout ohnehin überschreiben, eher Kosmetik). Erstes Aufgabe der nächsten Session.
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).
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:

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. Sandbox-Verifikation des kompletten Pipeline-Laufs mit pandoc cv.md → PDF deckt diese Bugs nicht ab. 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-Reads über den NTFS-Mount können stale/inkonsistent sein. Wenn Sandbox-Reads Schäden zeigen, die unplausibel sind, nicht panisch reagieren — erst Thomas via PowerShell verifizieren lassen, bevor Reparaturmaßnahmen ergriffen werden.
Sandbox-Schreibvorgänge sind zuverlässig (Write-Tool und Heredoc via Bash). Bei längeren Skript-Dateien (>100 Zeilen) bleibt Heredoc trotzdem die robustere Wahl.
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.
Edit-Tool kann Dateien beim Schreiben über den NTFS-Mount truncatieren (mehrfach in S07 erlebt am Python-Skript und an build.ps1). mcp__workspace__bash mit cat <<'EOF' > path ist die zuverlässige Alternative für längere Dateien (>~150 Zeilen). Nach jedem Edit auf NTFS-Mount-Datei: wc -l und tail -c 60 zur Verifikation.
DOCX-Pipeline ist jetzt 3-stufig: (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 für die 3-3-Listen-Bullet-Regel. Wer das Bullet-Verhalten ändern will, fasst das Post-Processing-Skript an, nicht die reference.docx.

12 KiB Raw Blame History Unescape Escape