/influencer-discovery

name: influencer-discovery
description: >
  Find the bloggers/creators who can help promote your work, capture
  their contact info, and append them to the target sheet in Google Sheets.
  Targets must bring their own audience — followers, readers, subscribers;
  people building their own product are not targets. Use for requests like
  "find a batch of bloggers doing X", "top up the target sheet", "dig up
  contact info for these people", "how do I get emails on this platform".
  Covers X/Twitter, TikTok, Instagram, Threads, YouTube, Reddit, Mastodon,
  DEV.to, Hashnode, Blog, Newsletter, Podcast, plus distribution Websites
  (tool-recommendation sites, directory sites).

  Stops at capturing contact info. Sending, tiering, deal tracking, and click
  settlement are all out of scope — do not use this skill for those requests.

influencer-discovery

One sentence: **hit the qualified-row count the user asked for, every row with contact info, not one row a duplicate.**

Who to find

**People who can help us promote our work.** The criterion is **bring your own audience**: followers, readers, subscribers — when they post something, someone sees it.

**People building their own product are not targets.** They want traffic and won't distribute for us — capturing their email is a false positive, not output. This is the biggest false-positive source in this methodology; see [seller-vs-buyer.md](reference/methodology/_shared/seller-vs-buyer.md) for how to tell.

**The publication itself is not a target; its authors may be.** Multi-author publications have editors and pages, and the site only exposes a submissions inbox — one row per site collapses hundreds of authors into a single row. The move is to pull the author list from the publication and go out through the authors; see [5-media/](reference/methodology/5-media/index.md).

Read these first

Before starting, read `docs/design/index.md`, then the docs for the areas involved. **Invariants and scope are authoritative there; this file does not restate them**:

• Append-only never modify, the log records everyone while the sheet records only the qualified, failures are not logged, better to miss a row than fabricate one

— [index.md](../../docs/design/index.md)

• Two shapes and three stop semantics, the two hops, fetching rules — [platforms.md](../../docs/design/platforms.md)
• What the log / target sheet / run report each record — [records.md](../../docs/design/records.md)
• Dedup rules and their premise — [dedup.md](../../docs/design/dedup.md)

Run loop

The number the user gives is **the count of qualified rows that end up in the sheet**, not how many to crawl.

loop {
  discover a batch of candidates    you plan the order; it is not pre-baked
  check the log, skip seen ones     the key is (person, platform)
  capture contact info              platform page → their own site → contact page
  write the log                     record hit or miss; failures are not logged
  qualified rows go to the sheet    has contact info AND meets the requirements
}

Each round produces a run report. Plan, actuals, deviations, per-channel stop reasons, yield by channel — since the order is not pre-baked, this ledger is the only point where constraint lands.

Three things to nail down before any run

They are **deliberately not in config**: intent differs every round; hard-wiring them lets the last round hijack the next.

1. **How many** — qualified-row count. 2. **What "meets the requirements" means** — thresholds on topic, size, audience. Comparing yield across rounds requires comparing the thresholds along with it, or the numbers are not comparable. 3. **What to prioritize** — size, topic fit, contact-capture success rate, platform diversity; weights are set at use time.

Run without nailing these down and the yield numbers in the report mean nothing.

Two tiers

Two separate things; do not mix them:

**[reference/datalayer/](reference/datalayer/index.md) — each platform's capability boundary.** One file for the no-auth surface, one per platform for the rest: whether the route is plain HTTP, cookie, CLI, or a third-party API; what you can get; what it costs. **Record only what is confirmed; leave the unverified blank.**

**[reference/methodology/](reference/methodology/index.md) — where contact info comes in once you have the data.** Per-channel entry points, stop semantics, dedup keys, known boundaries. **Directory names are the collaboration priority**; the prose does not restate ordering. **Shared rules are written once** (the three shared pieces: second hop, seller-vs-buyer, cost ranking); each channel writes only its own exceptions.

**Each channel doc answers one question: how to get a blogger's email on this platform.** Selection reasoning, cost arguments, and vendor comparisons do not go in the channel doc — cost belongs in [cost-ranking.md](reference/methodology/_shared/cost-ranking.md), vendors in the data layer.

The data layer states the **boundary**; methodology **rules on whether to run based on it** and writes the how. Channels ruled out but still needing a guard against accidental runs are demoted to reference (`_not-run/`); channels with zero yield for the goal are deleted outright, the reason kept in methodology's index.

**Credentials live in `~/.config/influencer-discovery/.env` (`chmod 600`); variable names in [reference/datalayer/index.md](reference/datalayer/index.md#credentials).** Not in the repo, and do not borrow from `~/.config/last30days/.env`. On a missing key, report the missing variable name — do not guess, do not fall back to another project's credentials.

**Current platform distribution of the target sheet** (2026-08-06, 409 rows; used to judge investment priority, will drift as the sheet grows):

YouTube 113 · Newsletter 97 · Website 62 · Blog 38 · GitHub 28 · LinkedIn 26
Podcast 24 · Twitter 7 · Medium 4 · Reddit 3 · everything else 1 each

Among link domains, `passionfroot.me` a