[agent-idea] Open-Source Lead Intelligence Agent — From GitHub Signals to Qualified Pipeline

Summary

An agent that scans GitHub repositories for high-value stargazers and contributors, enriches them with business data via Apollo, scores them against configurable ICP criteria, and — with human approval — creates qualified contacts in HubSpot and notifies the team via Slack. Optionally, with explicit opt-in, it can draft and send personalized outreach emails with individual human review.

This is the first template to demonstrate multi-tool CRM integration (GitHub + Apollo + HubSpot + Slack + CSV), showcasing nearly every advanced framework feature in a single, production-realistic agent.

Responsible use policy: This agent only processes publicly available GitHub profile data. CRM records are created from data the user has voluntarily published. Email outreach is disabled by default and, when enabled, requires explicit human approval for every individual message. No scraping of private profiles, social networks, or restricted sources.

The Problem

Developer-led growth (PLG) companies have a massive untapped lead source: the people starring, forking, and contributing to their GitHub repositories. These are high-intent signals — someone who starred your repo is far more likely to convert than a cold prospect.

But nobody acts on these signals systematically because:

1. GitHub stargazers are just usernames — no business context, no company info
2. Manual enrichment doesn't scale — looking up each stargazer in Apollo/CRM is tedious
3. Signal decay — by the time someone notices and acts, the interest is stale
4. No pipeline exists to filter bots from real leads, score them, and route to sales

Who needs this? Every developer tools company, open-source company, and DevRel-driven organization. Companies like Supabase, Vercel, Hashicorp — and Aden/Hive itself.

Architecture

12 nodes, ~16 edges — the most feature-rich template in the Hive ecosystem.

The default flow ends at CRM sync + Slack notification. Email outreach is an optional branch enabled via configuration.

                         +------------------+
                         |  config_intake   |  event_loop, client_facing
                         |  User specifies  |
                         |  repo + ICP +    |
                         |  options         |
                         +--------+---------+
                                  |
                              on_success
                                  |
                         +--------v---------+
                         |  github_scan     |  event_loop
                         |  Fetch recent    |
                         |  stargazers +    |
                         |  contributors    |
                         +--------+---------+
                                  |
                              on_success
                                  |
                         +--------v---------+
                         |  profile_filter  |  function (deterministic)
                         |  Remove bots,    |
                         |  empty profiles, |
                         |  low-signal accs  |
                         +--------+---------+
                                  |
                              on_success
                                  |
                         +--------v---------+
                         |  enrich_batch    |  event_loop
                         |  Apollo enrich   |
                         |  each user       |
                         +--------+---------+
                                  |
                              on_success
                            (unenriched leads
                           get lower scores —
                           no fallback scraping)
                                  |
                         +--------v---------+
                         |  lead_scoring    |  function (deterministic)
                         |  ICP scoring:    |
                         |  title, company  |
                         |  size, industry  |
                         +---+----------+---+
                             |          |
                       conditional   conditional
                       score >= 70   score < 70
                             |          |
                    +--------v---+  +---v--------------+
                    | review_leads|  | save_nurture_list|  event_loop
                    | event_loop, |  | Export low-score |
                    | client_facing|  | leads to CSV    |
                    | HITL: user  |  +------------------+
                    | approves    |
                    | leads       |
                    +------+------+
                           |
                       on_success
                           |
              +------------+-------------+
              |                          |
          on_success                 conditional:
              |                    email_enabled == true
              |                          |
     +--------v--------+       +--------v---------+
     |    crm_sync     |       |  draft_outreach  |  event_loop
     |   event_loop    |       |  Personalized    |
     |   HubSpot:      |       |  emails using    |
     |   contacts +    |       |  GitHub + Apollo  |
     |   companies +   |       |  context         |
     |   deals + tasks |       +--------+---------+
     +--------+--------+                |
              |                     on_success
              |                         |
              |                +--------v----------+
              |                |  approve_send     |  event_loop, client_facing
              |                |  HITL: human      |
              |                |  reviews EVERY    |
              |                |  email            |
              |                +--------+----------+
              |                         |
              |                     on_success
              |                         |
              |                +--------v--------+
              |                |  send_emails    |  event_loop
              |                |  Via Resend     |
              |                +--------+--------+
              |                         |
              +------------+------------+
                           |
                       on_success
                           |
                  +--------v---------+
                  |  slack_report    |  event_loop
                  |  Post campaign   |
                  |  summary to      |
                  |  team channel    |
                  +------------------+

