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: 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:

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:

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.

13 KiB Raw Blame History Unescape Escape