用途
Inbound Opportunity Protocol 用于处理一种特定场景：当你的对外开源贡献（outbound contributions）吸引了外部关注——一封邮件、一个关注、一条私信、一个会议请求——该协议规定如何回应。它被定位为贡献引擎活动阶段（UNBLOCK → ENGAGE → CULTIVATE → HARVEST → INJECT）中的 HARVEST 环节。
何时使用
- 外部人士在看到 PR 或 GitHub 活动后发来邮件
- 某公司基于开源贡献主动联系
- 你仓库上的贡献者提议合作
- 任何「代码产出转化为人类接触」的信号
主要能力
协议分为六个阶段：
阶段 1：验证（回复之前） 在完成验证前绝不回复。包括身份验证（用 gh api search/users、gh search repos owner:<org> 搜索 GitHub，查看其仓库、关注者、贡献历史、公司归属，并搜索公司网站、LinkedIn、Twitter/X、Crunchbase）；公司调研（抓取并分析其公开网站、文档、产品页，识别团队规模、融资阶段、技术栈、产品架构，查看招聘信息但不在对话中提及，判断对方是潜在雇主、伙伴、合作者还是用户）；信号评估（什么触发了联系、响应速度、对方想要什么），并从技能获取、声誉杠杆、关系深度、直接改进四个维度评估战略价值。
阶段 2：架构对比 回复前理解对方系统与自身系统的差异，以决定对话策略。包括映射对方架构（读文档、API 参考、公开代码，识别其核心原语，区分已建、在建与挣扎之处）；寻找交集（重叠处、分歧处、你独有之处、对方独有之处）；识别「钩子」（找到一个你的方法与主流不同的架构立场，将其框定为改进而非反驳，且必须真实、基于实现）。
阶段 3：准备谈话要点 构建一份包含三种语域的对话准备文档：技术语域（每个主要架构组件给出 30 秒解释、设计权衡、诚实局限、与对方问题的关联）；人文语域（将每个组件翻译为其思想谱系：生物学先例、哲学框架、文化／文学引用）；ELI5 语域（用日常比喻、完全不用技术术语，作为无法支撑术语时的退路）；边界映射（明确列出三件不可声称之事、三个要问对方的问题、要避免的雷区）。
阶段 4：起草回复 遵循严格约束：长度纪律（匹配或优于对方的简洁，若对方写 5 句就写 4 句，绝不在首条消息中解释完整架构，回复是钩子而非演示）；结构（确认对方为何找到你、参与其论点并加以改进而非单纯赞同、给出钩子、接受会面、署名）；不包含的内容（不链接仓库、不提求职意向、不罗列资历或项目、不过度推销）。
阶段 5：对话前准备 发送回复后、实际对话前：代码熟悉度通读（读关键源文件，形成对设计权衡的观点，了解常量、阈值与架构原因）；对话策略（以独特主张开场、先问能揭示对方架构的问题、引用外部验证、被问及生产规模时诚实回答「架构上已设计并单元测试，但未在大规模下验证」）；权力位置意识（若对方先联系，回应者是被咨询的专家，保持该框架，不主动暴露弱点，不询问职位空缺，让雇佣／合作自然浮现）。
阶段 6：对话后 记录互动（在 outreach.yaml 中新增／更新条目并调整关系评分，若推进活动阶段则更新 campaign.yaml，若持续则加入 tracked_conversations.yaml）；回流提取（从对方系统学到哪些架构模式、对方提出的问题揭示了自身思维的哪些缺口，将学习成果存入 backflow.yaml 并标注目标器官）；跟进（若有行动项，48 小时内执行；若对方建议查看某物，研究并回应；若纯探索性对话，24 小时内简短跟进）。
使用方式
该技能以协议文档形式提供，许可证为 MIT。使用者按阶段顺序执行：先完成阶段 1 验证，再进行架构对比与谈话要点准备，然后起草回复，最后做对话前准备与对话后记录。协议产出三份工件，存放于 contrib_engine/artifacts/：
<company>-briefing.md— 公司概况、架构、团队、竞争定位<company>-conversation-prep.md— 技术谈话要点、权衡、边界、问题<company>-conversation-filters.md— 同一架构的人文与 ELI5 翻译
适用场景
适用于开源贡献者、开发者关系或技术布道者，在对外贡献引发外部主动联系时，需要一套结构化流程来验证对方、评估机会、准备对话并记录结果。
限制
资料未提供该技能的具体安装命令、运行环境要求、支持的平台或收费信息。协议中提及的 outreach.yaml、campaign.yaml、tracked_conversations.yaml、backflow.yaml 等文件的具体格式与字段暂未提供。