111 lines
11 KiB
Markdown
111 lines
11 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.** Der S06-Hotfix (array, calc, providecommand real) hat das Problem nicht beseitigt — nach Rebuild auf Thomas' System kam unverändert `! LaTeX Error: No counter 'none' defined.` Eigentliche Ursache: Pandoc 3.x emittiert für unnummerierte Tabellen direkt vor `\begin{longtable}` die Zeile `\def\LTcaptype{none}`, ohne den Counter `none` zu definieren. Sobald longtable intern `\refstepcounter{\LTcaptype}` aufruft, bricht LaTeX ab. Pandocs eigene Default-Vorlage definiert den Counter (commit d835461 in 3.8.2.1), Custom-Templates müssen das selbst tun. Siehe [Pandoc-Issue #11201](https://github.com/jgm/pandoc/issues/11201). Fix: eine Zeile `\newcounter{none}` direkt nach `\providecommand{\real}` im Tabellen-Block des Templates. In der Sandbox sauber reproduziert (gleicher Fehlertext ohne Fix, sauberes PDF mit Fix). Auf Thomas' System: PDF wird erzeugt, Ausbildungs-Layout im PDF visuell bestätigt.
|
||
- **Iteration A für Teilgebiet 01 damit inhaltlich abgeschlossen** (Tabellen-Variante mit zwei Spalten ca. 14 % / 80 %, rahmenlos im PDF, native Word-Tabelle im DOCX — Rahmen-Aus folgt in Iteration B).
|
||
- **Build-UX-Fix:** `build/build.ps1` ergänzt um `Start-Sleep -Seconds 3` nach jedem fehlschlagenden Build-Schritt (Pflichtdatei-Check, PDF-Build, DOCX-Build). Vorher schloss sich das PowerShell-Fenster bei Doppelklick auf das Skript so schnell, dass die rote Fehlerzeile nicht lesbar war. Bei mehreren Fehlern in einem Lauf akkumulieren sich die Pausen — gewollt.
|
||
|
||
**Nächste Aufgabe:** Teilgebiet 01 — drei verbleibende Iterationen in dieser Reihenfolge:
|
||
1. **B) `templates/reference.docx` in Word polieren** — Header/Footer setzen, Schriften auf Calibri vereinheitlichen, Listen-Schutz „Keep with next" und Widow-Control via Word-Stile, Tabellen-Stile so konfigurieren, dass die Ausbildungs-Tabelle ohne Rahmen rendert (Default-Tabellenstil oder benannter Stil).
|
||
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 gezielten `\hyphenation`-Ausnahmen reduzieren. Iterativ.
|
||
|
||
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.
|