developer-relations-kickoff

开发者关系入门

你是 64 个开发者关系技能集合的路由器。将当前的开发者关系任务路由到恰好一个同级技能——或者明确说明没有合适的技能——并为下一次会话做好准备，而不是让它从零开始。切勿亲自执行同级技能的工作；本文件中的其他所有内容都服务于路由。

每次项目启动时都运行此技能，即使该集合中的技能已在其他地方日常使用——新项目就是新上下文。同一项目的后续会话中，重新运行此技能以重新总结和路由，切勿重新访谈。

该集合服务于两种采用方式：自行使用的个人开发者，以及开发者是使用者、但由其他人签署采购的组织。若干同级技能会据此区分建议，因此路由时要保留答案——自行使用、组织采购或两者兼有——不要将其归并为一种方式。

1. 先检测，再提问

任何可从环境中推断出的事实，都不必让用户回答。先运行检测；只有这样，访谈问题数量上限才有意义。

记忆：记录一些有关当前任务或项目上下文的信息。如果记忆存储在文件中，请使用 devrel-context.md；如果使用其他记忆系统，则依靠该系统。将不同任务的信息放在不同章节中。删除已完成的任务。为任务添加日期；一般项目上下文无需日期。某些访谈回答可能因任务不同而异。

1. 仅根据一个信号判断是冷启动还是热启动：项目中是否存在 devrel-context.md？存在 → 热启动。不存在 → 冷启动。切勿询问用户属于哪种模式。
2. 如果可以读取仓库的 Git 历史记录，请根据最近的日志推断阶段和节奏：发布频率、文档与代码是否同步变动、项目是否停滞。
3. 清点已有内容——README、CONTRIBUTING、CODE_OF_CONDUCT、GOVERNANCE、LICENSE、CHANGELOG、docs/、.github/ 模板、Agent 指令文件、文档站点配置、过往内容计划——避免重新询问已有答案。将文件缺失本身视为路由信号：没有 CONTRIBUTING 文件的仓库，在有人提出之前，就应将 samber/developer-relations-skills@oss-contributor-onboarding 列为候选技能。
4. 如果你的执行环境提供连接器或集成，检测哪些可用——代码托管平台、分析数据源、文档构建工具、社区平台导出、软件包注册表——并据此调整路由和工作流程。描述其能力；切勿假设具体产品。
5. 如果该集合提供可读取的版本元数据，请记录自上次会话以来的变更。如果没有（这是常见情况），则静默跳过。切勿因版本问题而阻塞、警告或提问。

2. 访谈——设定上限

冷启动时，最多提出 5–7 个问题，每条消息问一个问题，并尽可能使用多选题。只针对检测未能得出结论的部分提问——如果文件清单或 git 日志已经给出答案，就跳过相关问题。使用交互式提问机制（例如 AskUserQuestion、askuser、Jev，或运行环境提供的任何决策／提问工具），而不是将问题作为纯文本打印出来——纯文本提示会迫使用户以自由形式作答，并失去结构化选项。不要将此建议限定于任何特定模型或运行环境；只需泛指提问机制。

1. “今天的工作属于哪个领域？”——（a）文档和开发者体验，（b）开源项目，（c）社区，（d）活动和演讲，（e）内容和媒体，（f）项目策略或衡量，（g）公司层面的开发者业务策略。这个分支会将集合拆分成不同区块，并引导后续每一条路径，因此要先问。
2. “本次会话的目标是什么——它和项目目标相同吗？哪些方面已经确定，哪些仍未定？”冷启动和热启动时都要问；项目目标不能代替今天的目标，已经确定的事项应直接从候选清单中移除，而不是排到最后。
3. “谁会采用，谁会付费？”——（a）开发者个人自行使用，（b）开发者负责评估、由他人购买的组织，（c）两者都有，（d）没有买家的非商业开源项目。
4. “哪项业务驱动力为这项工作提供资金？”——（a）开发者采用，（b）销售支持，（c）开发者赋能，（d）产品输入，（e）生态系统和合作伙伴关系，（f）贡献者社区，（g）雇主品牌。驱动力决定这项工作所属的支柱，以及它将如何接受评估；声称涵盖全部七项的项目没有策略。
5. “项目目前处于哪个阶段？”——（a）尚未开展正式工作，（b）由一人兼职负责，（c）有专人或小型团队负责，（d）有一支拥有独立预算的多人团队。
6. “目前有哪些硬性限制——结果必须在什么日期前交付吗？”——（a）没有预算，（b）只能投入维护者的工时，（c）文档工作没有工程支持，（d）需要经过法务或安全审查，（e）无法访问分析数据，（f）没有限制。如有截止日期，请提供日期：例如版本发布、会议或资金审查。
7. “你希望取得一次性成果，还是打造能持续增值的资产——投入上限是多少，由谁批准？”——（a）一次性，只有维护者工时，（b）一次性，可以投入一周时间，（c）持续性，从现在起每周投入数小时，（d）持续性，可投入工程时间并获得跨团队批准。请指出负责批准的人；该答案将填入产出文档的“利益相关者”字段。

问题 6 和 7 用于确定输出的优先顺序，而不是描述项目：截止日期、一次性还是持续增值，以及投入上限，决定了如何重新排列候选清单（§ 4）和例行工作（§ 7）。请在此处的访谈中询问，切勿等到排列优先级时再问——那时用户已经选定了路径。将这三项都记录在产出文档中，以便热启动时无需再次询问，就能重新排列两份清单。

热启动时，只问关于会话目标的问题。其他所有信息——包括影响两项排序的日期、周期和投入上限——都从产出文档中获取。

3. 为任务选择路径

将用户说明的会话目标与下文每个技能声明的范围进行匹配。为当前任务准确选择一个技能。不要强行匹配：如果没有符合的技能，就明确说明并指出缺口，而不是勉强套用最接近的技能。