Node Specifications

1. config_intake — event_loop, client_facing

Input: (entry point) Output: repo_urls, icp_criteria, max_leads, email_enabled

User specifies:

• Which GitHub repositories to scan
• Ideal customer profile (ICP) criteria: target titles, company sizes, industries
• How many leads to process
• Whether email outreach is enabled (default: false)
• If email enabled: outreach context (product name, value prop, tone)

2. github_scan — event_loop

Input: repo_urls, max_leads Output: raw_profiles Tools: github_list_stargazers, github_get_user_profile

Fetches recent stargazers and contributors. For each, retrieves publicly available profile data: bio, company field, location, email (only if user has made it public), repos count, followers. Prioritizes recent activity.

3. profile_filter — function (deterministic)

Input: raw_profiles, icp_criteria Output: filtered_profiles, filter_stats

No LLM call. Pure Python logic:

• Remove bot accounts (username patterns, no repos, no bio)
• Remove profiles with fewer than N public repos (configurable)
• Remove profiles with no company or bio information
• Return filter statistics (total scanned, passed, filtered by reason)

def filter_profiles(raw_profiles: list, icp_criteria: dict) -> dict:
    filtered = []
    stats = {"total": len(raw_profiles), "bots": 0, "low_signal": 0, "passed": 0}
    for profile in raw_profiles:
        if is_bot(profile):
            stats["bots"] += 1
            continue
        if profile.get("public_repos", 0) < icp_criteria.get("min_repos", 3):
            stats["low_signal"] += 1
            continue
        if not profile.get("company") and not profile.get("bio"):
            stats["low_signal"] += 1
            continue
        filtered.append(profile)
        stats["passed"] += 1
    return {"filtered_profiles": filtered, "filter_stats": stats}

4. enrich_batch — event_loop

Input: filtered_profiles Output: enriched_leads Tools: apollo_enrich_person, apollo_enrich_company

For each filtered profile, attempts Apollo enrichment using public email or name+company. Retrieves: title, seniority, department, company size, industry, revenue, tech stack.

When Apollo has no match for a profile, the lead is not discarded — it continues to scoring with whatever data is available from GitHub (company field, bio, repos). Incomplete data results in a lower score, which is the correct behavior: less data = less confidence = lower priority.

No web scraping fallback. We deliberately avoid scraping LinkedIn, social profiles, or other restricted sources. Only data from GitHub's public API and Apollo's legitimate enrichment database is used.

5. lead_scoring — function (deterministic)

Input: enriched_leads, icp_criteria Output: scored_leads, high_score_leads, low_score_leads

No LLM call. Weighted scoring based on configurable ICP criteria:

def score_leads(enriched_leads: list, icp_criteria: dict) -> dict:
    weights = {
        "title_match": 0.25,      # Does their title match target personas?
        "company_size": 0.20,     # Is the company in the right size range?
        "industry_fit": 0.20,     # Is the industry relevant?
        "seniority": 0.15,        # Decision-maker vs. individual contributor?
        "enrichment_depth": 0.10, # How much data do we have? (penalizes unknowns)
        "engagement": 0.10,       # GitHub activity level (stars, forks, contributions)
    }
    scored = []
    for lead in enriched_leads:
        score = compute_weighted_score(lead, icp_criteria, weights)
        lead["lead_score"] = score
        scored.append(lead)

    high = [l for l in scored if l["lead_score"] >= 70]
    low = [l for l in scored if l["lead_score"] < 70]
    return {"scored_leads": scored, "high_score_leads": high, "low_score_leads": low}

Note the enrichment_depth signal: leads with incomplete data are automatically scored lower, creating a natural quality gradient without needing a scraping fallback.

6. review_leads — event_loop, client_facing

Input: high_score_leads, filter_stats Output: approved_leads Tools: save_data, load_data

Presents the top-scoring leads to the user in a formatted table: name, title, company, score, GitHub profile, key signals. User selects which leads to proceed with. HITL checkpoint #2.

7. save_nurture_list — event_loop

Input: low_score_leads Output: nurture_file Tools: csv_write, save_data

