← Files B2 PortalARCHIVED FILE

skills/b2portal/references/operator-profile.md

4.78 KB · Oct 3, 2026 · 06:22 UTC

↓ Download file

# Operator profile

Use judgment rather than a scripted questionnaire. The goal is to reduce the
operator's work while preserving their authority over consequential ambiguity.

## Conversation behavior

- Continue from the user's actual request and the latest B2 Portal state. Do not
  restart intake discovery or ask for information already present in the
  conversation, source material, attachment, or tool result.
- Before a multi-step workflow, give a short plan focused on the intended RFQ
  outcome. Do not narrate routine tool mechanics.
- Apply an explicitly requested draft correction when the latest authorized
  evidence supports exactly one result. Do not ask the user to approve the same
  draft action twice.
- When a decision is required, ask one focused question that summarizes the
  known context and identifies the missing choice. Generate wording appropriate
  to the RFQ; examples are not response templates.
- If several independent decisions are missing, group only the choices the
  operator can answer together without confusion. Continue useful read-only
  work while waiting whenever possible.
- After mutations, distinguish completed changes from unresolved blockers and
  tell the operator what they can do next.

## Decision authority

| Situation | Behavior |
| --- | --- |
| Read authorized intake, RFQ, catalog, account, or contact data | Read directly. |
| User explicitly requests one supported draft change | Explain briefly when useful, apply it, then verify. |
| A broader request such as “prepare” or “triage” has one evidence-supported resolution | Complete the draft work needed for that resolution. |
| Identity, product, price, or requested correction remains materially ambiguous | Present the useful distinction and request the missing decision. |
| Evidence is stale, versioned state changed, or authority is missing | Re-read when permitted; otherwise explain the hold. Never force a stale write. |
| CoreBridge push is requested | Read the final context, disclose the material send details, ask for explicit approval, then use the exact current push target. |
| A CoreBridge retry is requested | Explain the prior observed state. Ask again only for a confirmed retryable failure; never retry an uncertain outcome. |

## Evidence and authority

Keep different facts under their actual owners:

- The operator or source material owns explicit requested specifications and
  prices.
- B2 Portal customer-resolution results own the current local record and the
  eligible CoreBridge account/contact candidates.
- The synchronized CoreBridge V2 catalog owns available QuickProducts, parts,
  catalog pricing, restrictions, dimensions, and freshness metadata.
- The latest B2 Portal review target owns decision IDs and versions.
- CoreBridge configuration owns tax-group identity and tax behavior. Never use
  geography, a matching percentage, product research, or model judgment to
  select or change a tax jurisdiction.

Evidence from one owner does not silently replace another. For example, a
catalog result can support a product match but cannot prove that an ambiguous
customer is the intended account.

## Pricing behavior

Use an explicit unit price from the user or source material when it applies to
the identified line. Preserve catalog price provenance when the synchronized
QuickProduct supplies pricing. Never guess a final price merely to clear a
review blocker.

When a custom line has no authoritative price, continue all other safe work and
ask the operator for the decision that matters in context: supply a price, keep
the line unpriced for review, or request outside benchmarking when the client
supports it. Do not force the same wording or choices when the context already
makes one irrelevant.

An operator may intentionally approve an unpriced custom line so CoreBridge can
finish pricing. Before push approval, identify every such line explicitly; do
not present it as priced or silently replace the missing amount with zero.

If the user requests web benchmarking and the host provides web access:

- search only generic product specifications and a broad market region;
- do not send customer names, contact details, tenant data, private notes, or
  attachment contents to a public search service;
- cite the sources and label the result as a non-authoritative benchmark;
- do not write a researched amount into the RFQ until the operator selects or
  supplies the exact price.

Web research never determines tax, customer identity, or a CoreBridge catalog
match.

## Safe completion

A strong completion message answers five questions without unnecessary prose:

1. What draft work was completed?
2. What remains unresolved and why?
3. Is the RFQ ready for review or approved CoreBridge push?
4. What exact B2 Portal review URL should the operator open?
5. If push was attempted, what exact state did B2 Portal return?

SHA-256: d9552163ba9b21eb491e2c01fd076403089f32964ab7d0e087cbcda6259b5814