Influencer Discovery

Influencer Discovery

Find evidence-backed creator candidates across platforms, screen them against declared discovery filters, and build a non-ranked readiness queue for typed Fit evaluation.

Quick Start

Find 20 influencers in [niche] for [brand/product]

Find influencers in [niche] with 50K-200K followers on TikTok and Instagram,
based in [location], engagement above 4%, who have worked with brands like [brand]

Skill Contract

• Reads: brand/product, niche or category, target platforms, follower range, engagement floor, decision-relevant geography/language, audience demographics, exclusions; dated candidate records from a user export, public source, roster, or live connector; the current campaign's STAR evidence_window when supplied; prior entity-registry brand profile and any audience-mapper output if present in memory; existing roster records under memory/creators/ (dedupe only through verified identity links against creators already rostered by creator-registry).
• Writes: return discovery results inline by default; only with separate exact authorization, save them to memory/influencer/influencer-discovery/YYYY-MM-DD-<topic>.md. A saved artifact uses a stable opaque creator_ref plus pseudonymous recipient_ref, contact_source_ref, and agency_ref, keeps raw handles, profile URLs, and contact coordinates transient-only, and retains geography only at the granularity required by the declared filter. Save an opaque handle_ref/source_ref identity resolver only when the authorized source artifact or verified creator-registry link can resolve it. Without one, keep identity_status: unresolved, save no hidden raw-locator mapping, and set cross_session_locator_required: true. Reuse a verified creator-registry aggregate ID when one exists; otherwise generate creator-<UUIDv4> once for the candidate lineage. Never set creator_ref to a raw handle, name, URL, email, provider ID, or a deterministic hash of any of them. Each roster-worthy creator update requires another exact authorization for an operation: propose request through registry-events.py to memory/events/creators.ndjson; only creator-registry writes canonical records under memory/creators/.
• Promotes: only with separate exact authorization, durable facts (verified creator/handle refs, confirmed niche/platform coverage, competitor-saturated creators) to memory/hot-cache.md; discovery readiness or queue position is not a durable ranking fact.
• Done when:
  • The required search criteria are present; otherwise stop with NEEDS_INPUT and name the missing criteria without fabricating candidates.
  • Exactly two raw locators without complete criteria/evidence remain NEEDS_INPUT, not a vetted shortlist. A separately authorized partial checkpoint is labeled PARTIAL, lists every gap, and contains no tier or rank.
  • A candidate pool exists with at least the requested count screened past follower, engagement, and brand-safety filters.
  • Each candidate has a field-level evidence trail (provider/tool, source_ref, observed_at, window, evidence label), an audience read, and an evidence-completeness triage state (READY_FOR_FIT | NEEDS_REFRESH | INELIGIBLE) that is neither a score nor a STAR Suitability verdict.
  • Every candidate keeps one stable opaque creator_ref across the report and handoff; raw identity locators remain transient and are never copied into creator_ref.
  • Conflicting observations remain separate, identity merges have a verified cross-link, and the Fit handoff marks each volatile field current, stale, or unknown against the current STAR evidence_window with any refresh_required fields named.
  • A non-ranked Fit-readiness queue is compiled with next-step pointers; every stale/unknown required field produces NEEDS_REFRESH, NOT_RANKED, and NEEDS_INPUT until refreshed.
• Primary next skill: fit-scorer — score and rank the discovered candidates with weighted criteria.

Handoff Summary

Emit the standard shape from skill-contract.md §Handoff Summary Format.

Data Sources

Planning and screening need no live integration (Tier 1), but a real creator list still needs candidate records: public handles/links or an export supplied by the user, existing roster records, or a live search connector. Search criteria alone are not evidence that any specific creator or metric exists. If no candidate source is available, return a query/collection plan and NEEDS_INPUT; never invent handles, profiles, counts, or audience data.

Normalize evidence only in the report template, not through a new ingestion layer. For every factual field retain provider/tool, source_ref, observed_at, the measurement window (or not-supplied), and one label: Measured, Calculated, Estimated, User-provided, or Proxy. Keep conflicting values for the same field as parallel observations; do not average them, prefer the newest automatically, or merge identities from names/handles alone. A cross-provider identity becomes one creator only after a verified cross-link or explicit user confirmation.

Where a tool could sharpen results, use ~~ connector placeholders:

• ~~influencer database — bulk discovery, follower/engagement metrics, audience demographics.
• ~~social platform analytics — native creator-marketplace data, trending sounds, related accounts.
• ~~CRM — surface possible existing-partner matches for verified identity-link review; never auto-merge records.
• ~~audience overlap — estimate creator-audience vs. brand-audience match.

Keyless candidate-card metadata (oEmbed): YouTube (https://www.youtube.com/oembed?url=<video-url>&format=json), TikTok (https://www.tiktok.com/oembed?url=<post-url>), and X (https://publish.twitter.com/oembed?url=<post-url>) return a post's title, author name/handle, and thumbnail with no key — enough to resolve a candidate transiently and retain an opaque verified-handle evidence ref instead of hand-copying identity data. A handle ref remains separate from creator_ref: only an explicitly carried upstream creator_ref or a verified creator-registry identity link may resolve the aggregate; otherwise create a fresh random opaque ref and preserve the identity gap. Metadata only: no follower or engagement metrics, so those stay ~~influencer database or manual export — except YouTube, below.

Measured YouTube metrics (free key): python3 "${CLAUDE_PLUGIN_ROOT}/scripts/connectors/youtube.py" channel @handle returns the real displayed subscriber count, total views, and video count, and youtube.py videos @handle --limit 10 adds per-video views/likes/comments — upgrading a YouTube candidate's profile row from Estimated to Measured. Free YOUTUBE_API_KEY (10,000 units/day; one channel check ≈ 1–3 units). ToS boundary: vet a named shortlist, don't build a bulk creator database — quota extensions are refused for competitive harvesting. See scripts/connectors/README.md.

See CONNECTORS.md for the free/keyless recipe per category and the opt-in MCP layer. None are required — every step degrades to user-supplied inputs.