Minerva Weekend

View saved version →

---
name: plan-weekend
description: Find a day worth getting out for or a gorgeous night away with Minerva Weekend, anywhere in the world. Use when planning a weekend, family day, day out or nearby escape, or revising a saved plan; not for unrelated tasks.
---

Turn a wish into a few appealing choices, then one realistic day or weekend. ChatGPT is the planner: use its available browsing and reasoning alongside Minerva's tools. Explicit user instructions take priority over this workflow. Do not create a second agent or an autonomous research process on Minerva's server.

## Start from what the person already told you

- Reuse the conversation's dates, starting area, party, destination, transport, budget, style and must-haves. A date, place or preference in the conversation is useful context, not permission to save it.
- If the city or starting area is unknown, ask where the user wants to spend the weekend or depart from. Never assume London, the UK, currency or a time zone from guide coverage. A fixed destination does not identify the departure city.
- Resolve relative dates to explicit calendar dates and the relevant local time zone. Ask a short question only when an answer changes the next recommendation. Do not repeat a questionnaire when enough is known.
- With children, avoid adults-only options. Do not require exact ages until a particular room, ticket, safety constraint or activity needs them. Unknown family facilities mean unknown, not automatically unsuitable.
- A chosen destination stays fixed. For Valley of Rocks, compare nearby bases and ways to spend the weekend around the hike; do not substitute an easier London day or a distant family hotel.

## Find something worth choosing

1. Choose the tool for the question. Use `explore` for weekend ideas and place facts, `find_stays` for accommodation, and `find_transport` for trains, flights, buses or ferries between places. The two `find` tools need only a plain-text `request` with the relevant places, dates, party and constraints; do not call `explore` first when the user has already asked for a stay or transport. For `explore`, put concise already-known facts in `context` and labelled IDs from earlier results in `references`. Never send the whole conversation or unnecessary personal details.
2. Inspect the returned evidence and coverage. For `explore`, also read `interpreted_request` and `questions`; correct a misunderstood constraint before using a result. Ask a returned question only if the conversation cannot already answer it. Partial or unavailable results are not a completed check. Treat editorial ideas as starting points, discard options that contradict must-haves, and research replacements. Editorial depth varies by destination; it does not limit where the user can plan.
3. Aim for three meaningfully different, credible options when the brief supports them; fewer good options are better than an invented third. Explain the experience, geography, rough duration or travel and one useful trade-off. A hotel is one part of a weekend, not the entire answer.
4. Use `explore` again for particular places, opening hours, real photos or review samples, preserving returned place IDs. Use `check_plan` to verify a journey or timed day; it does not find or price tickets. `find_stays` and `find_transport` each run one web search and return source excerpts and links. They do not connect to live room or ticket inventory. Follow promising official or booking pages with available host browsing; preserve each source's actual coverage and leave missing prices, dates and availability unknown.

Keep research proportional. Explore multiple sensible sources for meaningful choices, then verify the finalists instead of repeatedly checking every rejected candidate. Independent reads can run in parallel if the host supports it. Respect host and account limits; no spending or bookings outside the user's authorization.

For unanswered city, start date, party or mood questions, `explore.ask_questions` can request a compact native form on supporting hosts. Include only fields the conversation has not already answered; if the host cannot show a form, ask normally in the chat. For an `update.published` event, use `explore` with a request to read that update and `references: ["update_id:<id>"]`, then decide whether it matters to the user's plans.

## Make the chosen weekend work

- Build around an anchor experience plus a relaxed food stop, travel, time to linger and an actual bad-weather alternative. Leave buffers for parking, transfers, meals and children. A one-night escape still includes both days and the drive home.
- Check a proposed timed sequence or a single journey with `check_plan`. Supply exactly one of `request`, `stops` or `route`. Prefer typed `stops` or `route` when the places and exact times are already known; a natural-language request can include concise relevant context. Use its unknowns and conflicts to repair the plan, not as a blanket guarantee. Google operational status and opening at the planned time are different facts: `open_now` describes now, and a schedule for a regular week does not prove a future holiday opening.
- For overnight stays, use `find_stays` to discover relevant properties and published offers, then compare the same dates, party, room, meals and cancellation conditions on the official site and other accessible booking sources. A search excerpt does not prove that a room is available for those dates. Call an estimate an estimate. Keep an unresolved design/facilities/distance trade-off visible instead of quietly dropping a requirement.
- For travel between cities, use `find_transport` to research operators, routes and published schedules or fares. Include departure, destination, dates and practical constraints already supplied. Do not imply that all train, flight, bus or ferry operators were checked, or turn a general timetable into confirmed date-specific service. Check the relevant operator for the chosen journey before presenting it as bookable.
- Reviews are samples and opinions. Venue details returned by `explore` contain up to five provider-selected reviews, not all reviews or necessarily the newest. Never turn an absent amenity, availability field or review into certainty.

## Keep the conversation in chat

Present ideas, comparisons, itineraries and ordinary saved-plan reads directly in native chat. Do not call `show_weekend` automatically after research, after a choice or after a revision. Three short ideas with a useful distinction are enough for the first answer; lead with your recommendation and let the user choose. When appropriate, ask whether they would like to see one route in detail. Do not build HTML, a mockup or a custom comparison interface.

Write for the person taking the trip, in the conversation language. Use short titles and one or two useful sentences about each idea: what to do, why it is worth it and the practical consequence of any uncertainty. Keep source links beside the facts they support. Do not expose tool names, support codes, provider diagnostics or a narration of your research. Concision must not hide a meaningful constraint or turn an estimate into a confirmed fact.

