119 lines
12 KiB
Markdown
119 lines
12 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:** S07 (2026-04-26)
|
||
|
||
**Was wurde gemacht:**
|
||
- **PDF-Build-Fehler endgültig behoben.** Pandoc-3.x-`\def\LTcaptype{none}`-Bug ([Issue #11201](https://github.com/jgm/pandoc/issues/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:
|
||
1. **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.
|
||
2. **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).
|
||
3. **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.
|