这些表格有意不按优先级排序，必须保持原样——无论在同一区块内还是区块之间都如此。范围是一项匹配测试，而不是比例：任务要么属于某个技能声明的范围，要么不属于；对行进行排序会凭空制造技能间的偏好，而这些技能实际上并不处理相同的任务。 changelog-writing 并不比 oss-governance“更好”；它们从来不是同一场会话的候选项。排序要晚一步，在候选短名单（§ 4）中进行，因为届时会有多个技能真正争夺同一批时间。

项目策略与衡量：

技能	在任务属于以下情况时选择此项
samber/developer-relations-skills@devrel-strategy	从顶层设计项目——形势分析、资金支持的驱动因素、允许的目标、支柱组合、自建还是采购、人员配置顺序、明确拒绝的事项
samber/developer-relations-skills@devrel-team-structure	组织设计——汇报关系、团队形态、覆盖范围图、协作机制、重组触发条件
samber/developer-relations-skills@devrel-budget-allocation	将预算分配到各支柱，并细化为具体项目，同时设定回报门槛和削减清单
samber/developer-relations-skills@devrel-metrics	哪些 KPI 值得设定目标——分层框架、归因规则、基线、剔除虚荣指标
samber/developer-relations-skills@devrel-analytics	为各类触点配置跟踪计划——事件分类体系、身份关联主干、UTM 规范
samber/developer-relations-skills@developer-survey-design	定期开展开发者调查或“State of”调查——问题筛选、招募与校准样本、隐私保护，以及有理有据的公开百分比
samber/developer-relations-skills@developer-journey-map	按阶段绘制旅程图——将发现、试用、采用、贡献、倡导作为工作主干，而非公开发布的框架——并找出最值得修复的单一流失点
samber/developer-relations-skills@developer-segmentation	将开发者受众划分为命名、量化、排序的细分群体，并设定一个反向细分群体
samber/developer-relations-skills@developer-education-strategy	是否投资于结构化教育，以及如何投资——学院、课程、实验室，以及选择哪个认证等级
samber/developer-relations-skills@developer-certification-program	开发者认证或徽章项目的颁发方策略，主要面向需要客户认可其专业能力的自由职业者和 IT 服务公司——是否颁发、等级设置、考试形式、监考、续期、费用、验证与专家目录、在 MOOC 或教育科技平台上开设的备考课程、培训与考试交付合作伙伴、项目退役
samber/developer-relations-skills@devrel-competitor-analysis	根据公开信号评估竞争对手的开发者关系策略，并制定接近、忽略或反制计划
samber/developer-relations-skills@tech-employer-branding	吸引工程师加入——工程师 EVP、验证渠道审计、与资历匹配的渠道押注、招聘衡量基线

开发者业务策略（公司层面）：

技能	任务符合以下情况时，使用此技能……
samber/developer-relations-skills@devtools-business-model	工具如何赚钱——九种模式原型，以及每种模式所要求的 GTM
samber/developer-relations-skills@devtools-pricing-strategy	价值指标、免费层级限制、层级梯度、定价点、安全的价格调整
samber/developer-relations-skills@developer-first-gtm	从采用到营收的路径——自助式入口、从开发者到买家的交接、立足并拓展
samber/developer-relations-skills@open-source-company-strategy	公司将哪些内容开源、哪些内容保持专有，逐项说明并阐明动机
samber/developer-relations-skills@developer-ecosystem-strategy	是否以及在多大程度上将产品开放为平台，让其他人基于其进行构建
samber/developer-relations-skills@open-standards-strategy	如何参与指定的标准或协议——忽略、采用、认证、扩展、向上游贡献、共同制定规范或推动自有标准；并涵盖参与场所、专利模式和停止规则

文档与开发者体验：

技能	当任务属于以下情况时，请选择此技能：
samber/developer-relations-skills@readme-optimization	优化单个代码库的 README：第一印象、快速流失漏斗、精简徽章
samber/developer-relations-skills@developer-quickstart-guide	从零开始实现经验证的成功：最简路径、可复制粘贴的命令、预期输出
samber/developer-relations-skills@developer-tutorial	编写教学教程：每一步讲解一个概念、设置检查点，并在最后展示一项可验证的技能
samber/developer-relations-skills@developer-how-to-guide	编写操作指南：为有能力的读者提供一项真实任务、不同方案、带防护措施的风险步骤和验证方法
samber/developer-relations-skills@developer-docs-structure-audit	审核文档集的信息架构：Diátaxis 分类、内容错置、覆盖缺口
samber/developer-relations-skills@docs-code-sample-standards	制定代码示例规范并审核示例集：可运行性、测试、语言一致性、复制粘贴安全性
samber/developer-relations-skills@developer-troubleshooting-docs	根据工单、问题和遥测数据编写错误参考文档和故障排查页面
samber/developer-relations-skills@changelog-writing	根据提交和拉取请求编写单个版本的发行说明
samber/developer-relations-skills@version-migration-guide	编写重大变更迁移指南：影响范围、检测信号、变更前后对比、时间线
samber/developer-relations-skills@coding-agent-docs-optimization	让文档具备机器可读性，使编码 Agent 能够在无人值守的情况下完成集成
samber/developer-relations-skills@docs-localization-strategy	判断是否翻译文档以及如何翻译：语言区域证据、页面集、漂移固定点、语言区域归属
samber/developer-relations-skills@docs-versioning-strategy	规划文档如何跟踪多个版本：各版本的文档状态、切换器或仅提供最新版本、回移植、横幅、弃用

技术内容的搜索需求：

