should-i-buy · diff

git:20260419.54ca802 to git:20260419.cb9fd9c

65 added, 12 removed. Audit A to B.

---

name: should-i-buy

description: >-

Helps the user decide on a purchase by taking the product links they're

considering, asking a couple of sharp clarifying questions about their needs

and circumstances, then opening each link in real Chrome via the

Claude-in-Chrome extension to extract price, specs, ratings, reviews, return

policy, and shipping. Produces a modern 2026 HTML report with a side-by-side

comparison, pros/cons per option, an external-review pulse-check, and a clear

verdict (buy / wait / pick X over Y / skip). Saves each decision session to

its own folder. Learns from thumbs-up/down feedback — brand, budget style,

deal-breakers, and past regrets personalize future verdicts. Use when the

user pastes one or more product URLs and wants a second opinion before

buying, wants a comparison between links they already shortlisted, or asks

"should I buy this / which one should I get?".

argument-hint: "<url> [more urls...] [--for <context>] [--budget <range>] [--use <use-case>] [--deadline <when>] [--notes <text>]"

disable-model-invocation: true

allowed-tools:

- AskUserQuestion

- Read

- Write

- Edit

- Bash(mkdir *)

- Bash(ls *)

- Bash(open *)

- Bash(curl *)

- Bash(date *)

- Bash(pwd)

- Bash(echo *)

- WebSearch

- WebFetch

- mcp__claude-in-chrome__tabs_context_mcp

- mcp__claude-in-chrome__tabs_create_mcp

- mcp__claude-in-chrome__navigate

- mcp__claude-in-chrome__get_page_text

- mcp__claude-in-chrome__read_page

- mcp__claude-in-chrome__javascript_tool

- mcp__claude-in-chrome__find

- mcp__claude-in-chrome__resize_window

---

## 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 <url> [more urls...] One or more product links

/should-i-buy [...] --for <context> Who/what this is for (e.g., "me, daily driver")

/should-i-buy [...] --budget <range> Budget constraint (e.g., "under $200")

/should-i-buy [...] --use <use-case> How you'll actually use it

/should-i-buy [...] --deadline <when> "by Friday", "this month" — affects wait-for-sale advice

/should-i-buy [...] --notes <text> 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:

```markdown

# /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):

```

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 < 1.0.36. |

| "Browser extension is not connected" | Restart Chrome and Claude Code, then run `/chrome` → "Reconnect extension". |

| Works once, then dies after a pause | Extension service worker went idle. Run `/chrome` → "Reconnect extension". |

| "Receiving end does not exist" | Same as above — reconnect. |

| "No tab available" | Ask Claude to create a new tab, then retry. |

| First-time connection fails | Restart Chrome — the native messaging host config is picked up on Chrome startup. |

### Confirm it works

Once the user says they're set up, run the preflight (Step 0 below). If it passes, say:

```

Connection good. You're ready — paste your links:

/should-i-buy <url> [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 <context>` — who/what this is for

- `--budget <range>` — budget constraint

- `--use <use-case>` — concrete usage scenario

- `--deadline <when>` — urgency (affects wait-for-sale advice)

