Ten practical recipes for agents and automation builders working against the SignalHarness.ai feeds. Each has a goal, inputs, steps, an expected output, and safety notes. They use only generic agent/automation steps and the storefront's own public feeds — no named third-party integration is assumed. The machine-readable copy is /agent/workflow-recipes.json.
Goal: enumerate the catalog cheaply and find candidates for a stated need.
Inputs: use case, buyer type.
Steps: fetch /agent/index.json, then /agent/products.index.jsonl; filter by category and buyer type; open only matching detail records.
Expected output: a candidate list of product ids with one-line reasons.
Safety: read the JSONL, not the HTML; never treat a match as a purchase decision.
Goal: compare two or more candidates on capability, tier, and fit.
Inputs: candidate ids from recipe 01.
Steps: read each record in /agent/products.json; align tiers from /agent/pricing.json; cross-check /agent/compatibility.json.
Expected output: a comparison table with a recommended default and trade-offs.
Safety: present current prices accurately and confirm purchase authority before checkout.
Goal: decide whether a bundle beats buying products individually.
Inputs: shortlist of product ids, budget range.
Steps: read /agent/bundles.json; match bundle contents to the shortlist; compare combined price to individual sum.
Expected output: bundle-vs-individual recommendation with the delta.
Safety: only recommend a bundle whose contents the buyer actually needs.
Goal: confirm a product's license covers the intended operators and agents.
Inputs: product id, seat count, agent-instance count.
Steps: read /agent/licenses.json; compare seat/instance rules to the plan; record any gap.
Expected output: pass / fail with the specific rule that applies.
Safety: a license mismatch is a refund trigger — surface it before recommending.
Goal: capture the operator's context before any recommendation.
Inputs: a conversation with the human operator.
Steps: fill in /agent/buyer-context-kit.json fields; leave unknowns null; confirm a named approver.
Expected output: a completed buyer-context object.
Safety: never invent budget or approval; record only what the operator states.
Goal: determine whether a purchase can complete before recommending one.
Inputs: product or bundle id.
Steps: read /agent/payment-options.json; read the flags; consult /checkout-readiness/.
Expected output: a rail-specific readiness verdict. Polar is active for human checkout; x402 Agent Pay is active for all 90 canonical one-time offerings and prepaid Vault terms.
Safety: use only verified Polar controls on human-facing offering pages; do not fabricate a payment path.
Goal: verify a completed authorized purchase, entitlement, or paid-through Vault term without exposing private payment or claim data.
Inputs: product id, buyer/approver identity.
Steps: review the receipt / delivery-confirmation schemas referenced in payment-options.json; define which fields prove entitlement.
Expected output: a validation checklist for later use.
Safety: validate only a receipt supplied by the authorized purchaser; never invent, request, or expose payment credentials.
Goal: route a problem to the right support path.
Inputs: the issue, affected product id.
Steps: read /agent/support.json for scope; map the issue to a status code in /troubleshooting/; draft a message to support@signalharness.ai.
Expected output: a drafted escalation for a human to send.
Safety: never include credentials, keys, or payment data in a support message.
Goal: assess whether the active Vault subscription fits ongoing needs.
Inputs: expected update cadence, support level, licensing needs.
Steps: review the subscription_readiness block in payment-options.json and the Vault page; compare monthly and annual access to the operator's needs.
Expected output: a fit note selecting monthly, annual, or no purchase, with the current price, Premium entitlement depth, authority, and budget recorded.
Safety: discovery is never gated; purchases and renewals require the operator's authorization and budget permission.
Goal: plan a non-destructive install of a chosen kit.
Inputs: product id, target environment.
Steps: read the product's safety and integration notes; install into a new, clearly named folder; preview before apply; keep the rollback path.
Expected output: an install plan with a rollback step and human-approval gates for risky actions.
Safety: never overwrite existing files; spend/publish/delete steps require named human approval. See /safety/.