Should I Buy

Preferences

On startup, use Read to load ~/.claude/skills/should-i-buy/preferences.md. If missing, treat as first-run (see First-time detection below).

Defaults when no preferences exist:

• output-root: ~/Desktop/should-i-buy/ (confirmed on first run)
• currency: USD
• budget-style: value (value / premium / bargain — shapes the verdict weighting)
• tone: friendly-cli (terse, direct, warm — like a friend who actually knows the category)
• open-report: true (auto-open the HTML report when done)
• verdict-style: decisive (decisive / balanced — decisive means I pick one and say why; balanced lays out the trade-off)

Also load ~/.claude/skills/should-i-buy/feedback-journal.md if present — it contains thumbs-up/down on past verdicts. Summarize its signal (e.g., "regretted buying X for Y reason", "consistently prefers refurb over new") and carry that into the current verdict.

Context

On startup, use Bash to detect: today's date (date +%Y-%m-%d), and whether the output-root folder exists (ls or absence). Do not fetch the shared URLs yet — that happens after we've clarified the ask.

Command routing

Check $ARGUMENTS:

• help → show help, stop
• config → run config flow, stop
• reset → delete preferences + feedback journal, confirm, stop
• feedback → collect thumbs-up/down on the most recent decision (see Feedback section), stop
• history → list recent decision folders with titles and dates, stop
• setup or preflight → run the Chrome extension setup/onboarding flow (see Setup section), stop
• anything else (one or more URLs, optionally with flags) → run the skill (starts with a preflight check — see Step 0)

Help

should-i-buy — Paste links, get a verdict with a 2026-aesthetic comparison report

Usage:
  /should-i-buy  [more urls...]                 One or more product links
  /should-i-buy [...] --for                 Who/what this is for (e.g., "me, daily driver")
  /should-i-buy [...] --budget                Budget constraint (e.g., "under $200")
  /should-i-buy [...] --use                How you'll actually use it
  /should-i-buy [...] --deadline               "by Friday", "this month" — affects wait-for-sale advice
  /should-i-buy [...] --notes                  Constraints, dealbreakers, leanings
  /should-i-buy config                               Set preferences
  /should-i-buy reset                                Clear preferences + feedback journal
  /should-i-buy feedback                             Rate the last verdict (teaches the skill)
  /should-i-buy history                              List past decision folders
  /should-i-buy setup                                Walk through Chrome extension setup
  /should-i-buy help                                 This help

Examples:
  /should-i-buy https://www.amazon.com/dp/B0XXXXXX https://www.rei.com/product/123
    --for "me, weekend hiking" --budget "under $180"
  /should-i-buy https://bestbuy.com/... --use "home office, 2 monitors" --notes "USB-C PD required"
  /should-i-buy https://apple.com/shop/buy-mac/mac-mini --deadline "before WWDC"

Output:
  {output-root}/{YYYY-MM-DD}-{kebab-title}/
    ├── report.html              ← modern 2026 single-file report with verdict
    ├── data.json                ← structured data (options, scores, verdict)
    ├── options/
    │   ├── {slug-1}/
    │   │   ├── hero.png         ← product image
    │   │   ├── page.png         ← screenshot of listing (best-effort)
    │   │   └── notes.md
    │   └── ...
    └── sources.md               ← URLs visited + reasoning trail

Current preferences:
  (loaded from preferences.md)

Config

Use AskUserQuestion to collect:

1. Output root — where should decision folders live? (default: ~/Desktop/should-i-buy/)
2. Currency & region — currency symbol and Amazon TLD (amazon.com / .co.uk / .ca / .de / ...)
3. Budget style — value (best bang-for-buck), premium (quality first, price second), bargain (cheapest that clears the bar)
4. Verdict style — decisive (I pick one and say why) or balanced (I lay out the trade-off and let you choose)
5. Standing dealbreakers — categories/brands to always flag negatively (free text)
6. Tone — friendly-CLI (terse, warm), detailed (more explanation), minimal (facts only)

Save to ~/.claude/skills/should-i-buy/preferences.md in the format:

# /should-i-buy preferences
Updated: {date}

## Defaults
- output-root: {path}
- currency: {USD|EUR|CAD|...}
- amazon-tld: {com|co.uk|ca|...}
- budget-style: {value|premium|bargain}
- verdict-style: {decisive|balanced}
- tone: {friendly-cli|detailed|minimal}
- dealbreakers: {free text}