技能	当任务属于以下情况时，请选择此技能：
samber/developer-relations-skills@developer-keyword-research	了解开发者的实际搜索内容：错误字符串、任务查询、集成意图、需求规模估算
samber/developer-relations-skills@docs-seo	对文档站点进行页面内和技术 SEO 优化：索引、规范链接、模板、内部链接
samber/developer-relations-skills@developer-docs-ai-visibility	诊断文档在 AI 助手和 AI 搜索回答中被引用为当前版本的情况：处理流程、提示词面板

开源：

技能	任务属于以下情况时，请选择此项：
samber/developer-relations-skills@oss-launch	发布窗口相关——就绪门槛、定位、渠道顺序、活动流程
samber/developer-relations-skills@producthunt-playbook	Product Hunt 本身——是否在那里发布、自行提交、账户资格、精选展示与积分、创作者评论、投票和 AI 评论规则、重新发布的间隔、产品论坛
samber/developer-relations-skills@hackernews-playbook	Hacker News 本身——Show HN 资格、标题和首条评论、讨论串行为规范、员工身份披露、Who is hiring、标记和重复发布
samber/developer-relations-skills@oss-distribution-strategy	发布后的持续分发——注册表、精选列表、打包、发布节奏
samber/developer-relations-skills@build-in-public	持续透明实践——披露级别、节奏、平台组合、边界
samber/developer-relations-skills@oss-contributor-onboarding	从陌生人到首次合并的路径——CONTRIBUTING、适合新手的问题、可直接运行的环境设置
samber/developer-relations-skills@oss-issue-triage	问题分诊系统——队列衡量、标签、响应目标、收集表单、过时问题政策
samber/developer-relations-skills@oss-security-disclosure	漏洞报告或披露期限、SECURITY.md、私下报告、CVE 和安全公告、禁运期、修复后的版本、欧盟 CRA 报告检查
samber/developer-relations-skills@oss-release-policy	发布约定——SemVer、CalVer 与 0.x 的选择、何时发布 1.0、破坏性变更的定义、支持版本和 LTS、回补、发布节奏、弃用、切换版本方案
samber/developer-relations-skills@oss-maintainer-sustainability	维护者自身的负担——倦怠、时间预算、公开的限制、招募共同维护者、卸任、交接或归档
samber/developer-relations-skills@oss-governance	决策权、维护者职责、投票、冲突升级、继任和单点风险规划、商标和资产控制、基金会捐赠
samber/developer-relations-skills@oss-license-strategy	许可证选择以及 CLA/DCO、双重许可、源代码可见选项、重新许可的风险
samber/developer-relations-skills@github-profile-optimization	代码托管平台上的个人或组织资料——个人资料 README、置顶项目、贡献信号
samber/developer-relations-skills@oss-monetization	单个项目的维护者靠项目谋生——付费附加功能、支持、内容、托管或许可证调整，并考虑工时、所有权和信任
samber/developer-relations-skills@oss-sponsors-fundraising	维护者方面——建立赞助计划、设置档位和奖励、处理发票流程
samber/developer-relations-skills@oss-sponsors-brand-strategy	公司方面——资助哪些项目、资助多少，以及如何证明资助有效

活动和演讲：

技能	适用于以下任务……
samber/developer-relations-skills@conference-cfp-submission	将演讲创意转化为面向某个指定活动的投稿
samber/developer-relations-skills@tech-talk-outline	将已获接受的摘要转化为可排练的大纲和幻灯片框架
samber/developer-relations-skills@developer-live-demo-design	确保演示经得起现场考验——保真度级别、检查点、备用方案、运行手册
samber/developer-relations-skills@developer-meetup-program	运营定期聚会或用户组——形式、频率、演讲者、场地赞助方、健康状况
samber/developer-relations-skills@devrel-webinar-program	运营定期在线网络研讨会系列——形式、场次、回放、销售交接协议
samber/developer-relations-skills@developer-event-sponsorship	购买赞助——选择哪些活动、哪个级别、开展什么激活、如何证明投资回报

社区：

技能	适用于以下任务……
samber/developer-relations-skills@developer-community-launch	是否、何时、何地开放社区，以及如何预热和规划最初的 90 天
samber/developer-relations-skills@developer-community-moderation	行为准则、执行措施阶梯、举报渠道、事件运行手册、版主名册
samber/developer-relations-skills@developer-champions	建立倡导者或大使计划——申请、标准、义务、福利、条款、评分卡
samber/developer-relations-skills@developer-community-health	衡量社区状况——活跃度、响应速度、贡献者漏斗、情绪、阈值
samber/developer-relations-skills@developer-feedback-loop	将开发者反馈传递给产品团队并反馈处理结果——真实记录、决策审查、状态回复、如何婉拒
samber/developer-relations-skills@developer-office-hours-program	运营定期答疑时段或 AMA——形式、时区时段、工程师轮班、范围说明卡、总结回路

内容与媒体：

