---
name: finance-trip
description: "Use when the user wants to track trip expenses, tag travel transactions, find late-posting charges from a trip, or get a trip spending summary. Example: 'tag my Tahiti trip expenses' or 'how much did I spend in Whistler?'"
---

# Finance Trip

## When to use

- The user wants to tag travel transactions for a trip
- The user asks "how much did I spend in [place]?"
- The user wants to find late-posting charges from a recent trip

## Do NOT use if

- The "trip" isn't a discrete date range (it's general spending in a category) → use `/finance-pulse`
- The user wants Amazon-specific reconciliation → use `/amazon-sync`

Track trip expenses by finding transactions in a date range, using location and merchant data to suggest which ones belong to the trip, and tagging confirmed ones. Can re-run to catch stragglers.

## Guardrails

1. **Stage writes as a draft.** Before any `create_tag` or `update_transaction` call (including tag adds via `tag_ids`), show the user the proposed change (new tag name, or which transactions get which tags) and wait for explicit confirmation. The "Definitely trip" batch-approval flow (Phase 3) is the carve-out — the batch must still be presented first, but per-item confirmation isn't required after the batch is approved in the same turn.
2. **Confirmation is per-turn.** A previous "go ahead" does not authorize subsequent batches. Each new batch of writes requires its own confirmation in the same turn.

## Phase 1 — Scope the Trip

1. **Read the user profile** at `~/.claude/copilot-money/user-profile.md`. If the file doesn't exist: run `mkdir -p ~/.claude/copilot-money`, then copy `skills/user-profile.template.md` (relative to the copilot-money-mcp repo root) to the profile path. First-time bootstrap may require CWD = repo root for the template read. Check Trip Tracking preferences and any existing trips.

2. **Get trip parameters.** Ask the user or infer from context:
   - **Trip name:** e.g., "French Polynesia", "Whistler Weekend"
   - **Date range:** start and end date. If the user says "my Tahiti trip" and you know dates from prior conversation or tagged transactions, use those.
   - **Location hint:** country, city, or region (optional — helps filter)

3. **Check for existing trip tag.** Use `get_transactions` with `tag` filter to see if a tag already exists for this trip. If it does, this is a **re-run** to find stragglers — note which transactions are already tagged.

## Phase 2 — Find Trip Transactions

1. **Pull transactions for the date range.** Use `get_transactions` with `start_date`/`end_date`, `exclude_transfers: true`. Paginate if needed.

2. **Also pull a 2-week buffer after the trip end date.** Late-posting charges (hotels, rental cars, foreign transactions) often settle days or weeks after the trip. Use a separate `get_transactions` call for `end_date + 1` through `end_date + 14`.

3. **Score each transaction.** Use Python via Bash. For each transaction, compute a trip-likelihood score based on:

   **Strong signals (high confidence):**
   - Location match: transaction's `city`, `region`, or `country` field matches the trip location
   - Merchant type matches travel categories: Hotels, Airplane Tickets, Car (rental), Transportation (rideshare/taxi)
   - Foreign currency or foreign transaction fee during trip dates

   **Medium signals:**
   - Merchant name contains trip location keywords (e.g., "PAPEETE", "MOOREA", "WHISTLER")
   - Category is travel-adjacent: Restaurants, Bars & Pubs, Tickets & Shows, Gas (road trips)
   - Transaction is in the buffer window (post-trip) from a merchant that also appears during the trip

   **Weak signals (include but flag as uncertain):**
   - Online purchases during trip dates (could be coincidental)
   - Generic merchants (Amazon, grocery stores) during trip dates

   **Exclude:**
   - Recurring charges that happen regardless of travel (subscriptions, rent, utilities, phone)
   - Transactions already tagged with this trip (if re-run)
   - Internal transfers
   - **Home-location spending during trip dates.** The user may still have charges from their home city (Seattle) while traveling — e.g., Lime scooters, local tolls (WSDOT), local restaurants, Venmo payments to friends. Don't assume all spending during trip dates is trip spending. Check the merchant name for home-city indicators before classifying travel-adjacent categories as "probably trip."

4. **Group into tiers:**
   - **Definitely trip:** Strong signals. Will be auto-suggested.
   - **Probably trip:** Medium signals. Present for confirmation.
   - **Maybe trip:** Weak signals. Mention but don't push.

## Phase 3 — Present & Confirm

