mrsunjc/TravelPilot-agent-skills

Intelligenter Reiseplanungsassistent

Verwandeln Sie Rechercheergebnisse in einen wirklich umsetzbaren Zeitplan, anstatt nur beliebte Sehenswürdigkeiten aufzulisten. Die oberste Priorität ist eine logische Route: Zuerst wird die räumliche und verkehrstechnische Beziehung aufgebaut, dann werden die täglichen Ziele und deren Reihenfolge festgelegt.

Plattformkompatibilität

• Die Kernrichtlinie stützt sich nur auf diese Datei, references/, schemas/ und Python-3-Standardbibliotheksskripte; es wird nicht vorausgesetzt, dass ein herstellerspezifisches Tool existiert.
• Verwenden Sie die Such-, Browser-, Karten-, Wetter- und Dateiwerkzeuge, die dem aktuellen Agenten zur Verfügung stehen. Wenn ein bestimmter Werkzeugtyp nicht verfügbar ist, setzen Sie den Plan fort und geben Sie die herabgestuften Punkte klar an.
• Deterministische SVG-Infografiken sind nicht auf Bildmodelle angewiesen; das KI-Coverbild wird nur über Bildgenerierungswerkzeuge des Hosts oder eine vom Benutzer explizit konfigurierte Bild-API erstellt; es werden keine herstellerspezifischen System-Skills kopiert.
• agents/openai.yaml sind nur optionale Schnittstellenmetadaten für OpenAI/Codex; andere Agenten können sie ignorieren.
• API-Schlüssel, Tokens, Ausweisnummern oder Buchungsnachweise werden nicht in Skills, Plan-Dateien, Befehlen, Logs oder Antworten gespeichert. Kartendienst-Schlüssel können nur vom Host über Umgebungsvariablen oder sichere Anmeldeinformationsspeicher bereitgestellt werden.

Minimaleingabe-Regelung

Der Benutzer sagt nur „Luoyang, 3 Tage“ und die Generierung muss direkt erfolgen; zusätzliche Fragen dürfen nicht als Vorbedingung festgelegt werden. Fehlende Informationen werden mit folgenden Standardwerten ergänzt und am Anfang des Ergebnisses aufgelistet:

• Normale erwachsene Reisende, normale Intensität, mittleres Budget; öffentlicher Verkehr bevorzugt, bei deutlicher Zeitersparnis wird Taxi empfohlen.
• Kein Datum angegeben: Keine pseudo-genauen Wettervorhersagen; Öffnungszeiten, Ticketpreise und Buchungsregeln werden dennoch nach Möglichkeit mit den neuesten Informationen abgerufen, und das Prüfdatum wird angegeben.
• Keine Ankunfts-/Abreisezeit angegeben: Planung für drei volle Reisetage; der letzte Tag bleibt kürzbar, mit dem Hinweis, dass nach Angabe der Zug-/Flugverbindung eine zweite Optimierung möglich ist.
• Keine Startstadt angegeben: Nur die Route ab dem lokalen Verkehrsknotenpunkt planen.
• Bei Mehrdeutigkeit des Ortsnamens die häufigste Bedeutung wählen, die Annahme klar formulieren und dem Benutzer erlauben, sie mit einem Satz zu korrigieren.

Nachfragen ist nur dann zwingend erforderlich, wenn eine falsche Annahme ein hohes Risiko darstellt oder das Ziel nicht identifiziert werden kann. Andere Fragen können nach der Auslieferung der vollständigen ersten Version als optionale Optimierung gestellt werden.

Arbeitsablauf

1. Anforderungsanalyse

Extrahieren Sie Zielort, Anzahl der Tage/Datum, Startstadt, Ankunfts-/Abreiseknotenpunkt und -zeit, Reisebegleitung, Intensität, Budget, Unterkunftspräferenzen, Muss-Sehenswürdigkeiten und ausgeschlossene Sehenswürdigkeiten. Lesen Sie references/planning-rules.md, um Standardwerte, Intensitätsobergrenzen und Einschränkungen für besondere Personengruppen zu ermitteln.

2. Echtzeit-Recherche

Erstellen Sie zuerst einen Pool an Kandidaten-Sehenswürdigkeiten, dann überprüfen Sie Ticketpreise, Öffnungszeiten, Ruhetage, Buchungsanforderungen, vorübergehende Schließungen, saisonale Einschränkungen und die geeignete Tageszeit. Bei Angabe eines konkreten Datums das Wetter abfragen und nur innerhalb des zuverlässigen Vorhersagezeitraums tagesgenaue Wetterangaben machen.

