skills/plan-with-zuzli/references/live-trip-mode.md

# Live trip mode

## Establish the live state

1. Determine the current date and time in the trip's IANA timezone, not the user's home timezone.
2. Read the latest matching trip from Zuzli.
3. Select the day whose date matches locally. If none matches, explain whether the trip is upcoming or finished.
4. Read `progress` from `get_trip` and separate completed, skipped, and remaining main-chain stops from its recorded stop IDs. Never mark or infer an outcome from the clock alone.
5. Identify the current location from the user's statement, app progress, or last confirmed stop. Ask one short question if it is ambiguous.
6. Calculate the next stop, intended travel mode, current travel estimate, venue timing, and the next hard deadline.

## Give an action-first response

Lead with the recommendation. A useful live response usually contains:

- **Now:** current or just-completed stop and current local time.
- **Next:** exact destination, how to get there, and when to leave or arrive.
- **Constraint:** closing time, booking, queue risk, weather, meal need, or hard deadline.
- **Adjustment:** what changes if the user is delayed, hungry, tired, or wants something different.

Keep it compact. The user is moving, possibly with children or luggage.

Sound present and reassuring, not operational or robotic. Acknowledge the real situation in one natural phrase, then give the next move. Do not announce that progress was written, validated, synchronized, or read back; say only that Zuzli is updated and what the traveller should do now.

## Replan under pressure

When the user reports a delay, closure, queue, fatigue, weather change, early hunger, or a new preference:

1. Read the current trip again.
2. Protect airport, train, ticket, reservation, and other hard deadlines.
3. Check live availability for the affected venue and immediate alternatives.
4. Prefer an alternative already on or near the route.
5. Remove backtracking and recalculate downstream travel and visit times.
6. Preserve the most distinctive experiences and the group's meal and rest needs.
7. Recommend one revised plan and optionally one clearly different fallback.
8. After approval, update Zuzli, read back the route, and state the new next action.

Do not merely move every remaining stop later. Shorten, skip, reorder, or change transport when necessary to keep the day feasible.

## Interpret common live requests

- “We finished here”: use `mark_stop_completed` for the named or unambiguous current stop, read progress back silently, then respond naturally and state the next move.
- “We skipped it”: use `mark_stop_skipped`, read progress back silently, acknowledge without judgment, and replan from the next actual location. Skipping records the outcome; it does not by itself remove the stop from the itinerary.
- “We are hungry now”: find a verified suitable meal near the current route, protect later deadlines, and insert or replace the meal only after the choice is accepted.
- “We are running an hour late”: calculate what no longer fits; recommend explicit cuts or faster transport.
- “Is everything done today?”: count recorded completed, skipped, and remaining main-chain stops; distinguish optional or fallback branches.
- “What should we still do?”: rank remaining stops by distinctiveness, feasibility, route fit, and fixed commitments.
- “Take us back to the hotel/airport”: prioritize the real endpoint, exact terminal or entrance, luggage actions, buffer, and current transport disruption status.

## Reinforce live-use habits

At useful moments, remind the user to mark a stop done as they leave it, mark skipped stops promptly, and message ChatGPT as soon as reality changes. Avoid repetitive onboarding; one timely sentence is enough.