---
name: trip-email-html-itinerary
description: >
Extract trip logistics from pasted travel emails, booking confirmations,
forwarded messages, reservation notes, or raw itinerary text and generate one
polished, self-contained offline HTML itinerary file for sharing with family
or other travelers. Trigger when the user asks to turn trip emails into an
HTML itinerary, travel handoff page, shareable trip page, family trip summary,
booking-reference page, or offline travel document.
version: 2.0.0
---
# Trip Email HTML Itinerary
## Intent
Turn a batch of travel-related emails into a complete, shareable HTML trip document. The final file should help the traveler and a spouse, family member, or travel companion quickly understand flights, lodging, rental cars, events, booking references, contact details, open issues, and day-by-day logistics.
Primary viewing target is Apple Notes on iPhone while traveling. Assume the user will drop the `.html` file into Apple Notes for quick access. Favor clarity and larger section labels over dense desktop styling when there is a tradeoff.
Use this skill for email-derived travel organization and offline HTML output. If the user wants a planning Markdown file instead, use the travel-itinerary skill.
## Trigger When
- The user asks to create an HTML itinerary from emails, confirmations, or forwarded trip details.
- The user asks for a shareable trip page, family travel handoff, offline travel document, or complete travel summary from bookings.
- The user asks for an itinerary they can save into Apple Notes for quick mobile retrieval.
- The user says they will drop the HTML file into Apple Notes for quick travel access.
- The input includes travel emails for flights, hotels, car rentals, tours, events, restaurants, insurance, visas, or logistics.
- The user wants a single `.html` file that works locally without a server or internet access.
## Do Not Use When
- The user wants live booking, price comparison, destination research, or current visa/legal advice.
- The user only wants a plain text summary or Obsidian Markdown itinerary.
- The user asks to preserve confidential PINs, full payment card numbers, passwords, account login links, or private access codes in the output.
---
## Workflow
### 1. Ingest The Emails
Accept pasted emails, exported email text, copied booking confirmations, screenshots transcribed by the user, or structured trip notes. If the user provides multiple emails, treat the newest or most explicit confirmation as authoritative unless it is clearly a cancellation or change notice.
Extract and normalize:
- trip title, date range, traveler names, route stops, destination cities
- flights: airline, flight number, airports, dates, departure and arrival times, confirmation codes, ticketing notes, baggage notes, terminal notes, cancellation/change status
- lodging: property name, city, dates, address, phone, email, booking number, room type, check-in/out windows, parking, meals, arrival instructions, cancellation status
- ground transport: rental car, train, ferry, bus, shuttle, ride reservation, pickup/drop-off locations and times, reservation numbers
- events and tours: names, dates, times, meeting points, ticket references, warnings, and schedule-sensitive notes
- travel admin: passport, visa, Global Entry/TSA PreCheck, insurance, pending bookings, canceled items, documents to carry
- open questions, gaps, conflicts, or items still needing user action
### 2. Reconcile And Protect The Data
- Prefer confirmed bookings over draft plans.
- Treat cancellation emails as warnings and mark related items canceled unless a later email re-confirms them.
- Preserve confirmation and booking numbers when useful.
- Never include Booking.com PINs, door/keypad/access codes, passwords, full payment card details, CVV codes, bank details, or sensitive login URLs.
- Redact sensitive values as `[redacted]` when the surrounding context is still useful.
- If dates or times conflict, include the most likely value in the main itinerary and add a short conflict note in pending items.
- Do not invent addresses, phone numbers, confirmation codes, or exact times. Use `TBD` or `Pending` when unknown.
### 3. Build A Working Trip Model
Use this internal shape while drafting. It does not have to be shown to the user:
```json
{
"tripTitle": "",
"dateRange": "",
"travelerNames": [],
"routeStops": [{"code": "", "city": ""}],
"statusPills": [],
"keyTripCards": [],
"contacts": [],
"flights": [],
"lodging": [],
"groundTransport": [],
"events": [],
"dayByDay": [],
"bookingReferences": [],
"travelAdmin": [],
"pendingItems": [],
"canceledItems": []
}
```
### 4. Required HTML Sections
Produce a complete HTML document with these sections in order, omitting only sections with no useful data:
1. **Hero** — trip title, date range, route string (BNA → LIS → BCN → ...), status badge pills, destination character gradient
2. **Destination Timeline** — one card per major stop (equivalent to "island cards" in multi-stop trips)
3. **Action Items** — red/gold alert strips for anything requiring user action before departure
4. **Flights** — confirmed segments in green-badged panels; unbooked/verify segments in red/yellow panels
5. **Destination Sections** — one per city/region with hotel card, transport card, activity card, and alert strips
6. **Day-by-Day Itinerary** — date-keyed rows with country tags and activity lists
7. **Booking References** — full table with What / Details / Reference / Status columns
8. **Booking Checklist** — card grid organized by category (Flights, Hotels, Transport, Tours, Admin, Finance)
9. **Travel Admin** — 2-column card grid for passport/visa, ID rules, baggage, emergency contacts
10. **Footer** — trip name · traveler · dates · route
---
## Design System
This is the canonical visual spec. All HTML output from this skill must use it. It is derived from the Hawaii Trip (Oct 2026) and Europe & Morocco Trip (Jul 2026) itinerary files produced for Mick Pletcher.
### Font Stack
```html
```
- **Playfair Display 700** — hero title, destination section headers, card names
- **DM Sans 300/400/500** — body text, card subtitles, list items
- **DM Mono 400/500** — all labels, badges, codes, timestamps, section labels, footer
Note: These fonts require an internet connection on first load. The file works offline once fonts are cached. If strict offline is required, fall back to `Georgia, 'Times New Roman', serif` for display and `'Courier New', monospace` for mono.
### CSS Variables
Always declare exactly these variables in `:root`. Swap the destination-palette values per trip; never change the structural variable names.
```css
:root {
/* ── DESTINATION PALETTE (swap per trip) ── */
--c1: #0a4f6e; /* primary — deep tone of main destination */
--c1-mid: #1a8fa0; /* primary mid — lighter accent */
--c2: #e8603c; /* secondary — alert / contrast destination */
--c3: #2d6a4f; /* tertiary — third destination or activity accent */
--gold: #d4a843; /* universal gold — labels, prices, accents */
--em-color: #c8eaf5; /* italic emphasis in hero h1 */
/* ── STRUCTURAL (never change) ── */
--white: #fdfaf6;
--dark: #0c1820;
--dark2: #111e28;
--mid: #3a5060;
--green-ok: #4caf50;
--green-ok-dim: rgba(76,175,80,0.15);
--coral: #e8603c;
--purple: #7c5cbf;
--purple-dim: rgba(124,92,191,0.12);
}
```
### Destination Palette Reference
Pick the closest match and tune hues to suit:
| Trip character | --c1 (deep) | --c1-mid | --c2 (alert/contrast) | --c3 | --em-color |
|---|---|---|---|---|---|
| Pacific / Hawaii | #0a4f6e | #1a8fa0 | #e8603c | #2d6a4f | #c8eaf5 |
| Mediterranean / Atlantic | #0a3f6e | #1a7a9e | #e8603c | #4a7a38 | #a8d4f0 |
| Morocco / Desert | #6a2a08 | #b04820 | #e8603c | #0a3f6e | #f0a858 |
| Japan / East Asia | #1a2a5e | #2a5a9e | #c8302a | #2d6a4f | #c8d8f5 |
| Scandinavia / Arctic | #0a2a4e | #1a5a8e | #c85030 | #2a4a3a | #a8c8e8 |
| Central America / Tropics | #1a5a2a | #2a9a4a | #e8803c | #0a3f6e | #a8e8b8 |
### Hero Section
```html
Trip Planning Document · [N] Days · [N] Countries
[Destination] & [Secondary] [Month Year]
BNA → [CODE] → [CODE] → BNA · [Date range]
[Airline] [Conf] · Confirmed
Hotels [N] of [N] confirmed
[N] Action Items · required
```
Hero gradient: `linear-gradient(155deg, [darkest] 0%, [c1-dark] 28%, [c1-mid-dark] 52%, [c2-dark] 76%, [darkest-c2] 100%)`
Hero `::before` radial overlays: 3 ellipses — primary destination glow at 70% 20%, secondary glow at 15% 85%, gold accent at 50% 60%.
### Destination Timeline Cards
One card per major stop. Status dots: `done` = green (confirmed), `todo` = red (action needed), `sel` = gold (partial/selected).
Card gradient backgrounds follow destination palette:
- Confirmed stop: `linear-gradient(140deg, [c1-dark], [c1-mid])`
- Alert/gap stop: dashed border, warm dark gradient, `border-style: dashed`
- Dim/transit stop: dark muted gradient, `opacity: 0.7`
```html
[City]
[Country]
[Jul 4–7]
[N]nights
[Hotel name or warning]
```
### Alert Strip System
Four severity levels. Always use `.icon` + `.txt` structure. Strong tags inside `.txt` inherit the strip color.
```html
```
### Day-by-Day Grid
Country tags color-coded per destination. Anchor items (flights, check-ins, tours) use `.anchor` class for white bold text. Optional activities use `.opt` (dimmed italic). Warnings use `.flag` (coral). Notes use `.note` (gold). Tour/event highlights use `.tour` or `.tdf` (amber/purple).
```html
Jul 4SAT
[LABEL]
[Flight / check-in / tour time — bold white]
[Regular activity]
⚠ [Warning or action needed]
[Optional suggestion]
```
Use `.alert-day` on `.day-content` for days with a lodging gap or critical issue (adds coral border tint).
### Booking References Table
Four columns: What (with sub-label), Details, Reference (DM Mono gold), Status badge.
Status classes: `.status-confirmed` (green), `.status-verify` (yellow), `.status-needed` (coral). Canceled rows use `.canceled-row` class on `