procurement-tools

Build a bill of materials — a shopping list written as requirements rather than as products, with stable line ids, quantities, substitution rules and optional references to a spec. Use when a purchase is several items rather than one, when kitting out a space or a job, when a list needs to go to suppliers before every item has been chosen, or when a shopping list needs to survive long enough to be revised. Lines can be described-but-unidentified and still be quotable.

Generate the evaluation-criteria brief from a spec, judge candidates against it one requirement at a time, and render the conformance matrix. Use when candidates have to be checked against a defined requirement set rather than ranked, when several candidates need evaluating in parallel by subagents, when a shortlist needs auditing for what it actually rests on, or when the question is "does this meet A, B and C" rather than "which is best". Answers pass, fail, partial or unknown per requirement and never produces a score.

Rank the candidates that survived conformance evaluation and produce a purchase recommendation — a top three in order, each with product, price and where to actually buy it, followed by category picks such as best budget, best overall and best for features. Use once conformance records exist and the question has moved from "which of these qualify" to "which should I buy", when someone asks for a recommendation or a shortlist ranked, or when a matrix has narrowed the field and a decision is now needed. Ranks only candidates that clear every disqualifying requirement, and states its weighting rather than hiding it in a score.

Decide when a purchasing question has stopped being about the product and become a question about a specific marketplace, and hand it to that marketplace's dedicated plugin instead of answering it here. Use mid-workflow when a comparison, price check or delivery question narrows to one named marketplace. The roster of which marketplaces have plugins is maintained in the shopping plugin's marketplace-plugins skill, not here.

Provision a new purchasing workspace as a standalone repo — scaffold, personalised CLAUDE.md, workspace manifest with a stable id, and a private GitHub repo by default.

Work out which part numbers name the same product across regions, brands and channels — and which look identical but are not. Use when a product found in one market has to be sourced in another, when a manufacturer's model numbers differ between the US and Europe, when the same object is sold under an OEM or private-label brand, when a supplier offers something "equivalent", or when a suspiciously cheap listing may be a different variant. Produces an equivalence record with per-member confidence and the evidence behind it.

Scan a shortlist of products for current price, stock, shipping and landed cost across the user's configured marketplaces, from the user's own machine with the VPN exit set to the country each shop requires. Use when comparing live prices across shops, re-checking whether a shortlisted item has moved, working out what something will actually cost delivered to a specific address, or checking which delivery options make a deadline. Works inside any purchase-research repo.

Render a dated, never-overwritten report (markdown + PDF) from whichever spec, conformance and pricing artefacts a workspace holds.

Assemble a request for quotation from a bill of materials — line descriptions a supplier can actually quote, substitution rules, delivery and terms, and the questions worth asking. Use when a shopping list is ready to go out to suppliers, when comparing quotes from several suppliers on the same basis, or when a purchase needs a supplier's input on what they carry. Produces a JSON RFQ document plus a plain-text version for an email body; branded PDF rendering and sending are handed to the dsrholdings-rfq plugin.

Turn a purchase requirement into a versioned, machine-readable spec.yaml with stable requirement ids, so that evaluation, BOM lines and RFQs all reference the same requirements instead of restating them in prose. Use when a purchase has enough requirements that a paragraph stops being enough, when requirements are changing as research proceeds and the changes need a record, or when subagents will be judging candidates and need something unambiguous to judge against. Also use to amend an existing spec — bumping a revision, retiring a requirement, relaxing a threshold.

Find the manufacturer's own documentation for a specific product — datasheet, technical data, operating manual, declaration of conformity — and extract the published values with the document and revision they came from. Use when a spec claim has to be settled rather than repeated, when retailer listings disagree with each other, when a parameter is not on the product page, or before treating any number as a fact in a comparison. Records what the manufacturer does not publish as well as what it does.

Run several parallel either/or versions of one spec — a budget bar and a premium bar for the same purchase — each independently versioned, and diff what actually differs between them. Use when the answer is "it depends how much we want to spend", when a requirement could reasonably be set at two levels and you want to see what each level finds on the market, when someone asks for a cheap option and a nice option, or when converging variants back to one after the market has answered. Not needed for the ordinary case of one spec with iterative revisions.

Run a technical purchasing investigation end to end — spec as code, manufacturer documentation, part-number equivalence across regions, conformance evaluation, bill of materials, RFQ. Use when a purchase turns on specifications rather than on price or reviews, when requirements are specific enough that most of the market fails them, when sourcing across regions, or when the user asks for in-depth or serious purchasing research. Sequences the atomic sourcing skills and says which steps this particular purchase can skip.

Add a purchase-decision folder inside an existing procurement repo instead of a standalone repo — same scaffold and manifest, never a nested git. The repo sibling is new-workspace.