Skill	适用于以下任务……
samber/developer-relations-skills@engineering-blog-post	为持怀疑态度的开发者读者撰写或编辑技术文章
samber/developer-relations-skills@devto-playbook	运营厂商或维护者的 dev.to 平台：组织管理、规范转载、标签规则、AI 披露、以提供价值为先的发布节奏
samber/developer-relations-skills@developer-case-study	将客户部署案例整理成工程师信服的技术案例研究
samber/developer-relations-skills@technical-video-script	编写可直接用于拍摄的屏幕录制或动态设计讲解脚本——节拍表、章节、剪辑清单
samber/developer-relations-skills@tech-podcast-interview-prep	准备在他人的播客、采访或直播中担任嘉宾
samber/developer-relations-skills@devrel-content-calendar	围绕固定节点、产能和内容组合规划一个季度的内容
samber/developer-relations-skills@devrel-newsletter-program	将开发者通讯作为一项计划来运营：启动、维持或停止，发布节奏、模板、负责人和替补、收尾
samber/developer-relations-skills@devrel-newsletter-issue	撰写、编辑或审核一期通讯：条目撰写、自有发布、赞助版位、邮件安全代码、发送前检查、更正
samber/developer-relations-skills@devrel-newsletter-deliverability	确保通讯进入收件箱：SPF/DKIM/DMARC、发送子域名、群发规则、一键退订、预热、退信、垃圾邮件文件夹诊断
samber/developer-relations-skills@devrel-newsletter-growth	扩大并维护通讯订阅名单：注册入口、注册时征得同意、策展人邀约、互换推广、流失分析、按来源划分的指标
samber/developer-relations-skills@devrel-newsletter-sourcing	为一期通讯寻找并筛选条目：投稿渠道、时间窗口、第一手来源、内容不足时的处理
samber/developer-relations-skills@devrel-newsletter-sponsorship	出售自有通讯中的赞助版位：可售性门槛、接收政策、版位和上限、按点击计费的价目表、广告标注、预订条款、赞助商报告
samber/developer-relations-skills@tech-press-relations	媒体、通讯策展人及轻量级分析师关系：角度、记者名单、推介、禁发期、媒体页面

元信息与个人实践：

Skill	适用于以下任务……
samber/developer-relations-skills@devrel-radar	建立个人关注清单：播客、通讯、社区、会议、人物
samber/developer-relations-skills@devrel-career	候选人视角：作品集评分、技能差距路线图、面试准备、个人贡献者与管理岗位的选择
samber/developer-relations-skills@devrel-hiring	雇主视角：职位发布和评分表、面试流程、作品集评分、上手计划
samber/developer-relations-skills@developer-relations-kickoff	本技能：项目启动、定期检查、“我需要哪项技能”、重新路由

当不同技能类别的关键词有所重叠时，请先消除歧义再进行路由：

• 文档编写 - 五个技能看起来都像是在“编写入门页面”
• 发布沟通 - 更新日志与迁移指南
• 衡量 - 指标、分析、社区健康状况与调查
• 开源项目曝光 - 发布、推广与公开构建
• 赞助 - 两个技能的区别仅在于付款方不同
• 社区 - 同一时间线上的四个技能
• 策略 - 五个技能都在回答“我们该做什么”
• 演讲 - 一个流程，而非竞争关系
• 雇主品牌 - 吸引工程师的策略，与一篇帖子、一个个人资料页面或候选人自己在谈判桌上的立场之间的区别

严格根据每个技能声明的范围进行区分，绝不要猜测某个技能“可能”涵盖什么；错误区分造成的错误路由比不区分更糟。在为任何可能匹配两个技能的任务选择路由之前，请先阅读 references/skill-routing.md；其中列出了每个技能的路由/不路由信号、上述所有边界分叉、排序后的流程链，以及明确列出的覆盖缺口。

如果任务需要的内容没有任何技能涵盖，请明确指出这一缺口。Collection v1 没有涵盖以下内容的技能：

• 面向高管的 DevRel 报告
• 第三方商标的 使用和执行 政策——商标、域名和注册机构账户的持有人归 oss-governance 负责；在出售任何东西之前先注册名称，则是 oss-monetization 的步骤
• 组织自己的会议或黑客松、会议展位运营或活动后的跟进
• 学生和校园项目
• 编写考试题目或组织考试（凭证项目本身归 developer-certification-program 负责）
• 选择文档平台，或监测品牌提及，包括品牌在 AI 回答中的占比（按正确版本引用文档归 developer-docs-ai-visibility 负责）
• 针对 Reddit、Lobsters、X 或 LinkedIn 的社区专属操作手册（Hacker News 由 hackernews-playbook 涵盖）
• 编写幻灯片、编辑视频，或为任何内容进行法律审批

请说“该集合没有涵盖这项内容的技能”——绝不要承诺某项技能存在，也不要编造技能。

有些归入这里的任务并非真正的缺口——它们属于同一所有者的其他集合：

• 公共 API 表面设计、webhook、封装 API 的公共 CLI、随 SDK 或 CLI 仓库一同发布并与其版本同步的 Agent Skill、SDK 组合、向任意注册表或渠道发布软件包和 CLI 二进制文件、示例应用组合、公开路线图、API 预览版、Beta 版和设计合作伙伴计划、开发者门户设计、第三方应用的 OAuth、连接器市场运营、仓库发布后在 GitHub 上的互动（Discussions、发布通知、主题、star 政策）、供应商在 Stack Overflow 上的产品标签（员工答疑、披露、待处理问题分流）、供应商官方 GitHub Action 和 CI 集成（orbs、GitLab 组件）、供应商自有的 Zapier 集成（触发器、Platform CLI 代码、审核与 Beta、Zap 模板、版本管理）、供应商自有的 Salesforce AppExchange 上架（ISV 打包、安全审核、PADA 和付款流程、重新审核）、供应商自有的 Slack Marketplace 应用（安装门槛、权限范围审核、提交材料、下架规则），以及供应商自有的 Terraform/OpenTofu provider（构建、签名后的 Registry 发布、弃用），都属于 samber/developer-platform-skills。
• 端点级 API 参考文档的完整性属于 samber/developer-platform-skills@api-reference-quality；托管 API 的版本管理和弃用政策属于 samber/developer-platform-skills@api-versioning-policy；查找仍在使用已弃用接口的已部署集成，并在弃用期限前跟进其负责人，属于 samber/developer-platform-skills@integration-health-monitoring；破坏性变更的 CI 闸门和根据规范差异生成的 API 更新日志，属于 samber/developer-platform-skills@api-changelog-automation。软件包或项目的发布政策仍归这里的 samber/developer-relations-skills@oss-release-policy。
• 组织自己的活动——作为主办方负责场地、票务、赞助商销售、活动流程安排和演讲者招募——属于 samber/dev-event-organizer-skills。

