superdesigndev/treg/lead-signals

Lead signals

A signal is a public fact that makes a conversation timely: someone complained about the problem you solve, engaged with a post about it, hired for it, raised money, switched tools.

Runs on treg, through its MCP tools or the treg CLI; either is enough. Over MCP, each command below maps onto a tool: treg catalog search is catalog_search, treg catalog get is catalog_get, treg call is call. With neither, treg is not set up: https://treg.to/llms.txt says how. Install only if the human asked you to; otherwise tell them how and stop.

The run

1. Detect raw signals for the user's buyer.
2. Qualify. Drop the noise; most runs discard more than half. A signal list is not a lead list.
3. Contact. Company → decision maker → work email, only for rows that survived.
4. Hand back a ranked list: person, company, the signal, why now in one line, source link, email

if found. State coverage plainly: "1,180 engaged, 800 emails found".

Default for "find buyers for X" or "monitor Y": search posts about the pain on LinkedIn, X and Reddit → read the comments and reactions on the best posts → keep people whose title fits → roll them up by company and score → decision makers and emails at the top companies.

Signals

The vendors are examples of who answers today, not a list to stick to: search, and take whatever the catalog ranks best now.

Anything else is a composition. A page change: scrape the page, keep a hash, compare next run. Custom intent: a Google search such as "migrating from <competitor>". Repo stars: GitHub with the team's own token.

Finding the endpoint

The catalog changes every week, so never trust a remembered endpoint id.

1. treg catalog search "<the job in plain words>", not a vendor name.
2. Prefer a routed treg.* endpoint when there is one: the team's own keys first, then providers in

order, and most misses are free.

1. treg catalog get <id>: the price, the hit rate (it found something), not just works (it

returned 200), and the row's note.

1. One small call first. Read the reported charge and _treg.served_by, then scale.
2. Nothing fits: treg catalog request "<what is missing>".

For emails use the routed finder, treg.people.email.find, and always send X-Treg-Route-Max-Cost: 0.05; uncapped, a miss can walk up to the dearest provider.

Score

Fit first (no fit, no row), then timing (fresher wins), then strength (two independent signals on one account beat one). Every row carries its reason in the user's words.

Keep watching

When the user wants it recurring:

1. Run once and report what it cost (sum the reported charges): that is the price of each run.
2. Keep signals.csv keyed by person URL, signal and source URL. Later runs report only new keys. The

first run is the baseline; say so.

1. Schedule it with the user's agent: Claude Code /schedule (a cloud routine) or /loop (while the

session is open), Codex codex exec "<prompt>" from cron, any other agent its own scheduler. The scheduled run needs TREG_TOKEN (an agent token from treg org agent-new) and a place for signals.csv it can read and write, such as a repo file or a sheet.

Before the first list

Say once: outreach to EU and UK people needs a lawful basis, and suppression and unsubscribe lists come first. Then hand over the list; the user decides how to use it.