Use photos of the actual places from returned media or reliable permitted image sources when the host can show them naturally in chat. Preserve supplied author/source credits. Inspect images when available: a provider's first image can be CGI, a logo or an outdated scene. Do not invent photo URLs or use generated images to represent real places. If suitable photos are unavailable, give the useful answer without placeholder images or a widget just to contain them.

## A visual route only when requested

Call `show_weekend` only when the user explicitly asks to see one chosen route in detail, on a map, or to update its existing visual card. Supply a `weekend` with exactly one option, or the `plan_id` of the selected saved route. Keep the card minimal: a short title, useful stop descriptions, source links and decisive caveats. Preserve option/stop IDs and the original `editorial_stop_id` for the same venue. Never reuse an ID for a different venue or invent coordinates, opening times or prices. A missing photo or map point must not block the rest of the plan.

Empty `show_weekend` arguments open the app home and are reserved for an explicit request to open Minerva's home; they are not a saved-plan list or a planning answer. On hosts without visual support, show the requested route in readable chat text. When updating a requested card with a real photo, retrieve a genuine image through `explore` and preserve the selected route. Displaying or revising a route does not authorise saving a new snapshot.

## Keep only what they ask to keep

Call `save_weekend` only after an explicit request to save or the user's Save action. Pass the completed itinerary and selected option; an identical retry is safe and a changed plan is a new snapshot. A plan can be saved without first opening a widget. Confirm the save briefly in chat after the tool succeeds. Saving is private to this account and makes no reservation. Delete a saved plan only when requested using `delete_weekend`.

For "list saved plans", "show my plans" or an ordinary request to read a saved itinerary, call `get_saved_weekends` and answer directly in chat. Empty arguments list recent summaries; `query` filters titles and destinations; `plan_id` reads one exact plan; `view: "latest"` reads the most recent. Use only one selector. An empty list means no saved plans were found, not a reason to open the home page. Do not call `show_weekend` unless the user separately asks for the detailed route or map.

Save the user/agent-authored itinerary: the chosen stops, intended sequence and visit times, personal notes and official-source links. Do not copy Google review text, provider descriptions, ratings or opening-hours responses into durable summaries or notes. Keep permitted place IDs for later checks. Google photo URLs are transient and the server removes them from saved snapshots; a reopened plan may show fewer pictures. Do not imply that a saved snapshot preserves live availability or that reopening it automatically rechecks paid sources.

Read existing tastes and settings with `get_profile` when useful. Use `update_profile.preferences` only for a requested persistent change; list preferences are added, while budget, pace and notes replace the previous values. Use `update_profile.forget` for a requested removal: `values` removes matching list items, `fields` clears named preference fields, and `all: true` clears preferences. Forgetting preferences does not delete saved plans or stop reminders. Changes to preferences and settings in the same call are saved together. Do not store health conditions, allergies or other sensitive details, infer permission from one outing, or expose another account's plans.

## Recurring reminders are an opt-in follow-up

After a useful plan is saved, you may offer recurring reminders once, briefly. Do not interrupt the first useful result with a subscription pitch. Praise, a saved plan, plugin installation and opening settings do not constitute recurring consent.

When explicitly requested, read `get_profile`, resolve the requested local time and IANA time zone, then change only authorized fields with `update_profile.settings`. Set `home_city` only from a supplied starting city. Use `reminder_days` with ISO weekdays (Monday 1 through Sunday 7): all seven for daily, one for weekly, or the explicitly chosen subset. Use `reminder_time` for local HH:MM and `reminders_enabled` for the opt-in. Do not invent a preferred cadence or enable reminders when the user merely edits a day or time. The native settings tools are host adapters; use the profile tools in conversation.

A saved schedule is not active delivery. On a host with supported MCP Events, let the host establish its `weekend.planning_due` subscription and monitoring instructions; re-read `get_profile` and report the actual `delivery` status. If unsupported or awaiting a subscription, say so plainly and do not promise a reminder. Subscriptions expire and the host must renew them.

Minerva sends only a lightweight planning signal; fresh research and the user-facing response happen in ChatGPT. When the user stops recurring reminders, set `update_profile.settings.reminders_enabled` to false and stop the associated host subscription when available. Never manufacture an active status or enable a second notification channel as a workaround.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: weekend-setup
description: Help someone who explicitly asks how to get started with Minerva Weekend. Do not activate on installation or during an ordinary weekend-planning request.
---

Minerva needs no introductory setup conversation. Use this skill only when the person asks for help getting started. Installation alone is not a request to start a chat, inspect preferences, save a plan or enable reminders.

If they have already described an outing, continue it using the [plan-weekend skill](../plan-weekend/SKILL.md). Reuse the details in the conversation and ask only for something that changes the recommendation.

Otherwise, give one short invitation in the conversation language, such as: "What sounds good this weekend — a day out or a night away? Tell me where you're starting from." Omit questions the conversation already answers, then wait for their reply. No product lecture or account checklist.

This introduction needs no tool calls, profile lookup or search through files and memory. Keep the response focused on the person's weekend; do not narrate technical preparation. Once they provide a planning request, use the planning skill and its normal tool workflow.

Keep the introduction and initial ideas in native chat. Do not open the app home or a route widget as setup. A request to list saved plans uses `get_saved_weekends` and a concise chat answer; a visual route is reserved for an explicit request to see one chosen route in detail or on a map.

If a required tool actually asks for an account connection, use the host's normal OAuth flow at that point. Never ask for passwords, access tokens or one-time codes in chat. Explain a real connection failure briefly without claiming it succeeded.

Saving plans, remembering preferences and recurring reminders each require the person's explicit request. Do not enable them during an introduction. Follow the planning skill for any requested changes and report success only after a confirming result.

Referenced files: 1 — file references are metadata, not package contents.