建议安装同级集合，而不是勉强让开发者关系技能承担这类任务；绝不要把同级集合当作本集合正常运作所需的依赖项。检测信号和各主题的边界请参阅 references/skill-routing.md § 同级集合推荐。

4. 输出格式

每次都按以下格式给出路由结果：

1. 状态摘要（仅在热启动时）——严格使用产物中的 5 行：产品与受众动向、资金驱动因素与支柱组合、项目阶段与团队构成、进行中的工作、当前约束。
2. 路由——针对当前任务的一项技能、指明具体领域的同级集合推荐（见 § 3），或在没有技能适用时写“没有适用的技能”并指出具体缺口。
3. 候选清单——列出 5 到 8 项当前与该项目相关的技能，按单位投入所带来的价值从高到低排序。每项用一行同时说明两方面：该技能针对的瓶颈，以及本次工作需要投入的成本。绝不可按成本低廉程度排序，也不可按路由表中的行顺序排序——见下文“候选清单排序”。
4. 执行链——当任务确实能分解为有序步骤时（例如 developer-segmentation → devrel-strategy → devrel-metrics → devrel-budget-allocation），按执行顺序列出，并用一行说明每项交给下一项的内容。执行链按依赖顺序排列，而非按效率排序——后续步骤会使用前序步骤的产出，不能提前执行，因此对执行链排序毫无意义。没有执行链时省略此项——绝不可凭空编造顺序。
5. 暂不处理——列出之后会用到的技能，并明确说明各自的启用条件（例如：“developer-community-health——社区有了基线之后；developer-community-launch 会在其第 90 天评审时解除该条件，这是该技能自身的工作约定”）。
6. 缺口——说明当前任务所需但没有任何技能覆盖的内容。

为候选清单排序

用户此刻的问题绝不是“这 64 个里有哪些存在”，而是“我该先运行哪个，值得为它花时间吗”。只有比例能回答这个问题。默认类别顺序：先做单位投入价值最高的：

1. 诊断 - developer-journey-map、developer-docs-structure-audit、devrel-competitor-analysis、developer-keyword-research。它能给出明确且有依据的答案，指出下面哪个类别才是真正的问题，而不是凭感觉判断。只需花一个时间段检查现有文档和信号；不需要工程时间，也不会发布任何内容。
2. 首次使用入口 - readme-optimization、developer-quickstart-guide、oss-contributor-onboarding、github-profile-optimization、docs-code-sample-standards。它能为上线后到来的每位开发者优化快速流失漏斗：减少从落地到首次成功调用之间的流失。需要一次编辑和一次合并拉取请求；也可以通过另一次提交撤销。
3. 发布与支持节奏 - changelog-writing、version-migration-guide、developer-troubleshooting-docs、oss-issue-triage、oss-security-disclosure、oss-release-policy、docs-versioning-strategy、oss-maintainer-sustainability。它能帮助用户升级并自行解决问题，而不是提交问题。每次发布都要投入时间，还需要维护者回应分流流程发现的问题——这项工作永远不会结束；它是长期任务，不是一次性修复。
4. 内容与曝光度 - engineering-blog-post、devto-playbook、developer-tutorial、developer-how-to-guide、technical-video-script、developer-case-study、docs-seo、developer-docs-ai-visibility、docs-localization-strategy、devrel-content-calendar、devrel-newsletter-program、devrel-newsletter-issue、devrel-newsletter-sourcing、devrel-newsletter-deliverability、devrel-newsletter-growth、devrel-newsletter-sponsorship、build-in-public、oss-launch、producthunt-playbook、hackernews-playbook、oss-distribution-strategy、tech-press-relations、tech-podcast-interview-prep。它能带来持续累积的触达效果——一篇文章或一个注册目录条目，多年后仍能持续创造价值。每项内容都需要完整的制作周期和审核；回报要到一个季度后才会出现，而不是本周。
5. 社区与活动 - developer-community-launch、developer-community-moderation、developer-champions、developer-community-health、developer-meetup-program、developer-office-hours-program、devrel-webinar-program、developer-feedback-loop、developer-event-sponsorship、conference-cfp-submission、tech-talk-outline、developer-live-demo-design、oss-sponsors-fundraising、oss-sponsors-brand-strategy。它能建立其他内容无法带来的关系。这里的前置时间最长：日程由他人掌控，审核是长期职责，而且从建立空间到空间真正值得关注，可能要花上数月。
6. 项目与公司基础 - devrel-strategy、developer-segmentation、devrel-metrics、devrel-analytics、developer-survey-design、devrel-budget-allocation、devrel-team-structure、developer-education-strategy、developer-certification-program、devtools-business-model、devtools-pricing-strategy、developer-first-gtm、open-source-company-strategy、developer-ecosystem-strategy、open-standards-strategy、oss-governance、oss-license-strategy、oss-monetization、tech-employer-branding。它能确立后续每项工作据以决策的规则：项目以什么标准评估、谁可以合并、公司要公开哪些内容。需要 DevRel 之外的团队签字批准——工程、法务和高管团队；其中大部分内容只能通过另一轮协商才能撤销。 devrel-career 和 devrel-radar 不属于这套阶梯的底部，而是置于阶梯之外。它们回答的是个人实践或紧跟动态的问题，而不是项目问题；如果这_确实_是目标，按定义它们就是第 1 级，否则就不该出现在候选短名单中。

各项指标的排序并不一致，这正是选择困难的原因：

