# Vendor Listing

Onboard a vendor who wants their API listed in the treg catalog.

- Repository: https://github.com/superdesigndev/treg (6950 stars)
- Category: Testing
- License: see repository
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add superdesigndev/treg --skill vendor-listing -g -a claude-code -y`
Codex: `npx skills add superdesigndev/treg --skill vendor-listing -g -a codex -y`
Cursor: `npx skills add superdesigndev/treg --skill vendor-listing -g -a cursor -y`
Gemini CLI: `npx skills add superdesigndev/treg --skill vendor-listing -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add superdesigndev/treg`

## Description

Onboard a vendor who wants their API listed in the treg catalog. Use whenever someone asks "how do we get listed on treg", a vendor sends their API details, or a listing PR/issue needs review. Walks the whole pipeline: eligibility gate → registry entry → platform-key slot → logo → tests → LIVE bogus-key test → core catalog YAML → verify → scrub → validate → evidence ledger in the PR. Every listing ships tier-4 wiring and a per-endpoint verification table. The vendor-facing doc this skill implements is docs/VENDORS.md.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Vendor listing, add a provider to the catalog

A listing has **three parts**, and all three ship in the same PR:

1. **Registry entry** (`src/treg/oauth_providers.py`), how a team connects a credential for the
   provider, and how treg verifies that credential is real.
2. **Core catalog file** (`src/treg/catalog/<service>.yaml`), what an agent can *do*: 8, 15
   curated endpoints with capability mapping, inputs, cost + provenance, and verified examples.
3. **Platform-key slot** (`config.py` + `fx.yaml`), so treg can serve the
   endpoints on its own key (tier 4). **Always aim for this.** A listing that is BYOK-only is the
   exception and needs a stated reason (no self-serve pricing, `own_account` data, sales-gated).

And every listing PR carries a **verification evidence ledger** (Step 7b). No ledger, no merge.

Deep references (read before non-trivial work; do not duplicate them here):
- `docs/context/guides/expanding-a-category.md`, the add-a-provider playbook, verify toolbox, traps
- `docs/context/architecture/catalog.md`, catalog schema, cost provenance, verify pipeline, PII rules
- `docs/VENDORS.md`, what we told the vendor to prepare (their checklist)
- `src/treg/web/vendor-listing.md`, the HOSTED instructions (served at `/vendor-listing`) that a
  vendor's own coding agent follows to raise a listing PR; the dashboard's "List as vendor" modal
  (connections view, `vendorAsk` in `index.html`) hands vendors a prompt pointing at it. Keep the
  three vendor-facing surfaces (doc, hosted page, modal prompt) telling one story.

## Step 0, intake: collect the vendor facts

Before touching code, you need ALL of these. If the vendor's submission is missing any, ask, do not guess ("unconfirmed" beats a wrong path shipped):

The rest: https://github.com/superdesigndev/treg/blob/HEAD/.agents/skills/vendor-listing/SKILL.md