plan-tour-route
Über
Diese Fähigkeit plant und optimiert Routen für Touren mit mehreren Stopps, indem Wegpunkte geokodiert, mittels Algorithmen wie dem Nearest-Neighbor-Verfahren angeordnet und Zeit-/Distanzmatrizen berechnet werden. Sie ermittelt Points of Interest (POIs) über OpenStreetMap und kann Fahr-, Geh- oder Verkehrsmitteloptionen vergleichen. Nutzen Sie sie für Roadtrips oder Stadtrundgänge, um Reisezeiten zu minimieren, die Besuchsreihenfolge zu optimieren und eine Route mit nahegelegenen Sehenswürdigkeiten anzureichern.
Schnellinstallation
Claude Code
Empfohlennpx skills add pjt222/agent-almanac -a claude-code/plugin add https://github.com/pjt222/agent-almanacgit clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/plan-tour-routeKopieren Sie diesen Befehl und fügen Sie ihn in Claude Code ein, um diese Fähigkeit zu installieren
Dokumentation
Plan Tour Route
Plan + optimize multi-stop tour: time est, distance, POIs along way.
Use When
- Road trip or walking tour w/ multiple destinations
- Optimize visit order → min total travel time/distance
- Discover restaurants, viewpoints, cultural sites along route
- Day-by-day itinerary w/ realistic time budgets
- Compare driving vs walking vs transit
In
- Required: Waypoint list (place names, addresses, coordinates)
- Required: Travel mode (driving, walking, cycling, transit)
- Optional: Start + end (if different from first/last waypoint)
- Optional: Time constraints (departure, must-arrive-by, opening hours)
- Optional: POI categories (food, viewpoints, museums, fuel)
- Optional: Route type pref (fastest, shortest, scenic)
Do
Step 1: Define Waypoints
Collect + structure all stops.
Waypoint Schema:
┌──────────┬────────────────────────────────────────────┐
│ Field │ Description │
├──────────┼────────────────────────────────────────────┤
│ name │ Human-readable label for the stop │
│ address │ Street address or place name │
│ lat/lon │ Coordinates (if known; otherwise geocode) │
│ duration │ Time to spend at this stop (minutes) │
│ priority │ Must-visit vs. nice-to-have │
│ hours │ Opening/closing times (if applicable) │
│ notes │ Parking, accessibility, booking required │
└──────────┴────────────────────────────────────────────┘
Separate fixed-order (hotel start/end) from reorderable.
→ Structured waypoint list w/ min name + address or coordinates each.
If err: ambiguous waypoint ("the castle") → WebSearch to resolve. Coordinates needed but only name → Step 2 geocoding.
Step 2: Geocode + Validate
Convert waypoints → lat/lon, verify reachable.
Geocoding Sources (in preference order):
1. Nominatim (OpenStreetMap) - free, no key required
https://nominatim.openstreetmap.org/search?q=QUERY&format=json
2. Overpass API - for POI-type queries
https://overpass-api.de/api/interpreter
3. Manual coordinates from mapping services
Per waypoint:
- Query geocoding service w/ address or name
- Verify returned coords in expected region
- Multiple results → disambiguate (pick correct)
- Store coords w/ waypoint data
→ Every waypoint has valid lat/lon, all in plausible region (no continent outliers).
If err: no results → try alt spellings, add region/country qualifiers, search nearby landmarks. Remote area w/ poor OSM coverage → WebSearch travel blogs/tourism sites.
Step 3: Optimize Route Order
Visit sequence → min total travel time/distance.
Optimization Strategies:
┌─────────────────────┬────────────────────────────────────────┐
│ Strategy │ When to use │
├─────────────────────┼────────────────────────────────────────┤
│ Fixed order │ Stops must be visited in given sequence│
│ Nearest neighbor │ Quick approximation for 5-15 stops │
│ TSP solver │ Optimal ordering for any number │
│ Time-window aware │ Stops have opening hours constraints │
│ Cluster-then-route │ Stops span multiple days/regions │
└─────────────────────┴────────────────────────────────────────┘
Nearest-neighbor heuristic:
- Start at origin
- From current pos, pick unvisited closest by travel time
- Move + mark visited
- Repeat until all visited
- Return to end (if round trip)
Multi-day → cluster by geo proximity first, then optimize within day.
→ Ordered waypoint sequence, no excessive backtracking. Total distance within 20% of theoretical optimum for <10 stops.
If err: nearest-neighbor obvious backtracking (later stops closer to earlier) → reverse route or 2-opt: swap pairs, keep if shortens. Time-window constraints → verify arrival w/in opening hours.
Step 4: Calc Times + Distances
Compute travel time + distance per leg.
Time Estimation Methods:
┌──────────────┬────────────┬────────────────────────────────┐
│ Mode │ Avg Speed │ Notes │
├──────────────┼────────────┼────────────────────────────────┤
│ Highway │ 100 km/h │ Varies by country/road type │
│ Rural road │ 60 km/h │ Add 20% for winding roads │
│ City driving │ 30 km/h │ Add time for parking │
│ Walking │ 4.5 km/h │ Flat terrain; reduce for hills │
│ Cycling │ 15 km/h │ Touring pace with luggage │
│ Hiking │ 3-4 km/h │ Use Munter formula for accuracy│
└──────────────┴────────────┴────────────────────────────────┘
Per consecutive pair:
- Straight-line (haversine) distance baseline
- Detour factor (1.3 roads, 1.4 urban, 1.2 highways)
- Travel time from adjusted distance + mode speed
- Buffer: 10% driving, 15% transit
- Sum legs + dwell times → total tour duration
→ Time/distance matrix, running cumulative time covering travel + dwell. Total realistic (within available daylight for walking).
If err: estimates unrealistic (2 hrs for 10 km city drive) → check detour factor. Mountain roads → 1.6-2.0. Transit → WebSearch actual timetables.
Step 5: Generate Itinerary w/ POIs
Compile route → complete itinerary w/ discovered POIs.
POI Discovery (Overpass API query pattern):
[out:json];
(
node["tourism"="viewpoint"](around:RADIUS,LAT,LON);
node["amenity"="restaurant"](around:RADIUS,LAT,LON);
node["amenity"="cafe"](around:RADIUS,LAT,LON);
);
out body;
Recommended search radius:
- Along route corridor: 500 m for walking, 2 km for driving
- At waypoints: 1 km radius
Build itinerary doc:
- Header: tour name, dates, total distance, total time
- Per day (multi-day):
- Day summary (start, end, total km, hrs)
- Per leg: departure, mode, distance, duration
- Per stop: arrival, dwell, desc, nearby POIs
- Logistics: parking, fuel, rest, emergency contacts
- Map ref (link to OSM or GPX export)
→ Complete time-budgeted itinerary w/ realistic schedules, POI suggestions, practical logistics.
If err: POI queries → too many → filter by rating/relevance. Itinerary exceeds time → mark low-pri optional or add days. No POIs in remote → note + suggest local research on arrival.
Check
- All waypoints geocoded w/ valid coords
- Route order min backtracking
- Travel times realistic for mode
- Dwell times accounted
- Total tour duration fits time window
- POIs relevant + near route
- Opening hours of time-sensitive stops respected
- Itinerary has practical logistics (parking, fuel, rest)
Traps
- Ignore opening hours: Optimize only by distance → arrive after museum closes. Check time-window constraints.
- Underestimate urban: City driving + parking → double expected time. Add buffers for urban stops.
- Over-pack itinerary: Every minute filled → no room for delays/spontaneous. Build 30-60 min slack per half-day.
- Straight-line fallacy: Haversine severely underestimates road distance, especially mountainous/coastal. Always apply detour factor.
- Forget return logistics: One-way routes → plan for rental return, train, pickup.
- Seasonal closures: Mountain passes, ferries, scenic routes → seasonal closures. Verify access dates.
→
create-spatial-visualization— render planned route on interactive mapgenerate-tour-report— compile itinerary → formatted Quarto reportplan-hiking-tour— specialized planning for hiking segmentsassess-trail-conditions— check conditions for walking/hiking legs
GitHub Repository
Verwandte Skills
llamaguard
AndereLlamaGuard ist Metas 7-8B-Parameter-Modell zur Moderation von LLM-Eingaben und -Ausgaben in sechs Sicherheitskategorien wie Gewalt und Hassrede. Es bietet eine Genauigkeit von 94-95 % und kann mit vLLM, Hugging Face oder Amazon SageMaker eingesetzt werden. Nutzen Sie diese Skill, um Inhaltsfilterung und Sicherheitsguardrails einfach in Ihre KI-Anwendungen zu integrieren.
cost-optimization
AndereDiese Claude Skill unterstützt Entwickler bei der Optimierung von Cloud-Kosten durch Ressourcen-Dimensionierung, Tagging-Strategien und Ausgabenanalysen. Sie bietet einen Rahmen zur Senkung von Cloud-Ausgaben und zur Implementierung von Kosten-Governance für AWS, Azure und GCP. Nutzen Sie sie, wenn Sie Infrastrukturkosten analysieren, Ressourcen richtig dimensionieren oder Budgetvorgaben einhalten müssen.
quantizing-models-bitsandbytes
AndereDiese Fähigkeit quantisiert LLMs auf 8-Bit- oder 4-Bit-Präzision mittels bitsandbytes und erreicht dabei eine Speicherreduzierung von 50–75 % bei minimalem Genauigkeitsverlust. Sie ist ideal für den Betrieb größerer Modelle mit begrenztem GPU-Speicher oder zur Beschleunigung von Inferenzvorgängen und unterstützt Formate wie INT8, NF4 und FP4. Die Fähigkeit integriert sich in HuggingFace Transformers und ermöglicht QLoRA-Training sowie 8-Bit-Optimierer.
dispatching-parallel-agents
AndereDiese Claude-Fähigkeit verteilt mehrere Agenten, um drei oder mehr unabhängige Probleme gleichzeitig zu untersuchen und zu beheben. Sie ist für Szenarien konzipiert, die unabhängige Fehler umfassen, die ohne gemeinsamen Zustand oder Abhängigkeiten gelöst werden können. Die Kernfähigkeit ist die parallele Problemlösung, bei der pro unabhängigem Problembereich ein Agent zugewiesen wird, um die Effizienz zu maximieren.
