DevRel 项目启动或续跑时用：把任务路由到…

适用于每次 DevRel 项目启动、周期性 check-in、或不清楚该用哪个 devrel 技能时，先检测环境、最多 7 问访谈，再输出单技能路由、短名单、链、暂缓与缺口，并写入或更新 devrel-context.md。

适用场景

解决思路

1. 在每次项目开始时运行此技能；在现有 DevRel 项目的每个新会话开始时重跑；即使集合技能已在别处日常使用也运行——新项目就是新上下文。后续会话重跑用于重新总结和重新路由，绝不重新访谈。
2. 在每次周期性 DevRel check-in、新 DevRel 项目、『我需要哪个 devrel 技能』、devrel/docs/开源技能路由、重复开发者计划审查时运行；即使用户只描述 DevRel 问题且从未问用哪个技能也运行。
3. 把自己当作 samber/developer-relations-skills 集合（55 个技能）的路由器：将当前 DevRel 任务路由到恰好一个同级技能，或明确说都不合适；绝不自己执行同级技能的职责。
4. 识别集合服务两种采用动因：个人开发者自助；组织购买（开发者是用户但他人签字）。在路由中携带答案——self-serve、organization-buys 或 both——不要压缩成一种。
5. 检测先于提问：从环境可推导的每个事实都不问用户。
6. 冷/暖启动只用一个信号：项目里是否存在 devrel-context.md。存在→暖启动，缺失→冷启动。绝不问用户是哪种模式。
7. 如果能读仓库 git history，从最近 log 推断阶段和节奏：发布频率、文档和代码是否一起移动、项目是否停滞。
8. 盘点已有内容：README、CONTRIBUTING、CODE_OF_CONDUCT、GOVERNANCE、LICENSE、CHANGELOG、docs/、.github/ templates、agent-instruction files、docs site config、past content plans，避免重复询问已写内容。把文件缺失本身当作路由信号：无 CONTRIBUTING 使 samber/developer-relations-skills@oss-contributor-onboarding 成为候选。
9. 如果 harness 暴露 connectors 或 integrations，检测哪些可用：代码托管、分析源、文档构建、社区平台导出、包注册表，并让它们影响路由和 routines。描述能力；不要假设特定产品。
10. 如果集合提供可读版本元数据，记录自上次会话的变化；如果没有（常见情况），静默降级。绝不阻塞、警告或询问版本。
11. 冷启动访谈至多 5-7 个问题，每条消息一个问题，尽可能多选。只把问题花在检测为空的地方；跳过文件清单或 git log 已回答的问题。
12. 访谈 Q1 问：今天的工作在哪个表面？选项 (a) 文档和开发者体验，(b) 开源项目，(c) 社区，(d) 活动和演讲，(e) 内容和媒体，(f) 项目策略或测量，(g) 公司级开发者业务策略。此分叉把集合分成块并引导后续路由，所以先问。
13. 访谈 Q2 问：本次 session 的目标是什么——是否与项目目标相同，其中哪些已决定、哪些仍开放？冷启动和暖启动都问；项目目标不能替代今天的目标；已决定项从 short-list 完全移除，而不是排最后。
14. 访谈 Q3 问：谁采用，谁付费？选项 (a) 个人开发者自助，(b) 组织，开发者评估但别人购买，(c) 两者，(d) 非商业开源项目无买方。
15. 访谈 Q4 问：哪个业务驱动资助此工作？选项 (a) 开发者采用，(b) 销售赋能，(c) 开发者赋能，(d) 产品输入，(e) 生态和伙伴关系，(f) 贡献者社区，(g) 雇主品牌。驱动决定工作属于哪个支柱以及被评判标准；声称全部七个的计划没有策略。
16. 访谈 Q5 问：项目处于什么阶段？选项 (a) 尚无正式，(b) 一个人兼职，(c) 专职个人或小团队，(d) 多人团队有自己预算。
17. 访谈 Q6 问：当前有什么硬约束——结果必须落地的日期？选项 (a) 无预算，(b) 只有 maintainer 小时，(c) 文档无工程支持，(d) 需要法律或安全审查，(e) 无分析访问，(f) 无。有日期就给日期：发布、会议、资金审查。
18. 访谈 Q7 问：想要一次性胜利还是复利资产——努力上限是多少，谁签字？选项 (a) 一次性，仅 maintainer 小时，(b) 一次性，一周工作可以，(c) 持续，每周几小时，(d) 持续，有工程时间和跨团队签字。命名签字人；该答案填入 artifact 的 Stakeholders 字段。
19. Q6 和 Q7 用于排序输出，不是描述项目；落地日期、一次性 vs 复利、努力上限重新排序 short-list（§4）和 routines（§7）。在访谈中问，不要在排名旁边问，因为用户已承诺路径。把三者记录在 artifact，使暖启动无需重问即可重新排序两个列表。
20. 暖启动只问 session-goal 问题。其他所有内容——包括驱动两个排序的日期、horizon、effort ceiling——都来自 artifact。
21. 路由任务：把陈述的 session goal 与每个技能的声明范围表匹配。为即时任务路由到恰好一个技能。不要强行匹配：无技能适合时，明说并命名 gap，不要拉伸最近技能。
22. 保持路由表不排序（块内和块间均不排序）。范围是匹配测试，不是比率：任务要么落在技能声明范围内，要么不落；排序行会发明从未竞争同一任务的技能之间的偏好。
23. 不要把 changelog-writing 当作优于 oss-governance；它们从不是同一 session 的候选。排名放在后一步 short-list（§4），多个技能真正竞争同一时间时使用。
24. 使用『Program strategy and measurement』表路由：devrel-strategy（顶层设计项目：情境分析、资助驱动、允许目标、支柱组合、build-vs-buy、人员顺序、拒绝清单）；devrel-team-structure（组织设计：汇报线、团队形态、覆盖图、接口、重组触发）；devrel-budget-allocation（按支柱拆预算、设回报阈值和削减清单）；devrel-metrics（哪些 KPI 值得设目标：分层框架、归因规则、基线、虚荣指标削减）；devrel-analytics（跟踪计划：事件分类、身份主线、UTM 纪律）；developer-journey-map（逐阶段映射旅程并定位值得修的唯一泄漏）；developer-segmentation（把开发者受众切成命名、有规模、排序的 segment 加 anti-segment）；developer-education-strategy（是否以及如何投资结构化教育：学院、课程、实验室、认证）；devrel-competitor-analysis（从公开信号基准竞品 devrel 动作，形成 close/ignore/counter 计划）；tech-employer-branding（吸引工程师来工作：工程 EVP、验证面审计、按资历匹配渠道下注、招聘测量基线）。
25. 使用『Developer business strategy (company level)』表路由：devtools-business-model（工具如何赚钱：九种模型原型及各自强制 GTM）；devtools-pricing-strategy（价值指标、免费层限制、层级阶梯、价格点、安全调价）；developer-first-gtm（从采用到收入的运动：自助进入、开发者到买家交接、land and expand）；open-source-company-strategy（公司开源什么、保留什么，逐资产、带动机）；developer-ecosystem-strategy（是否以及多开放产品为平台让他人构建）；open-standards-strategy（如何参与命名标准或协议：ignore、consume、certify、extend、contribute upstream、co-found a spec、drive your own，以及 venue、patent mode、kill rule）。
26. 使用『Documentation and developer experience』表路由：readme-optimization（单仓库 README：第一印象、bail-fast 漏斗、badge 清理）；developer-quickstart-guide（零到一验证成功：最小路径、copy-paste 命令、期望输出）；developer-tutorial（教学教程：每步一个概念、检查点、结尾可演示技能）；developer-docs-structure-audit（文档集信息架构：Diátaxis 分类、错位、覆盖缺口）；docs-code-sample-standards（示例政策与语料审计：可运行性、测试、语言对等、copy-paste 安全）；developer-troubleshooting-docs（从 ticket、issue 和 telemetry 构建错误参考和排障页）；changelog-writing（单次发布的 release notes，来自 commits 和 pull requests）；version-migration-guide（破坏性变更迁移指南：影响范围、检测信号、before/after、时间线）；coding-agent-docs-optimization（让文档机器可读，使 coding agent 可无人值守集成）。
27. 使用『Search demand for technical content』表路由：developer-keyword-research（开发者实际搜什么：错误字符串、任务查询、集成意图、需求规模）；docs-seo（文档站 on-page 和技术 SEO：索引、canonical、模板、内链）。
28. 使用『Open source』表路由：oss-launch（发布窗口：就绪门、定位、渠道顺序、run of show）；oss-distribution-strategy（发布后持续分发：注册表、精选列表、打包、发布节奏）；build-in-public（持续透明实践：披露阶梯、节奏、平台组合、边界）；oss-contributor-onboarding（陌生人到首次合并路径：CONTRIBUTING、good first issues、冷启动可运行安装）；oss-issue-triage（triage 系统：队列测量、标签、响应目标、intake 表单、陈旧政策）；oss-governance（决策权、maintainer 角色、投票、冲突升级、继任和 bus-factor 规划、商标和资产控制、基金会捐赠）；oss-license-strategy（许可证选择加 CLA/DCO、双许可、source-available 选项、relicense 风险）；github-profile-optimization（个人或组织在代码托管上的 profile：profile README、pins、贡献信号）；oss-sponsors-fundraising（维护者侧：搭建赞助计划、层级、奖励、发票路径）；oss-sponsors-brand-strategy（公司侧：资助哪些项目、多少钱、如何证明有效）。
29. 使用『Events and speaking』表路由：conference-cfp-submission（把一个演讲想法变成针对一个命名活动的提交）；tech-talk-outline（把已接受摘要变成可排练提纲和幻灯片骨架）；developer-live-demo-design（让 demo 扛住舞台：保真层级、检查点、fallback、runbook）；developer-meetup-program（运营重复 meetup 或用户组：形式、节奏、讲者、场地赞助、健康度）；developer-event-sponsorship（购买赞助：哪些活动、哪个层级、哪种激活、什么 ROI 证明）。
30. 使用『Community』表路由：developer-community-launch（是否、在哪里、何时开放社区，以及种子用户和前 90 天）；developer-community-moderation（行为准则、执行阶梯、举报渠道、事件 runbook、moderator 名册）；developer-champions（champions 或 ambassador 计划：入口、标准、义务、福利、条款、记分卡）；developer-community-health（测量社区：活动、响应度、贡献者漏斗、情绪、阈值）。
31. 使用『Content and media』表路由：engineering-blog-post（为怀疑的开发者读者写或编辑技术文章）；developer-case-study（把客户部署变成工程师相信的技术案例）；technical-video-script（可拍摄的 screencast 脚本：beat sheet、代码节奏、章节、剪辑清单）；tech-podcast-interview-prep（准备作为嘉宾上别人播客、访谈或直播）；devrel-content-calendar（围绕固定锚点、产能和组合规划一季度内容）；tech-press-relations（媒体和轻量分析师关系：角度、记者地图、pitch、embargo、press page）。
32. 使用『Meta and personal practice』表路由：devrel-radar（建立个人观察列表：播客、newsletter、社区、会议、人物）；devrel-career（候选人侧：portfolio 评分、技能差距路线图、面试准备、IC vs 管理）；devrel-hiring（雇主侧：职位发布和记分卡、面试循环、portfolio 评分、ramp 计划）；developer-relations-kickoff（本技能：项目启动、周期性 check-in、『我需要哪个技能』、重新路由）。
33. 在关键词冲突的集群中先消歧：Docs authoring（四个技能都像『写 getting-started 页面』）；Release communication（changelog vs migration guide）；Measurement（metrics vs analytics vs community health）；OSS visibility（launch vs distribution vs build-in-public）；Sponsorship（两个技能只差谁付钱）；Community（四个技能在同一时间线）；Strategy（五个技能都回答『我们该做什么』）；Speaking（是序列不是竞争）；Employer brand（吸引工程师的策略 vs 一篇帖子、一个 profile 页或候选人自己那一侧）。
34. 严格根据每个技能的声明范围消歧，绝不根据猜测技能大概覆盖什么；错误消歧比不消歧更糟。在任何可能匹配两个技能的任务前阅读 references/skill-routing.md；它包含每个技能的路由/禁止路由信号、每个边界分叉、有序链和命名覆盖缺口。
35. 当任务需要无技能覆盖的内容时，明确命名 gap。Collection v1 没有技能用于：面向任务的 how-to guides（区别于教程和快速开始）或 API reference 完整性；版本和弃用策略本身（相对于记录一次迁移）；招聘或面试 DevRel 员工——角色定义和面试循环，不是工程雇主品牌（由 tech-employer-branding 覆盖）——或面向高管的 DevRel 报告；为单个开源项目变现，或把 maintainer burnout 作为独立主题——继任和 bus-factor 规划属于 oss-governance，它还拥有商标、域名和注册表账号；仅第三方商标使用与执行策略未覆盖；组织自己的会议或 hackathon、会议展位运营、会后跟进；开发者 newsletter、学生和校园计划、office-hours 计划；选择文档平台、品牌提及监控；写幻灯片、编辑视频或任何法律签字。
36. 说『集合没有此技能』——绝不承诺存在技能或发明技能。
37. 有些落在这里的任务不是真正 gap——它们属于同一作者的同级集合：公共 API 表面设计、webhooks、SDK portfolios、developer-portal design、第三方应用 OAuth、connector-marketplace operations 属于 samber/developer-platform-skills；组织自己的活动——场地、票务、赞助销售、run of show、作为组织者寻找演讲者——属于 samber/dev-event-organizer-skills。推荐安装同级集合，而不是把 devrel 技能拉伸到任务上；绝不把同级集合当作此集合运行所需依赖。
38. 按固定输出形状交付路由结果：1. State summary（仅暖启动）——来自 artifact 正好 5 行：产品和受众动因、资助驱动和支柱组合、项目阶段和团队形态、进行中工作、活跃约束。2. Route——即时任务的一个技能、同级集合推荐并命名具体领域（见 §3），或『无技能适合』加命名 gap。3. Short-list——当前项目相关的 5 到 8 个技能，按单位努力回报价值从高到低排序。每条一行，命名两方面：它攻击的瓶颈，以及该 session 的成本。绝不按便宜排序，也绝不按路由表行序排序。4. Chain——当任务真正分解为有序序列时（例如 developer-segmentation → devrel-strategy → devrel-metrics → devrel-budget-allocation），按执行顺序列出，每条一行说明它交给下一个什么。链顺序是依赖顺序，不是效率顺序；后一链接消耗前一链接产出，不能先运行，所以给链排名没有意义。没有链就省略——绝不捏造序列。5. Not now——以后会重要的技能，每个带明确解除条件。6. Gap——今天任务需要但无技能覆盖的内容，作为 gap 陈述。
39. 短名单排序：用户当时的问题从不是『55 个中哪个存在』，而是『我先跑哪个，值不值一个 session』。只有比率能回答。默认类别顺序，单位努力价值最高优先：1. Diagnosis——developer-journey-map、developer-docs-structure-audit、devrel-competitor-analysis、developer-keyword-research。买来对哪个下层类别才是真正问题的命名且有证据的答案，而不是猜测。成本一个 session，基于已有文档和信号；无需工程时间且不发布。2. First-run surfaces——readme-optimization、developer-quickstart-guide、oss-contributor-onboarding、github-profile-optimization、docs-code-sample-standards。买来每个后续到达开发者的 bail-fast 漏斗：减少落地到首次成功调用之间的放弃。成本一个编辑 session 加一个合并 PR，可由另一次 commit 回滚。3. Release and support cadence——changelog-writing、version-migration-guide、developer-troubleshooting-docs、oss-issue-triage。买来能升级并自助错误而非开 issue 的用户。成本每次发布一遍加 maintainer 回答 triage 暴露的问题——永不结束；是常设工作，不是修复。4. Content and visibility——engineering-blog-post、developer-tutorial、technical-video-script、developer-case-study、docs-seo、devrel-content-calendar、build-in-public、oss-launch、oss-distribution-strategy、tech-press-relations、tech-podcast-interview-prep。买来复利触达——一篇帖子或注册表列表持续多年产生收益。成本每个 artifact 一个完整制作周期加审查，回报在季度后而非当周。5. Community and events——developer-community-launch、developer-community-moderation、developer-champions、developer-community-health、developer-meetup-program、developer-event-sponsorship、conference-cfp-submission、tech-talk-outline、developer-live-demo-design、oss-sponsors-fundraising、oss-sponsors-brand-strategy。买来集合中其他任何东西都不产生的关系。成本这里最长 lead time——他人控制的日历、常设 moderation 职责、开放空间到值得阅读之间数月。6. Program and company foundations——devrel-strategy、developer-segmentation、devrel-metrics、devrel-analytics、devrel-budget-allocation、devrel-team-structure、developer-education-strategy、devtools-business-model、devtools-pricing-strategy、developer-first-gtm、open-source-company-strategy、developer-ecosystem-strategy、open-standards-strategy、oss-governance、oss-license-strategy、tech-employer-branding。买来每个后续 session 决定的规则：项目按什么评判、谁可合并、公司放弃什么。成本 DevRel 外签字——工程、法律、exec——且多数只能通过另一次谈判回滚。
40. devrel-career 和 devrel-radar 在这个阶梯之外，不在底部。它们回答个人实践或保持最新问题，不是项目问题；当那确实是目标时它们按定义是第一级，否则完全不在 short-list。
41. 注意轴不同意，这是选择困难所在：efficiency: diagnosis > first-run surfaces > release cadence > content > community and events > foundations；value: foundations > first-run surfaces > community and events > content > release cadence > diagnosis；effort: foundations > community and events > content > release cadence > first-run surfaces > diagnosis；compliance cost: foundations > community and events > content > release cadence > first-run surfaces == diagnosis (none)。foundations 在价值领先、效率最后，因为签字以周计而产出落地当周不可见。
42. 这导致效率顺序饿死 class 6 基础技能。devrel-strategy 和 oss-license-strategy 是最清楚案例——协调成本最高、当周无可交付——所以比率优先顺序会永远打磨 README，而每个后续 session 重新争论项目目的和公司可放弃什么。
43. 当以下情况时将 class 6 直接提升到第 1 级：没人能说出资助驱动（Q4 空或声称全部七个）；已接受外部贡献的仓库没有 license 或 governance 文件；同一范围争论每个 session 重现；Q7 答案是 (d) 持续且有签字可用。
44. 默认：short-list 从 class 1 开始并留在那里直到诊断命名下面一个类别。每次向下移动恰好一个类别，绝不越过诊断标记缺失的类别。
45. 从 short-list 删除被排除类别；绝不降级到最后，因为被排除技能停在底部会悄悄重现为 scope。有明确解除条件→移到 Not now 列表并携带条件；没有→从输出完全删除。
46. 排序是默认不是法律——随采用动因和执行者变化。根据访谈和检测重新排序，并说出哪个答案移动了哪个类别：非商业开源无买方（Q3d）从 short-list 删除 devtools-pricing-strategy、devtools-business-model、developer-first-gtm，并在 class 6 和 5 内提升 oss-governance 和 oss-sponsors-fundraising；个人自助采用（Q3a）提升 class 2 和 4；组织购买（Q3b）把 developer-case-study 和 developer-first-gtm 提升到默认位置之上，因为签字者从不跑 quickstart；资助驱动（Q4）删除整个类别：销售赋能删除 class 3 的 triage 条目除非项目开源，贡献者社区直接删除 developer-first-gtm 和 devtools-pricing-strategy，雇主品牌把 tech-employer-branding 提升到第 1 级，因为它拥有该驱动整个计划并排名其下每个内容赌注；阶段『尚无正式』（Q5a）删除 devrel-team-structure、devrel-budget-allocation、developer-community-health——没有团队、预算和基线可测；文档无工程支持（Q6c）删除 class 2 的代码依赖条目，留下 readme-optimization，不需要工程时间；无分析访问（Q6e）从本 session 删除 devrel-analytics 和 developer-community-health，并移到 not now，由 instrumentation 解除；需要法律或安全审查（Q6d）延长 class 4、5、6 而不改变它们买什么——说出来而不是静默降级；固定日期（Q6）提升在那个窗口内行动的：会议日期把 conference-cfp-submission 和 developer-live-demo-design 提升到当季第 1 级，发布日期提升 class 3；『一次性，仅 maintainer 小时』（Q7a）把 short-list 削减为来自 class 1 和 2 的两个条目；『持续，有签字可用』（Q7d）把 class 5 和 6 提升到默认位置之上；已有资产改变比率而非价值：已 instrumented analytics stack、已部署 docs site、已接受会议 slot 使依赖技能接近零努力——提升它；已决定项（Q2）直接离开 short-list；不要排名已下桌的东西；检测也移动类别：无 CONTRIBUTING 文件在 class 2 内提升 oss-contributor-onboarding；git log 显示数月停滞在 build 前先诊断；已有 docs site 且信息架构已审计则删除其 class-1 条目。
47. 创建或更新项目根目录 devrel-context.md——一个版本化文件，项目在 git 中时随项目提交，是使下次启动变暖的唯一事实来源。其 sections：Product and audience；Program: funded driver, pillar mix, stage and team；Surfaces owned；Measurement；State: in flight, decided vs open, constraints including the date the result must land by, the one-off-versus-compounding horizon and the effort ceiling；Stakeholders with decision rights；A session log。
48. 后三个约束字段使暖启动无需重问 Q6 和 Q7 即可重新排序 short-list 和 routines。见 references/context-artifact.md 获取模板、工作示例和反例。
49. 暖启动：读取 artifact，不要重建。产生 5 行 state summary，追加 session-log 行，只修补变化字段。
50. 可选：把项目不变量（audience motion、funded driver、surfaces owned、hard constraints）补丁到项目的 agent-instruction 文件，使未来 session 无需加载此技能即可继承。
51. 不要搭建项目尚未赚来的工作树。只搭建本 session 所需——过早结构会硬编码项目尚未做出的决定。
52. 仅当项目实际积累有争议决定时才保留 decision log；否则 decided vs open 字段足够。空仪式日志会过期并侵蚀对 artifact 的信任。
53. 每次 session 结束前更新 artifact——未写的 session 是下次冷启动。
54. 如果 harness 有持久 memory，从 context artifact 派生 memory 条目——绝不反过来。artifact 是事实来源，因为 memory 对队友不可见且不可审查；memory-first 流程会按用户分叉项目状态。
55. 访谈完成后、§4 输出形状前，把访谈回复持久化到 memory：先把捕获答案写入 context artifact，再从 artifact 派生 memory 条目。绝不直接从答案写 memory，绝不因答案显而易见而跳过 artifact。
56. memory 只存三处之一：用户环境本地、团队知识库、git 仓库中的 memories/ 目录。用 index 文件索引，列出每个条目和一行 hook。
57. 暖启动时，将 memory 与 artifact 做 diff。分歧时提议对账——artifact 默认胜出；覆盖任一方前先询问。
58. 绝不放入 memory：社区成员或贡献者个人数据；行为报告和 moderation 案例；未宣布发布和禁运新闻；NDA 下的赞助和活动费率；未发布定价；尚未获准用于案例研究的客户名称；build-in-public 边界中的安全敏感细节。首次写 memory 时说明此排除。
59. 当 memory 位于 git 仓库时，绝不静默提交。每次先展示 diff 并获批准。
60. 如果 harness 支持 scheduled routines，提议 2 到 4 个——创建前始终 dry-run，每个有明确 output channel。没有 output channel 的 routine 是用户一周内会静音的噪音。
61. routine 成本不是设置而是每次触发注意力乘触发频率；价值是它在决策仍开放时推到某人面前的决策。按该比率排名候选——单位常设努力价值最高优先——并从顶部向下提议：1. Release-tag documentation pass → changelog-writing，加 version-migration-guide 当发布是 major。只在 tag 落地时触发，基于已写好的 commits 和 pull requests，是唯一输出能在发布前到达用户而不是用户撞到破坏后才到达的 routine。2. 每月或每季度重新调用此 kickoff。每次触发接近零，保持 artifact 和路由表最新——这阻止其他 routine 对不再存在的工作触发。从 git log 匹配 cadence 到项目节奏。3. CFP deadline sweep，在当季目标活动前 → conference-cfp-submission。每季少量触发，每次短读 deadline 列表，对抗绝对 deadline：错过则该舞台一年内消失。CFP 季节外买不到什么，所以不是第 1 级。4. 周期性 issue 和 pull-request 队列审查 → oss-issue-triage。买来队列保持可回答而不是复利成被遗弃项目。承担集合中最高常设成本：每次一遍 session 加 maintainer 回答它暴露的一切。只在有人拥有后续跟进行动的地方安装。5. 季度内容规划，在季度开始 → devrel-content-calendar。每年四次规划 session，买来一个季度内容针对真实锚点发布，而不是某人当周想到什么。6. 周期性 measurement read → devrel-metrics（项目）或 developer-community-health（仅社区）。买来某人可行动的 trend line——但只在 baseline 存在后；在此之前触发会按计划大声读出噪音。
62. routine 默认：第 1-2 级，即两个 routines。CFP 季节开放时加第 3 级；一旦有人拥有 triage 跟进行动加第 4 级。绝不超过 4——上限保护重要 routines 免受无效触发。排序是默认不是法律；随 surface 和执行者变化。根据访谈重新排序并说出哪个答案移动了哪个 routine：开源 surface（Q1b）把 queue review 提升到 CFP sweep 之上；活动 surface（Q1d）有会议日期时把 CFP sweep 提升到当季第 1 级；无分析访问（Q6e）删除 measurement read 而非降级；『尚无正式』（Q5a）也删除它，因为没有 baseline 可趋势；仅 maintainer 小时（Q6b）或『一次性，仅小时』（Q7a）意味着安装一个 routine——kickoff 重新调用——而不是四个；需要法律或安全审查（Q6d）延长 release-tag pass 而不改变它买什么；已运行每周 triage 轮值的团队使第 4 级重复，所以降级它而不是扫同一 issues 两次；已 instrumented analytics stack 或已在 tag 上构建的 docs pipeline 使依赖 routine 接近零努力——提升它。
63. 将 triggers 锚定到 DevRel 日历——发布列车日期、CFP deadline、会议日期、预算审查、社区仪式——而不是任意日期；存在事件触发时优先事件触发：tag push 胜过每月一号用于发布说明。添加新 routines 前列出并清理上一季度遗留的过时 routines。
64. 如果 harness 无 scheduled routines，回退到一个重复日历提醒（DevRel check-in - 重新运行 developer relations kickoff）并就此停止。见 references/routines.md 获取 dry-run 格式、日历锚定、事件触发偏好和清理清单。
65. 结束 session 前检查 pass bar 每项，失败则修复并重检，不要以失败 bar 关闭 session：1. 每个推荐技能的声明范围实际匹配陈述任务——重读描述确认。2. 零路由到上表 55 技能之外的名字。3. 访谈在 cap 内：冷启动最多 7 问，暖启动仅 session-goal 问。4. session 结束前已写入或更新 devrel-context.md，包括 session-log 行。5. 每个提议 routine 已 dry-run 且有明确 output channel。6. short-list 和 routine 集合都按单位努力价值排序，每条命名攻击的瓶颈和成本——且当访谈答案移动默认位置时，重新排序已大声说出。7. 访谈排除的每个类别完全离开 short-list，而不是停在底部。8. 路由表和任何提议链保持不排序——分别匹配测试和依赖顺序。
66. 避免失败模式：不要强行匹配；不要把所有文档问题路由到同一技能（Quickstart、tutorial、how-to、reference 是四个不同工作，且集合没有 how-to 技能，先查 § Docs-authoring fork）；不要强行适配平台或活动制作任务（API 设计、webhooks、SDK 策略、marketplace 运营属于 samber/developer-platform-skills；组织自己的会议属于 samber/dev-event-organizer-skills；推荐同级集合）；暖启动不要重新访谈；不要从猜测范围路由；不要跳过 funded-driver 问题；不要无上限访谈；不要扁平 short-list；不要以最便宜选项开头；不要给路由表或链排名；不要降级被排除技能；不要让比率饿死 foundations；不要没有 output channel 的 routines；不要静默提交 memory；集合变化时更新路由表、路由参考、边界分叉、链和 gap 列表——过期路由器比没有路由器更糟。

适用边界 · 注意事项

• 不适用于不使用 samber/developer-relations-skills 集合的通用开发任务；它依赖该 55 技能集合及其声明的技能名。
• 不应用于公共 API 表面设计、webhooks、SDK portfolios、developer-portal、第三方 OAuth、connector marketplace 等；这些属于 samber/developer-platform-skills。
• 不应用于自己组织会议、场地、票务、赞助销售、run of show、作为组织者寻找演讲者等；这些属于 samber/dev-event-organizer-skills。