inbound-opportunity-protocol

Inbound Opportunity Protocol

When outbound contributions attract inbound attention — an email, a follow, a DM, a meeting request — this protocol governs the response. The contribution engine's campaign phases (UNBLOCK → ENGAGE → CULTIVATE → HARVEST → INJECT) produce these moments. This skill handles HARVEST.

When to Use

• An external person emails after seeing a PR or GitHub activity
• A company reaches out based on open-source contributions
• A contributor on your repos proposes collaboration
• Any signal that code output has converted to human contact

The Protocol

Phase 1: Verify (Before Responding)

Establish who contacted you and why. Never reply before completing verification.

1.1 Identity verification:

• Search GitHub for the person and their org (gh api search/users, gh search repos owner:<org>)
• Check their GitHub profile: repos, followers, contribution history, company affiliation
• Search the web: company website, LinkedIn, Twitter/X, Crunchbase
• Cross-reference with existing outreach/campaign data if the contact traces to a tracked relationship

1.2 Company research (if applicable):

• Fetch and analyze their public website, docs, and product pages
• Identify: team size, funding stage, tech stack, product architecture
• Check for job openings (research, don't mention)
• Assess: is this a potential employer, partner, collaborator, or user?

1.3 Signal assessment:

• What triggered the contact? (specific PR, GitHub profile, repo discovery)
• How fast did they respond? (same-day = they're monitoring the contributor space)
• What do they want? (knowledge exchange, hiring, partnership, product feedback)
• Strategic value: rate across 4 axes:
  • Skill acquisition — what can we learn from them?
  • Reputation leverage — does association increase visibility?
  • Relationship depth — could this become a lasting professional connection?
  • Direct improvement — does their work improve our stack?

Phase 2: Architecture Comparison

Before responding, understand how their system compares to yours. This determines conversation strategy.

2.1 Map their architecture:

• Read their docs, API references, and any public code
• Identify their core primitives (what are their equivalents of your key abstractions?)
• Note what they've built vs what they're building vs what they're struggling with

2.2 Find the intersection:

• Where do architectures overlap? (shared problems, similar solutions)
• Where do they diverge? (different trade-offs, complementary approaches)
• What do you have that they don't? (your distinctive contribution to the conversation)
• What do they have that you don't? (what you can learn)

2.3 Identify the hook:

• Find one architectural position where your approach differs from the mainstream
• Frame it as a refinement, not a contradiction — "I'd push your thesis further" not "you're wrong"
• The hook must be genuine and grounded in implementation, not theoretical posturing

Phase 3: Prepare Talking Points

Build a conversation prep document with three registers. Same architecture, three voices.

3.1 Technical register: For each major architectural component:

• 30-second explanation — conversational, no jargon, how to explain it to a peer
• Design trade-off — what was the alternative, why this was chosen
• Honest limitation — what doesn't work yet or where the design breaks
• Connection to their question — how this relates to what they asked about

3.2 Humanities register: Translate each component into its intellectual lineage:

• Biological precedent (ecology, ethology, neuroscience)
• Philosophical framing (phenomenology, systems theory, process philosophy)
• Cultural/literary reference (art, literature, social theory)
• The humanities register demonstrates depth of understanding — knowing WHY it works at a conceptual level, not just how

3.3 ELI5 register: Translate each component into a simple analogy:

• Everyday metaphor (kitchen, school, office, nature)
• No technical terms whatsoever
• The ELI5 register is the escape hatch — when reaching for jargon that can't be backed up, drop to ELI5. It sounds confident, not evasive.

3.4 Boundary mapping: Explicitly list:

• Three things NOT to claim — areas where depth is thin or implementation is incomplete
• Three questions to ask them — questions that reveal their architecture without directly asking "show me your code"
• Landmines to avoid — company-specific sensitivities, naming confusions, things not to dismiss

Phase 4: Draft Response

The response follows strict constraints:

4.1 Length discipline:

• Match or beat their brevity. If they wrote 5 sentences, write 4.
• Never explain full architecture in the first message.
• The response is a hook, not a presentation.

4.2 Structure:

1. Acknowledge what brought them to you (shows understanding of the connection)
2. Engage with their thesis — refine it, don't just agree ("resonates, but I'd push it further")
3. Offer the hook — one distinctive architectural position
4. Accept the meeting/chat
5. Sign off

4.3 What NOT to include:

• Don't link to repos (let them discover the iceberg)
• Don't mention job interest
• Don't list credentials or projects
• Don't oversell — a peer being consulted, not an applicant pitching

Phase 5: Pre-Conversation Preparation

After sending the response and before the actual conversation:

5.1 Code fluency pass: Read key source files — not to memorize, but to have opinions about design trade-offs. Know the constants, thresholds, and architectural reasons.

5.2 Conversation strategy:

• Lead with the distinctive claim (the hook from the response)
• Ask questions that reveal their architecture before exposing yours
• Cite external validation (contributor threads, community engagement) not just own work
• If asked about production scale: be honest. "Architecturally designed and unit-tested, not validated at scale."

5.3 Power position awareness: If they reached out first, the responder is the expert being consulted. Maintain that framing:

• Don't volunteer weaknesses unprompted
• Don't ask about job openings
• Let employment/partnership surface naturally from demonstrated competence
• The conversation IS the audition without either side calling it that

Phase 6: Post-Conversation

6.1 Log the interaction:

• Add/update entry in outreach.yaml with event and relationship score adjustment
• Update campaign.yaml if this advances a campaign phase
• Add to tracked_conversations.yaml if ongoing

6.2 Backflow extraction:

• What architectural patterns were learned from their system?
• What questions did they ask that reveal gaps in own thinking?
• Deposit learnings into backflow.yaml with organ targets

6.3 Follow-up:

• If action items were discussed, execute within 48 hours
• If they suggested looking at something specific, research and respond
• If the conversation was purely exploratory, brief follow-up within 24 hours

Artifacts

The protocol produces three artifacts, stored in contrib_engine/artifacts/:

1. <company>-briefing.md — company profile, architecture, team, competitive positioning
2. <company>-conversation-prep.md — technical talking points, trade-offs, boundaries, questions
3. <company>-conversation-filters.md — humanities and ELI5 translations of the same architecture

Key Principles

• Research before responding. Never reply to an inbound contact without completing Phase 1.
• Shorter than theirs. The response is a hook, not a pitch deck.
• Three registers, one architecture. Technical for depth, humanities for breadth, ELI5 for escape.
• Honest boundaries. Know what NOT to claim before the conversation starts.
• The conversation is the demonstration. Competence surfaces through substance, not credentials.