- `--notes <text>` — 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 "<url>"`.

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 `"<exact product name>" 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 `"<product>" price history` or `"<product>" 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 color + typography to signal meaning

+ - **Interactive, one-file** — inline `<script>` for live filtering; NEVER split into multiple HTML files. The "open anywhere, no server" property matters

Structure:

- 1. **Header** — inline the SVG from `~/.claude/skills/should-i-buy/icon.svg` at ~32px next to the H1 with `color: var(--accent)` so it themes with light/dark mode. Title reflects the decision (e.g., "Standing desk under $500 — REI vs. Amazon"). Date, context, budget as pill chips.

- 2. **Verdict hero** — big, unmissable. One of:

- - `BUY THIS: {option}` + 2-3 bullet reasons + score

- - `PICK {option A} OVER {option B}` + the single deciding factor

- - `WAIT — {reason}` + recommended trigger ("buy when it drops under $X")

- - `SKIP ALL — {reason}` + one-line advice on what to search for instead

- 3. **Side-by-side comparison table** (if 2+ options) — spec-by-spec, with winner per row lightly highlighted

- 4. **Option deep-dives** — one section per option with:

+ 1. **Header** — inline the SVG from `~/.claude/skills/should-i-buy/icon.svg` at ~32px next to the H1 with `color: var(--accent)` so it themes with light/dark mode. Title reflects the decision (e.g., "Standing desk under $500 — REI vs. Amazon"). Date + a muted timestamp.

+ 2. **Interactive context chips** (below the title) — every input that shaped the verdict is a live chip, not a label:

+ - `Priority: {value}` — clickable, cycles through the Q1 options (or opens a small inline dropdown)

+ - `Dealbreakers: {chip list}` — each dealbreaker is a separate × removable chip; plus an inline "+ add" affordance to toggle others back on

+ - `Budget style: {value}` — clickable, cycles value / premium / bargain

+ - `Context: {context}` — display-only (can't usefully re-filter free-text)

+ - Chip styling: pill shape, subtle border, cursor pointer on the interactive ones, hover state. Priority chip gets the warm accent treatment when selected.

+ 3. **Verdict hero** — the big unmissable card. Layout **must** be a two-column split on desktop, stacked on mobile:

+ - **Left column** — the winner's `hero.png` rendered as a large square (~280-320px on desktop, full-width on mobile), rounded corners, subtle border. This is the quick-identify surface.

+ - **Right column** — the verdict prose. One of:

+ - `BUY THIS: {option}` + 3-5 bullet reasons

+ - `PICK {option A} OVER {option B}` + the single deciding factor + when-to-flip note

+ - `WAIT — {reason}` + recommended trigger ("buy when it drops under $X")

+ - `SKIP ALL — {reason}` + one-line advice on what to search for instead

+ - Below the split: runner-up and skip mini-cards with 64-80px thumbnails each (hero.png of those options), single-line framing ("Runner-up: X — flip to this if Y", "Skip: Z — triggers your fake-wood dealbreaker").

+ 4. **Stale banner + gray-out on chip change** — CRITICAL UX rule. The verdict card stores its original chip values in a data attribute. Inline JS listens for changes on the interactive chips. When ANY current chip value differs from the original:

+ - Add a `.stale` class to the verdict card: `opacity: 0.55; filter: saturate(0.6)`.

+ - Render a banner above the verdict: *"Verdict was computed with {original values}. Re-run `/should-i-buy` for a fresh call with these filters."* (in a subtle warm amber, not alarming red).

+ - The verdict prose stays fully readable — the gray-out signals staleness, it doesn't hide.

+ - The comparison table (below) DOES re-sort live — so the user can preview the new weighting while the verdict itself stays preserved as "this was the original reasoning."

+ - Clicking a "restore original" link in the banner resets all chips and un-stales the verdict.

+ 5. **Side-by-side comparison table** (if 2+ options) — spec-by-spec grid. Every row shows all options; the winner on that row is lightly highlighted. Column headers are clickable for re-sort (by score, price, rating). Rows for options that currently fail any active dealbreaker fade to `opacity: 0.4` rather than disappearing — the user still sees what's being filtered out and why.

+ 6. **Option deep-dives** — one section per option with:

- Hero image

- - Price, rating, review count, score ring

+ - Price, rating, review count, score ring (pure-CSS conic-gradient, no libs)

- Pros (3-5 bullets) and Cons (3-5 bullets)

- One positive + one critical review quote

- External review excerpt (if found) — cite the source

- "Good to know" row: warranty, return window, shipping, stock

- Deep link to the product page

- 5. **Deal intel** (if price history gathered) — sparkline of price trend, note any upcoming sale events

- 6. **Footer** — sources, criteria recap, "rate this verdict" prompt → `/should-i-buy feedback`

+ 7. **Deal intel** (if price history gathered) — sparkline of price trend (pure SVG), note any upcoming sale events.

+ 8. **Footer** — sources, criteria recap, "rate this verdict" prompt → `/should-i-buy feedback`.

+ Inline JS responsibilities (keep it ~150 lines max, vanilla, no framework):

+ - Read the original chip state from a `<script type="application/json" id="session">` payload embedded in the page

+ - Wire click handlers on interactive chips

+ - On any chip change: compute `isStale = current !== original`, toggle the `.stale` class and banner visibility

+ - On any chip change: recompute scores client-side using the same weighting logic used server-side (ship a small `scoreOption(option, weights, dealbreakers)` function in the JSON payload's `_recompute` hint, or inline it), re-sort the comparison table, re-dim filtered rows

Reference `~/.claude/skills/should-i-buy/reference/report-template.html` if it exists (load on demand; otherwise generate from scratch following the aesthetic above).

### Step 8 — Finalize and open

1. Write `sources.md` — every URL visited + one-line rationale per extraction decision.

2. Print the final CLI report (match tone preference):

```

Verdict — {kebab decision}

{one-line verdict}

Top pick: {title} → ${price} (score {N}/100)

Runner-up: {title}

{optional third line — "Skip:" or "Wait until:"}

Folder: {output-root}/{slug}/

Report: {output-root}/{slug}/report.html

Open it? (y/N) — or rate the call with: /should-i-buy feedback

