| name | rfq-package |
| description | 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. |
| allowed-tools | Read, Write, Edit, Glob, Grep, Bash(python3 *), Bash(ls *), Bash(cat *), Bash(mkdir *), Bash(date *) |
RFQ package
Turns a BOM into a document a supplier can quote against, and — where several
suppliers are being asked — into the same document for each, so the quotes
that come back are comparable.
This skill builds the content. It does not render a branded PDF and does not
send anything. See "Where this stops", below.
Requires a bom.yaml — see the bom-build skill.
1. Decide the scope of the request
One RFQ per supplier per coherent set of lines. A BOM spanning three trades sent
whole to one supplier gets a partial quote with silent omissions, which is worse
than three focused requests. Use BOM groups:
python3 "${CLAUDE_PLUGIN_ROOT}/scripts/spec_tools.py" rfq bom.yaml \
--vendor "Supplier name" --number RFQ-2026-014 --group measurement \
-o rfq/RFQ-2026-014.json
Contingent lines are dropped automatically. Optional lines are kept and marked
to be priced separately.
2. Read the generated document before it goes anywhere
The projection is mechanical; the judgement is not. Check:
Descriptions stand alone. The supplier has not read your spec. Every line
must be quotable by someone who knows their catalogue and nothing about your
project. If a description only makes sense next to spec.yaml, rewrite it in
the BOM and regenerate — not in the RFQ, or the two drift.
The substitution rule is right per line. Generated notes say what latitude
the supplier has. A blanket "no substitutions" reads as inflexible and loses you
the alternative they would otherwise have proposed.
The purpose statement is there and is honest. Suppliers quote better against
a stated purpose, and it is what lets them propose something that actually
works. It also protects you: a supplier who knows what the kit is for will often
say "that won't do what you want" before taking your money.
Quantities and units match how this trade sells. Per unit, per pack, per
metre. Get it wrong and the cheapest quote is the one that misread it.
3. Target prices are opt-in, and ask first
--targets carries target_price from the BOM into the document. It is off by
default because it anchors the supplier: quotes cluster just under a stated
target, including quotes that would have come in below it.
It is worth including when the target is a genuine ceiling and you would rather
be told "not at that price" than receive an unaffordable quote — for a
long-lead or made-to-order item, that saves a round trip. Ask the user which
they want rather than deciding for them.
4. Sharpen the questions
The generated set is a floor: stock, lead time, alternatives, price breaks, what
is included in the price. Add what this purchase actually turns on:
- Whether the regional part number they stock is the one that was evaluated —
attach the equivalence finding if there is one.
- Country of manufacture, where it decides warranty or lead time.
- Whether a listed price is trade or list, and what account is needed for trade.
- Whether they can supply against a specification rather than a part number.
- Certification or documentation that has to arrive with the goods.
Each question should be one a supplier can answer in a line. A list of fifteen
gets a reply to the first three.
5. Delivery and terms
The generated document names the destination profile, not the address —
addresses live in the private config that price-scan reads, and the RFQ is a
file in a repo. Fill the real address at send time, or say "full address on
request" and let the supplier ask.
Where relevant, state incoterms explicitly. For cross-border quotes, "delivered"
means different things to different suppliers, and a quote that turns out to
exclude duty is not comparable with one that includes it.
6. Track what comes back
Log each supplier's response against the line ids, not against product
names. Line ids are stable across BOM revisions, which is what makes a quote
received at revision 2 still matchable at revision 4. Record no-quotes and
substitution proposals too: a supplier declining a line is information about the
market, and a proposed alternative is a candidate that belongs in
evaluation-matrix rather than accepted on the supplier's word.
Where this stops
This skill does not send anything. Emailing a supplier is an outward-facing
action; it gets explicit confirmation each time, and approval for one does not
carry to the next.
Rendering and sending are handled elsewhere. The generated JSON conforms
exactly to the input schema of the
dsrholdings-rfq
plugin, which renders a branded PDF and sends it from the business address. Hand
over to dsrholdings-rfq:create-rfq / :send-rfq for anything going out under
the business identity.
That schema is additionalProperties: false, so nothing procurement-tools
specific can be smuggled into the document — no line ids, no spec references, no
provenance. Those stay in bom.yaml and in a sidecar next to the RFQ. If you
add a field to the generated JSON, add it to the renderer's schema first, or the
document will be rejected.
For an RFQ that is not going out under the business identity — an informal
request, a personal purchase, a list pasted into a supplier's web form — the
JSON plus a plain-text rendering of it is the deliverable. Write the plain-text
version alongside it; most trade counters want a pasteable list, not an
attachment.
Hands off to
dsrholdings-rfq:create-rfq — branded PDF and supplier correspondence.evaluation-matrix — for judging a supplier's proposed alternative against the spec instead of taking their word for it.price-scan — the retail-side counterpart. A price scan asks what a marketplace charges today; an RFQ asks a supplier what they will charge you.
