118 lines
12 KiB
Markdown
118 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, sandbox-reproduziert. PDF läuft auf Thomas' System, Ausbildungs-Layout visuell bestätigt. **Iteration A damit inhaltlich abgeschlossen.**
|
||
- **Build-UX-Fix:** `build/build.ps1` mit `Start-Sleep -Seconds 3` pro fehlschlagendem Schritt, damit das PowerShell-Fenster bei Fehler nicht zu schnell schließt.
|
||
- **Iteration B durchgezogen — `reference.docx` programmatisch via `build/build-reference-docx.py` (Python-Stdlib only, kein pip).** Holt Pandoc-Default-Reference per `pandoc --print-default-data-file`, entpackt die DOCX als ZIP, modifiziert XML mit ElementTree, repackt.
|
||
- **B1 — Schriften:** Theme `majorFont` und `minorFont` beide auf Calibri (Pandoc 3.x setzt Defaults auf Aptos Display / Aptos). Defensive Maßnahme: alle direkten `<w:rFonts>`-Referenzen außerhalb von Code-Schriften (Consolas, Courier, ...) auf Calibri.
|
||
- **B1 — Tabellen:** Stil `Table` mit `<w:tblBorders val="none">` auf allen Sides. Word-Editor zeigt weiterhin Tabellen-Anzeige-Hilfslinien (kein Druck-Rendering); Druckansicht und PDF-Export sind sauber rahmenlos.
|
||
- **B1.5 — Schriftgrößen analog PDF:** DocDefault Body 11 pt, Heading 1/2/3 auf 15/13/12 pt. DOCX schrumpft von 10 auf 9 Seiten.
|
||
- **B2 — Header, Footer, Page-Setup:** `header1.xml` (Default ab Seite 2: Name links, „Lebenslauf" rechts), `header2.xml` (leer für Seite 1 via `titlePg`), `footer1.xml` (rechts „Seite n / m" mit `PAGE`/`NUMPAGES`-Feldern, einmal als `default`, einmal als `first` referenziert, damit Seite 1 trotz titlePg den Footer hat). Page-Setup explizit: A4 mit 2.2 cm oben/unten, 2.5 cm links/rechts (analog PDF). Tab-Stop am rechten Textrand 9072 dxa = 16 cm. Beziehungen werden mit dynamisch ermittelter nächster freier `rId` registriert; Content-Types-Overrides ergänzt; sectPr regex-basiert ersetzt (idempotent gegen `<w:sectPr/>` und längere Varianten). Pandoc 2.9 und 3.x übernehmen die sectPr ins generierte DOCX (in der Sandbox end-to-end verifiziert). DOCX-Layout von Thomas visuell bestätigt: Seite 1 ohne Header und mit Footer, Seite 2 ff. Header und Footer wie gewünscht, Tab-Stops bündig am rechten Textrand.
|
||
|
||
**Nächste Aufgabe:** Teilgebiet 01 — verbleibende Iterationen:
|
||
1. **B3 — Keep with next + Widow/Orphan-Control für DOCX.** Schusterjungen-Schutz analog `\widowpenalty`/`needspace` im PDF. Auf Stilebene `<w:keepNext/>` für Headings und `<w:widowControl w:val="true"/>` als DocDefault.
|
||
2. **B4 (optional) — Heading-Farben auf DesTEngS-Blau und/oder Trennlinien analog PDF.** Eher Kosmetik bei Vorlage für Consulting-Agenturen.
|
||
3. **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).
|
||
4. **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). `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` zur Verifikation.
|