plan-tour-route
Acerca de
Esta habilidad planifica y optimiza rutas turísticas con múltiples paradas mediante la geocodificación de puntos de ruta, ordenándolos a través de algoritmos como el del vecino más cercano, y calculando matrices de tiempo/distancia. Descubre Puntos de Interés (POIs) a través de OpenStreetMap y puede comparar opciones de conducción, caminata o transporte público. Úsala para viajes por carretera o recorridos a pie con el fin de minimizar el tiempo de viaje, optimizar el orden de las visitas y enriquecer un itinerario con sitios cercanos.
Instalación rápida
Claude Code
Recomendadonpx 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-routeCopia y pega este comando en Claude Code para instalar esta habilidad
Documentación
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
Repositorio GitHub
Habilidades relacionadas
llamaguard
OtroLlamaGuard es el modelo de Meta de 7-8B parámetros para moderar las entradas y salidas de LLM en seis categorías de seguridad como violencia y discurso de odio. Ofrece una precisión del 94-95% y puede implementarse usando vLLM, Hugging Face o Amazon SageMaker. Utiliza esta skill para integrar fácilmente filtrado de contenido y barreras de seguridad en tus aplicaciones de IA.
cost-optimization
OtroEsta Skill de Claude ayuda a los desarrolladores a optimizar los costes en la nube mediante el ajuste de tamaño de recursos, estrategias de etiquetado y análisis de gastos. Proporciona un marco para reducir los gastos en la nube e implementar una gobernanza de costes en AWS, Azure y GCP. Úsala cuando necesites analizar los costes de infraestructura, ajustar el tamaño de los recursos o cumplir con restricciones presupuestarias.
quantizing-models-bitsandbytes
OtroEsta habilidad cuantiza LLMs a precisión de 8 o 4 bits utilizando bitsandbytes, logrando una reducción de memoria del 50-75% con pérdida mínima de precisión. Es ideal para ejecutar modelos más grandes en memoria GPU limitada o para acelerar la inferencia, admitiendo formatos como INT8, NF4 y FP4. La habilidad se integra con HuggingFace Transformers y permite entrenamiento QLoRA y optimizadores de 8 bits.
dispatching-parallel-agents
OtroEsta Skill de Claude despliega múltiples agentes para investigar y solucionar 3 o más problemas independientes de forma concurrente. Está diseñada para escenarios que involucran fallos no relacionados que pueden resolverse sin estado compartido o dependencias. Su capacidad principal es la resolución paralela de problemas, asignando un agente por cada dominio problemático independiente para maximizar la eficiencia.
