Commuting Plan Skill (Default Real-Time Verification + Executable + No Fabrication)

Strong Constraints (Must Comply)

• Default Real-Time Verification: As long as the user asks about routes/commuting, you must verify by default (especially for travel time/cost/transfers/first/last train times/walking distance).
  • The output must include as much as possible: source link + query time (local time) (or the release/update time marked on the source page; write "Source not marked" if unavailable).
• No Fabrication of Precise Figures: Do not provide specific figures like "x kilometers / x minutes / x yuan / only a few house numbers apart" without verification; you must mark it as "Experience-based estimate" and only give a wide range.
• Tool Invisibility: Only say "I checked/I verified" to users; do not mention tool names or implementation details.
• Explicit Confirmation Required for Calendar Entry: Only output the plan by default; create/update the schedule only after the user says "Confirm/Help me add to the calendar/Create a reminder based on this".

Clarify First (Maximum 2~3 Key Questions)

1. Starting Point and Destination (or list of points for multi-stop routing): Preferably provide "Name + City/Area", address is better
2. Departure/Arrival Time Window: For example, "Arrive before 8:30 tomorrow" "Depart at 19:00 tonight" (determines peak hours/nighttime)
3. Preference Priority (Choose 1): Save time / Save money / Less walking for comfort

Task Types

A) Point-to-Point (A → B)

• Public Transportation (Subway/Bus)
• Taxi/Ride-Hailing
• Walking/Cycling (When the distance is appropriate)

B) Multi-Stop Routing (A → B → C → …)

1. First ask/infer the "time constraints" for each point (must arrive by a certain time/duration of visit/whether reservation is required)
2. First do a "regional clustering": Group nearby areas into the same day or same time period
3. Output two versions:
   • Relaxed Version: Fewer transfers, buffer time reserved, each segment as simple as possible
   • Speed Version: More compact, faster, but clearly state the risk points

Verification and Expression Specifications (Default Execution)

• Transfer station/route suggestions
• Estimated travel time (especially for "shortest/fastest/rush")
• Estimated cost (price range for taxi/ride-hailing, bus/subway fares/billing)
• Availability of first/last train/night transportation (if involved)

• Separate "Verified" and "To be confirmed" content; do not pretend to be certain with words like "I think/should/probably".

Output Format (Fixed Markdown Structure, Short and Useful)

1. A concluding paragraph: Recommend which one to choose (based on user preferences and time constraints)

2. ## Plan Comparison

   : Use a table (Mode | Estimated Time | Estimated Cost | Suitable For | Risk Points | Source)

3. ## My Recommendation (With Reasons)

   : 2~4 sentences

4. ## Departure Time Suggestion

   : Provide "Departure time + buffer"

5. ## Sources

   : List links collectively + local time/query time

Calendar Entry (Explicit Confirmation Required)

• It is recommended to create each commuting segment as an event:

  Commute｜A → B

• Write the meeting point, backup plan, and source link (if available) in the description
• Use "local time of the trip" for the event time; mark the time zone in the description when crossing time zones

Reference Sources (Mainly Domestic, Load On Demand)

references/sources_cn.md