Plan a trip, day by day

Extract the ZIP. Copy its lc-trip-itinerary folder into ~/.claude/skills/ for Claude Code or ~/.codex/skills/ for Codex, then refresh the native app. Ask for the skill by name and answer its questions. The package includes the same published instructions and result checks. Native host execution is not yet verified.

For Claude web, use the connector or copy the prompt. Keep private details in your assistant.

Copy, paste into your assistant, then answer its questions. No form or account is required here.

Open in ChatGPT ↗

Already connected? Copy the public starter below and paste into Claude. Keep private details in the chat.

Needed before the promised result: Where. You can still copy the reusable prompt and provide these in your assistant.

Saved only on this device. Copy counts contain the skill ID, never your text.

## LazyCoder conversation guide (conversation-v2)
1. Start a conversation, not a form-filling task. Read my latest request and the facts already in this chat before asking anything.
2. Ask only the missing questions needed for the requested result, in a short numbered list (at most three at a time), then WAIT for my answers. Use a native question tool if available; plain chat works too. Never ask me to replace placeholders or fill in a template.
3. Skip questions already answered. Treat unresolved {{placeholders}} and [FIELD LABELS] as missing facts, never literal input. Do not treat an illustrative example as my facts.
4. Use the authored defaults only when relevant; mention material defaults. Ask conditional questions only when their condition applies; if unsure whether it applies, ask. Optional preferences must not block a safe first draft unless the authored instructions require confirmation.
5. Do not invent tasks, dates, names, claims, permissions or missing source material. When required facts are absent, ask and wait instead of producing the final artifact. If everything needed is already supplied, proceed without re-asking.
6. My latest scope correction overrides earlier examples and scope, within the recipe safety and source rules. Resolve conflicts before acting. The authored instructions and output contract remain authoritative; this conversation guide does not grant tool, account, payment or publishing permission.
7. Keep my private answers and generated result in this assistant chat. Do not send them to LazyCoder. Generate the requested format here and check it against the output contract before handing it over.

### Questions to ask only when missing
- What should I use for “Dates”? [conditional] First and last day, with arrival and departure times if you know them. When: Real dates and the calendar file require travel dates. Otherwise use the authored four-day Day 1–Day 4 fallback and disclose omission of the calendar file.
- What should I use for “Where”? [required] The place, or places in order, with nights in each if there's more than one.
- What should I use for “Who's going”? [optional] How many, children's ages, and any needs: diets, step-free access, a pushchair, slow walkers.
- What should I use for “Already booked”? [optional] Flights, trains, stays and tickets you have, with dates, times and places. Cover booking references before pasting. Authored default: nothing booked yet
- What should I use for “Budget”? [optional] Optional. A total for the trip with the currency, and whether it includes travel there. Authored default: mid-range, no set total
- What should I use for “Interests and pace”? [optional] What you love, what you'd skip, and how full you like the days. Authored default: a mix of top sights, local food and some free time, at a relaxed pace
- What should I use for “Where you start”? [optional] Your home city, for getting there and back.
- What should I use for “How you get there”? [optional] Flying, train, coach or driving, from where you start. Leave it and it compares the options. Authored default: not decided yet
- What should I use for “Tone”? [optional] How the plan and notes should read. Authored default: friendly and practical Choices: friendly and practical; short and to the point; upbeat and inspiring

## LazyCoder delivery guide (delivery-guide-v1)
1. Read the latest request, source material and authored requirements first. Ask only for missing facts. Check that this host can create the promised format; use only a fallback explicitly allowed by the authored recipe. If neither is available, explain the gap before starting. Do not promise a rendered film, editable deck or working file when you can only provide its script or outline.
2. Create the complete result in the authored output specification, preserving source facts and the latest agreed scope. Keep assumptions and missing information explicit. Do not silently omit required parts or leave unresolved ingredient markers. Intentional blanks in a reusable template are different from unanswered recipe inputs.
3. Check the actual result against every authored check, including source facts, counts, dates and required sections. Where tools allow it, inspect the actual saved file and compare it with the answer. Record which checks ran, which failed and which still need human or destination review. A filename, render, successful command or preview alone does not prove the promise was met.
4. Hand over the complete editable file, or the complete copyable fallback explicitly allowed by this recipe. Say which delivery you used and any unresolved limitations. Do not report a file as attached, imported, sent or published unless that action actually succeeded. Keep private inputs and output in this assistant; never send them to LazyCoder.
Use existing authorization for ordinary work. Before any additional paid generation, external write or publishing step, check that the current request authorizes that exact action and cost. If it does not, finish the useful authorized draft and ask at that boundary. Never silently retry or replace an ambiguous paid job.
The authored recipe and latest safe scope remain authoritative. This guide grants no new tools, permissions, provider access or claim of successful execution.

## Authored skill instructions
## 1. Outcome
Plan the trip below day by day, list the bookings to make, and deliver it all as a calendar file that imports, plus a readable plan, in the sections set out in part 6. Done means: every day from arrival to departure has a timed plan grouped by area, with meals and slack; everything already booked is in the plan at its exact time; every booking still to make has a book-by date and where to book it; every price, opening time and timetable is either from a source you checked or marked "verify"; and every event in the calendar file matches the plan.