## Profile (optional — edit freely)
- Favored brands:
- Avoided brands:
- Aesthetic: (minimal, maximalist, vintage, tech-forward, etc.)
- Sustainability: (important / nice-to-have / not a factor)
- Risk tolerance: (safe/proven only / will try new/indie)
- Return behavior: (rarely returns / returns if imperfect — affects how heavily return policy weighs)
- Past regrets: (free text — things you wish you hadn't bought and why)

## Learned

After saving, confirm with a warm one-liner: "Saved. I'll use this as the baseline — and I'll keep sharpening as you rate my verdicts."

Reset

Delete both ~/.claude/skills/should-i-buy/preferences.md and ~/.claude/skills/should-i-buy/feedback-journal.md. Confirm: "All cleared. I'll start from scratch on the next decision."

First-time detection

If no preferences file exists, show a warm onboarding (not a blocker):

First time running /should-i-buy — quick intro:

  Paste me one or more product links and I'll help you decide. I open each
  link in a real Chrome window you control, pull price / specs / reviews /
  return policy, cross-check a few independent reviews, and write a single-file
  HTML report with a clear verdict (buy / wait / pick X / skip).

  I ask at most two sharp questions up front — your context and your
  dealbreakers — then I get out of your way.

  I get smarter over time. After each decision you can run
  `/should-i-buy feedback` and tell me if I called it right. I save that and
  factor it into future verdicts (past regrets are especially useful signal).

  To browse the web, I need the Claude in Chrome extension. If you haven't
  set it up yet, run:  /should-i-buy setup
  Otherwise, continue and I'll auto-check the connection.

Then proceed to Step 0 (preflight). After the first successful decision, ask inline if they want to save any quick prefs (budget style, verdict style, dealbreakers) — don't force the full config flow.

Setup — Chrome extension onboarding

When invoked as /should-i-buy setup (or when Step 0 preflight fails and the user asks for help), walk through the Chrome extension setup. Reference: the official docs at https://code.claude.com/docs/en/chrome.

Prerequisites checklist (print this)

Before we go:

  1. Browser        Google Chrome or Microsoft Edge
                    (Brave, Arc, other Chromium browsers: not yet supported)
                    Windows WSL: not supported

  2. Plan           A direct Anthropic plan — Pro, Max, Team, or Enterprise
                    (Free tier and third-party providers like Bedrock/Vertex
                     don't have Chrome integration)

  3. Claude Code    Version 2.0.73 or higher
                    Check:  claude --version

  4. Extension      "Claude" by Anthropic, version 1.0.36 or higher
                    Install:
                    https://chromewebstore.google.com/detail/claude/fcoeoabgfenejglbffodgkkbkcdhcgfn
                    After install, pin it via the puzzle-piece icon.

Use Bash to run claude --version and surface the result so the user knows where they stand.

Enable Chrome in Claude Code

Tell the user exactly what to type (they run these themselves — you can't run slash commands for them):

Next:

  A.  Inside Claude Code, type:   /chrome
      Select "Enable" — or "Enabled by default" to auto-enable every session.

  B.  To verify, type:            /mcp
      Look for "claude-in-chrome" in the list.

  C.  Site permissions are managed inside the Chrome extension itself
      (click the extension icon → settings). Allow whichever sites you
      actually shop on — common ones:
        amazon.com, apple.com, bestbuy.com, rei.com, bhphotovideo.com,
        target.com, walmart.com, costco.com, and any specialty retailer
        your links point to.

Quick troubleshooting

If the user reports trouble, walk through in this order (from the official docs):

| Symptom | Fix | |---|---| | "Extension not detected" | Open chrome://extensions, confirm it's installed and enabled. Update if version [more urls...]

## Workflow

### Step 0 — Preflight (Chrome extension check)

Before anything else, verify the Claude-in-Chrome extension is connected. Without it, the decision can't run.

1. Call `mcp__claude-in-chrome__tabs_context_mcp`.
2. **If it succeeds** → extension is live. Continue silently to Step 1.
3. **If it fails** (any error — "extension not detected", "receiving end does not exist", etc.) → do NOT retry blindly. Stop and show:

Hmm — the Claude-in-Chrome extension isn't responding.

Common causes: • Extension not installed → https://chromewebstore.google.com/detail/claude/fcoeoabgfenejglbffodgkkbkcdhcgfn • Chrome integration not enabled in this session → run /chrome and select "Enable" • Extension idle → run /chrome → "Reconnect extension" • First time ever → restart Chrome once after enabling, then retry

Need the full walkthrough? Run: /should-i-buy setup

Then stop. **One retry allowed**: if the user replies "retry" or "try again", call `tabs_context_mcp` once more. If it still fails, route them to `/should-i-buy setup`.

### Step 1 — Parse the ask

Extract from `$ARGUMENTS`:
- **URLs** — every token starting with `http://` or `https://` (dedupe, preserve order)
- `--for ` — who/what this is for
- `--budget ` — budget constraint
- `--use ` — concrete usage scenario
- `--deadline ` — urgency (affects wait-for-sale advice)
- `--notes ` — extra constraints or leanings

**Validation gates (fail fast):**
- No URLs → ask once: "Paste one or more product links and I'll take it from there." Stop.
- One URL → single-option mode (verdict is buy/wait/skip, no comparison).
- 2-5 URLs → comparison mode (the sweet spot).
- 6+ URLs → warn: "That's a lot to compare. Want me to shortlist the top 4 after a quick glance, or run the full gauntlet?" — default to full if the user says go.

### Step 2 — Ask the two sharp questions

Fire **one** AskUserQuestion call with up to two questions. Skip any question that's already answered by flags. The goal is minimum interruption, maximum signal.

- **Q1 (context)** — "What's the single thing that most matters here?" Options tailored to the category if detectable from the URLs (e.g., for laptops: battery life / raw performance / portability / screen quality / price). If category is unclear, offer: price / quality / specific feature / aesthetic / speed of delivery / other.
- **Q2 (dealbreakers)** — "Anything that would make an option an instant no?" Options: price over budget / brand I don't trust / no good return policy / out of stock / poor reviews on my use case / none of the above.

If the user has a feedback-journal with strong signal, mention it in one line before asking: e.g., "Your past regrets say you over-index on brand reputation — I'll weight that. Still want to answer:"

### Step 3 — Echo the plan

Show a crisp plan and wait for `go` (or a tweak):

Plan: ├── Options: {N} links ({domains summary}) ├── What matters most: {answer} ├── Dealbreakers: {answer} ├── Scoring factors: {derived — 3-5, weighted per answers} └── Verdict style: {decisive|balanced}

Reply 'go' to open the links, or tweak any of the above.

This is the only hard gate. Keep it fast.

### Step 4 — Create the decision folder

Generate a slug from the ask: `{YYYY-MM-DD}-{kebab-summary-max-60chars}`. Summary should capture the decision, not just the product, e.g.:
- `2026-04-19-standing-desk-under-500-rei-vs-amazon`
- `2026-04-19-macbook-air-m4-13-vs-15`
- `2026-04-19-hiking-boots-weekend-use`

mkdir -p {output-root}/{slug}/options

**Clear policy**: only the per-decision folder is created fresh. Never delete sibling folders or anything outside `{output-root}/{slug}/`.

### Step 5 — Open each link and extract

1. Call `tabs_context_mcp` to see current tabs — never reuse a prior session's tab IDs.
2. For each URL, create a new tab with `tabs_create_mcp`. Resize to `1440x900` on the first tab for consistent screenshots.
3. For each option page, extract via `javascript_tool` (prefer structured JSON over `get_page_text`):
   - Full title, brand, model
   - Current price + MSRP + any on-sale signal
   - Key specs (category-aware — for a laptop: CPU/RAM/storage/screen/battery; for a chair: dimensions/weight-capacity/materials; etc.)
   - Rating + review count + star-distribution if visible
   - 3-5 top positive review snippets (highest-rated helpful reviews, verified purchase if marked)
   - 3-5 top negative/critical review snippets
   - Return window + shipping cost + ship-by date
   - Stock status (in stock / low stock / backorder / out)
   - Warranty if surfaced
4. **Save hero image**: extract the main image URL via `javascript_tool`, then `curl -L -o {options}/{slug}/hero.png ""`.
5. **Capture a page snapshot** (best-effort): try via `javascript_tool` with `html2canvas` dynamically loaded, or skip silently if it fails.
6. **Write `{options}/{slug}/notes.md`** — one short file per option with all extracted fields.

**Cross-source reviews** (adds credibility, do for each finalist):
- Run one `WebSearch` for `"" review` — look for Wirecutter, Rtings, Consumer Reports, Reddit threads, reputable YouTubers.
- Quote 1-2 short excerpts in the report.
- For deal-check: one `WebSearch` for `"" price history` or `"" sale` — helps the wait-vs-buy-now call.

**Graceful degradation**: if a page blocks extraction (common on some retailers), log the gap in `sources.md` and continue with partial data. Note the gap in the report so the verdict is honest about what's known.

### Step 6 — Score, compare, and verdict

Compute a composite score per option (0-100) using the weighted factors from Step 3. Then compose the verdict using the user's `verdict-style`:

**Decisive style** — pick one and say why in 2-3 sentences. Always name the runner-up and what would flip the call.

**Balanced style** — lay out the trade-off matrix (option A wins on X, option B wins on Y) and surface the decision criterion back to the user.

**Special verdicts** to consider:
- **Wait** — if price history shows a regular sale pattern and deadline allows, say so.
- **Skip all** — if none clear the dealbreakers, say so directly; don't force a pick.
- **One clear winner** — if score gap > 15 points, be direct about it.
- **Near-tie** — if top two are within 5 points, say "coin flip on specs — pick the one with the better return policy."

Write `data.json` with the full structured data: options, specs, scores, verdict, reasoning, sources, query metadata.

### Step 7 — Generate the HTML report

Generate a single self-contained `report.html` (no external JS dependencies — inline everything). Aesthetic targets:

- **Modern 2026** — clean typography (system font stack + Inter-style weights), generous whitespace, soft shadows, subtle gradients, rounded corners (12-16px), pill badges
- **Light + dark mode** via `prefers-color-scheme` — CSS variables only
- **Mobile-responsive** — single-column layout on small screens
- **Verdict-forward** — the hero of the page IS the verdict, not the product grid
- **Data-dense but scannable** — pill chips for key specs, inline stars for ratings, mini bar charts for review distribution (pure CSS, no libs), side-by-side spec table for comparison mode
- **No emoji soup** — use

…

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [mostafa-drz](https://github.com/mostafa-drz)
- **Source:** [mostafa-drz/claude-skills](https://github.com/mostafa-drz/claude-skills)
- **License:** MIT

Install and usage instructions live in the source repository linked above.