One Anchor Per Day, Room to Breathe: Itinerary Design With AI
WEEK 96 :: POST 3 :: CLAUDE
Directions Given To The A.I. This Week+
Instructions Given to each A.I. — Please provide 3 prompt variations that share this objective:
Each A.I. also received two static attachments: the blog post template (structure) and the authoring instructions (voice and standards). The text below is the week-specific assignment as sent — reflowed for the web; wording unchanged.
I'd like you to write this week's Ketelsen.ai post. Two files are attached: the blog post template (the structure to follow) and the authoring instructions (context, voice, and standards). Please read both before you begin, then produce the complete post in a single response.
This week's theme: "Building the Itinerary That Doesn't Break" — Day-by-Day Design and Pacing.
This is Week 5 of an eight-week series on planning a vacation with AI. By now the reader has a budget ceiling (Week 1), a destination (Week 2), booked flights that fix the dates and arrival time (Week 3), and a place to stay whose location is now known (Week 4). This week they turn a list of things they want to do into a day-by-day plan that survives contact with a real trip.
Most itineraries fail the same three ways, and none of them are about picking the wrong attractions. They fail from over-scheduling — cramming a day so full that one late lunch collapses everything after it; from geographic ping-ponging — crossing the city four times because the plan was built by interest rather than by map; and from ignoring the calendar — arriving to find the museum closed on Mondays and the one restaurant they cared about booked out for three weeks. The job this week is a plan built around how days actually go, not how they look on paper.
The deliverable the reader should walk away holding is a day-by-day itinerary they can defend: activities clustered so each day stays in one part of the map, a realistic pace, a booking-deadline calendar sorted by how far ahead each thing must be reserved, and a backup for the days most likely to fall apart.
The three prompts should help a reader work through:
- Clustering by geography, not by interest. Grouping the things they want to do by where they are, so a day moves through one neighbourhood or district instead of doubling back across town. The AI is good at taking a list of places plus the reader's lodging location and proposing sensible clusters — as long as the reader supplies the places and the rough map.
- Pacing with an anchor-and-flex rhythm. One committed thing per day — the anchor — with everything else held loosely as optional. This is the antidote to over-scheduling: a day with a single non-negotiable and a menu of maybes bends instead of breaking when something runs long. Building in a deliberate zero day — a day with nothing planned — belongs here too.
- Reservation lead-time intelligence. Which kinds of things book out far in advance and which can be decided the morning of, turned into a calendar sorted by book-by date so nothing is lost to a deadline the reader never saw. The AI supplies the pattern — that certain restaurants, timed-entry museums, and marquee experiences typically need booking well ahead — while the reader confirms the actual dates against live booking pages.
At the advanced tier, the strongest version of this week is a structured day-by-day plan with pacing rules made explicit: each day an anchor plus ranked optionals, transit time between clustered stops accounted for, a backup option per day, and a reservations-deadline calendar the reader can act on. That is the structure worth reaching for.
A hard constraint, carried forward from Weeks 3 and 4 and just as binding here. AI models cannot see live opening hours, this season's closure days, current reservation availability, or today's transit schedules — and their recall of a specific venue's hours is stale and frequently wrong. No prompt in this post may ask the AI to state a specific attraction's opening hours, claim a particular restaurant is bookable on a given date, or assert current transit times as fact. A confidently wrong opening time sends the reader across the city to a locked door. Prompts should have the AI produce what to verify and where — the questions to ask, the pages to check, the buffers to leave — rather than deliver a schedule stated as certain.
Design the prompts so the AI does what it is genuinely good at: organising a messy wish-list into a coherent map-aware sequence, enforcing a sane pace, and naming what must be booked ahead. The reader supplies the wish-list, the lodging location, and the confirmed hours; the AI supplies the structure and the sequencing. Posts that have the AI invent hours or availability should expect to be marked down on Practical Utility, exactly as in Weeks 3 and 4.
Series dependency chain, for the Metadata block: Week 5 consumes the booked lodging and its location from Week 4 (the itinerary is built outward from where the reader wakes up each morning), the confirmed dates from Week 3, the destination from Week 2, and the budget ceiling from Week 1. Week 5 produces the day-by-day plan and its reservation calendar, which Week 6's logistics-and-protection audit and Week 7's in-trip prompts both assume as the shape of the trip they are protecting and running.
Because readers may arrive at this post without having read Weeks 1 to 4, the prompts should work for someone who knows their destination, dates, lodging area, and a rough list of what they want to do, while making clear they get far more from them with a real constraint profile and confirmed bookings in hand.
Three difficulty tiers as always — Beginner, Intermediate, Advanced — each a genuinely different approach to the same problem, not the same prompt at three lengths.
On examples: this is a consumer travel topic. The template lists tech startup / retail / freelance as suggested industry examples — those are marked MAY, and this week you should almost certainly adapt them. Families pacing a trip around nap times and young children, couples balancing one person's museum day against the other's beach day, a group trying to share a plan without a dozen group-chat threads, and older travellers for whom walking distance between stops decides the day are the right contexts here. Choosing them over the suggested business examples is correct behaviour and will not be scored against you.
A note on supplied figures. Anything marked `[SUPPLIED — use as given]` above came from Ketelsen.ai's own research brief. Use it freely — you are not fabricating by repeating it, and you will not be marked down for leaving it uncited. Do not attach an invented source to it. (No supplied figures this week. Given the live-hours-and-availability constraint above, this is a bad week to invent any — if you find yourself reaching for a venue's opening hours or how far ahead a restaurant books, that is the signal to restructure the prompt so the reader supplies the real detail instead.)
## BEFORE YOU SUBMIT — STRUCTURAL CHECK
(This block is identical every week. It exists because these specific items are the ones posts drop, and a dropped structural item costs compliance points for something that takes one minute to add.)
Your post is parsed by a script before any human reads it. Confirm all seven:
1. ☐ Response begins with `PLATFORM: <your name>` and `WEEK: 5` 2. ☐ `## Lead` present once, at the very top, before Variation 1 3. ☐ `## In one line` present in all three variations 4. ☐ `## What this prompt gives you` present in all three variations 5. ☐ `## The Prompt` present in all three variations, with the prompt in double quotes beneath it 6. ☐ `## Introductory Hook` and `## Current Use` present in all three variations (three of each — not one) 7. ☐ Every template heading written as `##`, none bolded instead; prompt breakdown is running text split on ` : `, with no `###` headings inside it
A complete post has 57 `##` headings. If your count is well short, a section is missing or was bolded instead of hashed.
One extra check this week: confirm no prompt asks the AI to state a specific venue's opening hours, closure days, or current reservation availability, or to present a transit time as fact. Those must be things the reader goes and verifies.
Most vacation itineraries don't fail because someone picked the wrong museum. They fail because a day was packed too tight, because it was built by interest instead of by map, or because it hung on an opening time nobody checked. This week's three prompts attack that at three depths: a beginner prompt that gives every day one anchor and room to breathe, an intermediate prompt that clusters your wish list geographically before it assigns a single day, and an advanced four-pass prompt that builds the plan, attacks it, repairs it, and hands you a booking calendar sorted by deadline. If you have a destination, dates, and a rough list of things you want to do, all three work right now.
The One-Anchor Day
Turn a messy wish list into days that bend, not break.
There is a specific moment every over-planned trip contains. It is 2:40 in the afternoon, lunch ran long, the queue was worse than expected, and you are standing on a street corner doing arithmetic about whether you can still make the 4:00 thing — and the answer is no, which means the 6:00 thing is also gone, which means the dinner you were quietly looking forward to is now a rushed plate eaten while checking a phone. Nothing went wrong. One thing ran long. The plan simply had no slack in it, and a plan with no slack does not degrade gracefully; it collapses. This prompt builds the slack in from the start, before you have anything to defend.
Why this matters now
You are somewhere between "I have a list" and "I have a plan," and that gap is where most people either freeze or over-commit. Booking windows are already closing on the things that need booking, and every day you spend deciding is a day of options quietly disappearing. This prompt takes ten minutes and gives you a shape you can react to — which is far easier than producing a shape from nothing. Even if you change half of it, you will change it faster than you would have built it, and you will have a written list of what still needs checking.
I'm planning a trip to [DESTINATION] from [START DATE] to [END DATE]. I'll be staying in or near [NEIGHBOURHOOD OR AREA]. Here is everything I'd like to do, in no particular order: [LIST EVERYTHING — attractions, restaurants, neighbourhoods, day trips, activities, however messy].
Turn this into a day-by-day plan using these rules:
1. Give each day exactly one anchor — the single thing I'd be genuinely disappointed to miss — plus no more than two optional extras nearby that I could drop without ruining the day.
2. Keep each day in one part of the city or region. Don't send me back and forth across town on the same day.
3. Leave one day with no anchor at all and mark it as a rest day.
4. Put anything that depends on good weather early in the trip, so I have room to move it.
5. Keep the arrival day and the departure day deliberately light.
Two things you must not do. Do not tell me opening hours, closure days, or whether something can be booked on a particular date — you can't see live information, and a confidently wrong opening time sends me across the city to a locked door. Do not state travel times between places as fact.
Instead, finish with a short list titled 'Check before you go' naming every item I need to confirm myself and where I should look for it.
How the AI reads this prompt
Practical examples from different industries
A family with a four-year-old, five days in Barcelona.
The input is a wish list assembled from three months of half-remembered recommendations: Sagrada Família, the aquarium, a beach, a food market, two parks, a cable car. The output gives each day one anchor and stops — and because the parents added "our daughter naps from one to three" to the list, the anchors land in the morning with the optionals sitting after the nap window. The value here is not the plan itself but the arithmetic it makes visible: six wants, five days, one of which is a rest day, means two things get cut. Better to cut them at the kitchen table than at 2:40 on a street corner with a tired child.
Two friends with a long weekend and a folder of saved posts.
They have forty-one saved items and three days, which is not a planning problem so much as a triage problem. Pasting the whole folder in and asking for one anchor per day forces the list down to three things that matter and a supporting cast, and the geographic clustering rule immediately reveals that eleven of the forty-one are in one district they could walk in an afternoon. The "check before you go" list catches the two places that looked like restaurants and are actually bakeries that close at two.
Grandparents visiting a city where walking distance decides everything.
The wish list is short and the constraint is real: comfortable for about a mile and a half, then done for the afternoon. Adding that single line to the input changes the output structurally — the model clusters tightly, keeps the anchor close to the lodging, and offers optionals that are near rather than merely thematically related. The plan they walk away with has three or four stops a day instead of seven, which is not a compromise; it is the only version of the trip they would actually have enjoyed.
Creative use case ideas
- A wedding weekend for out-of-town guests. Send them a one-anchor-per-day plan of the area rather than a list of forty things to do, and you have given them a weekend instead of homework.
- A conference you are attending for the first time. Same problem, different map: too many sessions, spread across too many rooms, with a lunch break that always runs long. One anchor session per block and two optionals nearby is a better conference than trying to attend everything.
- The first weekend after moving to a new city. Feed the model your new address and a list of everything you have been told to check out, and get an unhurried plan for learning your own neighbourhood.
- A day of errands in an unfamiliar place. Registry office, bank, phone shop, hardware store. The clustering instruction is the entire value — it turns a to-do list into a route.
- A staycation in your own city. The wish list is all the things you have lived beside for years and never done. One anchor per day, one rest day, no travel required.
Adaptability tips
The prompt scales in both directions by changing the numbers rather than the wording. Travelling with a group that genuinely likes moving fast? Raise the optionals from two to four. Recovering from illness, travelling with a newborn, or on a trip whose real purpose is doing nothing? Drop the anchor to every other day and ask for two rest days.
Swap the constraint that matters most for your trip into rule four. Weather is the default, but it is not always the right one. A trip built around a sporting fixture, a festival, or a friend's availability should put that fixed point in first and let the rest of the plan arrange itself around it — tell the model the fixed thing is immovable and it will build outward from it.
For a multi-city trip, run the prompt once per city rather than once for the whole trip. The geographic clustering rule quietly stops working when the "one part of the region" spans a four-hour train ride, and you will get better output from three focused runs than one sprawling one.
Finally, if the first plan is close but wrong, do not start over. Reply with what specifically failed — "day two has us crossing the river twice" or "the rest day should be day four, not day six" — and ask for a revision. Correcting a draft is faster than commissioning one, and the model keeps everything you did not object to.
Pro tips
Add one line about energy, not just logistics: "we are slow starters and rarely leave before ten" or "we are up at six and fading by eight." Pace is a function of when your day begins, and models default to a nine-to-nine day that almost nobody actually lives.
Paste your list in as raw as it exists. Screenshots transcribed badly, half-sentences, place names spelled wrong — models are excellent at cleaning this up, and the ten minutes you would spend tidying the input adds nothing to the output.
Ask for the plan twice with one thing changed: "now do it again assuming we don't want to use public transport at all." The second version is rarely the one you use, but the difference between the two versions tells you which parts of your plan are load-bearing and which are incidental.
Prerequisites
You need a destination, your dates, and the area you will be staying in — a neighbourhood name is enough, an exact address is better. You need a list of things you want to do, in whatever state it currently exists; it does not need to be researched, ordered, or complete. Nothing else. If you have come through Weeks 1 to 4 of this series you will already have all of it, plus a budget ceiling and confirmed booking dates that make the output noticeably sharper — but the prompt does not require them.
Required tools
Any general-purpose AI chat tool — ChatGPT, Claude, Gemini, or Copilot. The free tier of any of them handles this prompt comfortably; nothing here requires a long context window or a premium model. A map app open in another tab is worth having so you can sanity-check the clusters as you read them, and somewhere to paste the "check before you go" list so it does not disappear into your chat history.
Frequently asked questions
The AI grouped two places together that are actually miles apart. Is the whole plan wrong?
No, and this is worth understanding rather than just fixing. Models have a reasonable but imprecise sense of where things sit relative to each other, and that sense degrades for smaller places, newer venues, and cities they have seen less of. Tell it directly — "the market and the castle are not walkable from each other, they're about forty minutes apart" — and ask it to re-cluster. It will incorporate the correction across the whole plan, not just that one day. Treat the clustering as a first draft that you verify on a map, not as a finished answer.
Why can't I just ask it for opening hours? It seems to know them.
It seems to, which is precisely the problem. A model will produce hours in the same confident register whether it is recalling something accurate, something that was accurate three years ago, or something it has essentially reconstructed from what similar venues usually do. You have no way to tell those cases apart from the text. The cost of being wrong is high and asymmetric — a locked door burns half a day — so the prompt trades a small amount of convenience for the removal of a whole category of expensive error.
My trip is only three days. Do I still need a rest day?
Probably not a full one, but keep the principle. On a short trip, make the rest day a rest afternoon: ask for the third day to have its anchor in the morning and nothing scheduled after it. The purpose of unstructured time is not rest in the literal sense — it is having somewhere to put the things that go wrong and the things that go unexpectedly right. A three-day trip has fewer of both, but it has some.
What if I genuinely want to see everything and I am fine with a packed schedule?
Then say so, and change the numbers rather than abandoning the structure. Ask for one anchor and four optionals, drop the rest day, and keep the geographic clustering rule — because dense days are exactly the days that punish backtracking hardest. The anchor-and-optional distinction still helps you, because when the packed day inevitably slips, you will already know what to cut.
Can I run this before I have booked anything?
Yes, and there is an argument for doing it early. A draft itinerary tells you which things need booking, which is useful precisely when you still have the flexibility to act on it. Just re-run it once your bookings are confirmed, because a fixed dinner reservation or timed entry changes the shape of the day around it.
Recommended follow-up prompts
The rain plan.
Feed the finished itinerary back in and ask for an indoor alternative for each day that is within the same geographic cluster. Two minutes of work that saves an improvised afternoon.
The cut list.
Ask the model which items from your original wish list did not make it into the plan and why, ranked by how close each one came. This surfaces the near-misses you might want to fight for, and occasionally reveals that the thing you cared about most was quietly dropped.
Week 6's logistics-and-protection audit,
which takes the plan this prompt produces and asks what happens when something goes wrong with the trip itself rather than the day.
Tags and categories
Tags:
itinerary planning, travel prompts, day-by-day planning, pacing, geographic clustering, beginner prompts, vacation planning, trip planning, rest days Categories: Travel Planning, Beginner Prompts
Citations
NOT APPLICABLE
Map First, Days Second
Build the map first, then the days — with your constraints honoured.
Here is the flaw buried in almost every AI itinerary: the model decides where things are and what day they belong on in the same breath, and by the time you see the output, those two decisions are fused. If the geography is wrong — and it often is in small ways — the days are wrong too, and you cannot fix one without demolishing the other. So you either accept a plan you half-trust or you start over. This prompt separates the two decisions and puts a hold point between them. The model shows you its map, you correct it while corrections are still cheap, and only then does it build days on top of ground you have both agreed on.
Why this matters now
Staged prompting is the single most useful intermediate technique available right now, and itinerary planning is an unusually clean place to learn it, because the failure it prevents is so visible. Every model available today will happily produce a full itinerary in one shot; none of them will tell you which parts of it rest on shaky spatial assumptions. Inserting your own judgement at the exact point where the model's confidence outruns its knowledge is a skill that transfers to anything you plan with AI — a project schedule, an event, a move. Learn it on a trip where the stakes are a pleasant afternoon rather than a deadline.
Act as a trip planner who builds itineraries around geography and energy rather than around a list of sights. You are working in two stages and you will stop between them.
My trip: [DESTINATION], [NUMBER] days, [DATES]. I'm staying in [NEIGHBOURHOOD OR ADDRESS AREA].
Travelling as: [WHO — for example, two adults and a four-year-old; a couple with very different interests; four friends; two people in their seventies who walk about two miles a day comfortably].
My wish list: [PASTE EVERYTHING, however messy].
My constraints: [FOR EXAMPLE — nobody wants to be out past eight; one of us needs an afternoon break; we don't drive; one full day is already committed; we're on a tight daily budget].
STAGE ONE — THE MAP. Sort my wish list into geographic clusters, treating my accommodation as the centre of the map. For each cluster tell me: which of my items are in it, roughly how it sits relative to where I'm staying, and how much of a day it could reasonably fill. If you're not confident where something is, say so and put it in a cluster called 'Unplaced' rather than guessing. Then propose a pacing profile for this specific group of travellers — how many hours out per day, how many moves between locations per day, where a rest day should fall, and what time of day is realistically our best window. Stop there and ask me to confirm or correct the clusters before you go any further.
STAGE TWO, ONLY AFTER I REPLY — THE DAYS. Turn the confirmed clusters into a day-by-day plan. Each day gets one anchor, a ranked list of optionals from the same cluster, and one line telling me what to cut first if the day runs late.
RULES FOR BOTH STAGES. Do not state opening hours, closure days, prices, reservation availability, or travel times as fact — you cannot see live information, and being confidently wrong about a Monday closure costs me a day of my trip. Where the plan depends on timing, write the assumption you are making, mark it VERIFY, and tell me where to check it. Use plain prose and short lists, not tables.
How the AI reads this prompt
Practical examples from different industries
A couple whose ideal days do not match.
One wants three museums and a long lunch; the other wants a beach and no schedule at all. Entering "a couple with very different interests" as the party description changes the model's approach: the clusters get proposed with an eye to which ones can absorb both preferences, and the pacing profile typically suggests alternating anchors rather than compromise days that satisfy nobody. The hold point matters here too, because it gives them a shared object to argue over — a cluster list is a much easier thing to negotiate than a finished itinerary that one person already feels ownership of.
Six friends who have been planning in a group chat for two months.
The wish list is the chat, deduplicated. What this prompt gives them is a single artefact at stage one that everyone can react to before anyone commits to days — which is the actual problem with group trips, since the itinerary usually becomes whatever the most organised person decided while nobody was paying attention. Confirming clusters as a group takes one round of messages. Confirming a full itinerary takes twelve and ends in resentment.
A traveller with a fixed commitment mid-trip and a mobility constraint.
They are attending a wedding on the Saturday, it runs late, and they can comfortably walk about a mile and a half a day. Both facts go into constraints, and both propagate structurally: Sunday comes back as deliberately empty, the clusters get proposed tightly rather than sprawlingly, and the pacing profile names a realistic window rather than assuming a full day is available. The plan that comes out is smaller than the one they would have written for themselves, and it is the one they will actually complete.
Creative use case ideas
- A house-hunting day across several neighbourhoods. Six viewings, an unfamiliar city, and a fixed schedule set by other people. Clustering first tells you which viewing times to push for before you agree to any of them.
- The holiday visiting circuit. Four sets of relatives, three days, and a car. Same problem, same solution, considerably higher stakes.
- A race weekend. Expo, packet pickup, the course itself, and a family who came along. The pacing profile is genuinely useful here, because the day before a race has a hard energy budget.
- An open-studios art trail or garden tour. Dozens of stops scattered across a region with a fixed window. This is pure clustering, and doing it badly costs you half the studios.
- A caregiver planning a week of appointments. Specialists, pharmacy, physiotherapy, and one person's real energy limits. The prompt does not know it is not planning a holiday, and the discipline it applies is exactly the same.
Adaptability tips
Add a third stage when the trip deserves it. After stage two returns, reply with "stage three: for each day, tell me what breaks the day and what I do instead." You have now built the advanced prompt's stress test incrementally, which is often how the best prompts get discovered — by adding stages to a working one rather than designing everything upfront.
Change what the pacing profile keys on. Energy is the default, but budget works the same way: ask for a spending profile alongside the clusters, and the model will tell you which days are structurally expensive before you have committed to them. So does interest balance for groups who are trying to keep everyone happy.
If you are planning several trips or replanning the same one repeatedly, save your constraints block as a reusable snippet. It is the part that does not change, it is the part that is tedious to retype, and it is the part that most improves the output.
For a long or multi-region trip, run stage one across the whole trip and stage two region by region. The map is worth seeing whole; the days are better built in smaller pieces.
Pro tips
At the hold point, before you confirm the clusters, ask one question: "which of these clusters are you least confident about?" Models will tell you, and the answer is a reliable guide to where you should be checking a map yourself.
Give the model a real anchor in space if you have one — a street name or a nearby landmark rather than just a neighbourhood. Spatial reasoning improves noticeably with specificity, and "two streets from the main station" is more useful to it than a district name it may associate with a wide area.
When you correct a cluster, correct it with a relationship rather than a fact. "The market is forty minutes from the castle, not walkable" is more useful than "the market is in the north," because relationships are what the clustering actually runs on.
Keep the stage-two output and feed it forward. It is the input for Week 6's protection audit and Week 7's in-trip prompts, and a plan the model can read back is worth more than one that lives only in your head.
Prerequisites
You need everything Variation 1 needs, plus two things you have to actually think about before you start: an honest description of who is travelling, and a written list of constraints. The constraints are the part people skip and the part that determines the quality of the output. It also helps to have your accommodation confirmed — Week 4's output — because the clustering runs on where you are staying, and clustering around a guess means redoing it later. If you have Week 3's confirmed flight times, add your arrival and departure hours; they shape the first and last days more than people expect.
Required tools
Any general-purpose AI chat tool with a conversation thread, since the prompt depends on a two-turn exchange — this rules out one-shot interfaces and simple API playgrounds set to a single completion. Free tiers work. Have a map open while you review stage one; the entire value of the hold point is your ability to catch a cluster that is wrong, and you cannot do that from memory unless you know the city well.
Frequently asked questions
The model ignored the stop instruction and gave me the whole itinerary. What now?
Reply with "you skipped stage one — show me only the clusters and the pacing profile, then stop." It will comply, and you have lost nothing but a message. This happens more on models tuned toward thoroughness, and it happens less if the two-stage structure is stated in the first sentence, which is why the prompt puts it there. If a particular model does it every time, split the prompt in two and send stage one on its own.
How do I know whether the clusters are actually right?
You check them, and this is not a weakness in the prompt — it is the design. Open a map, drop in the three or four items per cluster that matter most, and look at the shape. You are not verifying every claim; you are checking whether the model's mental map matches the real one at the level of "is this a walk or a journey." That takes about five minutes and it is the highest-value five minutes in the whole process.
Can I skip the constraints if I do not have any?
Everyone has them; most people have not written them down. If nothing comes to mind, answer three questions instead: what time do we realistically leave in the morning, what is the latest we want to be out, and is there anyone in the group whose limits set the pace. Those three answers are a constraints block. A plan built without them will be built for a traveller who does not exist.
What if my wish list is enormous — fifty or sixty items?
That is a good case for this prompt rather than a bad one, because clustering is exactly how you make a large list tractable. Expect the Unplaced cluster to be larger, and expect stage one to be long. If the model starts summarising rather than sorting, split the list in half and run stage one twice, then ask it to merge the two cluster sets.
Does the VERIFY marker actually help, or is it just labelling?
It helps because it is searchable and consistent. When you come back to the plan a week later, you can find every unconfirmed assumption in one pass rather than rereading the whole document trying to remember which parts were solid. Consistent markers are a small habit with a compounding payoff across any long AI output you intend to reuse.
Recommended follow-up prompts
The transit reality check.
Take the confirmed clusters and ask the model what questions you should be asking about getting between them — not the answers, the questions. It is a fast way to discover that one cluster depends on a ferry that runs twice a day.
The disagreement resolver.
For group and couple trips, hand the model the two competing versions of the ideal day and ask it to propose three structures that give each person a genuine win rather than splitting the difference on every day.
The single-day deep dive.
Take the one day you care most about and rebuild it hour by hour with the same constraints, treating the rest of the trip as fixed.
Tags and categories
Tags:
staged prompting, geographic clustering, itinerary planning, pacing, travel prompts, constraint setting, role assignment, group travel, intermediate prompts, accessibility Categories: Travel Planning, Intermediate Prompts
Citations
Anthropic, prompt engineering documentation (docs.claude.com) — general guidance on clear, direct instructions and structuring prompts for reliable output. Cited as a prompting reference, not as a travel source.
The Four-Pass Stress Test
Draft the itinerary, then attack it before your trip does.
Any competent model can produce a plausible itinerary. Plausible is a low bar and a dangerous one, because the failure modes of a travel plan are invisible in the document that describes it — you cannot see, by reading a day, that it contains three sequential dependencies and no slack, or that losing it removes the only opportunity for the thing you flew here to do. The document reads beautifully right up until Tuesday. This prompt makes the model do the thing a good planner does and a first draft never does: build it, then attack it, then fix what the attack found, then tell you what has to be booked and by when. Four passes, one message, and a plan that has already survived an argument.
Why this matters now
Self-critique is the most underused capability in current models, and it is underused because you have to ask for it explicitly and in a form the model can act on. "Is this plan good?" gets you reassurance. Four specific adversarial questions asked day by day get you a list of real structural weaknesses, because the model is far better at finding problems in text placed in front of it than at avoiding them while generating. There is also a deadline dimension that makes this urgent rather than merely interesting: the things that need booking furthest ahead are the things you lose first, and you lose them silently. A plan that does not end in a sorted booking calendar is a plan that will quietly shed its best parts.
You are going to build a day-by-day itinerary and then try to break it.
CONTEXT
Destination: [ ]
Dates and total days: [ ]
Arrival day and time, departure day and time: [ ]
Lodging area: [ ]
Party: [ages, mobility, tolerance for early starts, who wants what]
Wish list, each item marked M for must-do or W for would-like: [ ]
Fixed commitments already on the calendar: [ ]
Rough daily budget ceiling: [ ]
Non-negotiables: [ ]
WORK IN FOUR PASSES AND LABEL EACH ONE.
PASS 1 — DRAFT. Build the day-by-day plan. One anchor per day, optionals ranked within the same geographic cluster, arrival and departure days deliberately light, at least one day left unstructured. Every M item must appear somewhere or you must tell me why it could not.
PASS 2 — STRESS TEST. Now argue against your own draft. Go day by day and answer four questions for each day: what single delay collapses this day and what does it take down with it; where does this day double back on itself geographically; what does this day assume about opening times, availability, or weather that I have not confirmed; and what happens to the rest of the trip if this day is lost entirely. Be specific and be hard on it — a vague audit is worse than none, because it produces false confidence.
PASS 3 — REPAIR. Revise the draft to fix what pass 2 found. For each change, state the change and the failure it addresses. If a problem cannot be designed out, say so plainly and tell me what to watch for instead.
PASS 4 — THE BOOKING CALENDAR. List everything in the final plan that needs to be reserved, sorted by how far ahead that kind of thing typically needs booking, longest lead time first. For each item give: the item, the day it falls on, the lead-time category you are assuming (months ahead, weeks ahead, days ahead, or walk-up), why that category, and the specific page or channel where I confirm it. Finish with a single 'book this week' shortlist.
STANDING RULES
Treat every opening hour, closure day, price, availability, and travel time as unknown to you. You may say that a category of thing typically books out far ahead. You may not say that a specific venue opens at a specific time, closes on a specific day, or has availability on a specific date. Wherever the plan depends on such a fact, mark it VERIFY and name where I check it.
Flag any day with more than three moves between locations.
Flag any day where the plan depends on two things going right in sequence.
End with a RULES block: the pacing rules you applied, written so I can paste them into a future trip and get the same discipline without re-explaining any of this.
How the AI reads this prompt
Practical examples from different industries
A three-week, four-city trip with trains between them.
The wish list runs to eighty items and the failure mode is not a bad day, it is a bad connection — an anchor scheduled on a travel day, or a city given two nights when its M items need three. Pass 2's trip-level question does the heavy lifting: losing the Florence day does not just cost Florence, it costs the only window for the thing that required a Florence base. The booking calendar is where this example earns its keep, because a trip this size has reservations spanning four months of lead time and no chance of tracking them mentally.
A family reunion where eleven people arrive across three days.
Arrival and departure times are not one pair but several, and the plan has to work for a group that is partially present until Thursday. Feeding the staggered arrivals into the context and the shared meals in as fixed commitments produces a plan that puts the big group anchors after everyone has landed — obvious in hindsight, and reliably missed by anyone building the plan in their head, because the person building it is usually thinking about their own arrival.
A solo traveller doing a high-demand destination in peak season.
Half the wish list is timed entry and the other half needs a reservation weeks out. Here pass 4 is effectively the product: an ordered list of what to book and when, with everything marked VERIFY and pointed at the right official page. The stress test matters too — a plan built entirely from timed slots is a plan made of sequential dependencies, and pass 2 will say so day by day, which usually results in the traveller booking fewer timed things rather than more.
Creative use case ideas
- A wedding weekend run-of-show. Rehearsal, setup, ceremony, photos, dinner. Pass 2's "what single delay collapses this" question is precisely the question wedding planners are paid to ask, and it applies unchanged.
- A house move. Truck, keys, utilities, the handover window, and the people helping who are only free until three. Sequential dependencies everywhere and one shot at each.
- A touring musician or theatre company's routing. Load-in times, travel between venues, and days off that have to fall somewhere survivable.
- A caregiver's week of appointments and respite. Same structure, entirely non-commercial, and the stress test question about what happens if a day is lost is more than rhetorical.
- A film or photo shoot day plan. Light-dependent anchors, location moves, and a backup plan for weather that has to exist before the day begins.
- A conference you are speaking at. Your talk is the anchor and it is immovable; everything else is optional and the plan should say so out loud.
Adaptability tips
Run the passes across separate messages when the trip is large. Four passes in one response will hit length limits on a three-week itinerary, and the output degrades before it stops — pass 4 gets thin exactly when you need it most. Send pass 1 and 2 together, then request 3 and 4. The prompt is written to work either way.
Change the audit questions to match what actually worries you. Budget-fragile trips want "what does this day cost if everything goes to plan, and what does it cost if it doesn't." Trips with young children want "where is the nearest bail-out point if this day ends early." The four questions given are a strong default, not a fixed set — the technique is asking specific ones, whichever they are.
Keep the RULES block between trips and paste it into pass 1 next time. After two or three trips it stops being generic advice and becomes a description of how your household actually travels, which is a genuinely valuable artefact and one you could not have written from scratch.
Feed the finished output forward. This plan is the input Week 6 audits for things that can go wrong with the trip rather than the day, and the thing Week 7's in-trip prompts assume you are carrying.
Pro tips
After pass 4, ask one more question: "which single change to this plan would most reduce its total fragility?" You will typically get an answer about one day carrying too much, and acting on it is usually the difference between a good trip and a tense one.
Ask for pass 2 in a fresh conversation with the pass 1 output pasted in. Models critique text they did not just write with slightly less charity, and less charity is what you want from an audit.
Put your non-negotiables in your own words, not planning language. "We are not spending our anniversary on a train" reads to the model as a hard constraint and gets treated as one. "Prefer minimal transit on day five" reads as a preference and gets traded away.
Save the whole exchange rather than just the final plan. When something changes — a cancelled flight, a closure you discover on arrival — replanning inside the original thread is dramatically faster than starting over, because everything the model needs is already there.
Prerequisites
This prompt expects real inputs. You need confirmed dates with actual arrival and departure times, a confirmed lodging area, a wish list you have already sorted into must-do and would-like, any fixed commitments, and a daily budget you have actually thought about — Weeks 1 through 4 of this series produce every one of these. It also expects something of you afterwards: pass 4 hands you a list of things to verify and book, and the plan is only as good as your willingness to work that list. Some familiarity with multi-step prompting helps but is not required; the prompt carries its own structure.
Required tools
A current frontier model with a generous context window — ChatGPT, Claude, or Gemini on a paid tier is the comfortable choice, because four passes over a week-long trip produces a long response and free tiers may truncate it. If you are on a free tier, split the passes across messages as described above; the output quality holds up, it just takes two turns. A document or notes app for the RULES block and the booking calendar, since both are meant to outlive the conversation.
Frequently asked questions
Pass 2 was gentle and did not find much. How do I get a real audit?
Push back directly: "that audit was too soft — assume this plan will fail and tell me where." Models default toward agreeableness with work they have just produced, and one round of pressure usually produces a substantially harder critique. The more durable fix is running pass 2 in a fresh conversation with the draft pasted in as someone else's work. If it still returns nothing, that is weak evidence the plan is sound — but check the number of location moves per day yourself before believing it.
Is the booking lead-time guidance reliable?
It is reliable as a pattern and unreliable as a fact, and the prompt is built around exactly that distinction. That certain categories of thing — high-demand restaurants, timed-entry sites, marquee experiences — typically need booking well ahead is a general regularity models capture reasonably well. Whether a specific place has a table on your specific Thursday is live information no model can see. Use pass 4 to build your checking order, then confirm every line of it against the actual booking page.
Four passes in one response is a lot. Will it lose the thread?
On a short trip, usually not. On a long one, sometimes — and the tell is that pass 4 gets shorter and vaguer rather than that the model announces a problem. If the booking calendar looks thin relative to the plan, ask for pass 4 again on its own with the final itinerary pasted back in. Splitting the passes across messages is the reliable route for anything longer than about ten days.
Why does the prompt insist the model does not know things it clearly has some information about?
Because partial, undated knowledge presented confidently is worse than no knowledge at all in this specific domain. A model may well have seen a venue's hours at some point; it cannot tell you whether that was current, whether it was seasonal, or whether it changed last spring. The epistemic framing — you do not know this — produces a clean VERIFY marker rather than a hedge that still reads as an answer.
Can I use this for a trip that is already partly booked?
Yes, and it works better. Put everything already booked into fixed commitments, and pass 2 will audit the plan you are actually going to have rather than a hypothetical one. This is also the right way to use the prompt after something changes mid-planning: paste the new constraint in and run all four passes again rather than patching the old output by hand.
Recommended follow-up prompts
The rules refinement.
After your trip, paste the RULES block back in with a short account of what actually happened and ask the model to revise the rules based on what went wrong. Two trips of this and you have a genuinely personal pacing standard.
The fragility ranking.
Ask the model to rank your days from most to least fragile and explain the ranking. It is a fast way to know which mornings to protect and which ones you can afford to improvise.
Week 6's logistics and protection audit,
which takes this stress-tested plan and asks a different question: not what breaks the day, but what breaks the trip — and what you should have in place before you leave.
Tags and categories
Tags:
multi-pass prompting, self-critique, stress testing, booking lead times, itinerary planning, reusable prompts, structured input, failure modes, advanced prompts, travel prompts Categories: Travel Planning, Advanced Prompts
Citations
NOT APPLICABLE
Which of the three should you use?
The three prompts differ in where they put your effort, not in how ambitious they sound. Variation 1 asks almost nothing of you: a list, a neighbourhood, some dates, and the work happens entirely inside one response. It buys pacing discipline with a numeric constraint — one anchor, two optionals, one rest day — and that single rule prevents the most common failure by itself. Variation 2 asks you to think before you paste, and it inserts you into the middle of the process at the point where your judgement is worth the most: after the model has shown its map and before it has built anything on top of it. Variation 3 asks for real inputs and returns a plan that has already been argued with, plus the deadline calendar that determines what you can still have.
Where they overlap is the underlying discipline, and it is worth naming because it is the transferable part. All three separate what the model is genuinely good at — organising a messy list into a map-aware sequence, enforcing a pace, naming what needs booking — from what it cannot know, which is anything live. All three convert that boundary into a task for you rather than a gap in the output. If you take one idea from this week and use it nowhere else, take that one.
Choose by how far along you are rather than by how experienced you feel. Still deciding what the trip even looks like? Variation 1, today, and then again in a week when the list has changed. Have real constraints and a group whose needs conflict? Variation 2, because the hold point is where those conflicts get resolved cheaply. Flights booked, lodging confirmed, and things on your list that book out months ahead? Variation 3, and do not put it off — pass 4 is the part with a deadline attached, and every week you wait removes options from it silently.
TAGS:
