plan-tour-route
О программе
Этот навык планирует и оптимизирует маршруты с несколькими остановками путем геокодирования путевых точек, их упорядочивания с помощью алгоритмов (например, "ближайшего соседа") и расчета матриц времени/расстояния. Он находит достопримечательности (POI) через OpenStreetMap и может сравнивать варианты поездки на автомобиле, пешком или на общественном транспорте. Используйте его для автопутешествий или пеших экскурсий, чтобы минимизировать время в пути, оптимизировать порядок посещения и обогатить маршрут близлежащими объектами.
Быстрая установка
Claude Code
Рекомендуетсяnpx 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-routeСкопируйте и вставьте эту команду в Claude Code для установки этого навыка
Документация
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 репозиторий
Похожие навыки
llamaguard
ДругоеLlamaGuard — это модель от Meta с 7–8 миллиардами параметров для модерации входных и выходных данных больших языковых моделей по шести категориям безопасности, таким как насилие и разжигание ненависти. Она обеспечивает точность 94–95% и может быть развернута с помощью vLLM, Hugging Face или Amazon SageMaker. Используйте этот навык, чтобы легко интегрировать фильтрацию контента и защитные механизмы в ваши ИИ-приложения.
cost-optimization
ДругоеЭтот навык Claude помогает разработчикам оптимизировать облачные расходы за счет правильного подбора ресурсов, стратегий тегирования и анализа затрат. Он предоставляет framework для сокращения облачных расходов и внедрения управления затратами в AWS, Azure и GCP. Используйте его, когда вам нужно проанализировать расходы на инфраструктуру, оптимизировать ресурсы или уложиться в бюджетные ограничения.
quantizing-models-bitsandbytes
ДругоеЭтот навык выполняет квантизацию LLM до 8-битной или 4-битной точности с использованием библиотеки bitsandbytes, обеспечивая сокращение использования памяти на 50-75% при минимальной потере точности. Он идеально подходит для запуска больших моделей при ограниченной памяти GPU или для ускорения вывода, поддерживая форматы INT8, NF4 и FP4. Навык интегрируется с HuggingFace Transformers и позволяет использовать обучение QLoRA и 8-битные оптимизаторы.
dispatching-parallel-agents
ДругоеЭтот навык Claude распределяет нескольких агентов для исследования и устранения трёх и более независимых проблем параллельно. Он предназначен для сценариев с несвязанными сбоями, которые можно устранить без общего состояния или зависимостей. Ключевая возможность — параллельное решение проблем, где за каждую независимую предметную область назначается отдельный агент для максимальной эффективности.
