---
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
metadata:
  trigger: "Pasting one or more product links and asking whether to buy, which one to pick, or whether to wait."
  tags: "shopping, decision, browser-automation, claude-in-chrome"
---

## 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
<!-- Patterns auto-appended as they emerge from feedback journal -->
```

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 < 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 + 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 (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

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