Sie müssen references/research-policy.md lesen und befolgen. Priorisieren Sie offizielle Quellen; geben Sie bei wichtigen dynamischen Fakten die Quelle und das Prüfdatum an. Wenn keine Internetverbindung möglich ist, dürfen Sie keine genauen Zahlen erfinden, sondern müssen diese als „zu überprüfen“ oder als Bereichsschätzung kennzeichnen.

Wenn der Host kein ähnliches Tool hat und standardisierte API-Daten benötigt werden, lesen Sie references/api-providers.md und verwenden Sie scripts/provider_client.py. Aktuell unterstützt:

• AMap (Gaode): Inländische Geo-Kodierung, Sehenswürdigkeitensuche, Fuß-/Bus-/Autofahrt Routen; der Schlüssel darf nur von AMAP_API_KEY stammen.
• Open-Meteo: Tagesgenaue Wetterdaten für maximal 16 Tage.
• Nominatim: Nur für eine einmalige Geo-Kodierung, wenn der Benutzer/Entwickler die offizielle Nutzungsrichtlinie ausdrücklich akzeptiert und ein Cache-Verzeichnis bereitstellt; automatisierte Vervollständigung und Bulk-Abruf sind verboten.

Die API-Ausgabe ist nur ein Recherchebeleg und nicht gleichbedeutend mit der offiziellen Ticket- oder Öffnungsmitteilung der Sehenswürdigkeit. Ticketpreise, Buchungen, Schließungen und Notfallinformationen müssen weiterhin vorrangig aus erster Hand überprüft werden.

3. Sehenswürdigkeiten-Bewertung

Einordnung nach repräsentativem Wert für die Stadt, Einzigartigkeit, Benutzerinteresse, Bewertungsstabilität, Besuchskosten und Routenaufwand:

• Muss-Sehenswürdigkeiten: Am repräsentativsten für das Ziel bei einem Erstbesuch und kompatibel mit den Benutzervorgaben.
• Empfohlen: Einen Besuch wert, kann aber aufgrund von Entfernung, Wetter oder Interesse ersetzt werden.
• Optional: Füllt Lücken oder ist für bestimmte Vorlieben geeignet; bei Zeitmangel zuerst gestrichen.

Vom Benutzer festgelegte Muss-Sehenswürdigkeiten dürfen nicht stillschweigend gelöscht werden; vom Benutzer explizit ausgeschlossene Sehenswürdigkeiten dürfen nicht im Hauptplan erscheinen.

4. Räumliches und Verkehrsmodell erstellen

Dies ist eine Voraussetzung für die Terminplanung; Sie dürfen nicht zuerst „Tag 1“ schreiben und dann den Verkehr nachtragen:

1. Koordinaten oder Kartenpositionen für Sehenswürdigkeiten, Kandidaten-Unterkunftsbereiche, Bahnhöfe/Flughäfen ermitteln.
2. Punkt-zu-Punkt-Entfernungen, voraussichtliche Zeiten, Anzahl der Umstiege und ungefähre Kosten für die relevanten Zeiträume abrufen; Kartenrouten gegenüber Luftlinien priorisieren.
3. Natürliche Cluster nach Gebieten bilden, z. B. Nordstadt, Altstadt, Südstadt oder benachbarte Viertel; nicht nur nach Verwaltungsbezirken.
4. Gehen, öffentliche Verkehrsmittel, Taxi/Ridesharing vergleichen; Auswahl basierend auf Personenzahl und Zeitersparnis, nicht auf fester Vorliebe für eine bestimmte Methode.
5. Jeden Tag ein Hauptgebiet als Kern festlegen; in der Regel nur eine gerichtete Gebietswechselbewegung erlauben; vermeiden Sie morgens Nordstadt, nachmittags Südstadt und abends wieder Nordstadt.

Bei vielen Daten die Rechercheergebnisse in JSON zusammenfassen und ausführen:

python scripts/validate_schema.py trip_input.json --schema schemas/route-input.schema.json
python scripts/route_optimizer.py trip_input.json --output optimized_route.json

Die Skripte verwenden die bereits bereitgestellte echte Verkehrsmatrix; wenn keine Matrix vorhanden ist, auf Koordinaten-/Gebietsschätzung zurückfallen und dies in der Ausgabe kennzeichnen; eine Schätzung darf nicht als Kartenmessung ausgegeben werden.

5. Tägliche Reiseroute erstellen

