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 runORIGIN-DEST— airport codes. Multiple destinations:SFO-NRT-HND-SFOshort-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: bookedorstatus: 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
.envvalues or account numbers in trip logs.