plan-tour-route
정보
이 스킬은 경유지에 지오코딩을 적용하고, 최단 인접 알고리즘 등을 통해 순서를 최적화하며, 시간/거리 매트릭스를 계산하여 다중 정점 관광 경로를 계획하고 최적화합니다. OpenStreetMap을 통해 관심 지점(POI)을 탐색하며, 운전, 도보, 대중교통 옵션을 비교할 수 있습니다. 로드트립이나 도보 관광에 활용하여 이동 시간을 최소화하고 방문 순서를 최적화하며, 주변 장소를 추가하여 일정을 풍부하게 만드세요.
빠른 설치
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-routeClaude 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는 폭력 및 혐오 발언 등 6가지 안전 범주에서 LLM 입력과 출력을 조정하기 위한 Meta의 70-80억 파라미터 모델입니다. 94-95% 정확도를 제공하며 vLLM, Hugging Face 또는 Amazon SageMaker를 사용해 배포할 수 있습니다. 이 기술을 사용하여 AI 애플리케이션에 콘텐츠 필터링 및 안전 가드레일을 손쉽게 통합하세요.
cost-optimization
기타이 Claude Skill은 리소스 적정화, 태깅 전략, 지출 분석을 통해 개발자들이 클라우드 비용을 최적화할 수 있도록 지원합니다. AWS, Azure, GCP에서 클라우드 비용을 절감하고 비용 거버넌스를 구현하기 위한 프레임워크를 제공합니다. 인프라 비용을 분석하거나, 리소스를 적정화하거나, 예산 제약을 충족해야 할 때 사용하세요.
quantizing-models-bitsandbytes
기타이 스킬은 bitsandbytes를 사용하여 LLM을 8비트 또는 4비트 정밀도로 양자화하며, 최소한의 정확도 손실로 50-75%의 메모리 감소를 달성합니다. 제한된 GPU 메모리에서 더 큰 모델을 실행하거나 추론을 가속화하는 데 이상적이며, INT8, NF4, FP4와 같은 형식을 지원합니다. 이 스킬은 HuggingFace Transformers와 통합되어 QLoRA 학습 및 8비트 옵티마이저를 가능하게 합니다.
dispatching-parallel-agents
기타이 Claude Skill은 3개 이상의 독립적인 문제를 동시에 조사하고 해결하기 위해 다중 에이전트를 배치합니다. 공유 상태나 의존성 없이 해결 가능한 무관련 장애 시나리오에 맞게 설계되었습니다. 핵심 기능은 병렬 문제 해결로, 각 독립 문제 영역마다 하나의 에이전트를 할당하여 효율성을 극대화합니다.