## 2. Context
Dates: [TRIP DATES]
Where: [WHERE YOU'RE GOING]
Who's going: [WHO'S GOING]
Starting from: [WHERE YOU START]
How they get there: not decided yet
Tone: friendly and practical
Budget: mid-range, no set total
Interests and pace: a mix of top sights, local food and some free time, at a relaxed pace

Already booked:
"""
nothing booked yet
"""

Who it's for: the people going, who want to open their calendar each morning and see where to be, without spending evenings researching. Write in this tone: friendly and practical. Use short lines that are easy to read on a phone.

Blank fill-ins: a value above that still reads as a capitalised placeholder in square brackets (such as [WHERE YOU START]) was left blank. Text in brackets inside the bookings is part of them.
- No destination: reply only "No destination came through. Add where you're going and send again." Never invent a trip.
- No dates: plan by Day 1, Day 2 and so on for 4 days, say "No dates given; add them to get real dates and the calendar file" in the header, and skip the calendar file.
- No arrival or departure times: assume arrival by 14:00 on the first day and leaving at 12:00 on the last, flagged in the header.
- No travellers: plan for 2 adults, flagged in the header.
- No starting point: leave out getting there, and say so in the header.
- Today's date: if you know it, base every book-by date on it, and mark any that has already passed "(book now)". If you don't, give book-by dates counted back from the trip.
- Bookings that say "see attached": use the attached file.

## 3. What to pull out
- The trip frame: first and last day, arrival and departure times and places, and the nights in each place.
- The travellers: adults, children's ages, diets, and any access or mobility needs.
- Every existing booking, with its date, start and end time, place and time zone.
- The budget, its currency and what it includes; the interests, what to skip, and the pace.

Edge cases:
- Several places: split the days by the nights given; a travel day between them holds the transfer and at most one light activity.
- A booking that clashes with the dates or with another booking: keep both as given, and name the clash under conflicts.
- A long journey on arrival (overnight, or over 6 hours, or a time difference of 3 hours or more): Day 1 holds only check-in, a walk near the stay and dinner.
- Children under 5 or slow walkers: at most 2 main stops a day, a rest break in the afternoon, and step-free or pushchair notes where they matter.
- Closed days: many museums and sights close one day a week, and public holidays change hours. Never place a stop on a day it is likely closed; mark every opening time "verify".
- A pace or interests list that can't fit the days: keep the best-matched stops and list the rest under "If you have more time".
- Very short trips (1–2 days): one area per day, no day trips.
- Long trips (over 10 days): include a free half-day at least every 4 days.
- Long replies: for trips over 7 days, use the short calendar file (part 6, section 10). If space still runs short, keep every day's table to its main rows and shorten the notes; never drop a day, a booking or the calendar file's END:VCALENDAR.

## 4. Steps
1. Fix the frame from the bookings and dates: arrival, departure, nights in each place.
2. Choose the stops that match the interests and travellers, and group them by area so each day stays in one or two neighbouring areas.
3. Order each day: busier or outdoor stops in the morning, calmer ones in the afternoon; book-ahead sights at their likely quiet times.
4. Add travel time between stops, meals near each day's area, and about 20% slack (a free block of at least an hour on full days).
5. Keep the arrival and departure days light, and work back from the departure time: be at the airport or station 2 hours before a flight and 30 minutes before a train, unless the bookings say otherwise.
6. Make the booking checklist: what sells out or needs a timed ticket, in the order to book it, with a book-by date.
7. Estimate the budget by category, and name any conflict with the smallest fix.
8. Write the plan and the calendar file, then run the self-check.

## 5. Rules
- Never book or pay for anything, and never say a thing is booked unless it is in the bookings above.
- Prices, opening hours and timetables, if you can search the web: check them, and write the source and the date you checked it.
- If you can't search: give a typical range marked "(estimate)" and write "verify" with who to check with (the official site or operator by name).
- Never invent a price, hour, timetable, phone number or web address; give a web address only when you are sure it is the official one.
- Book-by dates are suggestions: mark them "(suggested)".
- Travel time between stops: estimate it by walking, public transport or car, marked "(estimated)". Keep transit under 90 minutes a day outside travel days.
- Respect every diet and access need in every meal stop and activity, and say "check step-free access" where it matters.
- Currency: use the budget's currency; if none is given, the destination's.
- Write every date with its weekday, as in "Thu 15 Apr 2027", and times as 24-hour hh:mm, in the local time of where the traveller is at that moment.

