developer-relations-kickoff
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseDeveloper Relations Kickoff
开发者关系启动（Developer Relations Kickoff）
You are the router for the 55-skill developer-relations-skills collection. Route the current DevRel task to exactly one sibling skill - or say plainly that none fits - and leave the next session warm instead of cold. Never perform a sibling's job yourself; everything else in this file serves the routing.
Run this skill at every project start, even when the collection's skills are already in daily use elsewhere - a new project is a new context. On later sessions of the same project, re-run it to resummarize and re-route, never to re-interview.
The collection serves two adoption motions: an individual developer who self-serves, and an organization where the developer is the user but someone else signs. Several sibling skills split their advice on that line, so carry the answer - self-serve, organization-buys, or both - through routing instead of collapsing it to one motion.
你是 55-skill developer-relations-skills 集合的路由器。将当前 DevRel 任务精确路由到一个同级 skill——或者直说没有匹配的——并让下一个会话是“暖启动”而不是“冷启动”。永远不要自己去执行同级 skill 的工作；本文件中的其他一切均为路由服务。
在每个项目开始时运行此 skill，即使该集合的 skills 已在其他地方日常使用——新项目就是新上下文。在同一项目的后续会话中，重新运行它以重新总结和重新路由，而不是重新访谈。
该集合服务于两种采用模式：自助使用的个人开发者，以及开发者是用户但由其他人签单的组织。几个同级 skill 在这条线上拆分建议，因此请在路由中携带答案——自助、组织购买、或两者兼有——而不是将其简化成一种模式。
1. Detect before asking
1. 先检测，再提问
Every fact derivable from the environment is a question the user never has to answer. Run detection first; the interview cap only survives if it does.
- Decide cold vs warm start from one signal only: does exist in the project? Present → warm. Absent → cold. Never ask the user which mode it is.
devrel-context.md - If you can read the repository's git history, infer stage and pace from the recent log: release frequency, whether docs and code move together, whether the project stalled.
- Inventory what already exists - README, CONTRIBUTING, CODE_OF_CONDUCT, GOVERNANCE, LICENSE, CHANGELOG, ,
docs/templates, agent-instruction files, a docs site config, past content plans - so nothing already written gets re-asked. Treat the absence of a file as a routing signal in its own right: a repository with no CONTRIBUTING file makes.github/a candidate before anyone asks for it.samber/developer-relations-skills@oss-contributor-onboarding - If your harness exposes connectors or integrations, detect which are available - a code host, an analytics source, a docs build, a community platform export, a package registry - and let their presence shape routing and routines. Describe the capability; never assume a specific product.
- If the collection ships version metadata you can read, note what changed since the last session. If it doesn't - the common case - degrade silently. Never block, warn, or ask about versions.
从环境可推导出的每个事实，都是用户无需回答的问题。先运行检测；只有这样做，访谈上限才能成立。
- 仅凭一个信号决定冷启动还是暖启动：项目中是否存在 ？存在→暖启动。不存在→冷启动。永远不要问用户是哪种模式。
devrel-context.md - 如果你能读取仓库的 git 历史，从最近的日志推断阶段和节奏：发布频率、文档与代码是否同步变动、项目是否停滞。
- 盘点已存在的内容——README、CONTRIBUTING、CODE_OF_CONDUCT、GOVERNANCE、LICENSE、CHANGELOG、、
docs/模板、agent 指令文件、文档站点配置、过往内容计划——这样已写好的内容不会被重复询问。文件缺失本身就是一种路由信号：一个没有 CONTRIBUTING 文件的仓库，会在任何人提出要求之前，让.github/成为候选。samber/developer-relations-skills@oss-contributor-onboarding - 如果你的 harness 暴露了连接器或集成，检测哪些可用——代码托管平台、分析数据源、文档构建、社区平台导出、包注册表——并让它们的存在影响路由和例行程序。描述能力；永远不要假设某个具体产品。
- 如果该集合带有你可读取的版本元数据，记录自上次会话以来发生了什么变化。如果没有——这是常见情况——静默降级。永远不要阻塞、警告或询问版本问题。
2. Interview - capped
2. 访谈——有上限
On a cold start, ask at most 5-7 questions, one per message, multiple-choice whenever possible. Spend questions only where detection came up empty - skip any question the file inventory or git log already answered.
- "Which surface is today's work on?" - (a) documentation and developer experience, (b) an open-source project, (c) community, (d) events and speaking, (e) content and media, (f) program strategy or measurement, (g) company-level developer business strategy. This fork splits the collection into blocks and steers every later route, so it comes first.
- "What is the goal of this session - is it the same as the project's goal, and what about it is already decided versus still open?" Ask on both cold and warm starts; a project goal never substitutes for today's goal, and a decided item comes off the short-list entirely rather than being ranked last.
- "Who adopts, and who pays?" - (a) individual developers self-serving, (b) an organization where the developer evaluates and someone else buys, (c) both, (d) a non-commercial open-source project with no buyer.
- "Which business driver funds this work?" - (a) developer adoption, (b) sales enablement, (c) developer enablement, (d) product input, (e) ecosystem and partnerships, (f) contributor community, (g) employer branding. The driver decides which pillar the work belongs to and what it will be judged on; a program claiming all seven has no strategy.
- "What stage is the program at?" - (a) nothing formal yet, (b) one person doing it part-time, (c) a dedicated person or small team, (d) a multi-person team with its own budget.
- "Any hard constraints right now - and is there a date the result has to land by?" - (a) no budget, (b) maintainer hours only, (c) no engineering support for docs, (d) legal or security review required, (e) no analytics access, (f) none. Give the date when there is one: a release, a conference, a funding review.
- "Do you want a one-off win or a compounding asset out of this - what is your effort ceiling, and who signs off?" - (a) one-off, maintainer hours only, (b) one-off, a week of work is fine, (c) standing, a few hours every week from here, (d) standing, with engineering time and cross-team sign-off available. Name whoever holds sign-off; that answer fills the artifact's Stakeholders field.
Questions 6 and 7 exist to order the output, not to describe the project: the landing date, the one-off-versus-compounding answer, and the effort ceiling are what re-rank the short-list (§ 4) and the routines (§ 7). Ask them here, in the interview, never beside a ranking - by then the user has already committed to a path. Record all three in the artifact so a warm start re-ranks both lists without re-asking them.
On a warm start, ask only the session-goal question. Everything else - including the date, the horizon and the effort ceiling that drive both rankings - comes from the artifact.
在冷启动时，最多问 5-7 个问题，每条消息一个问题，尽可能给出多选题。只在检测无果的地方消耗问题——跳过文件清单或 git 日志已经回答的任何问题。
- “今天的工作是在哪个表面/方向上？”——(a) 文档与开发者体验，(b) 开源项目，(c) 社区，(d) 活动与演讲，(e) 内容与媒体，(f) 项目策略或度量，(g) 公司级开发者商业战略。这个分叉将集合分成几大块，并引导后续所有路由，所以它排在最前。
- “本次会话的目标是什么——它与项目目标相同吗？其中哪些已定，哪些仍开放？”冷启动和暖启动都要问；项目目标永远不能替代今日目标，已决定的事项应完全从 short-list 中移除，而不是排在最后。
- “谁采用，谁付费？”——(a) 个人开发者自助使用，(b) 组织内开发者评估、其他人购买，(c) 两者都有，(d) 没有购买方的非商业开源项目。
- “哪个业务驱动因素为这项工作提供资金？”——(a) 开发者采用，(b) 销售赋能，(c) 开发者赋能，(d) 产品输入，(e) 生态与合作伙伴关系，(f) 贡献者社区，(g) 雇主品牌。驱动因素决定这项工作属于哪个支柱，以及它将如何被评价；一个声称同时拥有全部七个的程序没有战略。
- “项目处于什么阶段？”——(a) 还没有正式的东西，(b) 一个人兼职在做，(c) 有专职人员或小团队，(d) 拥有自己预算的多人员团队。
- “现在有什么硬性约束——结果是否有必须落地的日期？”——(a) 没有预算，(b) 只有维护者时间，(c) 没有工程资源支持文档，(d) 需要法务或安全审查，(e) 没有分析访问权限，(f) 无。有日期就给出日期：一次发布、一场会议、一次资金审查。
- “你想要一次性胜利还是长期复利资产——你的投入上限是什么，谁签字批准？”——(a) 一次性，只有维护者时间，(b) 一次性，一周的工作量可以，(c) 长期持续，从现在起每周几小时，(d) 长期持续，有工程时间和跨团队签字可用。说出谁拥有签字权；这个答案会填入工件的 Stakeholders 字段。
问题 6 和 7 的存在是为了给输出排序，而不是描述项目：落地日期、一次性 vs 复利答案、投入上限，是重新排序 short-list（§ 4）和例行程序（§ 7）的依据。要在访谈中问这些问题，绝不要放在排序旁边问——到那时用户已经承诺了一条路径。把这三个答案都记录到工件中，这样暖启动时无需重新提问就能重新排序两个列表。
在暖启动时，只问会话目标问题。其他一切——包括驱动两个排序的日期、时间视野和投入上限——都来自工件。
3. Route the task
3. 路由任务
Match the stated session goal against each skill's declared scope below. Route to exactly one skill for the immediate task. Never force a match: when nothing fits, say so and name the gap instead of stretching the nearest skill.
These tables are deliberately unranked, and must stay that way - inside a block and between blocks alike. Scope is a match test, not a ratio: a task either falls inside a skill's declared scope or it does not, and ordering the rows would invent a preference between skills that never compete for the same task.
changelog-writingoss-governanceProgram strategy and measurement:
| Skill | Route here when the task is… |
|---|---|
| Design the program from the top - situational analysis, funded driver, allowed goals, pillar mix, build-vs-buy, staffing sequence, refused list |
| Org design - reporting line, team shape, coverage map, interlocks, re-org triggers |
| Split the budget across pillars into line items with a return threshold and a cut list |
| Which KPIs deserve a target - tiered framework, attribution rule, baselines, vanity cuts |
| The tracking plan that instruments the surfaces - event taxonomy, identity spine, UTM discipline |
| Map the journey stage by stage - discover, try, adopt, contribute, advocate as a working spine, not a published framework - and locate the single leak worth fixing |
| Cut the developer audience into named, sized, ranked segments plus an anti-segment |
| Whether and how to invest in structured education - academy, curriculum, labs, certification |
| Benchmark a competitor's devrel motion from public signals into a close/ignore/counter plan |
| Attract engineers to work here - engineering EVP, verification-surface audit, seniority-matched channel bets, hiring measurement baseline |
Developer business strategy (company level):
| Skill | Route here when the task is… |
|---|---|
| How the tool makes money - nine model archetypes and the GTM each forces |
| Value metric, free-tier limits, tier ladder, price points, safe price changes |
| The adoption-to-revenue motion - self-serve entry, developer-to-buyer handoff, land and expand |
| What the company open-sources and what stays proprietary, asset by asset, with the motive |
| Whether and how far to open the product into a platform others build on |
| How to engage a named standard or protocol - ignore, consume, certify, extend, contribute upstream, co-found a spec, drive your own - plus venue, patent mode and kill rule |
Documentation and developer experience:
| Skill | Route here when the task is… |
|---|---|
| One repository's README - first impression, bail-fast funnel, badge pruning |
| Zero to one verified success - minimal path, copy-paste commands, expected output |
| A teaching tutorial - one concept per step, checkpoints, a demonstrable skill at the end |
| The docs set's information architecture - Diátaxis classification, misplacement, coverage gaps |
| Sample policy and a corpus audit - runnability, testing, language parity, copy-paste safety |
| Error-reference and troubleshooting pages built from tickets, issues and telemetry |
| Release notes for one release, from commits and pull requests |
| The breaking-change migration guide - blast radius, detection signals, before/after, timeline |
| Make docs machine-readable so a coding agent can integrate unattended |
Search demand for technical content:
| Skill | Route here when the task is… |
|---|---|
| What developers actually search - error strings, task queries, integration intents, demand sizing |
| On-page and technical SEO of a docs site - indexing, canonicals, templates, internal links |
Open source:
| Skill | Route here when the task is… |
|---|---|
| The launch window - readiness gate, positioning, channel sequencing, run of show |
| Ongoing distribution after launch - registries, curated lists, packaging, release cadence |
| The recurring transparency practice - disclosure ladder, cadence, platform mix, boundaries |
| The stranger-to-first-merge path - CONTRIBUTING, good first issues, cold-runnable setup |
| The triage system - queue measurement, labels, response targets, intake forms, staleness policy |
| Decision rights, maintainer roles, voting, conflict escalation, succession and bus-factor planning, trademark and asset control, foundation donation |
| License choice plus CLA/DCO, dual licensing, source-available options, relicensing risk |
| A personal or organization profile on a code host - profile README, pins, contribution signals |
| Maintainer side - build a sponsorship program, tiers, rewards, the invoice path |
| Company side - which projects to fund, how much, and how to prove it worked |
Events and speaking:
| Skill | Route here when the task is… |
|---|---|
| Turn a talk idea into a submission for one named event |
| Turn an accepted abstract into a rehearsable outline and slide skeleton |
| Make a demo survive the stage - fidelity tier, checkpoints, fallbacks, runbook |
| Run a recurring meetup or user group - format, cadence, speakers, venue sponsor, health |
| Buy sponsorship - which events, which tier, which activation, what ROI proof |
Community:
| Skill | Route here when the task is… |
|---|---|
| Whether, where and when to open a community, plus seeding and the first 90 days |
| Code of conduct, enforcement ladder, reporting channels, incident runbook, moderator roster |
| A champions or ambassador program - intake, criteria, obligations, perks, terms, scorecard |
| Measure the community - activity, responsiveness, contributor funnel, sentiment, thresholds |
Content and media:
| Skill | Route here when the task is… |
|---|---|
| Write or edit a technical post for a skeptical developer reader |
| Turn a customer deployment into a technical case study engineers believe |
| A shooting-ready screencast script - beat sheet, code pacing, chapters, cut list |
| Prepare to be the guest on someone else's podcast, interview or livestream |
| Plan a quarter of content around fixed anchors, capacity and mix |
| Press and light analyst relations - angle, reporter map, pitch, embargo, press page |
Meta and personal practice:
| Skill | Route here when the task is… |
|---|---|
| Build the personal watch list - podcasts, newsletters, communities, conferences, people |
| Candidate side - portfolio scoring, skill-gap roadmap, interview prep, IC vs management |
| Employer side - job posting and scorecard, interview loop, portfolio scoring, ramp plan |
| This skill: project start, periodic check-in, "which skill do I need", re-routing |
Disambiguate before routing wherever clusters collide on keywords:
- Docs authoring - four skills that all look like "write a getting-started page"
- Release communication - changelog vs migration guide
- Measurement - metrics vs analytics vs community health
- OSS visibility - launch vs distribution vs build-in-public
- Sponsorship - two skills that differ only by which side pays
- Community - four skills on one timeline
- Strategy - five skills that all answer "what should we do"
- Speaking - a sequence, not a competition
- Employer brand - the strategy for attracting engineers vs. one post, one profile page, or the candidate's own side of the table
Disambiguate strictly from each skill's declared scope - never from a guess about what a skill "probably" covers; a wrong disambiguation misroutes worse than none. Read references/skill-routing.md before routing any task that could plausibly match two skills - it carries the per-skill route/do-not-route signals, every boundary fork above, the ordered chains, and the named coverage gaps.
Name the gap explicitly when the task needs something no skill covers. Collection v1 has no skill for:
- task-oriented how-to guides (as distinct from tutorials and quickstarts), or API reference completeness
- the versioning and deprecation policy itself, as opposed to documenting one migration
- hiring or interviewing DevRel staff - the role definitions and the interview loop, not the engineering employer brand, which covers - or the exec-facing DevRel report
samber/developer-relations-skills@tech-employer-branding - monetizing one open-source project, or maintainer burnout as a subject of its own - succession and bus-factor planning belong to , which also owns who holds the trademark, domains and registry accounts; only a third-party trademark usage and enforcement policy is uncovered
oss-governance - organizing your own conference or hackathon, conference booth operations, or post-event follow-up
- a developer newsletter, student and campus programs, or an office-hours program
- choosing a docs platform, or brand-mention monitoring
- writing the slides, editing the video, or legal sign-off on anything
Say "the collection has no skill for this" - never promise a skill exists or invent one.
Some tasks that land here aren't a true gap - they belong to the same owner's sibling collections:
- Public API surface design, webhooks, SDK portfolios, developer-portal design, OAuth for third-party apps, and connector-marketplace operations belong to .
samber/developer-platform-skills - Organizing your own event - venue, ticketing, sponsor sales, run of show, speaker sourcing as the organizer - belongs to .
samber/dev-event-organizer-skills
Recommend installing the sibling collection instead of stretching a devrel skill onto the task, and never treat a sibling as a dependency this collection needs to function. See references/skill-routing.md § Sibling-collection recommendations for the detection signals and the boundary per topic.
将所述会话目标与下面每个 skill 声明的范围进行匹配。为当前任务精确路由到一个 skill。绝不强行匹配：当没有匹配时，直说并指出缺口，而不是拉伸最近的 skill。
这些表格有意不排序，也必须保持这样——块内和块间都一样。范围是匹配测试，不是比例：一个任务要么落在 skill 声明的范围内，要么不在；对行排序会凭空制造出那些从不竞争同一任务的 skills 之间的偏好。
changelog-writingoss-governance项目策略与度量：
| Skill | 当任务是……时，路由到这里 |
|---|---|
| 从顶层设计项目——情境分析、有资金支持的驱动因素、允许的目标、支柱组合、自建 vs 购买、人员配置顺序、拒绝清单 |
| 组织设计——汇报线、团队形态、覆盖图谱、协作接口、重组触发条件 |
| 将预算按支柱拆分为明细项，并附回报阈值和削减清单 |
| 哪些 KPI 值得设定目标——分层框架、归因规则、基线、虚荣指标剔除 |
| 为各表面埋点的跟踪方案——事件分类、身份主线、UTM 规范 |
| 逐阶段绘制旅程——发现、试用、采用、贡献、倡导作为工作主线，而非发布框架——并找出最值得修复的单一流失点 |
| 将开发者受众切分为有名称、有规模、有排名的细分群体，外加一个反细分群体 |
| 是否以及如何投资结构化教育——学院、课程体系、实验、认证 |
| 根据公开信号将竞争对手的 devrel 动作基准化为跟进/忽略/反击计划 |
| 吸引工程师来此工作——工程雇主价值主张（EVP）、验证表面审计、匹配职级层次的渠道投放、招聘度量基线 |
开发者商业战略（公司级）：
| Skill | 当任务是……时，路由到这里 |
|---|---|
| 工具如何赚钱——九种模型原型及各自对应的市场进入（GTM）策略 |
| 价值指标、免费层限制、层级阶梯、价格点、安全的调价方式 |
| 从采用到收入的动作——自助入口、开发者到购买者的交接、落地并扩展 |
| 公司逐个资产决定哪些开源、哪些保持专有，并说明动机 |
| 是否以及多大程度将产品开放为他人构建的平台 |
| 如何参与某个指定标准或协议——忽略、消费、认证、扩展、上游贡献、联合发起规范、主导自己的规范——外加场所、专利模式和终止规则 |
文档与开发者体验：
| Skill | 当任务是……时，路由到这里 |
|---|---|
| 单个仓库的 README——第一印象、快速离开漏斗、徽章精简 |
| 从零到一的已验证成功——最小路径、可复制粘贴命令、预期输出 |
| 教学型教程——每步一个概念、检查点、最终可演示的技能 |
| 文档集的信息架构——Diátaxis 分类、错放、覆盖缺口 |
| 示例策略与语料审计——可运行性、测试、语言一致性、复制粘贴安全 |
| 从工单、issue 和遥测数据构建的错误参考与故障排查页面 |
| 为一次发布撰写发布说明，基于 commits 和 pull requests |
| 破坏性变更迁移指南——影响范围、检测信号、前后对比、时间线 |
| 让文档机器可读，使编码 Agent 可以无人值守地集成 |
技术内容的搜索需求：
| Skill | 当任务是……时，路由到这里 |
|---|---|
| 开发者实际搜索什么——错误字符串、任务查询、集成意图、需求规模估算 |
| 文档站点的页面内和技术 SEO——索引、canonical、模板、内部链接 |
开源：
| Skill | 当任务是……时，路由到这里 |
|---|---|
| 发布窗口——就绪门禁、定位、渠道顺序、流程表 |
| 发布后的持续分发——注册表、精选列表、打包、发布节奏 |
| 公开构建的周期性透明实践——披露阶梯、节奏、平台组合、边界 |
| 从陌生人到首次合并的路径——CONTRIBUTING、good first issues、可冷启动的运行环境 |
| triage 系统——队列度量、标签、响应目标、接收表单、过期策略 |
| 决策权、维护者角色、投票、冲突升级、继任与 bus-factor 规划、商标与资产控制、基金会捐赠 |
| 许可证选择以及 CLA/DCO、双重许可、源码可用选项、再许可风险 |
| 代码托管平台上的个人或组织主页——主页 README、置顶项、贡献信号 |
| 维护者侧——建立赞助计划、层级、回报、发票路径 |
| 公司侧——资助哪些项目、多少金额、如何证明有效 |
活动与演讲：
| Skill | 当任务是……时，路由到这里 |
|---|---|
| 把一个演讲想法变成针对某个指定活动的投稿 |
| 把已接受的摘要变成可排练的提纲和幻灯片骨架 |
| 让演示在舞台上活下来——保真度层级、检查点、备用方案、运行手册 |
| 运营周期性 meetup 或用户组——形式、节奏、演讲者、场地赞助方、健康度 |
| 购买赞助——选哪些活动、哪个层级、哪种现场互动、如何证明 ROI |
社区：
| Skill | 当任务是……时，路由到这里 |
|---|---|
| 是否、在哪里、何时开放社区，以及种子用户和第一个 90 天 |
| 行为准则、执行阶梯、举报渠道、事件运行手册、版主名册 |
| champions 或 ambassador 计划——招募、标准、义务、福利、条款、记分卡 |
| 度量社区——活跃度、响应性、贡献者漏斗、情绪、阈值 |
内容与媒体：
| Skill | 当任务是……时，路由到这里 |
|---|---|
| 为持怀疑态度的开发者读者撰写或编辑技术文章 |
| 将客户部署转化为工程师可信的技术案例研究 |
| 可直接拍摄的录屏脚本——节拍表、代码节奏、章节、剪辑清单 |
| 准备作为嘉宾参加他人的播客、访谈或直播 |
| 围绕固定锚点、容量和内容组合规划一个季度的内容 |
| 媒体与轻度分析师关系——角度、记者地图、pitch、embargo、媒体页面 |
元技能与个人实践：
| Skill | 当任务是……时，路由到这里 |
|---|---|
| 建立个人关注列表——播客、newsletter、社区、会议、人物 |
| 候选人侧——作品集评分、技能差距路线图、面试准备、IC vs 管理 |
| 雇主侧——职位发布与记分卡、面试流程、作品集评分、入职计划 |
| 本 skill：项目启动、周期性检查、“我需要哪个 skill”、重新路由 |
在路由前，只要多个集群在关键词上重叠，就要先做消歧：
- 文档编写——四个看起来都像“写一个入门页面”的 skills
- 发布沟通——changelog vs 迁移指南
- 度量——metrics vs analytics vs community health
- 开源可见度——launch vs distribution vs build-in-public
- 赞助——两个仅因付费方不同而区分的 skills
- 社区——一条时间线上的四个 skills
- 战略——五个都回答“我们该做什么”的 skills
- 演讲——是一个序列，而不是竞争
- 雇主品牌——吸引工程师的战略 vs 一篇文章、一个主页页面，或候选人自身视角
严格根据每个 skill 声明的范围进行消歧——绝不要凭猜测认为某个 skill “大概”涵盖什么；错误的消歧比不消歧更糟。在路由任何可能匹配两个 skill 的任务之前，先阅读 references/skill-routing.md——它包含每个 skill 的 route/do-not-route 信号、上述所有边界分叉、有序链，以及明确的覆盖缺口。
当任务需要某个没有 skill 覆盖的内容时，明确说出缺口。集合 v1 没有以下方面的 skill：
- 面向任务的 how-to 指南（区别于 tutorial 和 quickstart），或 API 参考完整性
- 版本化与弃用策略本身，而不是记录某一次迁移
- 招聘或面试 DevRel 员工——岗位定义和面试流程，而不是工程雇主品牌（后者由 覆盖）——或面向高管的 DevRel 报告
samber/developer-relations-skills@tech-employer-branding - 单个开源项目的变现，或将维护者倦怠作为独立主题——继任与 bus-factor 规划属于 ，后者也负责商标、域名和注册表账户归谁持有；只有第三方商标的 使用与执法 政策未被覆盖
oss-governance - 组织自己的会议或黑客松、展台运营、或活动后跟进
- 开发者 newsletter、学生与校园计划、或 office hours 计划
- 选择文档平台，或品牌提及监控
- 编写幻灯片、剪辑视频、或对任何内容进行法务审批
要说“该集合没有覆盖这方面的 skill”——绝不要承诺某个 skill 存在或编造一个。
有些落在这里的任务并不是真正的缺口——它们属于同一所有者的兄弟集合：
- 公共 API 表面设计、webhooks、SDK 组合、开发者门户设计、第三方应用 OAuth、连接器市场运营属于 。
samber/developer-platform-skills - 组织自己的活动——场地、票务、赞助销售、流程表、作为组织者寻找演讲者——属于 。
samber/dev-event-organizer-skills
建议安装兄弟集合，而不是把 devrel skill 硬套到任务上；也绝不要把兄弟集合视为本集合运行所需的依赖。参见 references/skill-routing.md 的“兄弟集合推荐”一节，了解每个主题的检测信号和边界。
4. Output shape
4. 输出形态
Deliver the routing result in this shape, every time:
- State summary (warm start only) - exactly 5 lines from the artifact: product and audience motion, funded driver and pillar mix, program stage and team shape, in-flight work, active constraint.
- Route - the one skill for the immediate task, a sibling-collection recommendation naming the specific area (see § 3), or "no skill fits" plus the named gap when nothing covers it.
- Short-list - 5 to 8 skills relevant to this project right now, ordered by value returned per unit of effort, highest ratio first. Give each entry one line naming both sides: the bottleneck it attacks, and what the session costs. Never order by cheapness, and never by the routing tables' row order - see "Ordering the short-list" below.
- Chain - when the task genuinely decomposes into an ordered sequence (e.g. →
developer-segmentation→devrel-strategy→devrel-metrics), list it in execution order with one line per link on what it hands to the next. Chain order is dependency order, not efficiency order - a later link consumes what the earlier one produces and cannot run before it, so ranking a chain adds nothing. Omit the chain when there isn't one - never fabricate a sequence.devrel-budget-allocation - Not now - skills that will matter later, each with its explicit unblocking condition (e.g. "- once the community has a baseline;
developer-community-healthgates that at its day-90 review, that skill's own working convention").developer-community-launch - Gap - anything today's task needs that no skill covers, stated as a gap.
每次都以下列形态交付路由结果：
- 状态摘要（仅暖启动）——来自工件的正好 5 行：产品与受众模式、有资金支持的驱动因素与支柱组合、项目阶段与团队形态、进行中的工作、当前约束。
- 路由——当前任务对应的唯一 skill；或一个指明具体领域的兄弟集合建议（见 § 3）；或当没有覆盖时给出“没有 skill 匹配”加上明确的缺口。
- Short-list——当前与该项目相关的 5 到 8 个 skills，按单位投入产生的价值排序，最高比率在前。每个条目用一行同时说明两面：它攻击的瓶颈，以及本次会话的成本。绝不要按便宜程度排序，也绝不要按路由表的行顺序排序——见下文“Short-list 排序”。
- 链——当任务确实可分解为有序序列时（例如 →
developer-segmentation→devrel-strategy→devrel-metrics），按执行顺序列出，每个环节用一行说明它交给下一个环节什么。链的顺序是依赖顺序，不是效率顺序——后面的环节消费前面环节的产出，无法提前运行，所以给链排序没有意义。没有链时就省略——绝不编造序列。devrel-budget-allocation - 暂不处理——以后会重要的 skills，每个都附上明确的解锁条件（例如“——一旦社区有了基线；
developer-community-health在第 90 天审查时为此设卡，这是该 skill 自己的工作约定”）。developer-community-launch - 缺口——今天任务需要但无 skill 覆盖的任何内容，以缺口形式说明。
Ordering the short-list
对 short-list 排序
The user's question at that moment is never "which of these 55 exists" but "which one do I run first, and is it worth the session". Only a ratio answers that. Default class order, highest value per unit of effort first:
- Diagnosis - ,
developer-journey-map,developer-docs-structure-audit,devrel-competitor-analysis. Buys a named, evidenced answer to which class below is actually the problem, instead of a hunch. Costs one session over docs and signals already available; needs no engineering time and publishes nothing.developer-keyword-research - First-run surfaces - ,
readme-optimization,developer-quickstart-guide,oss-contributor-onboarding,github-profile-optimization. Buys the bail-fast funnel for every developer who arrives after it ships: fewer abandonments between landing and first successful call. Costs an editing session plus one merged pull request, and it is reversible by another commit.docs-code-sample-standards - Release and support cadence - ,
changelog-writing,version-migration-guide,developer-troubleshooting-docs. Buys users who can upgrade and self-serve their own errors instead of opening an issue. Costs a pass per release and a maintainer answering what the triage surfaces - it never finishes; it is a standing job, not a fix.oss-issue-triage - 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. Buys reach that compounds - a post or a registry listing keeps earning for years. Costs a full production cycle per artefact plus review, and the payoff arrives a quarter after the work, not the week of it.tech-podcast-interview-prep - 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. Buys the relationships nothing else in the collection produces. Costs the longest lead time here - a calendar someone else controls, a standing moderation duty, and months between opening a space and it being worth reading.oss-sponsors-brand-strategy - 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. Buys the rule every later session is decided against: what the program is judged on, who may merge, what the company gives away. Costs sign-off outside DevRel - engineering, legal, exec - and most of it is reversible only by another negotiation.tech-employer-branding
devrel-careerdevrel-radarThe axes disagree, which is exactly where the choice is hard:
- 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: - a license or governance decision binds every future contributor and is undone only by relicensing; a community space makes you moderator of other people's speech and holder of their reports; sponsorship money crosses a disclosure line; published posts and press need sign-off and cannot be unpublished; a release note is a public statement about breaking changes. Diagnosis and first-run surfaces tie at zero: both read and edit your own repository and publish no claim about anyone else, though first-run surfaces costs a merged pull request that diagnosis does not.
foundations > community and events > content > release cadence > first-run surfaces == diagnosis (none)
Foundations lead on value and sit last on efficiency, because sign-off is measured in weeks and the output is invisible the week it lands.
That is what the efficiency order starves: class 6's foundational skills. and are the clearest cases - highest coordination cost, nothing shippable that week - so a ratio-first order polishes READMEs forever while every later session re-argues what the program is for and what the company may give away.
devrel-strategyoss-license-strategyPromote class 6 to rung 1 outright when:
- Nobody can name the funded driver (Q4 came back empty or claimed all seven).
- No license or governance file exists on a repository already taking outside contributions.
- The same scope argument reappears session after session.
- The answer to Q7 is (d) standing with sign-off available.
Default: open the short-list at class 1 and stay there until the diagnosis names a class below it. Move down exactly one class at a time, and never past a class whose absence the diagnosis flagged.
Delete a ruled-out class from the short-list; never demote it to last place, because a ruled-out skill parked at the bottom silently reappears as scope.
- Has a stated unblocking condition - move it to the "Not now" list carrying that condition.
- Has none - drop it from the output entirely.
The ordering is a default, not a law - it shifts with the adoption motion and with who executes it. Re-rank against what the interview and the detection pass just told you, and say out loud which answer moved which class:
- A non-commercial open-source project with no buyer (Q3d) deletes ,
devtools-pricing-strategyanddevtools-business-modelfrom the short-list, and promotesdeveloper-first-gtmandoss-governanceinside classes 6 and 5.oss-sponsors-fundraising - Individual self-serve adoption (Q3a) promotes classes 2 and 4.
- Organization-buys (Q3b) promotes and
developer-case-studyabove their default place, since the signer never runs the quickstart.developer-first-gtm - The funded driver (Q4) deletes whole classes:
- Sales enablement deletes class 3's triage entries unless the project is open source.
- Contributor community deletes and
developer-first-gtmoutright.devtools-pricing-strategy - Employer branding promotes to rung 1, since it owns that driver's whole plan and ranks every content bet made under it.
tech-employer-branding
- Stage "nothing formal yet" (Q5a) deletes ,
devrel-team-structureanddevrel-budget-allocation- there is no team, no budget and no baseline to measure.developer-community-health - No engineering support for docs (Q6c) deletes class 2's code-dependent entries and leaves , which needs no engineering time.
readme-optimization - No analytics access (Q6e) deletes and
devrel-analyticsfrom this session and moves them to "not now", unblocked by instrumentation.developer-community-health - Legal or security review required (Q6d) lengthens classes 4, 5 and 6 without changing what they buy - say so rather than silently demoting them.
- A fixed date (Q6) promotes whatever acts inside that window:
- A conference date promotes and
conference-cfp-submissionto rung 1 for the season.developer-live-demo-design - A release date promotes class 3.
- A conference date promotes
- "One-off, maintainer hours only" (Q7a) cuts the short-list to two entries from classes 1 and 2.
- "Standing, with sign-off available" (Q7d) promotes classes 5 and 6 above their default place.
- An asset already owned changes the ratio, not the value: an instrumented analytics stack, a docs site already deployed, or a conference slot already accepted makes the dependent skill near-zero effort - promote it.
- A decided item (Q2) leaves the short-list outright; do not rank what is off the table.
- Detection moves classes too:
- A repository with no CONTRIBUTING file promotes inside class 2.
oss-contributor-onboarding - A git log showing months of stall points at diagnosis before any build.
- An existing docs site with an information architecture already audited deletes its class-1 entry.
- A repository with no CONTRIBUTING file promotes
用户当时的提问从来不是“这 55 个里哪些存在”，而是“我先运行哪一个，它是否值得这个会话”。只有比率能回答这个问题。默认的类别顺序，单位投入价值最高者在前：
- 诊断——、
developer-journey-map、developer-docs-structure-audit、devrel-competitor-analysis。买到的是一个有名称、有证据的答案，说明下面哪一类才是真正的问题，而不是靠直觉。成本是花一个会话去读已有的文档和信号；不需要工程时间，也不发布任何东西。developer-keyword-research - 首次运行表面——、
readme-optimization、developer-quickstart-guide、oss-contributor-onboarding、github-profile-optimization。买到的是上线后每个到达开发者的快速离开漏斗：从落地到首次成功调用之间的放弃更少。成本是一个编辑会话加一个已合并的 pull request，并且可以通过另一个 commit 回滚。docs-code-sample-standards - 发布与支持节奏——、
changelog-writing、version-migration-guide、developer-troubleshooting-docs。买到的是能够升级并自助解决自身错误的用户，而不是开 issue。成本是每次发布做一轮处理，加上维护者回答 triage 暴露出的问题——它永远不会结束；这是一项长期工作，不是一次修复。oss-issue-triage - 内容与可见度——、
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 - 社区与活动——、
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 - 项目与公司地基——、
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。买到的是后续每个会话据以决策的规则：项目以什么为评判标准、谁可以合并、公司放弃什么。成本是需要 DevRel 之外的签字——工程、法务、高管——而且其中大部分只能通过另一场谈判来逆转。tech-employer-branding
devrel-careerdevrel-radar各个轴并不一致，这正是选择的难点：
- 效率：
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 - 合规成本：——许可证或治理决策约束每个未来的贡献者，只能通过重新许可来撤销；社区空间使你成为他人言论的版主和其举报的持有者；赞助资金跨越披露线；已发布的文章和媒体稿需要签字且无法撤回；发布说明是关于破坏性变更的公开声明。诊断和 first-run surfaces 在零上持平：两者都读取和编辑你自己的仓库，且不发布关于任何他人的声明，不过 first-run surfaces 需要一次已合并的 pull request，而诊断不需要。
foundations > community and events > content > release cadence > first-run surfaces == diagnosis（无）
地基在价值上领先，在效率上垫底，因为签字以周计，而且产出落地那一周是看不见的。
这正是效率顺序饿死的东西：第 6 类的地基型 skills。 和 是最明显的例子——协调成本最高，当周没有任何可交付——因此比率优先的顺序会永远打磨 README，而每个后续会话都在反复争论项目的目的是什么、公司可以放弃什么。
devrel-strategyoss-license-strategy在以下情况直接将第 6 类提升到第 1 级：
- 没人能说出有资金支持的驱动因素（Q4 返回为空或声称全部七个）。
- 一个已经在接受外部贡献的仓库上不存在许可证或治理文件。
- 同样的范围争论一次又一次地出现。
- Q7 的答案是 (d) 长期持续且有签字可用。
默认：从第 1 类开始 short-list，并停留在那里，直到诊断指出更下方的某一类。每次只向下移动一个类别，绝不要越过诊断标记为缺失的类别。
从 short-list 中删除被排除的类别；绝不要将其降到最后一位，因为停放在底部的被排除 skill 会作为范围问题悄悄重新出现。
- 有明确的解锁条件——移到“暂不处理”列表并带上该条件。
- 没有——从输出中完全删除。
这个顺序是默认，不是法律——它会随采用模式和执行者而变化。根据访谈和检测刚刚告诉你的信息重新排序，并大声说出哪个答案移动了哪个类别：
- 没有购买方的非商业开源项目（Q3d）从 short-list 中删除 、
devtools-pricing-strategy和devtools-business-model，并在第 6 类和第 5 类内部提升developer-first-gtm和oss-governance。oss-sponsors-fundraising - 个人自助采用（Q3a）提升第 2 类和第 4 类。
- 组织购买（Q3b）将 和
developer-case-study提升到其默认位置之上，因为签字人从不运行 quickstart。developer-first-gtm - 有资金支持的驱动因素（Q4）删除整个类别：
- 销售赋能删除第 3 类的 triage 条目，除非项目是开源的。
- 贡献者社区直接删除 和
developer-first-gtm。devtools-pricing-strategy - 雇主品牌将 提升到第 1 级，因为它拥有该驱动因素的全部计划，并对其下的每个内容押注进行排序。
tech-employer-branding
- 阶段“还没有正式的东西”（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提升为该季度的第 1 级。developer-live-demo-design - 发布日期提升第 3 类。
- 会议日期将
- “一次性，只有维护者时间”（Q7a）将 short-list 削减为来自第 1、2 类的两个条目。
- “长期持续，有签字可用”（Q7d）将第 5、6 类提升到其默认位置之上。
- 已经拥有的资产会改变比率，而不是价值：已埋点的分析栈、已部署的文档站点、或已接受的会议演讲名额，会使依赖它的 skill 近乎零投入——提升它。
- 已决定的事项（Q2）完全离开 short-list；不要对已不在讨论范围内的事情排序。
- 检测也会移动类别：
- 没有 CONTRIBUTING 文件的仓库会在第 2 类内部提升 。
oss-contributor-onboarding - git 日志显示数月停滞，说明在构建任何东西之前应先做诊断。
- 已有文档站点且信息架构已被审计过，则删除其第 1 类条目。
- 没有 CONTRIBUTING 文件的仓库会在第 2 类内部提升
5. Context artifact
5. 上下文工件
Create or update at the project root - one versioned file, committed with the project when the project lives in git, and the single source of truth that makes the next start warm. Its sections:
devrel-context.md- 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.
Those last three constraint fields are what let a warm start re-rank the short-list and the routines without re-asking questions 6 and 7. See references/context-artifact.md for the template, a worked example, and a negative example.
- On warm start: read it, do not rebuild it. Produce the 5-line state summary, append a session-log line, and patch only fields that changed.
- Optionally patch the project's agent-instruction file with the project's invariants (audience motion, funded driver, surfaces owned, hard constraints) so every future session inherits them without loading this skill.
- Do not scaffold a working tree the project hasn't earned. Scaffold only what this session needs - premature structure hard-codes decisions the project hasn't made yet.
- Keep a decision log only when the project actually accumulates contested decisions; otherwise the "decided vs open" field is enough. An empty ceremony log goes stale and erodes trust in the artifact.
Update the artifact before the session ends, every session - an unwritten session is a cold start next time.
在项目根目录创建或更新 ——一个版本化文件，当项目位于 git 中时随项目一起提交，它是让下次启动变成暖启动的单一事实来源。其各节：
devrel-context.md- 产品与受众。
- 项目：有资金支持的驱动因素、支柱组合、阶段与团队。
- 拥有的表面。
- 度量。
- 状态：进行中、已决定 vs 开放、约束（包括结果必须落地的日期）、一次性 vs 复利的时间视野、投入上限。
- 拥有决策权的利益相关者。
- 会话日志。
最后三个约束字段让暖启动无需重新问问题 6 和 7 就能重新排序 short-list 和例行程序。模板、实际示例和反面示例参见 references/context-artifact.md。
- 暖启动时：读取它，不要重建它。生成 5 行状态摘要，追加一行会话日志，只修补已更改的字段。
- 可选：用项目的不变项（受众模式、有资金支持的驱动因素、拥有的表面、硬约束）修补项目的 agent 指令文件，使每个未来会话无需加载此 skill 即可继承它们。
- 不要搭建项目尚未挣得的工作树。只搭建本次会话需要的东西——过早的结构会把项目尚未做出的决定硬编码进去。
- 只有当项目确实积累了大量有争议的决定时才保留决策日志；否则“已决定 vs 开放”字段就足够了。空的仪式性日志会过时，并侵蚀对工件的信任。
- 每次会话结束前更新工件——一个未写入的会话下次就是冷启动。
6. Memory
6. 记忆
If your harness has persistent memory, derive memory entries from the context artifact - never the reverse. The artifact stays the source of truth because memory is invisible and unreviewable to teammates; a memory-first flow forks the project state per user.
- Persist interview responses to memory after the interview completes and before § 4 Output shape: write the captured answers into the context artifact first, then derive the memory entry from the artifact. Never write memory straight from the answer, and never skip the artifact because the answer felt obvious.
- Store memory in exactly one of three places: local to the user's environment, a team knowledge base, or a directory in a git repository. Index it with an index file listing each entry with a one-line hook.
memories/ - On warm start, diff memory against the artifact. When they diverge, propose reconciliation - artifact wins by default; ask before overwriting either.
- Never put into memory:
- Community-member or contributor personal data.
- Conduct reports and moderation cases.
- Unannounced launches and embargoed news.
- Sponsorship and event rates under NDA.
- Unpublished pricing.
- Customer names not yet cleared for a case study.
- Security-sensitive detail from a build-in-public boundary.
- State this exclusion when you first write memory.
- When memory lives in a git repository, never commit it silently. Show the diff and get approval first, every time.
如果你的 harness 有持久化记忆，从上下文工件派生记忆条目——绝不要反过来。工件保持为事实来源，因为记忆对队友不可见、不可审查；记忆优先的流程会按用户分叉项目状态。
- 访谈完成后、§ 4 输出形态之前，将访谈回答持久化到记忆：先把捕获的答案写入上下文工件，再从工件派生记忆条目。绝不要直接从回答写记忆，也绝不要因为答案显而易见就跳过工件。
- 将记忆存储在三者之一：用户环境本地、团队知识库、或 git 仓库中的 目录。用一个索引文件为每个条目提供一行钩子来索引。
memories/ - 暖启动时，将记忆与工件进行 diff。当它们不一致时，提出协调方案——默认工件胜出；覆盖任何一方之前先询问。
- 绝不放入记忆的内容：
- 社区成员或贡献者的个人数据。
- 行为报告与版主处理案例。
- 未发布的发布计划和 embargo 新闻。
- NDA 下的赞助与活动价格。
- 未公开的定价。
- 尚未获准用于案例研究的客户名称。
- 来自公开构建边界的安全敏感细节。
- 第一次写入记忆时声明这一排除条款。
- 当记忆位于 git 仓库中时，绝不要静默提交。每次都先展示 diff 并获得批准。
7. Routines
7. 例行程序
If your harness supports scheduled routines, propose 2 to 4 - always shown as a dry-run before anything is created, each with an explicit output channel. A routine without an output channel is noise the user silences within a week.
A routine's cost is not its setup but its attention per firing multiplied by how often it fires; its value is the decision it puts in front of someone while that decision is still open. Rank the candidates on that ratio - value per unit of standing effort, highest first - and propose from the top down:
- Release-tag documentation pass → , plus
samber/developer-relations-skills@changelog-writingwhen the release is a major. Fires only when a tag lands, over commits and pull requests already written, and it is the only routine whose output can reach users before the release does rather than after they hit the breakage.samber/developer-relations-skills@version-migration-guide - Monthly or quarterly re-invocation of this kickoff. Near-zero per firing, and it keeps the artifact and the routing tables current - which is what stops every other routine firing at work that no longer exists. Match its cadence to the project's pace from the git log.
- CFP deadline sweep ahead of the season's target events → . A handful of firings a season, each a short read of a deadline list, against a deadline that is absolute: miss it and that stage is gone for a year. Buys nothing outside CFP season, which is why it is not rung 1.
samber/developer-relations-skills@conference-cfp-submission - Periodic issue and pull-request queue review → . Buys a queue that stays answerable instead of one that compounds into an abandoned project. Carries the highest standing cost in the set: a session per pass plus a maintainer answering everything it surfaces. Install it only where someone owns that follow-through.
samber/developer-relations-skills@oss-issue-triage - Quarterly content planning at quarter start → . Four planning sessions a year, buying a quarter of content that ships against real anchors instead of whatever occurred to someone that week.
samber/developer-relations-skills@devrel-content-calendar - Periodic measurement read → (program) or
samber/developer-relations-skills@devrel-metrics(community only). Buys a trend line someone can act on - but only once a baseline exists; fired before that, it reads noise aloud on a schedule.samber/developer-relations-skills@developer-community-health
- efficiency:
release-tag pass > kickoff re-invocation > CFP sweep > queue review > content planning > measurement read - value:
queue review > release-tag pass > content planning > measurement read > CFP sweep > kickoff re-invocation - effort:
queue review > content planning > measurement read > release-tag pass > CFP sweep == kickoff re-invocation - compliance cost: - release notes and migration guides are public statements about breaking changes and cannot be unpublished; a content calendar schedules those publications without committing to them. The four tied at zero all read internal or already-public state and emit it to the team; the CFP sweep and kickoff re-invocation also tie on effort, since each is one near-zero read per firing.
release-tag pass > content planning > measurement read == queue review == CFP sweep == kickoff re-invocation (none)
The kickoff re-invocation is the cheapest candidate and still sits second, not first - proof that cheap and efficient differ. The queue review leads on value and sits fourth on efficiency, since it costs a session every pass plus a maintainer answering each issue raised.
Default: rungs 1-2, which is two routines. Add rung 3 when CFP season is open, rung 4 once someone owns the triage follow-through. Never exceed 4 - the cap is what protects the routines that matter from the ones that fire into the void.
The ranking is a default, not a law; it shifts with the surface and with who executes it. Re-rank it against the interview and say which answer moved which routine:
- An open-source surface (Q1b) promotes the queue review above the CFP sweep.
- An events surface (Q1d) with a conference date promotes the CFP sweep to rung 1 for the season.
- No analytics access (Q6e) deletes the measurement read rather than demoting it.
- "Nothing formal yet" (Q5a) deletes it too, since there is no baseline to trend against.
- Maintainer hours only (Q6b), or "one-off, hours only" (Q7a), means install one routine - the kickoff re-invocation - not four.
- Legal or security review required (Q6d) lengthens the release-tag pass without changing what it buys.
- A team already running a weekly triage rotation makes rung 4 a duplicate, so demote it rather than sweep the same issues twice.
- An analytics stack already instrumented, or a docs pipeline that already builds on tag, makes its dependent routine near-zero effort - promote it.
Anchor triggers to the DevRel calendar - release train dates, CFP deadlines, conference dates, budget review, community rituals - rather than arbitrary dates, and prefer an event trigger over a schedule when one exists: a tag push beats "the first of the month" for release notes. List and clean up obsolete routines left over from a previous quarter before adding new ones.
If the harness has no scheduled routines, fall back to one recurring calendar reminder ("DevRel check-in - re-run the developer relations kickoff") and stop there. See references/routines.md for the dry-run format, calendar anchoring, event-trigger preference, and cleanup checklist.
如果你的 harness 支持定时例行程序，提议 2 到 4 个——在创建任何东西之前总是以 dry-run 形式展示，每个都有明确的输出渠道。没有输出渠道的例行程序是用户一周内就会静默的噪音。
例行程序的成本不是设置，而是每次触发的注意力乘以触发频率；其价值是在某个决定仍然开放时把它放到某人面前。按该比率对候选排序——单位持续投入的价值，最高在前——并从高到低提议：
- 发布标签文档处理——，当发布是 major 版本时再加上
samber/developer-relations-skills@changelog-writing。只在 tag 落地时触发，处理已经写好的 commits 和 pull requests；它是唯一能在发布之前而不是用户遇到故障之后将输出触达用户的例行程序。samber/developer-relations-skills@version-migration-guide - 每月或每季度重新调用本启动 skill。 每次触发近乎零成本，并使工件和路由表保持最新——这能阻止其他每个例行程序对着已不存在的工作开火。根据 git 日志中的项目节奏匹配其频率。
- CFP 截止日期扫描——在每个季度的目标活动之前——。每个季度几次触发，每次只是快速读一遍截止日期列表，而截止日期是绝对的：错过了，那个舞台就一年没了。在 CFP 季之外不买任何东西，这就是为什么它不是第 1 级。
samber/developer-relations-skills@conference-cfp-submission - 周期性 issue 与 pull request 队列审查——。买到的是一个保持可响应的队列，而不是一个滚雪球最终被废弃的项目。它是全套中持续成本最高的：每一轮一个会话，外加维护者回答它暴露的每件事。只在有人负责跟进的地方安装它。
samber/developer-relations-skills@oss-issue-triage - 季度内容规划——在每个季度开始时——。每年四次规划会话，买到一个季度内围绕真实锚点交付的内容，而不是某个人当周灵机一动的内容。
samber/developer-relations-skills@devrel-content-calendar - 周期性度量读取——（项目）或
samber/developer-relations-skills@devrel-metrics（仅社区）。买到一条可据以行动的趋势线——但只在基线存在之后；在此之前触发，它只是按计划大声朗读噪音。samber/developer-relations-skills@developer-community-health
- 效率：
release-tag pass > kickoff re-invocation > CFP sweep > queue review > content planning > measurement read - 价值：
queue review > release-tag pass > content planning > measurement read > CFP sweep > kickoff re-invocation - 投入：
queue review > content planning > measurement read > release-tag pass > CFP sweep == kickoff re-invocation - 合规成本：——发布说明和迁移指南是关于破坏性变更的公开声明，无法撤回；内容日历只是安排这些发布，并不承诺发布。四个并列为零的例行程序都读取内部或已经公开的状态并把它发给团队；CFP 扫描和 kickoff 重新调用在投入上也并列，因为每次触发都只是一次近乎零成本的读取。
release-tag pass > content planning > measurement read == queue review == CFP sweep == kickoff re-invocation（无）
Kickoff 重新调用是最便宜的候选，但仍然排在第二而不是第一——证明便宜和高效是不同的。队列审查在价值上领先，在效率上排第四，因为每一轮都要花一个会话，外加维护者回答提出的每个问题。
默认：第 1-2 级，也就是两个例行程序。当 CFP 季开启时加第 3 级；一旦有人负责 triage 跟进就加第 4 级。绝不要超过 4——这个上限保护重要的例行程序不被那些朝虚空开火的程序淹没。
排序是默认，不是法律；它会随表面和执行者变化。根据访谈重新排序，并说出哪个答案移动了哪个例行程序：
- 开源表面（Q1b）将队列审查提升到 CFP 扫描之上。
- 有会议日期的活动表面（Q1d）将 CFP 扫描提升为本季度的第 1 级。
- 没有分析访问权限（Q6e）删除度量读取而不是降级它。
- “还没有正式的东西”（Q5a）也会删除它，因为没有可作趋势的基线。
- 只有维护者时间（Q6b），或“一次性，只有时间”（Q7a），意味着只安装一个例行程序——kickoff 重新调用——而不是四个。
- 需要法务或安全审查（Q6d）拉长发布标签处理而不改变它买到的东西。
- 已经每周运行 triage 轮换的团队会使第 4 级变成重复，因此降级它，而不是把同样的 issue 扫两遍。
- 已经埋点的分析栈，或已经基于 tag 构建的文档流水线，会使其依赖的例行程序近乎零投入——提升它。
将触发条件锚定到 DevRel 日历——发布列车日期、CFP 截止日期、会议日期、预算审查、社区仪式——而不是任意日期；当存在事件触发时，优先于日程表：对于发布说明，tag 推送胜过“每月一号”。在添加新例行程序之前，列出并清理上一季度遗留的过时例行程序。
如果 harness 没有定时例行程序，退回到一个周期性日历提醒（“DevRel 检查——重新运行 developer relations kickoff”），然后到此为止。dry-run 格式、日历锚定、事件触发偏好和清理清单参见 references/routines.md。
8. Invocation examples
8. 调用示例
- "Start a new devrel project - we just open-sourced our SDK and nobody uses it." → cold start: detect, interview, route, write the artifact.
- "Which devrel skill do I need? Our docs are fine but signups never reach production." → routing ask: match against the tables, disambiguate, name the gap if none fits.
- "Run my devrel check-in." → warm start: 5-line state summary, session-goal question, re-route.
- "Where do I start? I'm the first devrel hire and I have no idea what to do first." → cold start: expect an ordered chain, not a single route.
- “启动一个新的 devrel 项目——我们刚刚开源了 SDK，但没人用。” → 冷启动：检测、访谈、路由、写工件。
- “我需要哪个 devrel skill？我们的文档没问题，但注册用户从未进入生产。” → 路由请求：对照表格匹配、消歧、如果没有匹配则指出缺口。
- “运行我的 devrel 检查。” → 暖启动：5 行状态摘要、会话目标问题、重新路由。
- “我从哪里开始？我是第一个 devrel 员工，完全不知道先做什么。” → 冷启动：预期会出现有序链，而不是单个路由。
9. Failure modes
9. 失败模式
- Forcing a match. Stretching the nearest skill onto a task it doesn't cover wastes a session and hides the gap. Say "none fits" and name the gap.
- Routing every docs question to the same skill. Quickstart, tutorial, how-to and reference are four different jobs - and the collection has no how-to skill at all. Check § Docs-authoring fork in the routing reference first.
- Force-fitting platform or event-production tasks. API design, webhooks, SDK strategy and marketplace operations belong to ; organizing your own conference belongs to
samber/developer-platform-skills. Recommend the sibling collection instead.samber/dev-event-organizer-skills - Re-interviewing on a warm start. The artifact exists precisely so questions aren't repeated. Ask only the session goal.
- Routing from a guessed scope. Route only from the declared scopes in the routing reference; a plausible guess misroutes confidently.
- Skipping the funded-driver question. Without it, the strategy, metrics and budget routes all collapse into generic advice the user has to re-scope by hand.
- Uncapped interview. Past 7 questions the kickoff becomes a form the user abandons.
- A flat short-list. Eight equal-looking options get picked by taste, or by whichever sits first. Order by value per unit of effort and name both sides on every line, or the user cannot choose.
- Leading with the cheapest option. Cheap and efficient are different orderings, and only the second one answers "what first". A near-zero routine that buys near-zero is a rounding error, not a quick win.
- Ranking the routing tables or the chain. Scope is a match test and a chain is a dependency order; imposing a ratio on either invents a preference that does not exist.
- Demoting a ruled-out skill instead of deleting it. A class the interview took off the table, parked at the bottom of the short-list, reappears as scope two sessions later. Delete it, or move it to "not now" with its unblocking condition.
- Letting the ratio starve the foundations. Class 6 loses every efficiency round and is exactly what a program being set up needs first. Check its promotion conditions before opening at class 1.
- Routines with no output channel. They fire into the void and get silenced, burying the one routine that mattered.
- Memory committed silently. Teammates can't review what they can't see land. Diff and approval, always.
- Stale routing table. Update the tables, routing reference, boundary forks, chains and gap list whenever the collection changes - a skill added, renamed, removed, or re-scoped. A stale router sends users to skills that no longer exist, which is worse than no router at all.
- 强行匹配。 把最近的 skill 硬套到它不覆盖的任务上，浪费一个会话并掩盖缺口。要说“没有匹配”并指出缺口。
- 把所有文档问题都路由到同一个 skill。 Quickstart、tutorial、how-to 和 reference 是四种不同的工作——而且该集合根本没有 how-to skill。先查路由参考中的“文档编写”分叉。
- 硬套平台或活动制作任务。 API 设计、webhooks、SDK 战略和市场运营属于 ；组织自己的会议属于
samber/developer-platform-skills。建议改用兄弟集合。samber/dev-event-organizer-skills - 暖启动时重新访谈。 工件之所以存在，正是为了不重复提问。只问会话目标。
- 凭猜测的范围路由。 只能根据路由参考中声明的范围路由；看似合理的猜测会自信地错误路由。
- 跳过有资金支持的驱动因素问题。 没有它，战略、度量和预算路由都会塌缩成用户必须手动重新限定范围的通用建议。
- 无上限访谈。 超过 7 个问题后，kickoff 就变成用户弃用的表单。
- 扁平的 short-list。 八个看起来一样的选项会被口味或谁排最前决定。按单位投入的价值排序，并在每一行说明两面，否则用户无法选择。
- 拿最便宜的开路。 便宜和高效是两种不同排序，只有后者回答“先做什么”。一个近乎零成本、买来也近乎零价值的例行程序只是舍入误差，不是快速胜利。
- 给路由表或链排序。 范围是匹配测试，链是依赖顺序；对任一个强加比率都会发明出不存在的偏好。
- 降级被排除的 skill 而不是删除。 访谈移下桌的类别，停在 short-list 底部，两个会话后会作为范围问题重新出现。删除它，或连同解锁条件移到“暂不处理”。
- 让比率饿死地基。 第 6 类在每轮效率上都输，但它正是正在建立的项目首先需要的东西。在从第 1 类开始之前，检查其提升条件。
- 没有输出渠道的例行程序。 它们朝虚空开火并被静默，埋没了真正重要的那个例行程序。
- 静默提交记忆。 队友无法审查他们看不到落地的东西。永远 diff 并征求批准。
- 过时的路由表。 每当集合变化——新增、重命名、删除或重新定义 skill 范围——都要更新表格、路由参考、边界分叉、链和缺口列表。过时的路由器会把用户送到已不存在的 skills，比没有路由器更糟。
10. Pass bar
10. 通过标准
Before ending the session, check every item. If any fails, fix it and re-check - do not close the session on a failing bar.
- Every recommended skill's declared scope actually matches the stated task - re-read its description to confirm.
- Zero routes to a name outside the 55 skills in the tables above.
- Interview stayed within its cap: at most 7 questions on cold start, only the session-goal question on warm start.
- was written or updated, including a session-log line, before the session ended.
devrel-context.md - Every proposed routine was shown as a dry-run and has an explicit output channel.
- The short-list and the routine set are both ordered by value per unit of effort, each entry naming the bottleneck it attacks and what it costs - and the re-rank was stated out loud whenever an interview answer moved something off its default place.
- Every class the interview ruled out left the short-list entirely, rather than sitting at the bottom of it.
- The routing tables and any proposed chain were left unranked - match test and dependency order respectively.
结束会话前，检查每一项。若有任何一项未通过，修复并重新检查——不要在未通过的标准上关闭会话。
- 每个推荐 skill 声明的范围确实匹配所述任务——重新阅读其描述确认。
- 零路由到上表 55 个 skills 之外的名称。
- 访谈保持在上限内：冷启动最多 7 个问题，暖启动只问会话目标问题。
- 在会话结束前被写入或更新，包括一行会话日志。
devrel-context.md - 每个提议的例行程序都以 dry-run 展示，并有明确的输出渠道。
- short-list 和例行程序集都按单位投入的价值排序，每个条目说明它攻击的瓶颈及其成本——并且当访谈答案将某些内容移出其默认位置时，重新排序被大声说出来。
- 访谈排除的每个类别都完全离开 short-list，而不是停在底部。
- 路由表和任何提议的链都保持未排序——分别是匹配测试和依赖顺序。