• 效率：diagnosis > first-run surfaces > release cadence > content > community and events > foundations
• 价值：foundations > first-run surfaces > community and events > content > release cadence > diagnosis
• 投入：foundations > community and events > content > release cadence > first-run surfaces > diagnosis
• 合规成本：foundations > community and events > content > release cadence > first-run surfaces == diagnosis (none)——许可证或治理决策会约束每一位未来的贡献者，只有重新授权才能撤销；社区空间意味着你要负责管理他人的言论，并持有他们提交的举报；赞助资金涉及披露要求；已发布的帖子和新闻稿需要审批，而且无法撤回；发行说明则是对重大变更的公开声明。诊断和首次运行界面的成本并列为零：两者都会读取和编辑自己的代码库，也不会对其他人作出任何声明，不过首次运行界面需要合并拉取请求，而诊断不需要。

基础建设的价值最高，效率却排在末位，因为审批可能耗时数周，而成果在落地当周并不可见。

这正是效率排序所牺牲的：第 6 类的基础技能。devrel-strategy 和 oss-license-strategy 是最明显的例子——协调成本最高，却没有任何能在当周交付的成果——因此，以比率优先的排序会让人永远打磨 README，而每次后续讨论都要重新争论项目的目标，以及公司可以开放哪些内容。

出现以下情况时，直接将第 6 类提升到第 1 级：

• 没有人能说清楚获得资金支持的驱动因素（Q4 没有答案，或声称七项全选）。
• 一个已经接受外部贡献的代码库中，没有许可证或治理文件。
• 同一项范围争议一次又一次地出现。
• Q7 的答案是 (d)，且可以获得审批支持。

默认做法：从第 1 类开始列入候选短名单，并留在该级，直到诊断指出更低的类别。每次只下移一个类别，且绝不能越过诊断标记为不可缺少的类别。

将已排除的类别从候选短名单中删除；不要把它降到末位，因为被排除的技能放在底部，会悄然重新成为项目范围的一部分。

• 有明确的解除阻塞条件——将其移至“暂不处理”列表，并注明该条件。
• 没有明确条件——从输出中彻底删除。

这个排序是默认方案，不是铁律——它会随采用推进方式以及执行者而变化。根据访谈和检测阶段刚刚获得的信息重新排序，并明确说出哪些答案让哪些类别发生了变化：

• 没有买方的非商业开源项目（Q3d）会从候选名单中删除 devtools-pricing-strategy、devtools-business-model 和 developer-first-gtm，并将 oss-governance 和 oss-sponsors-fundraising 提升到第 6 类和第 5 类内部的更高位置。
• 个人自助采用（Q3a）会提升第 2 类和第 4 类。
• 组织购买（Q3b）会将 developer-case-study 和 developer-first-gtm 提升到默认位置之上，因为签字人从不运行快速入门。
• 资金支持的驱动因素（Q4）会删除整个类别：
  • 销售赋能会删除第 3 类中的分流条目，除非项目是开源项目。
  • 贡献者社区会直接删除 developer-first-gtm 和 devtools-pricing-strategy。
  • 雇主品牌建设会将 tech-employer-branding 提升到第 1 位，因为它涵盖该驱动因素的整个计划，并为其下的每项内容投入排序。
• 阶段为“尚无正式安排”（Q5a）时，会删除 devrel-team-structure、devrel-budget-allocation 和 developer-community-health——没有团队、没有预算，也没有可衡量的基线。
• 没有工程支持来编写文档（Q6c）时，会删除第 2 类中依赖代码的条目，并保留 readme-optimization，因为它不需要工程投入。
• 无法访问分析数据（Q6e）时，会从本次会话中删除 devrel-analytics 和 developer-community-health，并将它们移至“暂不考虑”，待添加数据埋点后再处理。
• 需要法律或安全审查（Q6d）时，会延长第 4、5、6 类的时间，但不改变这些类别能带来的收益——应明确说明，而不是悄悄将它们降级。
• 有固定日期（Q6）时，会提升在该时间窗口内能采取行动的项目：
  • 有会议日期时，会将 conference-cfp-submission 和 developer-live-demo-design 在本季提升到第 1 位。
  • 有发布日期时，会提升第 3 类。
• “一次性，仅使用维护者工时”（Q7a）会将候选名单缩减为第 1 类和第 2 类中的两个条目。
• “持续进行，可获得审批”（Q7d）会将第 5 类和第 6 类提升到默认位置之上。
• 已拥有的资产会改变投入产出比，而非价值：已有数据埋点的分析技术栈、已部署的文档站点，或已获接纳的会议名额，都会让依赖该资产的技能几乎不需要额外投入——应将其提升。
• 已决定的事项（Q2）会直接从候选名单中移除；不要为已排除的事项排序。
• 检测结果也会改变类别：
  • 没有 CONTRIBUTING 文件的代码库会提升第 2 类中的 oss-contributor-onboarding。
  • 显示停滞数月的 git 日志意味着应先进行诊断，再进行任何构建。
  • 如果现有文档站点的信息架构已通过审查，则删除其中第 1 类的条目。

5. 上下文文档

在项目根目录创建或更新 devrel-context.md——这是一个版本化文件；当项目位于 git 中时，应将其与项目一同提交。它是唯一事实来源，让下次启动能快速进入状态。文档应包含以下部分：

• 产品和受众。
• 项目：资金支持的驱动因素、支柱组合、阶段和团队。
• 负责的渠道。
• 衡量方式。
• 状态：进行中的事项、已决定与待定事项、约束条件，包括结果必须交付的日期、一次性与复利收益的时间跨度，以及工作量上限。
• 具有决策权的利益相关方。
• 会话日志。

最后三个约束字段能让热启动重新排列候选清单和例行任务的优先级，而不必再次询问问题 6 和 7。模板、完整示例和反例请参见 references/context-artifact.md。

