返回技能列表

plan-tour-route

pjt222
更新于 2 days ago
2 次查看
17
2
17
在 GitHub 上查看
其他api

关于

This skill plans and optimizes multi-stop tour routes by geocoding waypoints, ordering them via algorithms like nearest-neighbor, and calculating time/distance matrices. It discovers Points of Interest (POIs) via OpenStreetMap and can compare drive, walk, or transit options. Use it for road trips or walking tours to minimize travel time, optimize visit order, and enrich an itinerary with nearby sites.

快速安装

Claude Code

推荐
主要方式
npx skills add pjt222/agent-almanac -a claude-code
插件命令备选方式
/plugin add https://github.com/pjt222/agent-almanac
Git 克隆备选方式
git 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:

  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

GitHub 仓库

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

相关推荐技能

llamaguard

其他

LlamaGuard是Meta推出的7-8B参数内容审核模型,专门用于过滤LLM的输入和输出内容。它能检测六大安全风险类别(暴力/仇恨、性内容、武器、违禁品、自残、犯罪计划),准确率达94-95%。开发者可通过HuggingFace、vLLM或Sagemaker快速部署,并能与NeMo Guardrails集成实现自动化安全防护。

查看技能

cost-optimization

其他

这个Claude Skill帮助开发者优化云成本,通过资源调整、标记策略和预留实例来降低AWS、Azure和GCP的开支。它适用于减少云支出、分析基础设施成本或实施成本治理策略的场景。关键功能包括提供成本可视化、资源规模调整指导和定价模型优化建议。

查看技能

quantizing-models-bitsandbytes

其他

这个Skill使用bitsandbytes库量化大语言模型,能在GPU内存有限时通过8位或4位量化减少50-75%内存占用,同时保持精度损失最小。它支持INT8、NF4、FP4等多种量化格式,可与HuggingFace Transformers无缝集成,适用于需要部署更大模型或加速推理的场景。还提供QLoRA训练和8位优化器支持,让开发者能轻松实现高效模型压缩。

查看技能

dispatching-parallel-agents

其他

该Skill用于并行处理3个以上无依赖关系的独立故障,可为每个问题域分派专属Claude代理同时执行调查修复。它通过并发处理多个独立问题显著提升故障排查效率,特别适用于测试文件、子系统等无共享状态的场景。

查看技能