Three repos for running purchasing decisions through Claude Code

I buy a lot of things — not compulsively, but thoughtfully. Laptops, cameras, power tools, home-automation bits, the odd chair. Over the last year I've drifted into a pattern for running each of those decisions through a Claude Code workspace, and it's gelled into three reusable repos. This post is the pattern, and the templates that go with it.

The pattern: one repo per purchase

The core idea is that a purchasing decision is a research project with a deliverable (the thing you buy), and research projects deserve their own workspace. So every non-trivial purchase gets a fresh repo — my-new-laptop, studio-monitors-2026, cordless-drill. The repo is the purchase. When I've bought the thing, the repo becomes the archive.

That sounds over-engineered until you actually try it. Every purchase accumulates the same debris: screenshots of candidate products, PDFs of spec sheets, notes on which model has which port, a running price check across a few shops. Stuffing that into a Downloads folder and a notes app loses it within a week. Stuffing it into a named repo with a spec.md at the root and an for-ai/ inbox makes it legible to a coding agent, and — more importantly — legible to future-me when I'm doing the same class of purchase again.

Two-tier preferences: standing vs per-purchase

The single best thing I did was split preferences into two tiers. Most purchasing templates I've seen conflate them, and it's exactly why they get unwieldy.

Tier one is standing preferences — the stuff that's true of me regardless of what I'm buying. Country (Israel). Currency (ILS). VAT handling (18%, included). Brands I trust. Brands I avoid, and why. My tolerance for AliExpress, for grey-market imports, for waiting three weeks versus paying double to get it tomorrow. The review-score floor I won't go below. The email address where the final PDF should land. These don't change between a drill and a pair of studio monitors.

Tier two is the per-purchase spec — what this specific decision is about. What I'm buying, the must-haves, the hard nos (a deliberately separate category from must-haves, because "must have X" and "must not have Y" disqualify differently), the budget, the timeline, the priorities for this one decision.

Standing prefs live in memory via a Mem0 MCP server. Per-purchase spec lives in spec.md at the repo root. The /intake command pulls the standing prefs automatically at the start of every new workspace, so I never re-interview myself about whether I'll ship from AliExpress. I answered that once. It's remembered.

Three repos, three layers

The pattern is implemented as three cooperating repos on GitHub. Each does one job.

1. The general template

danielrosehill/Claude-Purchasing-Assistant

This is the country-agnostic template. It's what I copy when I'm buying something where local sourcing isn't the dominant question — digital goods, anything I'd mostly just order online wherever. The flow is /save-preferences once, then per-purchase: /intake → /research → /recommend. It ships with nine named buyer profiles (BIFL, budget, minimalist, power-user, ethical, early-adopter, aesthete, reliability, feature-maximiser) that you can apply singly or in combination — /apply-profile bifl+power-user — as a bias layer on top of the standing prefs. Profiles don't override must-haves or hard nos; they tilt the evaluation.

2. The Israel shopping plugin

danielrosehill/Israel-Online-Shopping-Skill

A Claude Code plugin, not a workspace. This bundles the skills, retailer knowledge, and MCP servers you need to actually shop in Israel competently — which is a very different problem from shopping in the US or UK, because the retail landscape is small, Hebrew-dominant, and full of traps (the VAT-exclusive displayed price, the Eilat-only lower price, the fact that Google Translate reliably gives you the wrong Hebrew noun for half of product categories).

Skills include search-zap (Zap.co.il is the canonical IL price-comparison aggregator, first-pass for almost any SKU), search-main-tech-stores (KSP, Ivory, Bug, TMS), search-major-retailers (appliance/office/audio chains), search-by-category which pulls dynamically from a curated 830-store database I maintain in data/israeli-stores.json, discover-hebrew-term which reverse-looks-up the correct Hebrew retail noun from a known Israeli SKU listing, and compare-to-international which checks what the markup over international RRP looks like.

It bundles Playwright MCP (browser-based, uses your local IP so Israeli pricing and shipping availability are accurate) and Tavily MCP (faster no-browser fallback). VAT detection, Eilat price handling, and domain whitelisting are baked into the skill instructions rather than left as exercises for the agent.

3. The Israel-specific workspace template

danielrosehill/Claude-Israel-Shopping-Recommender-Template

This is the combination: the purchasing-assistant pattern, pre-wired for the Israeli market, with the shopping skills bundled in. The key departure from the general template is that it splits research into two distinct steps.

/shortlist evaluates candidates on product merit alone — brand-agnostic, country-agnostic, "is this actually a good X". /source then runs an Israeli sourcing waterfall on the shortlist only: tier-1 IL retailers first, then broader chains, then Amazon-IL with ships-to-Israel verification, then AliExpress as a pragmatic fallback with a seller-rating floor.

Separating the two is the whole trick. If you conflate "is this a good product" with "can I get this product in Israel at a reasonable markup", you end up rejecting good products because they're hard to source, or accepting mediocre ones because they're conveniently on KSP. Doing merit first and sourcing second means the sourcing constraint is visible as a constraint, not silently collapsed into the ranking.

What the agent actually produces

Every workspace produces the same deliverable: a dated PDF in from-ai/ with a top-3 ranking, a clear #1 pick, a must-haves adherence matrix, a hard-nos matrix, and (for the Israel template) a sourcing channel comparison with per-channel total landed cost. If standing prefs include an email and Resend MCP is wired up, the PDF gets sent. I archive the whole repo after purchase and keep it searchable — which means the next time I'm buying something adjacent, the prior research is a gh repo clone away.

Why this works (for me)

Three reasons, roughly in order of importance.

One: separation of preferences from decisions. The Mem0 layer means each new workspace starts with a warm context of who I am as a buyer. I stop re-litigating my own philosophy with the agent every time. The agent is a researcher; it doesn't also need to be my therapist.

Two: one purchase per repo, end to end. No shared folder of active purchases, no cross-contamination between the drill research and the camera research, no giant monorepo of "shopping". Each decision is a discrete project with its own spec, its own sources, its own outputs. When it's done, it's archived — and findable by name.

Three: geography as a plugin, not a rewrite. The general pattern is country-agnostic; the Israel-specific knowledge is in a plugin and a derived template. If I moved (I won't, but hypothetically), I'd keep the pattern and swap the sourcing plugin. This is also why the shopping plugin and the workspace template are separate repos — the plugin is reusable outside the purchasing pattern (for instance, as a general "help me find this thing in Israel" skill), and the workspace template is reusable outside the Israeli market if you fork it and swap the sourcing step.

Using it

All three repos are public and MIT-licensed. The two workspace templates work via gh repo create --template ... (or my New-Repo-From-Template plugin if you want to stay inside Claude Code). The shopping plugin installs via /plugin install israel-online-shopping@danielrosehill once you've added my marketplace.

Standing prefs assume you've got a Mem0 MCP server configured — if not, the templates fall back to a local file. Usable either way; better with Mem0, because then the prefs follow you across machines and across every future workspace you spin up.

If you fork any of this and bend it to your own market, I'd be curious to see what you change. The split between standing prefs, per-purchase spec, product merit, and sourcing has held up across a lot of different purchases for me — but the specific skills and the retailer list are obviously local.