CardBenefits

• Every perk, credit or balance in an answer comes from the USER data files read in that run, and anything stale (>90 days) or marked UNVERIFIED is flagged inline instead of stated as fact.
• Each recommendation names the card, program or credit, its dollar or points value, and the exact next step the principal takes.
• The data files stay the single source of truth: balances change only on the principal's report or a statement, perks only after a web-verified refresh, credit status only on confirmed usage.
• Money never moves from this skill: transfers, bookings and activations are planned here. Where a booking skill is installed, it carries out a plan only after the principal's yes on the itemized total; otherwise the principal executes.

This skill is procedure only. All personal financial data (card inventory, balances, credits, cross-card strategy, standing travel preferences) lives in the USER tree at <configRoot>/LIFEOS/USER/CUSTOMIZATIONS/SKILLS/CardBenefits/ and is read by path on every invocation (configRoot is $CLAUDE_CONFIG_DIR when set, else ~/.claude). First-time setup, a worked example of each file and a proof command: Setup.md. When Cards.md is missing, stop and point the principal at Setup.md; never answer perks from model memory.

Data files:

• Cards.md — card inventory (issuer, product variant, annual fee, points program) plus the full perk and credit list per card, each with a last-verified date
• Points.md — current points balances, redemption valuations, transfer partners, standing travel preferences (including the default travel party)
• Playbook.md — cross-card strategy: category→card matrix, stacking plays, lounge and status map, combined transfer matrix, sweet spots tied to current balances
• Credits.md — unified credit ledger and deadline calendar across all cards

Account numbers never go in these files. Reference an account by its label in LIFEOS/USER/FINANCES/ACCOUNTS.md when you keep one.

• Perk lists rot. Issuers overhaul premium cards every few years: fee increases, new monthly or semiannual "coupon-book" credits, retired perks. That is why a perk whose last-verified in Cards.md is stale (>90 days) or marked UNVERIFIED gets RefreshPerks first or an inline flag.
• Points balances are principal-reported, never scraped. Issuers offer no API for consumer reward balances. If a balance in Points.md is old, say so and ask; a stale number is never presented as current.
• Product variants share a name. Two editions of one card (for example a business and a personal edition) can carry different perk sets, and statements and account nicknames may show only the short name. Cards.md records which product each card is, resolved from the issuer's dashboard or the product named on a statement; quote the perk set Cards.md names, never one inferred from a label.
• Annual fees on a held card can differ from the marketing page. Grandfathered pricing exists, so the fee charged comes from a statement.

Example 1: Vacation planning

User: "We have 120K bank points — what could a trip to Lisbon look like?"
→ UpdatePoints (record the 120K balance on its program), then PlanRedemption
→ Reads Points.md valuations + transfer partners (airline and hotel partners reachable from that program)
→ Returns 2-3 concrete routings with points cost, cash equivalent, and next steps

Example 2: Which card

User: "Which card should I use for this flight?"
→ ShowBenefits
→ Compares the airfare earn rate and travel protections of each card in Cards.md (for example the Acme Sky Card earning more on airfare but carrying no trip insurance, against the Example Travel Card that includes it)
→ One-line answer with why

Example 3: Credit sweep

User: "What credits am I leaving on the table this year?"
→ CreditSweep
→ Reads `Credits.md`, flags unused/expiring/unregistered credits against today's date, dollars-at-risk up top