plan-and-maintain-tripsSAFE

From the repository's own README, as read at the audited commit. Badges and raw HTML are left out.

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: plan-and-maintain-trips
description: Plan, research, revise, audit, and publish executable trips for any destination. Use when Codex needs to design a single-city or multi-city itinerary, compare lodging or transport, manage fixed bookings and changing constraints, distinguish booking availability from unreleased inventory, create route maps and day-of field cards, recheck volatile travel facts, or publish a final travel guide to an available document platform.
---

# Plan and Maintain Trips

Treat a trip as a maintained project, not a one-shot list of attractions. Keep one canonical state, preserve user decisions, verify volatile facts from current sources, and derive every itinerary, checklist, map, and published document from that state.

## Start the project

Collect only the information that changes the plan materially:

- dates or trip length;
- destinations or open-ended region;
- travelers and mobility needs;
- arrival and departure constraints;
- total and nightly budgets;
- interests, pace, food needs, and lodging requirements;
- bookings already made;
- dates or activities that must not move;
- requested outputs and publishing platform.

If details are missing, state safe assumptions and begin a draft. Ask a concise question only when the answer would change cities, dates, cost class, accessibility, or an irreversible booking recommendation.

Create a project directory outside the skill. Copy `assets/trip.example.json` to `trip.json` and replace the example data. Treat `trip.json` as the source of truth. Read `references/state-model.md` before creating or materially changing it.

Never put traveler credentials, payment data, passport numbers, API tokens, or document authorization codes in the project or skill.

## Choose the operating mode

- **Plan:** build the city/base structure first, then schedule days.
- **Revise:** record the new decision, compute its impact, and update every affected artifact.
- **Booking:** turn planned items into a status-controlled booking console with official links.
- **Recheck:** refresh only volatile facts whose review time has arrived.
- **Day-of:** produce compact field cards from confirmed bookings and current conditions.
- **Live replan:** propose a minimal same-day adjustment for delay, closure, or rain; protect hard anchors and reconfirm affected bookings.
- **Publish:** render local artifacts first, then use an available optional publisher.

The user can move between modes naturally. Do not restart from scratch when a decision changes.

## Build the plan in order

### 1. Freeze the trip skeleton

Set entry and exit points, overnight bases, night counts, transfers, and hard anchors. Separate:

- hard anchors that require explicit approval to move;
- soft targets that may shift;
- optional items that are first to cut;
- exclusions that must not reappear.

Validate date arithmetic before researching individual attractions:

```bash
python3 scripts/validate_trip.py /path/to/trip.json
```

Read `references/scheduling-and-change-control.md` for routing, pace, lodging, and impact-analysis rules.

### 2. Research volatile facts

Browse whenever information may have changed: opening days, timed-entry rules, sale windows, inventory, prices, transit schedules, strikes, special events, weather, restaurant hours, hotel availability, and local regulations.

Prefer primary sources in this order:

1. venue, operator, government, airline, railway, hotel, or restaurant official page;
2. official tourism authority or ticketing partner;
3. a reputable secondary source only when the primary source is unavailable.

Record the claim, source URL, checked time, applicable date, and next recheck time in `trip.json` or an evidence file. Read `references/research-and-evidence.md` before assigning booking status.

Never equate a missing date with sold out. Use only these booking states:

- `bookable`
- `not_released`
- `date_not_in_system`
- `sold_out`
- `walk_in`
- `same_day`
- `booked`
- `needs_recheck`

Use `unknown` only during research and eliminate it before final delivery.

### 3. Schedule executable days

Place hard anchors first. Then group attractions by geography, opening hours, realistic dwell time, security queues, meals, transfers, rest, and weather exposure.

For every day include:

- one primary outcome;
- hard anchors and arrival buffers;
- realistic visit and movement durations;
- a meal strategy tied to the route;
- a recovery block on long days;
- an estimated walking/standing load;
- a first-cut item;
- a weather or disruption branch.

Do not optimize only for straight-line distance. A geographically close venue can still be infeasible because of opening times, security, hills, luggage, or a later reservation.

### 4. Produce the booking console

For each paid or reserved item show:

- current status;
- intended date, time, and traveler count;
- official purchase or reservation link;
- price basis and whether fees/taxes are included;
- sale-window explanation;
- refund or cancellation condition when material;
- failure fallback;
- next action and next recheck date.

Do not claim success until the user has a confirmation or QR code. Do not buy, reserve, message, install software, or publish externally without user authorization.

### 5. Produce day-of field cards

Create one mobile-first card for every calendar day, including arrival, transfer, and departure days. Each card must contain:

- today's anchor;
- follow-in-order timeline;
- ticket wallet;
- one-tap location links;
- morning or previous-night checks;
- late/rain/closure decision;
- one sentence stating what must be protected.

Leave explicit fill-in fields for unknown hotel, flight, terminal, booking number, insurance, or emergency-contact details. Never invent them.

When the user wants a visual execution pack, export each card as a screenshot-friendly SVG or high-resolution PNG and keep a searchable text equivalent. Use `assets/readme-day-card.svg` only as a visual reference

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

declared (3 observation(s))

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (5)

assets/readme-day-card.en.png

assets/readme-day-card.png

assets/readme-publishing.en.png

assets/readme-publishing.png

assets/readme-route-sample.en.png

Gates applied: no_behavioural_pass.