All workflows

Turn new GitHub stargazers into qualified conversations

Find out who just starred your repository, keep the ones at companies you sell to, and start a relevant, low-pressure conversation.

View on GitHub

github-stargazers-outbound.md

Turn new GitHub stargazers into qualified conversations

Set up the tools below, then run the steps in order for the user, carrying each step's results into the next.

Inputs

Ask the user for these before you start.

  • repo: the repository to watch, as owner/name, e.g. acme/acme-sdk
  • lookback_days: how recent a star counts, e.g. 14
  • ideal_customer: the companies you sell to, e.g. B2B software, 50 to 1,000 employees
  • resources: one or two links worth sharing with a new user, e.g. the quickstart and an example app
  • max_enrichments: the most people to enrich in one run, since each match costs a credit, e.g. 50
  • campaign_id: the lemlist campaign that sends the emails, e.g. cam_123
  • email_variable: the custom variable that campaign's email prints as its body, e.g. drafted_email

Set up

List stargazers (GitHub, tool:github/list-stargazers)

Use the API.

Note: Send Accept: application/vnd.github.star+json to get each star's starred_at timestamp.

People Data Labs (tool:people-data-labs/enrich-person, tool:people-data-labs/enrich-company)

Use the API.

Notes:

  • Enrich a person: Charged per match; no match returns 404. Set required, such as work_email, to be charged only for matches with the fields you need. On the free plan, emails, phone numbers and detailed locations come back as true/false flags.
  • Enrich a company: Charged per match; no match returns 404. Headcount trends, inferred revenue, subsidiaries and job-posting insights are premium fields your plan must include.

Add a lead to a campaign (lemlist, tool:lemlist/add-lead-to-campaign)

Use the first option your agent supports.

Note: The campaign automates outreach to its leads: confirm it first. findEmail, verifyEmail, findPhone and linkedinEnrichment spend credits, and a lead already in the campaign is refused with 400 LEAD_ALREADY_IN_CAMPAIGN.

CLI (official)

Install the command and sign in with it, then confirm it runs.

npm install -g @lemlist-official/cli
lemlist --version

Run lemlist api POST /campaigns/{campaignId}/leads/.

API (official)

Note: LEMLIST_API_KEY holds the base64 of :<api key>, an empty username and the key; 20 requests every 2 seconds per key.

Before step 1, confirm access to each service with its cheapest read-only call, like a list or a search. Never send or change anything to test access.

Steps

  1. List new stargazers with List stargazers (GitHub). List the users who starred repo, with star times; the newest stars are on the last page, so follow the Link header there and read backwards. Keep the logins that starred within lookback_days.
  2. Identify them with Enrich a person (People Data Labs). Match up to max_enrichments logins on the profile URL https://github.com/<login>, requiring a work email. Keep name, title, work email, job_company_website, job_company_size and job_company_industry; skip people with no match.
  3. Qualify the company with Enrich a company (People Data Labs). Look up the website only for people whose company size or industry is missing. Keep the people whose company fits ideal_customer.
  4. Write emails yourself. Draft a three-sentence plain-text email per person: thank them for the star, share one link from resources that fits their role, ask one question. No pitch. Show the drafts to the user.
  5. Queue the emails with Add a lead to a campaign (lemlist). After the user approves, add each person to campaign_id with their approved email in email_variable.

Done when

  • Every new stargazer is queued, or has a note saying they did not match or did not fit.
  • The user has a table of who starred, their company and whether they were queued.

Rules

  • Use only the services set up above. The read-only calls they need, like listing ids or polling for results, are fine.
  • Ask the user before anything that sends messages, costs money, or changes data, and say how many records it touches. One approval covers a batch the user has seen.
  • Never print API keys.