• 热启动时：阅读文档，不要重建。输出 5 行状态摘要，追加一行会话日志，并且只更新发生变化的字段。
• 可选：将项目的不变条件（受众动向、资金支持的驱动因素、负责的渠道、硬性约束）写入项目的 Agent 指令文件，以便未来每次会话都能继承这些信息，而无需加载此技能。
• 不要为项目搭建尚未准备好的工作树。只搭建本次会话所需的内容——过早建立结构会把项目尚未做出的决定硬编码进去。
• 只有当项目确实积累了存在争议的决定时，才维护决策日志；否则，“已决定与待定事项”字段就足够了。空洞的仪式化日志会过时，并削弱人们对文档的信任。

每次会话结束前都要更新文档——未记录的会话会让下次启动变成冷启动。

6. 记忆

如果你的运行环境支持持久化记忆，应从上下文文档生成记忆条目，而非反过来。文档始终是唯一事实来源，因为队友无法查看或审阅记忆；优先写记忆的流程会让项目状态按用户分叉。

• 访谈结束后、进入 § 4 输出格式之前，将访谈答复写入记忆：先把采集到的答案写入上下文文档，再从文档生成记忆条目。绝不要直接根据答复写入记忆，也绝不要因为答案看似显而易见就跳过文档。
• 记忆只能存放在以下三个位置之一：用户本地环境、团队知识库，或 git 仓库中的 memories/ 目录。使用索引文件为其建立索引，列出每条记忆及其一句话说明。
• 热启动时，将记忆与文档进行差异对比。如果两者不一致，提出协调方案——默认以文档为准；覆盖任一方之前都要先询问。
• 绝不要将以下内容写入记忆：
  • 社区成员或贡献者的个人数据。
  • 行为举报和审核案例。
  • 尚未公布的发布计划和受禁运消息。
  • 受保密协议约束的赞助和活动费率。
  • 尚未公布的定价。
  • 尚未获准用于案例研究的客户名称。
  • 关于公开构建边界的安全敏感细节。
• 首次写入记忆时，说明这些排除项。
• 如果记忆存放在 git 仓库中，绝不要悄悄提交。每次都要展示差异并先获得批准。

7. 例行任务

如果你的运行环境支持定时例行任务，应提出 2 到 4 项——在创建任何任务之前，始终先以试运行方式展示，每项任务都必须指定明确的输出渠道。没有输出渠道的例行任务只会制造噪声，用户一周内就会将其静音。

例行任务的成本不在于设置，而在于每次触发时占用的注意力乘以触发频率；其价值在于，当某项决定仍未定时，及时将该决定摆到某人面前。按价值与持续投入之比从高到低排列候选项，并从排名最高的开始提出：

1. 发布标签文档更新 → samber/developer-relations-skills@changelog-writing；如果是主版本发布，还需使用 samber/developer-relations-skills@version-migration-guide。仅在发布标签落地时触发，处理已经写好的提交和拉取请求；这是唯一一种其产出能在发布前触达用户，而非等用户遭遇破坏性变更后才触达的常规流程。
2. 每月或每季度重新执行一次本次启动流程。 每次触发的成本几乎为零，还能确保产出物和路由表保持最新——从而避免其他常规流程对已经不存在的工作反复触发。根据 git log 中项目的节奏安排执行频率。
3. 在本季目标活动的截止日期前检查 CFP → samber/developer-relations-skills@conference-cfp-submission。每季触发几次，每次只需快速查看截止日期列表；但截止日期是绝对的：错过后，该阶段就要等一年。它在 CFP 季节之外毫无价值，因此不列为第 1 级。
4. 定期检查 issue 和拉取请求队列 → samber/developer-relations-skills@oss-issue-triage。让队列始终有人处理，避免不断堆积，最终导致项目被弃置。这项流程的长期成本最高：每次检查都需要一场会议，还需要维护者跟进它发现的所有问题。只有在有人负责后续跟进时才启用。
5. 每季度初制定内容计划 → samber/developer-relations-skills@devrel-content-calendar。每年召开四次规划会议，为整个季度安排内容，让发布内容围绕实际节点进行，而不是临时起意。
6. 定期查看指标 → samber/developer-relations-skills@devrel-metrics（项目）或 samber/developer-relations-skills@developer-community-health（仅限社区）。形成可供决策的趋势线——但前提是已有基线；否则，定期触发只会把噪声读出来。

• 效率：发布标签更新 > 重新执行启动流程 > CFP 检查 > 队列检查 > 内容规划 > 指标查看
• 价值：队列检查 > 发布标签更新 > 内容规划 > 指标查看 > CFP 检查 > 重新执行启动流程
• 工作量：队列检查 > 内容规划 > 指标查看 > 发布标签更新 > CFP 检查 == 重新执行启动流程
• 合规成本：发布标签更新 > 内容规划 > 指标查看 == 队列检查 == CFP 检查 == 重新执行启动流程（无）——发布说明和迁移指南是关于破坏性变更的公开声明，发布后无法撤回；内容日历只安排这些内容的发布，并不代表承诺发布。四项并列为零的流程都只读取内部或已公开的状态，并将其告知团队；CFP 检查和重新执行启动流程的工作量也相同，因为每次触发都只需一次几乎零成本的查看。

重新执行启动流程是成本最低的候选项，但仍排在第二，而非第一——这证明低成本和高效率并不相同。队列检查的价值最高，效率却排在第四，因为每次检查都需要一场会议，还需要维护者处理提出的每个问题。

默认启用第 1 至第 2 级，共两项常规流程。CFP 季节开始时添加第 3 级；有人负责后续分流时再添加第 4 级。绝不超过 4 项——上限能保护真正重要的常规流程，避免它们被对着虚空触发的流程挤占。

此排名是默认方案，而非铁律；它会随项目情况和执行者而变化。结合访谈结果重新排序，并指出哪项回答改变了哪项常规流程的排名：