```

If `open-report: true`, run `open {output-root}/{slug}/report.html`.

+ ### Step 8.5 — Offer to save as a docs example

+ After opening the report, ask ONCE via AskUserQuestion (skip if the user has said "don't ask again" in the past — save that as a preference):

+ > **Save a copy of this report as a reference example in the skill's `examples/` folder?** The next time you run `/publish-skills` it'll be pushed to the public skills repo and linked from the README, so anyone browsing `/should-i-buy` can see what the output actually looks like.

+ Options: `Yes` / `No, this one` / `Never ask` / `Edit first` (opens the file so the user can scrub anything sensitive before saving).

+ On **Yes**:

+ 1. Derive a clean example filename from the decision slug: `{kebab-summary}.html` (strip the date prefix — examples don't need chronology).

+ 2. Copy `{output-root}/{slug}/report.html` → `~/.claude/skills/should-i-buy/examples/{filename}.html`.

+ 3. If `~/.claude/skills/should-i-buy/examples/index.md` doesn't exist, create it with a header; append a link entry: `- [{decision title}]({filename}.html) — {one-line verdict summary}`.

+ 4. Remind the user: *"Saved. This will be published publicly when you next run `/publish-skills` — if there's anything sensitive (recipient name, personal notes, private URLs) in the report, open `examples/{filename}.html` and redact now."*

+ On **Edit first**: run `open -e {output-root}/{slug}/report.html` so the user can hand-scrub before saving, then re-prompt.

+ On **Never ask**: save `ask-save-example: never` in `preferences.md`.

+ The `examples/` folder is already picked up by `/publish-skills` (it copies `examples/` recursively per skill), so no separate publish flow is needed.

### Step 9 — Invite feedback

End with a soft prompt (not a blocker):

> When you've decided (or bought it and lived with it a week), run `/should-i-buy feedback` and tell me if I called it right. Honest signal here makes future verdicts sharper — especially if you regret something I approved.

## Feedback & learning

When invoked as `/should-i-buy feedback`:

1. Find the most recent decision folder under `{output-root}/`.

2. Ask via AskUserQuestion (fire once, multi-question):

- **Did I call it right?** (nailed it / close / missed / bought something else entirely / haven't decided yet)

- **What should I weight more next time?** (price / brand reputation / reviews / return policy / specs-for-use-case / aesthetic / other)

- **Any regret signal?** (free text — e.g., "returned it, too heavy", "bought option B instead because X")

3. Append to `~/.claude/skills/should-i-buy/feedback-journal.md`:

```markdown

## {decision slug} — {date}

- Verdict given: {what I recommended}

- User outcome: {nailed/close/missed/different/pending}

- Weight more: {factors}

- Regret / correction: {free text}

- Signal extracted: {one-line generalization, e.g., "over-weighted brand, under-weighted in-hand weight for mobile gear"}

```

4. If a clear pattern emerges across 3+ sessions (same dealbreaker hit, same brand regret, same wait-vs-buy miscall), promote it from the journal to the `## Learned` section of `preferences.md`. Mention the promotion: "Noticed {pattern} across recent decisions — saving that as a standing signal."

The journal is human-editable. Respect whatever the user writes there directly.

## Filename / folder naming rules

- Decision folder: `{YYYY-MM-DD}-{kebab-summary}` — 60 chars max in the summary half, frame around the *decision* not the product (e.g., `standing-desk-under-500-rei-vs-amazon`, not just `standing-desk`)

- Option folder: `{kebab-product-short-name}` — 40 chars max, derived from product title (not a counter); for Amazon items without a clean name, fall back to `{brand}-{model}`

- Never append `-2`, `-3` — if two options would collide, differentiate by brand or model number

## Principles

1. **Verdict-forward** — the report exists to deliver a decision, not to present data neutrally. Say what to do, then justify.

- 2. **Minimum interruption onboarding** — at most two sharp questions up front; infer the rest from URLs and feedback history.

+ 2. **Hero image leads the verdict, not text** — the winner's product image is the quick-identify surface. If the user has to read to know which one won, the card failed.

+ 3. **Interactive chips, gray-out on change** — input chips are live, not labels. When the user re-weights mid-report, the comparison table re-scores live, but the verdict card grays out and shows a "computed under different assumptions" banner. Never silently recompute the verdict — the original call is preserved; a fresh call requires a fresh run.

+ 4. **One HTML file, inline JS, vanilla only** — no external scripts, no framework. The report must open anywhere without a server.

+ 5. **Minimum interruption onboarding** — at most two sharp questions up front; infer the rest from URLs and feedback history.

3. **Real Chrome, explicit tabs** — always `tabs_context_mcp` first; always create a new tab with `tabs_create_mcp` rather than reusing one from a prior session.

4. **Structured over scraped** — prefer `javascript_tool` returning clean JSON over dumping `get_page_text`. Smaller context, higher accuracy.

5. **Per-decision isolation** — one folder per session; never delete or overwrite anything outside the current decision folder.

6. **Honest about gaps** — if a page blocked extraction, say so in the report; don't fake confidence.

7. **Learning is explicit and editable** — feedback lives in a human-readable journal; the user can read, edit, or wipe it anytime. Past regrets are the single highest-signal input for future verdicts.

8. **Graceful degradation** — a blocked page or a failed screenshot is logged and skipped; the verdict ships with what was possible.

9. **Stop on dialogs** — never click elements that trigger browser alerts/confirms/prompts; the extension becomes unresponsive if a modal appears.

10. **Warm, terse CLI tone** — direct sentences, no corporate filler, no emoji-heavy output; one friendly line at start and end is enough.