Card Rate

Return the earning-structure view of one exact card variant in compact format.

When To Use

When the user asks about a card's earning rates, rewards categories, multipliers, or points structure. Trigger phrases: "card-rate", "earning rates", "how many points", "what categories", "rewards rate".

Workflow

1. Resolve card identity — normalize the input and match to one exact card variant.
2. Search — use WebSearch by default. If BRAVE_API_KEY is available and curl exists, you may use one Brave Search API call instead. Classify results as issuer or secondary by domain.
3. Fetch pages — use WebFetch by default to fetch the top issuer URL and top 1 secondary URL from results.
4. Pace any follow-up searches — if another search is needed, wait briefly instead of bursting requests.
5. Compile — combine fetched page content + search snippets + training knowledge.
6. Confidence — flag uncertain or conflicting claims.

Step 1: Card Identity Resolution

Normalize the card name and resolve to an exact issuer + family + variant.

Common Abbreviations

Only shorthands and ambiguous names need entries here. Cards with full, unambiguous names (e.g., "Chase Marriott Bonvoy Boundless", "Chase United Explorer", "American Express Hilton Honors Aspire") are resolved via search — no table entry needed.

Business vs Personal

Both personal and business credit cards are supported. If the user specifies "business" or "biz", resolve to the business variant. If a card name exists in both versions and the user does not specify, treat as ambiguous and ask.

Ambiguity Rules

• If the input maps to 2+ plausible variants, return a numbered choice list and stop.
• If no match exists, return: "Could not match a card. Try including the full card name with issuer."

Supported Issuers

American Express, Bank of America, Barclays, Bilt, Capital One, Chase, Citi, Discover, Robinhood, U.S. Bank, Wells Fargo.

Step 2: Search

Use the platform's WebSearch and WebFetch tools by default. If BRAVE_API_KEY is available and the runtime also provides curl, you may use Brave Search API instead for faster and more repeatable search results.

Optional Brave template:

curl -sS "https://api.search.brave.com/res/v1/web/search?q=CARD+NAME+earning+rates+categories&count=10" \
  -H "X-Subscription-Token: $BRAVE_API_KEY"

Parse the JSON response — results are in .web.results[] with .title, .url, .description fields. Classify results by domain: issuer pages (use Issuer Domains table below) vs approved secondary sources. Use up to 1 secondary source (prefer bankrate.com, then thepointsguy.com) for merchant-coding caveats.

Search Budget Rule

Treat search as scarce and paced. Built-in web search is the default path; if Brave mode is used, it may rate-limit after only a few closely spaced requests.

• Start with one search.
• Fetch the issuer and approved secondary pages before deciding whether any additional search is needed.
• If an extra search is needed, wait about 2 to 5 seconds first.
• If Brave returns 429, wait about 8 to 15 seconds and retry once.
• If Brave is unavailable, continue with WebSearch + WebFetch.
• If it still fails, continue with the best evidence already gathered and note the limitation in ## 📋 Confidence Notes.

Issuer Domains (for classifying results, not constraining searches)

Step 3: Fetch Pages

Pick the top issuer URL and top 1 secondary URL from the search results. Fetch both in parallel with WebFetch.

An approved secondary page means a URL whose hostname matches the preferred secondary domains named in this skill. Do not fetch or cite secondary pages from any other domain.

URL Safety Rules

• Prefer WebFetch for page retrieval. Use curl only for the optional Brave Search API calls above, not for arbitrary result URLs.
• Never execute a shell command that interpolates a raw URL taken directly from search results.
• Only fetch URLs when all of the following are true:
  1. scheme is https
  2. hostname matches a supported issuer domain or an approved secondary domain from this skill
  3. the URL is being passed to WebFetch, not inserted into a shell pipeline
• If a result URL fails those checks, skip it and use the next valid result.

Search snippets are too shallow for earning details — the full page has complete rate tables and caps. Combine the fetched page content + search snippets + training knowledge.

Required Output Sections

## 📊 Rate Summary

Base earn rate, point currency, key mechanic (e.g., rotating categories, pay-over-time requirement).

## 📈 Earning Categories

Each bonus category with multiplier, numbered list. Include activation requirements if applicable.

## 🚫 Caps And Exclusions

Annual/quarterly caps, excluded merchant types, category restrictions.

## 📋 Confidence Notes

Flag any detail that may have changed since training data.

## 🔗 Sources

Numbered list of URLs fetched, as markdown hyperlinks with short "Site - Topic" labels.

Output Rules

• Use one emoji per section heading and numbered lists
• When listing credits, fees, or any monetary amounts, sort from highest to lowest dollar value. for categories.
• Keep content to condensed facts — no prose padding.
• Omit the Card Identity section when the match is confident.
• Do not show YAML blocks in output.
• End every report with a ## 🔗 Sources section listing each URL fetched during research as a markdown hyperlink with a short "Site - Topic" label, e.g. [Chase - Sapphire Preferred](https://...).

Confidence Definitions

• confirmed: supported by issuer terms or multiple approved sources
• unconfirmed: plausible but not fully resolved
• conflicting: sources disagree on a material fact