MCP HubMCP Hub
Volver a habilidades

plan-tour-route

pjt222
Actualizado Yesterday
1 vistas
17
2
17
Ver en GitHub
Otroapi

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

Recomendado
Principal
npx skills add pjt222/agent-almanac -a claude-code
Comando PluginAlternativo
/plugin add https://github.com/pjt222/agent-almanac
Git CloneAlternativo
git clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/plan-tour-route

Copia 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:

  1. Query geocoding service w/ address or name
  2. Verify returned coords in expected region
  3. Multiple results → disambiguate (pick correct)
  4. 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:

  1. Start at origin
  2. From current pos, pick unvisited closest by travel time
  3. Move + mark visited
  4. Repeat until all visited
  5. 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:

  1. Straight-line (haversine) distance baseline
  2. Detour factor (1.3 roads, 1.4 urban, 1.2 highways)
  3. Travel time from adjusted distance + mode speed
  4. Buffer: 10% driving, 15% transit
  5. 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:

  1. Header: tour name, dates, total distance, total time
  2. Per day (multi-day):
    • Day summary (start, end, total km, hrs)
    • Per leg: departure, mode, distance, duration
    • Per stop: arrival, dwell, desc, nearby POIs
  3. Logistics: parking, fuel, rest, emergency contacts
  4. 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 map
  • generate-tour-report — compile itinerary → formatted Quarto report
  • plan-hiking-tour — specialized planning for hiking segments
  • assess-trail-conditions — check conditions for walking/hiking legs

Repositorio GitHub

pjt222/agent-almanac
Ruta: i18n/caveman-ultra/skills/plan-tour-route
0
agentsagentskillsai-assisted-developmentclaude-codeskillsteams

Habilidades relacionadas

llamaguard

Otro

LlamaGuard 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.

Ver habilidad

cost-optimization

Otro

Esta 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.

Ver habilidad

quantizing-models-bitsandbytes

Otro

Esta 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.

Ver habilidad

dispatching-parallel-agents

Otro

Esta 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.

Ver habilidad