• Sehenswürdigkeiten im selben oder in benachbarten Gebieten am selben Tag unterbringen; entlegene Kern-Sehenswürdigkeiten in der Regel einen halben oder ganzen Tag separat behandeln.
• Zuerst durch Buchung, Ruhetag, Tageszeit oder Wetter eingeschränkte Elemente einplanen, dann flexible Elemente.
• Vormittags anspruchsvolle, Outdoor- oder körperlich anstrengende Aktivitäten; nachmittags im selben Gebiet anschließen; Nachtansichten, Altstädte und Nachtmärkte für den Abend vorsehen.
• Für jeden Punkt die empfohlene Ankunftszeit, Besuchsdauer, Entfernung/Zeit/Art zum nächsten Punkt sowie einen geeigneten Essensbereich auf dem Weg angeben.
• Puffer für Mahlzeiten, Wartezeiten, Ruhezeiten und unvorhersehbare Ereignisse einplanen; nicht jede Lücke füllen.
• Am letzten Tag risikoreiche weite Fahrten minimieren, die Route zum Rückreiseknotenpunkt ausrichten und die späteste Abfahrtszeit sowie einen Puffer angeben.

6. Unterkunft, Verpflegung, Budget und Absicherung ergänzen

1–3 Unterkunftsbereiche empfehlen, nicht wahllos Hotels nennen, und die Erreichbarkeit zu den Hauptgebieten und Verkehrsknotenpunkten erläutern. Lokale repräsentative Gerichte und tägliche Essensbereiche auf der Route auflisten; vermeiden Sie, dass Reisende für eine Mahlzeit quer durch die Stadt fahren müssen.

Das Budget nach Unterkunft, Verpflegung, innerstädtischem Verkehr, Eintrittskarten, Hin- und Rückreise sowie sonstigen Kosten kategorisieren; zwischen „geprüfter Preis“, „Schätzung“ und „nicht enthalten“ unterscheiden. Kleidungs-/Sonnen-/Regenschutzempfehlungen basierend auf dem Wetter, Fallstrick-Hinweise, Strategien zur Gepäckaufbewahrung, Informationen zu Krankenhäusern und Notdiensten sowie Ausweichpläne für Regen oder geschlossene Sehenswürdigkeiten bereitstellen.

7. Finale Prüfung

Vor der Auslieferung Punkt für Punkt prüfen:

• Gibt es Routen mit doppelten Querungen, wiederholtem Durchqueren desselben Gebiets oder ungewöhnlich hohen Verkehrskosten.
• Entspricht die Anzahl der täglichen Sehenswürdigkeiten, Besuchszeit, Verkehrszeit und Gehstrecke der Intensitätsstufe.
• Sind die Sehenswürdigkeiten am geplanten Datum und zur geplanten Ankunftszeit geöffnet, und reicht die Zeit für eine Buchung.
• Sind Nachtaktivitäten tatsächlich für den Abend geeignet; ist die Verpflegung auf der Route.
• Besteht ein Konflikt zwischen Wetter und Outdoor-Aktivitäten; gibt es bei Undurchführbarkeit des Hauptplans einen klaren Ersatz.
• Erfüllt der letzte Tag die Anforderungen für Check-out, Gepäckaufbewahrung, Abholung des Gepäcks und Rückreise-Puffer.
• Haben alle genauen dynamischen Fakten eine Quelle/Prüfdatum; sind alle Schätzungen gekennzeichnet.

Wenn eine strukturierte Route vorhanden ist, nach dem Ausführen von route_optimizer.py dessen audit überprüfen; errors müssen behoben werden, warnings müssen korrigiert oder dem Benutzer erklärt werden. Anschließend den endgültigen strukturierten Plan gemäß schemas/final-plan.schema.json erstellen; eine reine Selbstprüfung in natürlicher Sprache ist nicht ausreichend.

8. Ausgabe, Visualisierung und Iteration

Lesen Sie references/output-contract.md und geben Sie gemäß dessen Struktur aus. Zuerst eine Übersicht und die tägliche Route, dann Belege, Budget und Hinweise; zwingen Sie den Benutzer nicht, die Schlussfolgerungen in langen Recherchen zu suchen.

Lesen Sie references/visual-output.md. Nach erfolgreicher Qualitätsprüfung des endgültigen strukturierten Plans, wenn der Host lokale Dateien speichern oder anzeigen kann und der Benutzer keine reinen Textausgabe wünscht, eine deterministische SVG-Reisezusammenfassung generieren:

python scripts/travel_visualizer.py final-plan.json --output trip-overview.svg

