github-partner-outreach

name

github-partner-outreach

description

Discover, qualify, contact, and track potential partners or customers in the GitHub ecosystem for a product or website. Use when an agent needs to research relevant repositories and organizations, rank them by evidence-backed fit, identify collaboration angles and appropriate contact channels, draft personalized outreach from a verified team-member perspective, obtain approval before sending, and write delivery or reply status back to a table, CRM, spreadsheet, or CSV.

GitHub Partner Outreach

Build a traceable partnership pipeline from public product and GitHub evidence. Optimize for relevant conversations, not message volume. Default to research and drafts only until the user explicitly approves external contact.

Collect Inputs

Start with the following inputs. Infer public facts from the product website when possible and ask only for missing facts that materially affect the campaign.

• Product name and website
• Campaign goal: integration partners, customers, ecosystem listings, sponsors, or a mix
• Offer: free access, credits, engineering help, sponsorship, co-marketing, referral share, or another concrete benefit
• Verified sender profile: name, role, company, email, language, and optional writing samples
• Target count, markets, exclusions, and minimum project maturity
• Tracking destination and preferred sending channel
• Send mode: draft_only by default, or send_after_approval

Never invent a sender role, relationship, customer result, product capability, or review of code that did not occur.

Route Tools

Use purpose-built tools when available:

• Use a GitHub connector, GitHub CLI, or official GitHub pages for repository facts.
• Use the product's official website and documentation for product claims.
• Use a connected table or CRM such as Feishu Base, Notion, Airtable, or Google Sheets. Fall back to CSV when none is available.
• Use a connected mail provider for drafts or sends. Use browser or computer control only when a dedicated mail action is unavailable.

Treat stars, activity, contacts, and product details as time-sensitive. Capture the evidence URL and observation date for every material claim.

Run The Workflow

1. Build The Product Brief

Read the website and public documentation. Produce a compact brief containing:

• One-sentence product definition
• Primary users and jobs to be done
• Differentiators that can be demonstrated
• Resources the team can actually offer
• Natural integration surfaces
• Competitors, exclusions, and reputational constraints

Separate verified facts from inferences. Do not begin outreach until the proposed benefit is specific enough to explain in one sentence.

2. Discover Candidates

Search multiple candidate families instead of relying on one GitHub topic:

1. Direct integrations: projects that need the product's API, data, SDK, model, or infrastructure.
2. Adjacent workflows: tools used immediately before or after the product.
3. Ecosystem projects: agents, plugins, MCP servers, frameworks, benchmarks, and developer platforms.
4. Distribution surfaces: curated lists, tutorials, templates, and community resources.

Combine product terms, user problems, implementation terms, GitHub topics, and known alternatives. For each candidate, inspect the repository README, recent activity, license, contribution guide, open issues or discussions, organization profile, and official website when present.

Exclude or flag archived repositories, mirrors, forks without independent activity, obvious spam, unsupported regions, and projects that conflict with campaign exclusions. Deduplicate by canonical repository URL and organization.

3. Create Evidence Records

Record at least:

• Canonical repository and organization
• Stars and recent activity date
• What the project does
• Exact evidence of product fit or user pain
• Relevant integration surface
• Public business contact and its source URL, when available
• Contribution or contact policy
• Risks, uncertainty, and competitor overlap

Do not use private, leaked, purchased, or commit-derived personal email addresses. Never use a security contact for sales outreach.

4. Score And Rank

Read references/scoring.md before ranking. Score product fit, problem intensity, activity, reach, integration feasibility, and contactability. Stars influence only the reach component; never sort solely by stars.

For ten or more candidates, use the deterministic scorer:

python scripts/score_candidates.py candidates.json --format csv --output ranked.csv

Retain lower-ranked candidates in the table with a reason instead of silently deleting them.

5. Form The Partnership Thesis

Write one thesis per qualified candidate:

Because <public project fact>, the team likely faces <specific problem>. We can provide <concrete resource>, enabling <maintainer or user benefit>, with <low-friction next step>.

Choose the smallest credible offer first. Free support and implementation help should stand on their own; mention referral or revenue share only when it is relevant and optional.

6. Choose The Contact Channel

Read references/outreach.md before selecting a channel or writing messages.

• Prefer email for sponsorship, commercial terms, or a private introduction.
• Prefer a GitHub Discussion for an open-ended technical integration conversation when the repository welcomes it.
• Open an Issue only for a legitimate project-relevant proposal that follows the issue policy. Do not post a disguised sales message.
• Open a PR only when a useful, standards-compliant contribution is ready. Disclose sponsorship or affiliation.
• Use social media for an active maintainer when a short warm introduction is more natural than email.

Record the recommended channel and the reason. A missing email does not justify scraping personal data.

7. Draft From A Verified Team Perspective

Write a distinct message for each recipient. Ground the opening in one verified project detail, explain the practical benefit, make a concrete offer, and end with one easy question. Match the maintainer's language when reliable evidence supports it.

Use the verified sender's first-person perspective. If no sender identity is provided, draft from the company team voice and leave the signature unresolved. Never impersonate a founder, engineer, investor, customer, or community member.

Store the subject, body, evidence used, and any unresolved claim in the tracking record.

8. Create Or Update The Tracking Table

Read references/table-schema.md before creating or modifying records. Upsert by canonical repository URL plus campaign ID. Preserve prior notes and append timestamped events.

Set new drafts to draft_ready. Do not mark a project sent, replied, or complete based on intent alone.

9. Confirm, Send, And Verify

Before any external message is sent or posted, present a batch manifest containing:

• Project and recipient or destination
• Contact source
• Subject or post title
• Core offer
• Any uncertain claim

Wait for explicit approval of the exact batch. Approval for one batch does not cover newly added recipients or materially changed messages.

After sending, verify delivery through the provider response or sent folder. Only then append the timestamp and change the status to sent. Keep completion unchecked until the relationship reaches the user's stated completion condition.

10. Track Replies And Follow Up

Classify replies as positive, neutral, negative, bounced, or no response. Record the reply date, owner, next action, and follow-up date. Draft follow-ups with new value or useful progress; do not send repetitive nudges.

Deliverables

Return or persist:

1. Product brief with fact sources
2. Ranked candidate table with scores and evidence
3. Collaboration thesis and channel recommendation for each qualified candidate
4. Personalized outreach drafts
5. Approval manifest before external actions
6. Verified send ledger and table writeback summary

Report gaps honestly, including inaccessible pages, missing contacts, uncertain sender facts, failed sends, and records that could not be updated.