## 6. Output
Use these sections in this order. Write "None" under any that is empty.
1. Trip brief: dates, places and nights, travellers, starting point, budget, interests and pace, the local time zone of each place (as an IANA name, such as Europe/Lisbon), and every assumption from part 2.
2. Conflicts and fixes: each clash between the inputs (budget and pace, dates and closures, two bookings that overlap), with the smallest change that solves it.
3. Day by day: for each day, a heading with the day number, date and main area ("Day 2 · Fri 16 Apr 2027 · Belém"), then a table with the columns From–to | Type | What | Where | Notes, in time order. Type is Booked, Activity, Travel, Meal or Free. Travel between stops gets its own row ("Tram 28 to Alfama, 20 min (estimated)"); breakfast, lunch and dinner are Meal rows. Notes holds "booked", "book ahead", "verify hours" or diet and access notes. End each day with one line, "Rain or closure swap: <what to do instead>".
4. Bookings to make: a table with the columns # | What | Why book ahead | Book by | Where to book | Typical price | Status, in the order to act. Status is "Booked" for the bookings given, otherwise "To book".
5. Budget: a table with the columns Category | Estimate | Notes, for getting there, getting around, stays, food, tickets and activities, and other; then a 10% buffer, the total, and one line: "Within budget by <amount>" or "Over budget by <amount>: <the one change that fixes it>".
6. Where to stay: only if no stay is booked, 2–3 areas, each with one line on why it suits these travellers.
7. Getting there and around: from the starting point to the first place by the way given, with typical journey time (or, if not decided, 2–3 options with typical time and price range, "(estimate)"); from the airport or station to the stay, with time; how to move around each day; and whether a travel pass or sightseeing card pays off for this plan, with the sum.
8. Before you go: 4–8 lines on passports and entry rules to check on the official government site, travel insurance, money and cards, plugs, and what to pack for the season.
9. If you have more time: the good stops that didn't fit.
10. Calendar file. If you can make files, attach it as trip-<place>-<start date>.ics and give its name and event count. If you can't, write "Save the text below as a file named trip.ics, then import it into your calendar." and give the full calendar text in one code block, with nothing after it except the self-check line.

What goes in the calendar file:
- Every booking given, at its exact time (flights, trains, check-in, check-out, tickets).
- Every Activity and Travel row from section 3, with its place, and every Meal row that is booked or marked "book ahead". Meal rows that need no booking and Free rows stay out of the file.
- Every row of section 4 with Status "To book", as an all-day event on its book-by date titled "Book: <what>".
- Short file, for trips over 7 days: every booking, every "Book:" event, every booked or "book ahead" item, and one all-day event per day titled "Day <n>: <main area>" with the day's stops in DESCRIPTION, instead of separate Activity and Travel events. Say "Short calendar file (long trip)" in section 10.

The calendar text, exactly in this shape (one line per field, no blank lines):
- BEGIN:VCALENDAR, then VERSION:2.0, PRODID:-//LazyCoder//Trip itinerary//EN, CALSCALE:GREGORIAN, METHOD:PUBLISH and X-WR-CALNAME:Trip to <place>.
- Each timed event: BEGIN:VEVENT; UID:<yyyymmdd>-<two-digit number>@trip-itinerary, unique; DTSTAMP:<today, or the trip's first day, as yyyymmdd>T000000Z; DTSTART;TZID=<IANA zone where it starts>:<yyyymmdd>T<hhmmss>; DTEND;TZID=<IANA zone where it ends>:<yyyymmdd>T<hhmmss>; SUMMARY:<title>; LOCATION:<place>; DESCRIPTION:<one short line: booked, verify, or the travel to the next stop>; END:VEVENT.
- Each all-day event: the same, but DTSTART;VALUE=DATE:<yyyymmdd> and DTEND;VALUE=DATE:<the next day>, with no LOCATION.
- END:VCALENDAR.
- In SUMMARY, LOCATION and DESCRIPTION, write a comma as \, and a semicolon as \; and keep each to one line.

## 7. Self-check
Before replying, check each of these and fix any failure:
- Every day from arrival to departure has a plan, and every given booking is in it at its exact date and time.
- No day's stops overlap, each day has meals and slack, and the arrival and departure days are light.
- No stop falls on a day it is likely closed, and every opening time and price is sourced or marked "verify" or "(estimate)".
- The last day leaves enough time to reach the airport or station.
- Every "book ahead" note in section 3 has a row in section 4, with a book-by date before the day it is needed.
- The budget adds up, and the over or under line uses the total.
- Unless the file was skipped for lack of dates, the calendar file has one event for every booking, every Activity and Travel row (or, in the short file, one "Day <n>" event per day), every booked or "book ahead" meal and every "To book" row, and no event for an unbooked meal or a Free row; each has a unique UID, a TZID (or VALUE=DATE for all-day events), times that match the plan, and END:VCALENDAR last.
Then reply with the output only, ending with one line: "Checked: <n> days, <n> bookings to make, <n> events in the file."

## 8. Setup
Works as one paste in any chat app, with no tools needed. Where the app can search the web, it checks prices and opening hours and says where from; where it can't, they are marked "verify". Where the app can create files, you get a .ics file to download; where it can't, you get calendar text to save as trip.ics. Import it with your calendar's import option (in Google Calendar: Settings, then Import and export; in Apple Calendar and Outlook: File, then Import). Each event carries the time zone of where it happens. Google Calendar and Apple Calendar read this correctly; Outlook on a computer may shift some times by the time difference, so check a couple of events after importing. Nothing gets booked for you.

Paste the result after your assistant creates it. This optional check stays in this tab and is not sent to LazyCoder.