Travel Guidebook Maker
Von der Recherche bis zum fertigen Buch – eine umfassende Engine zur Erstellung von Reiseführern. Keine KI-Illustrationen, keine Emojis, rein via CDN eingebunden. Mit Tabler Icons + Inline-SVG-Dekoration + Claude-Designästhetik entstehen warmherzige, durchgestaltete Reise-PDFs.
Designphilosophie
Der redaktionelle Geschmack von Monocle + die visuelle Erzählkunst von DK + die Informationstiefe von Lonely Planet + die warme Ästhetik von Claude
Dies ist kein kalter Navigationsführer, sondern ein herzlicher Reisebegleiter – auf einem pergamentartigen, warmen Hintergrund, in einer Serifenschrift die Geschichten der Reiseziele erzählt, mit einem Symbolsystem, das funktionale Informationen markiert, und dekorativen Elementen, die ein verlegerisches Gefühl vermitteln.
Kernprinzip: Satz ist Design. Vertraue nicht auf KI-generierte Bilder oder Fotos. Erzeuge Designgefühl durch Schriftartenhierarchie, funktionales Farbsystem, Inline-SVG-Dekoration und CSS-Pseudoelemente.
Gesamter Ablauf
Stufe 0 Umgebungsvorbereitung → Stufe 1 Anforderungsbestätigung
→ Stufe 2 Tiefgreifende Recherche [5 explore Agenten parallel]
→ Stufe 3 Routenarchitektur
→ Stufe 4 Inhaltserstellung [dedizierter general-purpose Agent]
→ Stufe 5 HTML-Auslieferung und Prüfung → Stufe 6 PDF-Export
Stufe 0 erkennt automatisch die Node.js + Playwright-Umgebung; Stufe 2 beschleunigt die Informationssammlung durch parallele Recherche; Stufe 4 verwendet einen dedizierten Agenten in einem sauberen Kontext, um HTML konsistent zu schreiben; Stufe 5 ist der HTML-Kontrollpunkt – der Benutzer bestätigt die Zufriedenheit, bevor Stufe 6 das PDF exportiert.
Stufe 0: Umgebungsvorbereitung
Stelle vor Beginn der Reiseführererstellung sicher, dass die PDF-Exportumgebung bereit ist.
Überprüfe die folgenden Punkte nacheinander in der angegebenen Reihenfolge. Falls ein Schritt fehlschlägt, stoppe und informiere den Benutzer:
1. Node.js
node --version
- ✅ v18.x oder höher → fortfahren
- ❌ Befehl existiert nicht → stoppen, zur Installation auffordern: https://nodejs.org/
2. package.json
ls package.json
- ✅ vorhanden → fortfahren
- ❌ nicht vorhanden →
npm init -y
3. Playwright
node -e "require('playwright')"
- ✅ kein Fehler → fortfahren
- ❌ Fehler →
npm install playwright && npx playwright install chromium
4. html2pdf.mjs
Bereits in scripts/html2pdf.mjs gebündelt. Wird in Stufe 6 in das Arbeitsverzeichnis kopiert.
5. Amap MCP (optional, erweiternd)
Versuche, das Amap MCP-Tool zur Überprüfung der Verfügbarkeit aufzurufen:
Aufruf maps_whether("{Zielstadt}")
- ✅ Wetterdaten zurückgegeben → setze
AMAP_AVAILABLE = true - ❌ Tool existiert nicht oder gibt Fehler → setze
AMAP_AVAILABLE = false
Amap MCP ist eine Erweiterungsschicht – wenn es nicht verfügbar ist, wird der Reiseführer trotzdem normal erstellt, nur dass präzise Daten auf LLM-Schätzungen zurückfallen.
Hinweis, wenn der Benutzer es nicht konfiguriert hat (nur einmal erwähnen, blockiert den Ablauf nicht):
"💡 Amap MCP wurde nicht konfiguriert. Der Reiseführer wird trotzdem normal erstellt, aber Entfernungs-/Verkehrs-/Wetterdaten basieren auf Schätzungen. Für präzise Daten füge
@amap/amap-maps-mcp-serverin der MCP-Konfiguration hinzu."
Umgebungsbereitschaft bestätigen
Nachdem alle Prüfungen bestanden sind, ausgebe:
"✅ Umgebungsbereit (Node.js {Version} + Playwright + Chromium{+ Amap MCP, falls verfügbar}). Beginne mit der Erstellung des Reiseführers."
Stufe 1: Anforderungsbestätigung
Bestätige die folgenden Parameter mit dem Benutzer (frage nur nach, was nicht aus der Anweisung abgeleitet werden kann):
Erhalten, bereite die Erstellung des Reiseführers vor. Bitte bestätige die folgenden Informationen:
- Routenname: «{aus Anweisung abgeleitet}», korrekt?
- Reisetyp: Autoreise / Wanderung / Stadtbummel / Gemischt?
- Zielgruppe: Tiefgehende Kulturreise / Entspannte Erholungsreise / Abenteuerliche Herausforderung?
- Gesamttage: {abgeleitete Tage}, richtig?
- Persönliche Informationen: Sollen auf dem Cover oder am Ende persönliche/Team-Informationen hinzugefügt werden?
Antworte einfach mit den Änderungen. Wenn alles passt, beginne ich direkt.
Schnellmodus: Wenn der Benutzer genügend Informationen angegeben hat, überspringe die Bestätigung und führe direkt aus.
Standardwerte: Reisetyp = Autoreise, Zielgruppe = Tiefgehende Kulturreise, Tage = basierend auf Route abgeleitet, Persönliche Informationen = keine.
Intelligentes Routing
Nach der Anforderungsbestätigung bestimme basierend auf der Benutzereingabe die Startstufe:
| Vom Benutzer bereitgestellt | Springe zu | Beschreibung |
|---|---|---|
| Nur Ziel/Tage | Stufe 2 | Standardvollablauf |
| Vorhandene Reisedatei (Markdown/Text) | Stufe 3 | Lese Reise, extrahiere Architektur, überspringe Recherche |
| Vorhandene Reise + "Bestätigt/Keine Recherche nötig" | Stufe 4 | Gehe direkt zum Schreiben und Layout |
| Vorhandener HTML-Reiseführer | Stufe 5 | Gehe direkt zur Prüfung, kann nach Änderungen PDF exportieren |
Entscheidungsgrundlage: ob der Benutzer einen @Dateiname-Verweis beigefügt hat, ob explizit "Reise bestätigt", "keine Recherche nötig" usw. gesagt wurde. Bei Unsicherheit standardmäßig den vollständigen Ablauf verwenden, aber aktiv fragen: "Soll ich recherchieren oder direkt mit dem Schreiben beginnen?"
Stufe 2: Tiefgreifende Recherche (parallele Sub-Agenten)
Die Recherche für einen Reiseführer muss gleichzeitig praktische Informationen und kulturelle Tiefe abdecken. Verwende parallele explore Agenten, um die Recherche zu beschleunigen – jeder Agent arbeitet unabhängig in eine Richtung, blockiert sich nicht gegenseitig.
Parallele Recherche-Architektur
Haupt-Agent explore Agent-Pool (parallel)
┌──────────┐ ┌─────────────────────────┐
│ Erstelle 5+1 │ ── background ──→│ research-transport │
│ Agenten │ ── background ──→│ research-attractions │
│ Prompt │ ── background ──→│ research-food │
│ │ ── background ──→│ research-culture │
│ │ ── background ──→│ research-practical │
│ │ ── background ──→│ research-spatial (Amap) │
│ │ └─────────────────────────┘
│ Warte auf │ ←── auto-notify ─── (jeder Agent nach Abschluss)
│ Benachrichtigung│
│ Sammle und │ ── read_agent ──→ Ergebnis jedes Agenten abrufen
│ führe zusammen│
│ Ausgabe │
│ Bericht │
└──────────┘
research-spatialwird nur gestartet, wennAMAP_AVAILABLE = true. Wenn nicht verfügbar, werden nur 5 Agenten gestartet.
### Aufgabenverteilung der Agenten
Verwende das `task`-Tool, `agent_type: "explore"`, `mode: "background"`, starte gleichzeitig 5+1 Agenten:
| Agentenname | Forschungsrichtung | Beispiel-Suchschlüsselwörter (Chinesisch + Englisch) |
|-------------|-------------------|------------------------------------------------------|
| `research-transport` | Verkehrsrouten | "{Start} nach {Ziel} Zug/Anfahrt Fahrplan Preis", "{destination} transport" |
| `research-attractions` | Kern-Sehenswürdigkeiten | "{Ziel} Muss-Sehenswürdigkeiten Eintritt Öffnungszeiten TOP10", "{destination} attractions" |
| `research-food` | Lokale Küche | "{Ziel} Spezialitäten empfohlene Restaurants Essensstraße pro Person", "{destination} local food" |
| `research-culture` | Kultur und Geschichte | "{Ziel} Geschichte Kultur Anekdoten Bräuche Dialekt", "{destination} history culture" |
| `research-practical` | Praktische Informationen | "{Ziel} {Monat} Wetter Budget Sicherheit Hinweise", "{destination} travel tips" |
> Bei einer Autoreise füge einen 7. Agenten `research-road` hinzu (Straßenzustand, Tankstellen, Höhenänderungen).
### Amap Spatial Data Agent (falls AMAP_AVAILABLE = true)
Der 6. Agent `research-spatial`, spezialisiert auf die Erfassung von Amap-Daten:
Du bist ein Spezialist für die Erfassung von Geodaten. Verwende die Amap MCP-Tools, um die folgenden Daten zu erfassen.
Ziel: {Ziel} Bekannte Sehenswürdigkeiten: {Alle aus der Anforderungsbestätigung extrahierten Sehenswürdigkeitsnamen}
Aufgabe 1: POI-Daten der Sehenswürdigkeiten
Rufe für jede Sehenswürdigkeit maps_text_search("{Sehenswürdigkeitsname}") auf und extrahiere:
- POI ID, Name, vollständige Adresse, Koordinaten, Bewertung, Öffnungszeiten, Telefonnummer
Aufgabe 2: Umgebungsfunde
Rufe für jede Kernsehenswürdigkeit (Hauptsehenswürdigkeit des Tages) maps_around_search auf:
- Schlüsselwort="Restaurant|Imbiss", location={Koordinaten der Sehenswürdigkeit}, radius=1000 → Top 5 Restaurants in der Nähe
- Schlüsselwort="Tante-Emma-Laden|Apotheke", location={Koordinaten der Sehenswürdigkeit}, radius=500 → Notfall-Einrichtungen
Aufgabe 3: Wettervorhersage
maps_whether("{Name der Zielstadt oder Adcode}")
Aufgabe 4: Geocodierung
Rufe für alle Ortsnamen maps_gep auf, um genaue Koordinaten für die Routenplanung in Stufe 3 zu erhalten
Ausgabeformat
Zusammenfassung der Sehenswürdigkeiten-POIs
| Sehenswürdigkeit | Adresse | Koordinaten | Bewertung | Öffnungszeiten |
|---|---|---|---|---|
| ... | ... | ... | ... | ... |
Umgebungsfunde
{Sehenswürdigkeitsname} Umgebung
| Name | Typ | Entfernung | Bewertung |
|---|---|---|---|
| ... | ... | ... | ... |
Wettervorhersage
| Datum | Wetter | Temperatur | Wind |
|---|---|---|---|
| ... | ... | ... | ... |
> Bei einer Autoreise füge einen 6. Agenten `research-road` hinzu (Straßenzustand, Tankstellen, Höhenänderungen).
### Agent Prompt Vorlage
Der Prompt für jeden Agenten folgt dieser Struktur:
Du bist ein Recherche-Spezialist für Reisethemen, verantwortlich für die Recherche zu 【{Richtung}】.
Aufgabenparameter
- Ziel: {Ziel}
- Startort: {Startort}
- Datum: {Konkretes Datum}
- Tage: {N} Tage
- Reisetyp: {Auto/Bahn/Gemischt}
Rechercheanforderungen
- Verwende bash, um curl oder web_fetch für die folgenden URLs auszuführen (einzeln versuchen, bei Fehler überspringen):
- {Vordefinierte URL-Liste, 3-5 relevante Websites}
- Extrahiere aus jeder Quelle die wichtigsten Datenpunkte
- Wenn alle URLs fehlschlagen, basierend auf vorhandenem Wissen zusammenfassen, kennzeichnen mit "⚠️ Modellwissen"
Ausgabeformat (streng einhalten)
{Richtungsname}
Kernfunde
- Fund 1: {Konkrete Daten} (Quelle: {URL})
- Fund 2: ...
Empfehlungsliste
| Name | Details | Preis | Anmerkungen |
|---|---|---|---|
| ... | ... | ... | ... |
Quellen
- {URL1}
- {URL2}
Datenaktualität
- Die obigen Informationen wurden am {aktuelles Datum} abgerufen. Es wird empfohlen, Preise und Öffnungszeiten vor Reiseantritt zu überprüfen.
### Ergebnisse sammeln und zusammenführen
Nachdem alle Agenten abgeschlossen sind:
1. Rufe nacheinander `read_agent` auf, um die Ergebnisse jedes Agenten zu erhalten
2. Führe sie zu einem einheitlichen Recherchebericht zusammen, gegliedert nach Richtung
3. Markiere die Quelle jedes Datenpunkts (URL oder "Modellwissen")
4. Wenn ein Agent fehlschlägt, ergänze der Haupt-Agent diese Richtung mit LLM-Wissen
### Degradierungsstrategie
| Szenario | Vorgehen |
|----------|----------|
| task-Tool nicht verfügbar | Zurück zum **seriellen Modus**: Haupt-Agent führt web_fetch nacheinander pro Richtung durch |
| Teilweiser Agenten-Timeout/Fehler | Haupt-Agent ergänzt die fehlgeschlagene Richtung mit LLM-Wissen |
| research-spatial fehlschlägt | Entfernung/Zeit mit LLM schätzen, mit "ca." kennzeichnen |
| Keine Internetverbindung | **Offline-Modus**: Alles basierend auf LLM-Wissen, mit "⚠️ Bitte vor Reiseantritt überprüfen" kennzeichnen |
## Recherche-Qualitätsanforderungen
- Paralleler Modus: Jeder Agent mindestens 3 gültige Quellen, insgesamt ≥ 15
- Serieller Modus: Gesamtquellenanzahl ≥ 20 (≤3 Tage Kurztrip: ≥ 10)
- Offline-Modus: So umfassend wie möglich, Datenaktualität als unsicher kennzeichnen
- Priorität: Offizielle Tourismus-Websites, erfahrene Reiseblogger, lokale Medien, Fachforen
- Preisinformationen müssen mit Gültigkeitszeitraum versehen sein
- Schlüsselfakten durch mindestens 2 unabhängige Quellen überprüfen
---
# Stufe 3: Routenarchitektur
Generiere basierend auf den Rechercheergebnissen die tägliche Reiseroute. Wenn Amap-Raumdaten verfügbar sind, verwende **echte Routenplanung** anstelle von LLM-Schätzungen.
## Amap-Routenplanung (falls AMAP_AVAILABLE = true)
Der `research-spatial`-Agent aus Stufe 2 hat bereits die genauen Koordinaten aller Sehenswürdigkeiten bereitgestellt. Auf dieser Basis ruft der Haupt-Agent die Amap-Routenplanungs-API auf:
Wähle für aufeinanderfolgende Sehenswürdigkeitenpaare in der täglichen Reiseroute basierend auf dem Reisetyp die API:
Reisetyp │ API │ Beschreibung ──────────┼──────────────────────────────────────┼────────── Autoreise │ maps_direction_driving(A-Koordinate, B-Koordinate) │ Distanz/Zeit/Maut Stadtbummel │ maps_direction_walking (≤3km) │ Gehstrecke/Zeit │ maps_direction_transit_integrated (>3km)│ U-Bahn/Bus-Optionen Radfahren │ maps_bicycling │ Radroute/Distanz Stadtwechsel│ maps_direction_transit_integrated │ Zug/Bus-Optionen Alle Modi │ maps_distance │ Tägliche Gesamtdistanz prüfen
> Wenn Amap nicht verfügbar ist, schätze Distanz und Zeit mit LLM-Wissen und kennzeichne dies im Reiseführer mit "ca.".
## Stufe 3.1: Machbarkeitsprüfung der Reiseroute (Feasibility Gate)
> **Erstes Prinzip**: Eine Reiseroute ist eine Planung unter physischen Zwängen, keine freie Kombination von Sehenswürdigkeiten.
> Bevor eine tägliche Reiseroute geschrieben wird, muss die folgende Prüfung bestanden werden – wenn nicht, werden Sehenswürdigkeiten zwangsweise aufgeteilt oder gelöscht.
### Regel 1: Formel zur Machbarkeit von Tagesausflügen
Verfügbare Gesamtzeit = Zeit von Abfahrt bis Rückkehr (allgemein 12h, in Hochgebirgsregionen 10h)
Prüfungsformel: Startpunkt → Sehenswürdigkeit A (einfache Fahrtzeit) × 2 ← Hin- und Rückfahrt
- Summe der Besuchszeiten aller Sehenswürdigkeiten
- Summe der Fahrzeiten zwischen den Sehenswürdigkeiten
- Pufferzeit (1h) ≤ Verfügbare Gesamtzeit
Wenn nicht erfüllt → muss auf mehrere Tage aufgeteilt werden oder die entfernteste Sehenswürdigkeit entfernt werden
**Berechnungswerkzeug** (Priorität):
- AMAP_AVAILABLE = true → rufe `maps_direction_driving` / `maps_distance` auf, um die tatsächliche Zeit zu erhalten
- AMAP_AVAILABLE = false → schätze mit LLM-Wissen und kennzeichne im Reiseführer mit "ca."
### Regel 2: Zwangsweise Trennung von Sehenswürdigkeiten außerhalb der Stadt
| Einfache Entfernung vom Startort | Pflichtregel |
|--------------------------------|--------------|
| ≤ 80km | Kann am selben Tag wie andere Sehenswürdigkeiten sein |
| 80–150km | Am selben Tag nur diese Sehenswürdigkeit, keine anderen Ziele |
| > 150km | **Muss zwingend einen eigenen Tag erhalten, oder Unterkunft entlang der Strecke einplanen** |
> Typische Falle: Start in Lhasa, Yamdrok-See (100km) kann als eigenständiger Tagesausflug; Shigatse Tashilhunpo-Kloster / Pelkor Chöde-Kloster (280km) **auf keinen Fall** mit irgendeiner Lhasa-Sehenswürdigkeit oder dem Yamdrok-See am selben Tag kombinieren.
### Regel 3: Einschränkungen für besondere Ziele
**Hochgebirgsregionen (Höhe 3500m+):**
| Tag nach Ankunft | Erlaubter Aktionsradius | Verboten |
|-----------------|-------------------------|----------|
| Tag 1 | Spaziergang um das Hotel, ≤1h | Alle Sehenswürdigkeiten |
| Tag 2 | Flache Sehenswürdigkeiten in der Stadt, ≤3h | Sehenswürdigkeiten über 4000m |
| Tag 3+ | Normale Besichtigungen in der Stadt | Sehenswürdigkeiten über 4500m ab Tag 4 empfohlen |
| Tag 4+ | Hohe Lagen möglich (Yamdrok-See 4441m) | — |
| Tag 5+ | Extrem hohe Lagen (Namtso-See 4718m) möglich | Sauerstoff mitnehmen erforderlich |
**Zwingend durchzusetzen**: Tag 1 einer Hochgebirgsreise darf keine kostenpflichtigen Sehenswürdigkeiten beinhalten. Falls doch, die Sehenswürdigkeiten automatisch um einen Tag verschieben.
### Regel 4: Checkliste nach der Erstellung
Nach dem Entwurf der täglichen Reiseroute muss jeder Punkt überprüft werden:
□ Ist die tägliche Gesamtfahrstrecke (Hin und Rück) im machbaren Bereich? □ Liegen alle Sehenswürdigkeiten im selben vernünftigen Gebiet? (Kein Überspringen mehrerer Städte) □ Gibt es versteckte "weite Sprünge"? (Z.B. A→B→C scheint nah, ist aber tatsächlich ein Umweg) □ Hochgebirgsroute: Wird die Höhenanpassungsregel verletzt? □ Bei Tagesausflügen mit Mietwagen/Selbstfahrer: Gibt es genug Besichtigungs-/Aufenthaltszeit (≥2h)? □ Ist die Rückreisezeit ausreichend reserviert? (Rückkehr vor Einbruch der Dunkelheit)
Wenn ein Punkt nicht bestanden wird → **rote Warnung**, den Tagesplan neu erstellen, bevor Stufe 4 betreten wird.
---
## Rhythmus-Design
- **Wechsel von Anspannung und Entspannung**: Abwechselnde Tage mit langen Fahrten und Tagen mit tiefer Besichtigung
- **Höhepunkte einplanen**: Die besten Ziele in der Mitte der Reise platzieren (Tag 3-5)
- **Pufferzeit**: Alle 3-4 Tage einen "Freien Tag" oder "Ruhetag" einplanen
- **Emotionale Kurve**: Aufbruchseuphorie → Anpassungsphase → Höhepunkte → Nachklingen → Abschiedsweh
## Tägliche Reiserouten-Struktur
Tag X: [Startort] → [Ziel] ├─ Fahrstrecke: XXkm (Amap-gemessen / LLM-Schätzung) ├─ Voraussichtliche Zeit: Xh (inkl. Besuchszeit) ├─ Verkehrslösung (falls Amap verfügbar): │ ├─ Sehenswürdigkeit A→Sehenswürdigkeit B: Gehen 12min / 0,9km │ ├─ Sehenswürdigkeit B→Sehenswürdigkeit C: U-Bahn Linie 2, 3 Stationen / 15min │ └─ Sehenswürdigkeit C→Hotel: Bus Linie 537 / 25min ├─ Wetter (falls Amap verfügbar): ☁️ Bewölkt 26°C ├─ Highlight heute: Zusammenfassung in einem Satz ├─ Muss-Stopps: 2-3 ausgewählte (mit Amap-Bewertung) ├─ Umgebungsfunde (falls Amap verfügbar): Hoch bewertete Restaurants/Cafés in der Nähe der Sehenswürdigkeiten ├─ Essensempfehlungen: 1-2 ├─ Unterkunftsempfehlungen: 1-2 └─ Tipps: inklusive Wetterempfehlungen + tatsächliche Verkehrstipps
> Felder, die mit "falls Amap verfügbar" gekennzeichnet sind, werden bei `AMAP_AVAILABLE = false` weggelassen oder durch LLM-Schätzungen ersetzt.
## Benutzerbestätigung
Zeige die Reiserouten-Architektur zur Bestätigung oder Änderung an. Nach Bestätigung gehe zu Stufe 4 über.
**Schnellmodus**: Überspringe die Bestätigung, wenn der Benutzer "Schreib direkt, keine Bestätigung nötig" sagt.
---
# Stufe 4: Inhaltserstellung und Layout
Dies ist die Kernphase des Reiseführers – verwandle die Recherche und Architektur in ein wunderschön gestaltetes HTML-Dokument.
## Auswahl des Ausführungsmodus
Wähle basierend auf den verfügbaren Tools automatisch den optimalen Modus:
| Bedingung | Modus | Beschreibung |
|-----------|-------|--------------|
| task-Tool verfügbar | **Dedizierter Agenten-Modus** (empfohlen) | Starte 1 general-purpose Agenten, der das gesamte HTML in einem sauberen Kontext schreibt |
| task nicht verfügbar | **Haupt-Agent-Direktschreibmodus** | Haupt-Agent schreibt abschnittsweise mit heredoc (traditionelle Methode) |
### Dedizierter Agenten-Modus (empfohlen)
**Kernvorteil**: Der HTML-Schreibagent hat einen sauberen Kontext – ohne Rauschen von Rechercheprozessen, Chatverläufen oder Routendiskussionen. Vom ersten bis zum letzten Zeichen wird der Stil vollständig einheitlich sein.
Starte 1 `general-purpose` Agenten (`mode: "background"`), gib die folgenden **vollständig** in den Prompt ein:
Du bist ein Experte für das Schreiben von Reiseführer-HTML. Erstelle einen vollständigen, einzelnen HTML-Reiseführer.
Parameter des Reiseführers
- Routenname: {Name}
- Dateiname: {Name}_guidebook.html
- Reisedatum: {Datum}
- Tage: {N} Tage
- Reisetyp: {Typ}
CSS-Spezifikation (vollständig aus references/layout-css.md kopieren)
{layout-css.md Volltext}
Kapitelvorlagen (vollständig aus references/chapter-templates.md kopieren)
{chapter-templates.md Volltext}
Recherchedaten (zusammengeführter Bericht aus Stufe 2)
{Recherchebericht Volltext}
Routenarchitektur (bestätigte Version aus Stufe 3)
{Tägliche Reiseroute}
Schreibstil
Dreischichtiger bedarfsorientierter Ansatz:
- Orientierung (Wo) – präzise und klar: Ortsnamen, Richtungen, Distanzen und Zeiten genau
- Entscheidungsfindung (Was) – für den Benutzer filtern: 2-3 Muss-Stopps pro Tag
- Emotion (Warum) – Bedeutung verleihen: Historische Geschichten und lokale Perspektiven einweben
Technische Anforderungen
- Abschnittsweise mit heredoc schreiben (cat > für erste, cat >> für folgende), einfache Anführungszeichen << 'HTMLEOF'
- ¥ durch ¥ ersetzen, — durch —, → durch →, ° durch °
- Nach jedem Abschnitt wc -c ausführen, um Dateiwachstum zu bestätigen
- Insgesamt 3-5 Abschnitte, unterteilt nach logischen Absätzen
- Gesamtes CSS inline in , alle SVGs inline, null externe Bilder
- Letzter Abschnitt muss schließen
**Während der Haupt-Agent wartet**: Kann andere leichte Arbeiten erledigen oder den Benutzer informieren: "Generiere HTML, voraussichtlich 2-3 Minuten."
Nach Abschluss des Agenten:
1. `read_agent` aufrufen, um Ergebnis zu erhalten, bestätigen, dass die HTML-Datei erstellt wurde
2. `wc -c` ausführen, um die Dateigröße zu überprüfen (5-Tages-Reise sollte 50-80KB sein)
3. Zu Stufe 5 übergehen
### Haupt-Agent-Direktschreibmodus (Degradierung)
Wenn das task-Tool nicht verfügbar ist, schreibt der Haupt-Agent direkt mit heredoc in Abschnitten.
## Kapitelstruktur
Der Reiseführer verwendet eine fünfteilige Struktur. Lies `references/chapter-templates.md` für die vollständige HTML-Vorlage jedes Kapitels:
1. **Vor der Abreise**: Cover / Reiseübersicht / Reisevorbereitung
2. **Tägliche Reiserouten**: Tag für Tag (Kerninhalt) – Tageskarten, Routenbeschreibungen, Muss-Stopps, Essen, Unterkunft, Tipps, Notizbereich
3. **Zieltiefe**: 2-3 tiefgehende Einführungen zu wichtigen Zielen
4. **Praktischer Anhang**: Notfallkontakte, nützliche Ausdrücke, Kostenaufstellung, empfohlene Playlist
5. **Rückseite**: Reisezitat + persönliche Informationen + Platz für Reisegedanken
## Layout-Spezifikationen
Das visuelle Design des Reiseführers erbt die warme Ästhetik von Claude. Lies `references/layout-css.md` für die vollständigen CSS-Spezifikationen, die Folgendes abdecken:
- Externe Ressourcen (nur Google Fonts + Tabler Icons CDN)
- Seitenlayout (A4, max-width 680px)
- Schriftsystem (Noto Serif SC / Noto Sans SC / JetBrains Mono)
- Farbschema (Pergament-Hintergrund + Terracotta-Farbton + funktionales Farbsystem)
- Dekorationselemente (Kompass, Trennlinien, DAY-Abzeichen, Kartenecken, Initiale)
- Seitenumbruchkontrolle (Cover separat, Tag neue Seite, Karten nicht trennen)
- Druckanpassung (warmen Hintergrund beibehalten)
## Schreibstil
Dreischichtiger bedarfsorientierter Ansatz:
- **Orientierung (Wo)** – präzise und klar: Ortsnamen, Richtungen, Distanzen und Zeiten müssen genau sein, verkörperte Beschreibungen verwenden ("auf der linken Seite", "200 Meter voraus")
- **Entscheidungsfindung (Was)** – für den Benutzer filtern: pro Ziel nur 2-3 Muss-Stopps empfehlen, mit "Muss/Optional/Bei Zeit" gekennzeichnet
- **Emotion (Warum)** – Bedeutung verleihen: Jeden Ort mit "Warum es sich lohnt" erklären, historische Geschichten und lokale Perspektiven einweben, literarische Sprache zur Landschaftsbeschreibung verwenden
### Emotionaler Schreibstil (gesteuert durch Amap-Daten)
Wenn Amap-Raumdaten verfügbar sind, wende die folgenden vier emotionalen Verstärkungsmodi an:
**1. Distanz erzählen** – Präzise Distanzen in wahrnehmbare Erlebnisse umwandeln:
- ≤500m → "Ein paar Minuten zu Fuß" + was man unterwegs sehen/riechen/hören kann
- 500m-2km → "Eine Spazierstrecke" + Beschreibung der Landschaft unterwegs
- >2km → Verkehrsempfehlung + Aussicht aus dem Fenster
- Beispiel: "Verlasse den Südeingang des Gelben-Kranich-Turms, biege links ab und gehe 600 Meter die Wuluo-Straße entlang – etwa die Dauer eines Liedes – und du bist in der Hubu-Gasse."
**2. Umgebungsüberraschungen** – Präsentiere von Amap entdeckte hochbewertete POIs (die der LLM möglicherweise nicht kennt/neue Läden):
- Mit einer "💡 Reisefund"-Karte präsentieren
- Enthält: Name, Entfernung, Bewertung, ein Grund zur Empfehlung
**3. Zeitwahrnehmung** – Wetter + Distanz + Tageszeit = konkrete Erlebnisempfehlungen:
- Beispiel: "Heute 26°C bewölkt – perfektes Wetter für einen Spaziergang über die Nanjing-Brücke. Die Brücke ist 1,6 km lang, gemütliches Gehen dauert etwa 22 Minuten. Starte um 16:00 Uhr, dann erreichst du die Mitte genau zum Sonnenuntergang."
**4. Beruhigung** – In den täglichen Tipps nahegelegene Annehmlichkeiten einbetten:
- Beispiel: "200m von der heutigen Unterkunft entfernt gibt es einen FamilyMart (24h). Die nächste Apotheke ist 400m entfernt an der Wuluo-Straße."
> Wenn Amap nicht verfügbar ist, werden diese vier Modi automatisch weggelassen – der Reiseführer hat dennoch vollständige kulturelle Erzählungen und LLM-Schätzungen.
## HTML-Erstellung (heredoc-Abschnittsstrategie)
Erstelle eine vollständige einzelne HTML-Datei, gesamtes CSS inline in `<style>`, alle SVG-Dekorationen inline, null externe Bilder.
> Die folgende heredoc-Strategie gilt für **die interne Ausführung des dedizierten Agenten** und **den Direktschreib-Degradierungsmodus des Haupt-Agenten**.
### Strategie zum Schreiben großer Dateien
Der Reiseführer-HTML ist normalerweise 50-80KB (5-Tages-Reise etwa 30 Seiten), was die einmalige Obergrenze des write/create-Tools überschreitet. Verwende die **heredoc-Abschnittsstrategie**:
```bash
# Abschnitt 1: HTML-Head + vollständiges CSS (<style>-Tag)
cat > {Dateiname}_guidebook.html << 'HTMLEOF'
<!DOCTYPE html>
<html lang="de">
<head>...</head>
<style>/* Gesamtes CSS, siehe references/layout-css.md */</style>
<body>
HTMLEOF
# Abschnitt 2: Cover + Übersicht + Reisevorbereitung
cat >> {Dateiname}_guidebook.html << 'HTMLEOF'
<div class="cover">...</div>
<div class="overview">...</div>
<div class="preparation">...</div>
HTMLEOF
# Abschnitt 3-N: Tägliche Reiserouten (ein Abschnitt pro Tag oder pro 2 Tage)
cat >> {Dateiname}_guidebook.html << 'HTMLEOF'
<div class="day-chapter">...</div>
HTMLEOF
# Letzter Abschnitt: Tiefe Einblicke + Anhang + Rückseite + Schließen-Tags
cat >> {Dateiname}_guidebook.html << 'HTMLEOF'
<div class="deep-dive">...</div>
<div class="appendix">...</div>
<div class="back-cover">...</div>
</body></html>
HTMLEOF
Wichtige Hinweise:
- Verwende einfache Anführungszeichen heredoc (
<< 'HTMLEOF'), um Shell-Variablenexpansion zu verhindern - Ersetze
¥in heredoc durch¥, um Kodierungsprobleme zu vermeiden - Führe nach jedem Abschnitt
wc -caus, um das Dateiwachstum zu bestätigen - Halte die Gesamtzahl der Abschnitte auf 3-5, unterteilt nach logischen Absätzen (nicht mitten in HTML-Tags unterbrechen)
Stufe 5: HTML-Auslieferung und Prüfung
Auslieferungsumfang
- HTML-Datei:
{Routenname}_guidebook.html(einzelne Datei, null externe Abhängigkeiten) - Arbeitsbericht: Aufzeichnung des Erstellungsprozesses (Vorlage siehe
references/report-template.md)
HTML-Kontrollpunkt
Nachdem das HTML fertig ist, muss der Benutzer es zuerst überprüfen, nicht direkt zum PDF springen:
"Der HTML-Reiseführer wurde erstellt:
{Dateiname}_guidebook.html. Bitte öffne ihn im Browser, um Inhalt und Layout zu überprüfen. Wenn du zufrieden bist, sag mir Bescheid und ich exportiere das PDF. Wenn Anpassungen nötig sind, sag mir, was geändert werden muss."
- Benutzer sagt "OK / Zufrieden / PDF exportieren" → gehe zu Stufe 6
- Benutzer sagt "Ändere xxx" → zurück zu Stufe 4, nach der Änderung erneut zur Prüfung auffordern
Stufe 6: PDF-Export
Darf erst ausgeführt werden, nachdem der Benutzer in Stufe 5 die Zufriedenheit mit dem HTML bestätigt hat.
Ausführungsschritte
1. Export-Skript vorbereiten
Stelle sicher, dass html2pdf.mjs im Arbeitsverzeichnis vorhanden ist. Suche wie folgt:
# Zuerst das aktuelle Verzeichnis prüfen
ls html2pdf.mjs 2>/dev/null || \
# Das gebündelte Skript im Skill-Verzeichnis suchen
find ~/.agents/skills/travel-guidebook -name "html2pdf.mjs" 2>/dev/null | head -1 | xargs -I{} cp {} ./html2pdf.mjs || \
find . -path "*/travel-guidebook/scripts/html2pdf.mjs" 2>/dev/null | head -1 | xargs -I{} cp {} ./html2pdf.mjs
Wenn noch nicht gefunden, erstelle das folgende Minimalskript:
// html2pdf.mjs — Playwright A4 PDF export
import { chromium } from 'playwright';
import { resolve } from 'path';
const html = resolve(process.argv[2]);
const pdf = html.replace(/\.html$/, '.pdf');
const b = await chromium.launch();
const p = await b.newPage();
await p.goto('file://' + html, { waitUntil: 'networkidle' });
await p.waitForTimeout(2000);
await p.pdf({ path: pdf, format: 'A4', margin: { top: '2cm', right: '1.8cm', bottom: '2.5cm', left: '1.8cm' }, printBackground: true });
await b.close();
console.log('PDF saved:', pdf);
2. Export ausführen
node html2pdf.mjs {Dateiname}_guidebook.html
3. Verifizieren und ausliefern
Prüfe, ob das PDF existiert und zeige die Größe an. Fordere den Benutzer auf, es zu öffnen:
"✅ Das PDF des Reiseführers wurde exportiert:
{Dateiname}_guidebook.pdf({Seitenzahl} Seiten, {Dateigröße})."
PDF-Parameter
| Parameter | Wert | Beschreibung |
|---|---|---|
| Papier | A4 | Standarddruckgröße |
| Oberer Rand | 2cm | |
| Unterer Rand | 2,5cm | Platz für Seitenzahlen |
| Linker/rechter Rand | 1,8cm | |
| Fußzeile | Zentrierte Seitenzahl | 9pt JetBrains Mono |
| Wartestrategie | networkidle + 2s | Stellt CDN-Ressourcen-Ladung sicher |
| Hintergrund | printBackground: true | Behält den warmen Pergament-Hintergrund bei |
Ersatzlösung
Wenn Playwright fehlschlägt, leite den Benutzer zum manuellen Drucken im Browser an: Chrome/Edge HTML öffnen → Cmd/Ctrl+P → Als PDF speichern