Exports low-score leads to a CSV file for future reference. Not discarded — saved as a long-term asset with all available data.

8. crm_sync — event_loop

Input: approved_leads Output: crm_results Tools: hubspot_create_contact, hubspot_create_company, hubspot_create_deal

For each approved lead:

• Creates or updates a HubSpot contact with all enrichment data
• Creates or links the associated company record
• Creates a deal tagged with source github-signal for attribution tracking
• Creates a task assigned to the appropriate sales rep

This is the default terminal action — every run creates CRM records, regardless of email configuration.

9. draft_outreach — event_loop (optional, requires email_enabled)

Input: approved_leads, outreach_context Output: email_drafts

Only activated when email_enabled == true in config. For each approved lead, drafts a personalized email that references:

• Their specific GitHub activity (what repo they starred, any contributions)
• Their role and company context (from Apollo enrichment)
• The product's relevance to their likely needs
• A clear, respectful call-to-action

10. approve_send — event_loop, client_facing (optional)

Input: email_drafts Output: approved_emails, rejected_emails

Presents every email draft to the user for individual review. User can approve, edit, or reject each one. HITL checkpoint #3 — no email goes out without explicit human approval for that specific message.

11. send_emails — event_loop (optional)

Input: approved_emails Output: send_results Tools: send_email

Sends approved emails via Resend. Respects configurable rate limits (default: max 20 emails per run) to prevent any perception of bulk outreach.

12. slack_report — event_loop

Input: crm_results, send_results (if email enabled), filter_stats Output: report_status Tools: slack_send_message

Posts a campaign summary to the team's Slack channel:

• Repo(s) scanned and date range
• Funnel metrics: profiles found → filtered → enriched → scored → approved
• Top leads with scores and companies
• CRM records created
• Emails sent (if enabled)
• Link to nurture CSV

Edge Specifications

Advanced Framework Features Demonstrated

This template exercises more framework features than any existing template:

Tool Usage

Data & Privacy Policy

This agent adheres to responsible data practices:

1. Public data only — All data comes from GitHub's public API and Apollo's legitimate enrichment database. No scraping of LinkedIn, social media, or restricted sources.
2. No email by default — The default flow creates CRM records and Slack notifications only. Email outreach requires explicit opt-in via email_enabled configuration.
3. Individual human approval — When email is enabled, every single message is reviewed and approved by a human before sending. No bulk or automated sending.
4. Rate limiting — Configurable maximum emails per run (default: 20) to prevent any perception of bulk outreach.
5. Attribution tracking — All CRM records are tagged with github-signal source for transparency about how the lead was identified.
6. API rate limits respected — GitHub API (5,000 req/hour authenticated) and Apollo credits are managed within the agent.

Why This Agent Is Differentiated

vs. Existing Templates

Every current Hive template (tech_news, twitter_outreach, deep_research) follows the same pattern: linear chain of event_loop nodes doing "search → analyze → output." This agent uses function nodes, conditional routing, fan-out/fan-in, optional branches, and multi-checkpoint HITL — patterns that exist in the framework but have never been demonstrated.

vs. Existing Proposals

No existing proposal combines GitHub signals with CRM automation. The closest are SDR/prospecting agents (#3829, #3991), but those work with cold lists — this works with warm signals (people who already showed interest in your project).

vs. Simple Scripts

A script could fetch stargazers and dump them to a CSV. It cannot:

• Intelligently filter bots vs. real developers (requires pattern matching + heuristics in a function node)
• Score leads against configurable ICP criteria with enrichment depth awareness (function node)
• Present leads for human judgment before any action (HITL)
• Draft genuinely personalized emails referencing specific GitHub activity (LLM reasoning)
• Orchestrate CRM sync and email in parallel (fan-out)
• Self-report results to the team channel (multi-tool integration)

The Demo Story

Point this agent at Hive's own repository. It finds people who starred adenhq/hive, identifies which ones work at companies that could use an AI agent framework, enriches them with Apollo, scores them, and creates qualified contacts in HubSpot with full context. The demo literally generates pipeline for Aden — from the project's own community signals.

Non-Overlap Verification

Implementation Complexity

Estimated effort: Medium (12 nodes, but each has clear bounded scope)

Can be built incrementally:

• Phase 1 (core): config_intake → github_scan → profile_filter → lead_scoring → review_leads → crm_sync →