/build-connector

name: build-connector
description: >
  Gets Claude talking to a tool nobody built an official connector for. Works
  out what the system is, checks the Claude connector directory for an
  existing connector first, and when there isn't one connects the tool through
  Zapier — never by hand-building against a raw API — with credentials
  handled safely and approval gates on anything that writes. This is what
  turns "my ERP isn't supported" into an afternoon. Use this whenever
  the owner names a tool that isn't connected — including phrasings like "can
  you connect to my," "make my tools talk to each other," "there's no API for
  this," "pull data out of my field service software," "I use ServiceTrade and
  it's not on the list," or "is there any way to get at this data." Reach for
  it whenever an unsupported system is blocking something else.
allowed-tools: Read, WebFetch, ToolSearch

Build Connector

Turn an unsupported tool into a connected one.

Owners in this segment run software nobody will build a first-party connector for — field service platforms, vertical ERPs, practice management systems, regional accounting packages. Each one is a small market and a hard blocker. This skill is how that stops being a dead end.

Step 1 — Gather requirements

Before anything else: what are we connecting to, what do we need from it, and how does it need to work. Gather these four things:

1. **The exact system.** Get the precise product, not the category — "my ERP" could be any of forty things, and the answer differs for each. Ask for the login URL if the name is ambiguous; it usually identifies the product and version immediately. 2. **Search for it immediately.** The moment you have the exact name — don't wait for Step 2 — follow `reference/discovery.md`, section 1, right now, and keep the result. Step 2 interprets it rather than searching again. 3. **What the owner actually needs.** What data comes out, or what action goes in — and how often. 4. **Which skill or workflow this unblocks.**

**Scope is what keeps this an afternoon rather than a project.** "Connect my ERP" is unbounded. "Pull open work orders daily so they show up in the morning brief" is buildable today. Leave this step with that kind of narrow, single, testable scope — not a category of need.

Step 2 — Discovery

Read `reference/discovery.md` and follow it in order: a native Claude connector first; then Zapier, the build path for everything the directory lacks; then a scheduled export when the tool is on neither; then an honest no. A documented API is context, never a build path. Report the finding before building anything — cost, effort, and blocker in three lines, in the format at the end of `discovery.md`.

Also check whether the real need is already covered another way — most commonly a domain or DNS step you were about to build by hand. A surprising share of "connect this tool" requests bottom out in a verification TXT record or a CNAME the owner adds at their registrar, and that is solved by telling them the exact record rather than built.

| Path | When | |---|---| | Existing Claude connector | It exists in the directory. Always first — connect, don't build. | | Zapier connection | Everything else that's on Zapier. The build path when the directory has nothing. | | Scheduled export | Not on Zapier, but the tool can email or drop a file | | Nothing viable | Rare. Say so honestly and name what the owner can export by hand |

**Prefer the boring option.** A scheduled CSV export that never breaks beats a clever integration that fails silently in November. Owners cannot debug a broken connector, and a connector that fails quietly is worse than none. The tradeoffs per path are in `reference/paths.md`.

Step 3 — Connect

Follow the instructions for whatever Step 2 found:

• **Existing Claude connector or MCP tool:** connect it directly — install, authenticate, verify scope. Usually minutes.
• **Zapier:** follow `reference/use-zapier.md` — authenticating, connecting the app's own account, enabling exactly the actions the scope named, and testing against the owner's use case.
• **Scheduled export:** set it up per `reference/paths.md`, section 3, including the staleness check.

**Credentials, whichever path.** Request the narrowest scope that does the job — read-only unless writing is genuinely required. Tokens and OAuth only; never ask for a password, and if a system offers only password auth, say so and let the owner decide knowing that. Credentials go into the platform's own storage, never a file, a prompt, or a URL. Prefer a dedicated integration user over the owner's own login, so access can be revoked without locking them out. And say what the connector will reach, plainly, before it is created. The worked cases are in `reference/gotchas.md`.

Step 4 — Test against real data, visibly

Run a read action, show the owner the actual data it pulled, and ask if it's correct. The owner is the only person who can tell whether the data is right, and that question is the only way to confirm the connection is reading their real data and nothing quietly wasn't mapped.

Pulled 12 open work orders. First three:

  WO-4471  Ridgeline Property  Rooftop unit 3 — no cooling   Assigned Teri
  WO-4468  Corwin & Bay        Quarterly PM                  Unassigned
  WO-4465  Fairmount           Filter change                 Complete

Look right? Anything missing that you'd expect to see?

Every write action gets an approval gate before it runs, regardless of what the owner asked for. A connector that can modify the owner's system of record without asking is not something to ship.

Step 5 — Register and hand off

1. **Register the connector so skills can use it.** Note what it reaches, what it cannot do, and how it refreshes. 2. **Name the skills it now serves,** and note the row for `skills/smb-router/reference/connector-map.md` — the connector, the skills it serves, and the fallback those skills keep — for the pl