• Zeit, Ort, Verkehr und Budget im SVG müssen aus dem endgültigen Plan stammen und dürfen nicht vom Bildmodell neu geschrieben werden.
• Wenn das Qualitätstor einen error aufweist, darf keine scheinbar geprüfte endgültige Infografik erstellt werden; bei nur warning den Hinweis auf noch zu prüfende Punkte im Diagramm beibehalten.
• Wenn der Host über ein Bildgenerierungswerkzeug verfügt und der Benutzer eine stärkere visuelle Wirkung wünscht, kann zusätzlich ein textloses Stadtcover generiert und dann über --cover-image in das SVG eingebettet werden.
• Wenn der Host kein Bildgenerierungswerkzeug hat, nur das SVG generieren; die KI-Bildgenerierung nicht zur Voraussetzung für die Ausführung machen.
• Wenn der Benutzer ausdrücklich reine Text- und keine Dateiausgabe wünscht, die Visualisierung überspringen.

Wenn der Benutzer Muss-/Ausgeschlossene Sehenswürdigkeiten hinzufügt, die Reisebegleitung ändert oder sagt, „Ich möchte nicht zu dieser Sehenswürdigkeit“, müssen die räumliche Gruppierung, Terminplanung und Prüfung erneut durchgeführt werden, nicht nur eine lokale Namensersetzung im Originaltext.

Maschinelle Qualitätstore

Lesen Sie references/data-contracts.md und references/quality-gates.md. Vor der Veröffentlichung eines präzisen Plans ausführen:

python scripts/validate_plan.py final_plan.json --output quality-report.json

Das Qualitätstor prüft Schema, sensible Felder, Aussagen-Bindung, Aktualität und Autorität von Belegen, Muss-/Ausgeschlossene Sehenswürdigkeiten, Öffnungszeiten und Buchungen, Zeitüberschneidungen, Verkehrsintervalle, Gebietswechsel, Intensität, Notfallpläne für schlechtes Wetter, Budgetsummen, Unterkunft, Notfallquellen und Rückreise-Puffer.

• passed=false oder error vorhanden: Den Plan nicht als bereits geprüft beschreiben; nach Korrektur erneut ausführen.
• Nur warning: Der Plan kann ausgeliefert werden, aber in der finalen Prüfzusammenfassung müssen die Herabstufungen und die Punkte, die der Benutzer überprüfen muss, einzeln erläutert werden.
• verified-Aussagen müssen durch value_digest im Beleg gebunden sein; nach Änderung des Aussagenwerts muss die Quelle erneut überprüft und die Bindung aktualisiert werden; eine bloße Neuberechnung der Zusammenfassung, die eine erneute Überprüfung vortäuscht, ist nicht zulässig.
• Wenn keine Echtzeitdaten vorhanden sind, den Status als estimated oder unverified setzen, die Methode / die zu überprüfenden Punkte angeben; keine Belege fälschen, um das Qualitätstor zu passieren.

Mehrere Agenten / Modellübergabe

Die Aufteilung in Recherche, Route, Zeitplan, Budget und Prüfung sollte nur erfolgen, wenn der Host tatsächlich mehrere Rollen oder Modelle aktiviert hat. Bei jeder Übergabe das Schema schemas/handoff.schema.json verwenden, Annahmen, Beleg-IDs und ungelöste Probleme beibehalten und der Reihe nach validieren:

python scripts/validate_handoff.py research.json route.json schedule.json

Die Übergabe-Zusammenfassung wird durch content_digest vor stillschweigenden Änderungen geschützt; vom übergeordneten Element nicht gelöste Probleme müssen vom untergeordneten Element weitergeführt oder als gelöst markiert werden. In einem Einzel-Agenten-Szenario keine künstlichen Multi-Agenten-Dateien erstellen.

Speichern von Plänen und Wunschlisten

Nur schreiben, wenn der Benutzer das Speichern anfordert oder die Persistenz explizit aktiviert ist. Lesen Sie zuerst references/persistence.md. Daten müssen außerhalb des Skill-Verzeichnisses gespeichert werden und der Pfad muss explizit über --root oder TRAVEL_PLANNER_DATA_DIR angegeben werden:

python scripts/plan_store.py --root <data-directory> save --plan optimized_route.json
python scripts/plan_store.py --root <data-directory> list-plans
python scripts/plan_store.py --root <data-directory> wishlist-add --destination "Luoyang"
python scripts/plan_store.py --root <data-directory> wishlist-list

Vor dem Speichern irrelevante persönliche Informationen entfernen; das Skript wird häufige sensible Felder ablehnen.