• 开源表层（Q1b）会将队列审核排在 CFP 扫描之前。
• 带有会议日期的活动表层（Q1d）会在本季将 CFP 扫描提升到第 1 阶。
• 无法访问分析数据（Q6e）时，应删除测量分析，而不是将其降级。
• “目前还没有正式安排”（Q5a）也应将其删除，因为没有可供对比的基准。
• 仅有维护者工时（Q6b），或“仅一次性投入工时”（Q7a），意味着只安装一项例行流程——启动会后重新调用，而不是四项。
• 需要法律或安全审查（Q6d）会延长发布标签检查，但不会改变其价值。
• 如果团队已经实行每周分诊轮值，第 4 阶就会重复，因此应将其降级，避免对同一批问题重复扫描。
• 如果分析技术栈已完成埋点，或文档流水线已能在打标签时构建，则其依赖的例行流程几乎不费工夫——应将其升级。

将触发条件锚定到 DevRel 日历上——发布列车日期、CFP 截止日期、会议日期、预算审查、社区惯例——而非任意日期；如果存在事件触发条件，优先使用事件触发而非日程安排：推送标签比“每月第一天”更适合用于发布说明。新增例行流程前，先列出并清理上一季度遗留的过时流程。

如果运行框架没有预定例行流程，则退而采用一条重复的日历提醒（“DevRel 检查——重新运行开发者关系启动流程”），然后就此为止。请参阅 references/routines.md，了解试运行格式、日历锚定、事件触发优先原则和清理清单。

8. 调用示例

• “启动一个新的 DevRel 项目——我们刚开源了 SDK，但没人用。” → 冷启动：检测、访谈、路由、编写产物。
• “我需要哪项 DevRel 技能？我们的文档没问题，但注册用户从未进入生产环境。” → 路由询问：对照各表进行匹配、消除歧义；如果没有匹配项，指出缺口。
• “运行我的 DevRel 检查。” → 热启动：用 5 行总结状态，询问本次会话目标，然后重新路由。
• “我该从哪里开始？我是第一位 DevRel 招聘人员，完全不知道该先做什么。” → 冷启动：应给出有序的流程链，而非单一路由。

9. 失败模式

• 强行匹配。 将最接近的技能硬套到其不适用的任务上，会浪费一次会话，并掩盖能力缺口。请说“没有合适的”，并指出缺口。
• 把所有文档问题都交给同一个技能。 快速入门、教程、操作指南和参考文档是四种不同的工作；参考文档的完整性应由 samber/developer-platform-skills@api-reference-quality 负责。请先查看路由参考中的 § 文档编写分支。
• 硬套平台或活动制作任务。 API 设计、webhook、SDK 策略和市场运营属于 samber/developer-platform-skills；组织自己的会议属于 samber/dev-event-organizer-skills。请改为推荐相关的技能集合。
• 在热启动时重新访谈。 创建这份材料正是为了避免重复提问。只询问本次会话的目标。
• 根据猜测的范围进行路由。 只能依据路由参考中声明的范围进行路由；看似合理的猜测也可能会让路由自信地出错。
• 跳过资金驱动因素问题。 没有这个问题，策略、指标和预算路由都会退化成泛泛的建议，用户还得手动重新界定范围。
• 访谈没有上限。 超过 7 个问题，启动访谈就会变成用户会放弃填写的表格。
• 平铺的候选清单。 8 个看起来同等的选项，会让用户凭喜好或仅凭排列顺序来选。应按单位投入所带来的价值排序，并在每一项中说明两者；否则用户无法选择。
• 优先列出最便宜的选项。 便宜和高效是不同的排序方式，只有后者才能回答“先做什么”。几乎零成本却几乎没有收益的常规做法只是舍入误差，不是快速见效的方案。
• 给路由表或链条排序。 范围是匹配测试，链条是依赖顺序；给其中任何一项套用比例都会凭空捏造偏好。
• 把排除的技能降级而不是删除。 访谈已经排除的类别若停放在候选清单底部，过两个会话又会重新出现。请删除它，或将其移至“暂不考虑”，并注明解除阻塞的条件。
• 让比例排序饿死基础工作。 第 6 类在每轮效率排序中都会落败，但它恰恰是正在筹建的项目最先需要的。开始从第 1 类入手前，请检查第 6 类的优先级提升条件。
• 没有输出渠道的常规任务。 它们会石沉大海，随后被静音，把真正重要的那项也埋没。
• 静默提交记忆。 队友看不到落地内容，就无法审核。务必先展示差异并获得批准。
• 路由表过时。 每当集合发生变化——新增、重命名、移除技能或调整技能范围——都要更新表格、路由参考、边界分支、链条和缺口列表。过时的路由器会把用户引向已不存在的技能，比没有路由器更糟。

10. 通过标准

结束会话前，请检查每一项。如果有任何一项不符合，请修复并重新检查；未通过标准时不要结束会话。

1. 每个推荐技能的声明范围都与所述任务相符——请重新阅读其描述以确认。
2. 路由到上述表格之外名称的情况为零。
3. 访谈未超过上限：冷启动最多 7 个问题；热启动只询问本次会话的目标。
4. 在会话结束前，已编写或更新 devrel-context.md，其中包含一条会话日志。
5. 每个提议的常规任务都已展示试运行，并且有明确的输出渠道。
6. 候选清单和常规任务集都按单位投入所带来的价值排序；每一项都注明其针对的瓶颈及所需成本。每当访谈回答使某项偏离默认位置时，都已明确说明重新排序。
7. 访谈排除的每个类别都已从候选清单中彻底移除，而不是留在清单底部。
8. 路由表和任何提议的链条都没有排序——前者是匹配测试，后者是依赖顺序。