**Tone:** Match `~/.claude/copilot-money/user-profile.md` Communication Style. Default: blunt, simple, dollar amounts.

1. **Show the trip summary first** (before asking about individual transactions):

   > **[Trip Name]: [Start Date] – [End Date]**
   > Found [N] transactions totaling $[X]
   >
   > | Category | Amount | Count |
   > |----------|--------|-------|
   > | Hotels   | $X     | N     |
   > | Restaurants | $X  | N     |
   > | ...      | ...    | ...   |

2. **Present transactions for confirmation in batches:**
   - "Definitely trip" items: present as a batch for quick approval ("These 15 look like trip expenses — approve all?")
   - "Probably trip" items: present individually or in small groups with context
   - "Maybe trip" items: mention briefly ("Also found 3 Amazon orders during your trip — include any?")

3. **Show full merchant names.** Always use `name` or `original_name`, not `normalized_merchant`.

4. **For re-runs (stragglers):** Only show NEW transactions not already tagged. Frame as: "Found 3 late-posting charges from your [Trip Name] trip:"

## Phase 4 — Tag & Summarize

1. **Create the trip tag** if it doesn't exist. Use `create_tag` with the trip name (e.g., "frenchpolynesia", "whistler-jan-2026"). Use lowercase, no spaces.

2. **Tag confirmed transactions.** Use `update_transaction` with `tag_ids` for each approved transaction.

3. **Show final summary:**

   > **[Trip Name] — Final Tally**
   > Tagged [N] transactions, total: $[X]
   >
   > | Category | Amount | Count |
   > |----------|--------|-------|
   > | Flights  | $X     | N     |
   > | Hotels   | $X     | N     |
   > | Food     | $X     | N     |
   > | Transport| $X     | N     |
   > | Activities| $X    | N     |
   > | Other    | $X     | N     |
   >
   > Per-day average: $[X/days]

4. **Update user profile.** Only add the trip to the Trip Tracking section if it ended **within the last 3 weeks** (stragglers may still post). Remove concluded trips older than 3 weeks — the tag in Copilot Money is the source of truth, not the profile. Format for active/recent trips:
   ```
   - [Trip Name]: [dates], tag: #[tag], stragglers possible until [end_date + 3 weeks]
   ```

## Phase 5 — Straggler Follow-up (optional)

If the trip ended recently (within 3 weeks), suggest a follow-up:
> "Some charges may still be posting. Want me to check again in a week or two?"

If the user agrees, note it in the conversation for future reference. The user can re-invoke `/finance-trip [trip name]` anytime.

## Rules

1. **User confirms before tagging.** Never tag a transaction without the user approving it first. "Definitely trip" items can be batch-approved, but the batch must be presented first.
2. **Use Python for aggregations.** Category totals, per-day averages, scoring — all via Bash with Python.
3. **Show full merchant names.** Always `name` or `original_name`, never truncated `normalized_merchant`.
4. **Respect existing tags.** If transactions already have tags, add the trip tag alongside them — don't replace.
5. **Recurring charges are not trip expenses.** Subscriptions, rent, utilities, and other recurring charges that happen regardless of travel should be excluded even if they fall within the trip dates.
6. **Buffer for late charges.** Always check 2 weeks after the trip end date for late-posting charges (hotels, car rentals, foreign transactions).
7. **Re-runs are safe.** The skill can be re-run on the same trip without double-tagging — it skips already-tagged transactions.
8. **Tag filter bug (known issue).** `update_transaction` tag writes succeed but `get_transactions` with `tag` filter may return nothing even after `refresh_database`. This is a known MCP bug under investigation. Workaround: after tagging, verify by re-querying the specific transaction IDs rather than using the tag filter.
9. **Transaction IDs change on settlement.** Plaid replaces pending transaction IDs with new IDs when transactions settle. If you're tagging transactions from recent trips, some IDs from prior sessions may no longer exist. Always re-query by date range, not by cached IDs.
10. **Category IDs: user-created only.** When creating trip-related categories, only user-created category IDs work for `update_transaction`. Plaid taxonomy IDs (e.g., `travel_lodging`) will fail.
11. **Large datasets go to disk.** MCP tool responses >100KB are saved to temp files. Use Python via Bash to process them.
12. **`exclude_transfers` defaults to true.** To see all transactions including transfers (which you'll want to exclude from trip totals anyway), this default is fine. But be aware that payment app transactions (Venmo) may have trip-related spending on the payment app account side, not the bank-stub side — check both.