Trip Log Skill

Save and retrieve flight searches, award analyses, and booked itineraries from trips/logs/. Past entries are a reference library — pull them when planning connected trips, checking what was already searched, or reviewing what was booked and why.

This skill is opt-in. Create entries when the user asks ("log this trip", "save this search"), or automatically only if the user has said they want every search logged. Don't append logging to searches uninvited.

File Naming

trips/logs/YYYY-MM-DD_ORIGIN-DEST_short-label.md

• YYYY-MM-DD — date the search was run
• ORIGIN-DEST — airport codes. Multiple destinations: SFO-NRT-HND-SFO
• short-label — 2–4 word slug describing the trip purpose

Examples:

trips/logs/2026-08-11_SFO-CDG_paris-anniversary.md
trips/logs/2026-07-01_JFK-NRT_japan-ana-first.md
trips/logs/2026-09-02_SFO-OSL_oslo-work-trip-booked.md

Document Structure

Every trip log file uses this structure. Sections marked required must always be present. Others only when relevant.

---
date_searched: YYYY-MM-DD          # required
origin: XXX                        # required
destinations: [XXX, XXX]           # required
travel_dates: YYYY-MM-DD to YYYY-MM-DD  # required
cabin: business / premium / economy     # required
status: researched                 # required: researched | booked | completed | cancelled
booked_option: null                # fill in when booked: carrier, miles/cash, date
tags: [tag1, tag2]                 # freeform
points_at_search:                  # snapshot at search time — one key per program the user holds
  example_program: 0
---

# [Trip Title]

**Searched:** YYYY-MM-DD · **Status:** Researched
**Route:** ORIGIN → DEST1 / DEST2
**Travel window:** Month DD–DD, YYYY
**Cabin:** Business class
**Travelers:** N

---

## ✅ BOOKED (fill in when booked, delete if not)

...booking details...

---

## Search Summary

One-paragraph narrative of what was searched, why, and the headline finding.

---

## Award Options (seats.aero)

Table of award results. Note whether pricing is saver or dynamic. Note data freshness.

---

## Cash Options

Table of cash prices by destination. Source each result.

---

## Points Analysis

Effective balance table (direct + transferable). CPP math for each viable award option.
Compare against points-valuations.json floors/ceilings.

---

## Recommendation

Opinionated. One clear play, one backup. Include CPP and why.

---

## Action Items

Numbered checklist of next steps (verify on airline site, transfer points, book by date, etc.)

---

## Data Notes

Sources, freshness timestamps, caveats.

*Generated by travel-hacking-toolkit · YYYY-MM-DD*

Status Lifecycle

Update the frontmatter status field as the trip progresses:

Status	Meaning
researched	Search run, no booking yet
booked	Award or cash ticket purchased. Fill in booked_option. Add a ## ✅ BOOKED section at the top.
completed	Trip happened. Optionally add notes on actual experience.
cancelled	Booking cancelled. Note refund/redeposit outcome.

Reading Past Trips

To surface relevant history, grep the trips/ directory:

# Find all researched (unbooked) trips
grep -l "status: researched" trips/logs/*.md

# Find all trips from a specific origin
grep -l "origin: SFO" trips/logs/*.md

# Find trips tagged with a keyword
grep -rl "anniversary" trips/logs/

# List all trips with their status
grep -h "^status:" trips/logs/*.md

When to Create an Entry

• When the user asks — "log this", "save this search", "add this to my trips".
• When a booking is made and the trip is already logged — update status and add the booked section.
• For booked itineraries that predate the log — backfill with what you know. Set status: booked or status: completed.
• After every search, only if the user has opted in to automatic logging.

Notes

• Files live in trips/logs/, which is gitignored — local only, never pushed upstream.
• Snapshot the user's balances in the frontmatter at search time (from AwardWallet if configured, or whatever the user shares).
• Do not store .env values or account numbers in trip logs.