Skills
收录 96,981 个为 Agent 打包的专项能力与操作指引，复制一行命令即可安装。
全部
选择并记录一个开源项目的治理模式 —— 决策权、维护者角色与晋升、投票与共识规则、冲突升级、继任安排、商标与资产控制，以及是否加入基金会或财务托管方。当有人问「项目中谁说了算」、想编写或修订 GOVERNANCE.md、正在增减维护者、担心巴士因子或项目被单一厂商把控、遇到僵局或有争议的决策，或正在准备向基金会捐赠时使用 —— 即使他们只是说项目没有规则。涵盖个人项目、公司支持的项目和多厂商项目。不涉及许可证、CLA 或 DCO 的选择 —— 请使用 samber/developer-relations-skills@oss-license-strategy。不构成法律建议。
审查现有开发者文档体系的结构——逐页清点并按 Diátaxis 模式（tutorial、how-to、reference、explanation）分类，找出混合模式与放置错误的页面、各产品面的覆盖缺口、与文件树的导航偏差、CNCF TechDocs 评分，以及按优先级排序的整改队列。适用于用户提到文档结构或内容审查、文档信息架构、Diátaxis、我们的文档乱成一团、文档缺口分析、缺哪些文档、某页该放在哪里，或重组文档站点时——即使他们只是说“我们的文档很难导航”。不用于撰写文档页面。文档搜索排名请使用 samber/developer-relations-skills@docs-seo。
设计并运营定期举办的开发者 Meetup 或用户小组：宗旨与主办模式、形式选项、举办频率、固定的讲者来源、以实物形式提供场地与餐饮的赞助商及其行为边界、缺席应对方案、从参会者到联合组织者的成长阶梯，以及健康度评分卡。每当有人提到要创办开发者 Meetup 或用户小组、Meetup 出席率下滑、寻找 Meetup 讲者、争取场地或披萨赞助、确定举办频率、报名后从未到场的情况，或将 Meetup 移交他人时使用——即使对方只是说「我们想做本地活动」。涵盖独立举办、厂商赞助和公司内部支持的小组。不适用于在会议上演讲——请使用 samber/developer-relations-skills@conference-cfp-submission。
将开源项目的许可证和贡献政策作为一个整体决策来选择——宽松型还是弱/强型或网络型 copyleft、由依赖关系决定的兼容性约束、DCO 还是 CLA 还是两者都不要、双重许可证和 open core、源码可用选项（BUSL、FSL、Elastic License、SSPL），以及重新许可带来的分叉风险。当有人问该选哪个许可证、MIT/Apache-2.0/GPL/AGPL 是否合适、是否需要 CLA 或 DCO 签署、如何为现有项目重新许可、AGPL 是否真能防止云厂商、以及应发布哪些 LICENSE、SPDX 和 NOTICE 文件时，使用此技能——即使用户只表达法律层面的担忧。不适用于公司该开源什么——请使用 samber/developer-relations-skills@open-source-company-strategy。本技能不提供法律意见。
设计并检验一个陌生人在开源项目上完成首个被合入的贡献的路径 —— CONTRIBUTING 文件、good-first-issue 队列、一条开箱即可跑通测试的克隆命令，以及首个 pull request 的评审与认可闭环，并按阻塞项加权重评分表打分。当有人说「没人给我的项目贡献」「写一份 CONTRIBUTING.md」「我们的 good first issue 没人认领」「新贡献者消失了」「贡献者引导」「首次 pull request 体验」或「我们如何吸引更多开源贡献者」时使用 —— 即使他们只是抱怨仓库冷清。不涉及 triage 体系设计 —— 请使用 samber/developer-relations-skills@oss-issue-triage。不涉及治理或 CLA 选择。
使用 expo-updates 和 EAS CLI 配置并使用 EAS Update，以无线方式更新 JavaScript 和资源。适用于设置 OTA 更新、运行 eas update:configure 或 eas update、发布到 preview/staging/production 通道、解释分支／通道／运行时版本、测试更新，或排查已安装构建仍显示旧代码的原因。TestFlight、preview 或 production 更新未显示时均可加载，包括有关冷启动或重新打开应用的问题。不适用于更新健康指标；采用率、崩溃和发布监控请使用 eas-update-insights。
构建开发者关系（DevRel）衡量框架：制定一组从触达至产品和业务影响分层的指标，每项指标都包含书面归因规则、基于基线设定的目标、负责人和行动，并剔除虚荣指标。用户询问如何衡量 DevRel、哪些 DevRel KPI 重要、如何向高管证明 DevRel 的价值或 ROI、DevRel 计分卡或季度报告应包含什么、为什么数据看起来不错但领导层仍不信服，或报告中只有星标、展示量和活动次数时，均可使用——即使用户没有说“指标”。不要用于跟踪埋点和仪表板；请使用 samber/developer-relations-skills@devrel-analytics。不是仅针对社区健康度指标，也不是单场活动的 ROI。
依据公开可观察的信号对竞争对手的开发者关系（DevRel）工作进行基准评测——文档与快速上手质量、开源仓库健康度、社区规模与响应速度、问答板块的标签活跃度、各类内容的产出节奏、活动参与度、招聘信号——并为每一项返回差距分析及「接近」「忽略」或「反击」的结论。当用户要求 DevRel 竞争基准对比、开发者体验比较、“就开发者而言我们与 <competitor> 相比如何”、“<competitor> 在 DevRel 方面做了什么”、社区规模或内容产出节奏对比，或与竞品的文档对比时使用——即使用户只是说“为什么他们能吸引更多开发者”也一样。不适用于仅衡量自身的项目——请使用 samber/developer-relations-skills@devrel-metrics。
将一个季度的开发者关系内容规划为带日期的排期，指定负责人和审阅者，纳入固定节点（发布、上线、CFP 截止日期、会议）、发布渠道、内容支柱、用户旅程和内容时效组合，并根据实际写作和审阅能力安排工作量。凡是用户要求制定 devrel 内容日历、面向开发者的编辑日历或内容计划、询问下季度发布什么、如何平衡常青内容与发布相关内容、小团队能产出多少篇内容，或表示内容计划总是延期时均使用，即使对方只说“我们发布内容很随意”。只规划季度；单篇内容应使用对应格式的技能，例如 samber/developer-relations-skills@engineering-blog-post。
审查并重写仓库 README，让从未见过该项目的开发者也能明白它是什么、为何优于替代方案，并在一分钟内运行第一条命令——每一处说法和文档中的安装步骤都对照源码核实过，页面按“快速放弃漏斗”排序，没有价值的徽章一律删除。当有人说“帮我看看 README”“我的 README 太差了”“给这个仓库写个 README”“没人看懂我的项目是做什么的”“仓库的第一印象”“README 结构”“徽章太多”，或准备开源发布时使用——即使他们只称它为仓库落地页。不适用于个人主页 README——请使用 samber/developer-relations-skills@github-profile-optimization。
构建开发者关系触点的跟踪方案，为文档、博客、代码仓库、软件包注册表、社区渠道和线上线下活动设置埋点，包括事件分类、身份关联主线、链接标签规范、来源置信度标注和漏斗视图。用户提及“DevRel 跟踪方案”“文档分析”“UTM 规范”“文档事件分类”“GitHub 数据与分析工具不符”“如何为开发者漏斗埋点”“将文档流量与注册关联”，或想了解为什么不同工具中的 DevRel 数据不一致时使用。仅负责埋点层；哪些 KPI 应设目标，请使用 samber/developer-relations-skills@devrel-metrics。
设计开发者关系（DevRel）组织——DevRel 应归属哪个职能（市场、产品、工程、CEO、销售）以及这条汇报线会削弱什么、组织形态（集中式、拆分式、嵌入式、中心辐射式）、在倡导、社区、文档和教育方面的覆盖地图、与产品、文档、支持和销售的衔接，以及下一次重组的触发条件。当有人问 DevRel 应处于什么位置、应向谁汇报、如何搭建或重组 DevRel 团队、在这个规模下该配哪些 DevRel 角色、是否把倡导人员嵌入产品团队、为什么 DevRel 总被拉去做其他团队的工作，或 DevRel 与文档如何划分职责时，使用此技能——即使用户只是说团队感觉不对。不适用于预算分配——请使用 samber/developer-relations-skills@devrel-budget-allocation。
为面向开发者的产品开展媒体公关和轻量级分析师关系工作：新闻价值判断、切入角度、按记者与报道领域整理媒体地图、宣传提案、禁发期和独家内容处理、新闻页面与简报资料包，以及评估报道价值。用户提到科技媒体公关、争取媒体报道、联系记者、建立媒体名单、新闻资料包、争取 JavaScript Weekly 等开发者通讯提及、禁发期简报、宣布融资、分析师简报，或询问“如何让媒体报道我们”时使用，即使只说想上新闻也适用。不是用于撰写公告帖——使用 samber/developer-relations-skills@engineering-blog-post。不是用于扩大自有通讯订阅名单——使用 samber/developer-relations-skills@devrel-newsletter-growth。
为面向开发者的产品设计市场进入策略，包括自下而上的自助式采用、开发者影响型销售、由上而下并以开发者验证，或通过生态系统分发；同时设计自助入口、开发者向买家的交接规则，以及客户落地与扩展路径。创始人、开发者关系或增长负责人询问如何将开发者采用转化为收入、应自下而上还是聘请销售、何时联系免费用户、注册量高但付费账户持平的原因，或已落地团队如何在企业内扩展时使用，即使他们只说“我们的转化漏斗出了问题”。不用于定价——请使用 samber/developer-relations-skills@devtools-pricing-strategy。
企业微信智能文档（smartpage）操作技能。能够新建文档、导入 .md 为文档、读取文档内容、修改文档内容（整页重写、局部编辑、增删子页面）、上传附件到文档，以及搭建带看板/图表的数据系统页面和信息收集表单页面。当用户提及文档、智能文档、智能主页，提供 https://doc.weixin.qq.com/smartpage/xxx 或 https://page.weixin.qq.com/smartpage/xxx 链接，要求整理成文档，或表达“新建文档”“把 md 导入成文档”等未指定文档类型的需求时，也应使用本技能。
为他人技术播客、YouTube 采访、直播或座谈会的嘉宾做准备——节目情报调研、切入角度、以证据与故事支撑的 ABT 叙事主线、自成一体的开场回答、可剪辑的金句、深度校准、录制当天的流程，以及发布后的推广闭环。当有人说“播客嘉宾准备”、“我下周要上播客”、“YouTube 采访准备”、“DevRel 媒体训练”、“帮我准备要点”、“金句”、“我要参加座谈会”或“他们问到竞争对手时我该说什么”时使用——即使只是提到即将进行的录制。不用于运营自己的节目——请使用 samber/dev-event-organizer-skills@tech-podcast-youtube-channel。
将客户在真实生产环境中的部署转化为工程师认可的技术案例研究：提供与测量方法关联的量化数据、前后架构对比、已公开的限制，以及已获批准的名称和引述。用户提及客户案例研究、技术案例研究、开发者采用或成功故事、参考客户，或想将用户访谈、迁移或生产部署转化为公开证据时使用——即使他们只说“写一篇关于 Acme 如何使用我们的文章”。不要用于介绍自有系统的文章；请使用 samber/developer-relations-skills@engineering-blog-post。介绍自有项目持续进展时，请使用 samber/developer-relations-skills@build-in-public。
为面向开发者的产品编写或审查教学教程：每步一个新概念、供学习者验证与续学的检查点、逐步淡出的引导、故障排查钩子，以及最后可验证的技能。只要用户提到教程、跟做式或动手指南、"通过构建 X 来学习 Y"的文章、工作坊或实验讲义、开发者课程单元，或有人说他们的教程没人学完，就使用本技能——即使只是说"写一份教这个的指南"。不要用于从零到首次成功的快速上手（samber/developer-relations-skills@developer-quickstart-guide）或视频脚本（samber/developer-relations-skills@technical-video-script）。
为文档站点执行页面内和技术 SEO：检查可索引性、不同版本及翻译页面的 canonical 和 hreflang、重定向、生成器的标题与描述模板、内部链接，并根据约定的达标门槛制定指派负责人的修复清单。凡是有人提到“文档 SEO”“我们的文档排名不好”“文档搜索优化”“旧版文档排名超过当前版本”“文档页面未被索引”“修复文档的 canonical”“文档站点地图问题”“翻译文档的 hreflang”或“预览文档被索引”时均使用，即使对方没有说 SEO。适用于有版本、已翻译和自动生成的参考文档。不用于关键词研究——请使用 samber/developer-relations-skills@developer-keyword-research。
设计能在现场稳定运行的技术演示方案，包括风险分级、演示所需的保真度等级、可独立进入的检查点、一条命令重置环境、离线模式、录制好的备用方案和演练过的故障恢复话术，并交付包含演示前检查清单的演示运行手册。用户提到现场演示、现场编码、演示可靠性或备用方案、“我的演示在台上出故障了”、应现场演示还是预录、重置演示环境、干净的演示笔记本、演示配置或紧急按钮，或正在准备包含演示的演讲、工作坊、网络研讨会或发布直播时使用，即使他们只说“我有点担心演示”或“如果我共享错了屏幕怎么办”。不用于演讲结构——请使用 samber/developer-relations-skills@tech-talk-outline。
让编码 Agent 能够在无人值守的情况下集成 SDK、API 或协议文档：支持爬虫访问、提供机器可读入口（llms.txt、Markdown 端点、OpenAPI 和 JSON Schema 文件）、自包含且可安全复制粘贴的页面，并衡量 Agent 首次尝试的成功率。用户提到 Agent 可读或 AI 就绪文档、Agent 体验或 AX、llms.txt 或 llms-full.txt、面向编码 Agent 的文档、Agent 虚构不存在的 API 调用，或询问 Agent 是否能仅凭文档接入 SDK 时使用，即使用户没有说“Agent”也适用。不适用于 AI 搜索引用（samber/developer-relations-skills@developer-docs-ai-visibility）或仓库的贡献者 Agent 指引。面向人工读者的文档架构使用 samber/developer-relations-skills@developer-docs-structure-audit。
设计维护团队能够长期执行的问题和拉取请求分流体系：根据实际能力设定响应目标、制定标签分类、通过结构化表单和跟踪系统外分流进行入口筛选、设置独立的安全报告渠道、分配分流值班，并制定关闭、过期和数量门槛策略。用户说“问题跟踪器失控了”“设计问题分流流程”“为仓库设置标签”“我们有 900 个未解决问题”“要不要运行过期机器人”“没人审查的 PR 积压”“分流轮值”或“我们被 AI 生成的报告淹没了”时使用，即使他们只说维护工作令人不堪重负。不是用于精选适合新手的问题；请使用 samber/developer-relations-skills@oss-contributor-onboarding。
为吸引软件工程师设计雇主品牌策略——工程 EVP、渠道规划（工程博客、开源项目曝光、员工推荐、会议演讲、薪酬透明化材料）、验证触点审计（雇主评价网站、薪酬数据库、匿名论坛），以及衡量基线。当有人提出“工程雇主品牌”、“为什么我们招不到工程师”、“开发者招聘内容策略”、“是否应该公开薪资区间”、“技术招聘品牌”，或工程 offer 接受率下滑时使用——即使他们将其框定为招聘问题。覆盖从早期阶段到大型公司、从初级到 Staff 级员工的各个层级。不适用于 DevRel 项目策略——请使用 samber/developer-relations-skills@devrel-strategy。
把一个演讲想法变成可用于某一场具体会议投稿的提案，或帮助选择投稿目标会议、规划跨多个会议的投稿日程：涵盖赛道契合度、标题备选、面向听众的摘要、以动词开头的收获要点、仅评审可见的字段、可信度材料包，以及对照评审委员会自身标准的自审。只要用户提到 CFP、征稿（call for papers）、会议提案、演讲摘要、会话描述、投稿 KubeCon、PyCon 或 FOSDEM、该投哪个会议、规划 CFP 投稿季，或说提案屡次被拒，就使用本技能——即使他们只是要求把摘要缩短。涵盖社区主办和厂商主办的活动。不适用于已获录取演讲的结构编排（samber/developer-relations-skills@tech-talk-outline）或其演示设计（samber/developer-relations-skills@developer-live-demo-design）。
将已获接纳的会议演讲摘要转化为可排练的大纲：一句话核心观点、叙事脉络、按分钟分配的时间预算、演示安排，以及带有删减检查点的幻灯片框架。用户提到“演讲大纲”“技术演讲结构”“幻灯片框架”“我的演讲被接受了，接下来呢”“如何组织这场会议演讲”“我的演讲超时了”“该删掉演讲中的什么内容”或“演示应该放在哪里”时使用，即使他们只说正在准备会议演讲。它组织演讲内容。不是 CFP 摘要——请使用 samber/developer-relations-skills@conference-cfp-submission。也不适用于幻灯片文件或舞台表达指导。
把原始提交、拉取请求和工单转化为开发者真正会读的发布说明——一份可快速浏览的记录，说明发布了什么、实际意味着什么、以及哪些东西会不兼容。适用于以下情况：用户提到变更日志、CHANGELOG.md、发布说明、某个标签的 GitHub Release 正文、托管的「更新内容」页面、应用商店发布说明、Keep a Changelog 或 Common Changelog，或询问刚发布的版本该怎么写——即使提交历史混乱且没有任何提交规范。不适用于版本号递增、打标签或发布流水线。完整的破坏性变更升级指南请使用 samber/developer-relations-skills@version-migration-guide；叙述式的发布博客文章请使用 samber/developer-relations-skills@engineering-blog-post。
端到端设计无薪、仅提供福利的开发者 Champion 或大使计划，包括准备度检查、招募模式、公开的遴选标准、基于行为的义务、优先提供访问权限的福利阶梯、设有续期和校友身份的固定任期，以及成员评分卡。用户提到大使或 Champion 计划、类似 MVP 的认可、社区英雄、“如何认可社区中的核心成员”、大使应获得哪些福利、陷入停滞的大使计划，或移除不活跃的 Champion 时使用，即使他们没有说“Champion”。不适用于付费创作者、联盟或收入分成合作。要衡量社区本身，请使用 samber/developer-relations-skills@developer-community-health。
为开发者工具选择商业模式——专有 SaaS、开放核心、托管式开源、支持与 LTS 订阅、双重许可、源代码可用、按用量计费、市场抽成或 OEM 许可——以及每种模式所要求的市场进入策略。创始人或高管询问开发者工具如何盈利、开放核心还是托管云更合适、免费与付费的界限在哪里、是否应将产品开源、采用率高但收入持平的原因，或任何变现、收入模式、商业开源问题时使用，即使他们没有提到“商业模式”。不用于定价、套餐或免费层限制——请使用 samber/developer-relations-skills@devtools-pricing-strategy。
针对单一受众群体绘制开发者旅程图，按阶段展示发现、试用、采用、贡献和倡导，并以表格形式呈现。每个阶段都包含退出事件、明确的负责人、引用的摩擦证据和一个信号，同时指出下一步最值得修复的唯一流失点。用户询问开发者旅程、开发者采用漏斗或旅程图、为何开发者试用产品却从未投入生产、采用在哪个环节下降、谁负责每个开发者体验阶段，或开发者如何成为贡献者时使用——即使他们只说“我们在某个环节流失了用户”。这不是指标框架；请使用 samber/developer-relations-skills@devrel-metrics。
制定开发者活动赞助方案：赞助哪些会议、meetup 和黑客松，赞助哪一档，采用哪种现场激活方式，以及如何证明这笔钱花得值。只要 DevRel 负责人、开发者市场人员或创始人提到赞助会议、展位成本、赞助档位或赞助方案谈判、把活动预算分摊到多个活动、黑客松赞助或活动 ROI，就使用本技能——即使他们只是问“这个展位值不值”。不适用于筹办自己的活动（samber/developer-relations-skills@developer-meetup-program）、让演讲被录用（samber/developer-relations-skills@conference-cfp-submission），或赞助开源项目。
撰写或编辑面向持怀疑态度的开发者读者、能让他们信服的技术博客文章：采用恰当的文章模式、为每项主张提供证据、公开权衡与局限、提供可运行代码片段，并避免营销口吻。用户想要工程博客文章、技术文章、“我们如何构建它”或“我们用 X 重写了它”的故事、调试记录、公开复盘、基准测试文章，或不能读起来像营销内容的产品文章时使用；用户要求审阅、编辑、去除行话或营销腔，修改现有技术草稿时也使用，即使他们只称其为“文章”。这不是教学教程——请使用 samber/developer-relations-skills@developer-tutorial。也不适用于发行说明、迁移指南、案例研究或演讲。
根据文档搜索日志、支持工单、问题跟踪系统和一方查询数据，构建按优先级排序的技术搜索查询关键词列表（错误字符串、“如何在 Y 中使用 X”任务、集成意图、比较、迁移），而非依赖关键词工具的搜索量。用户询问开发者实际搜索什么、想为开发者工具、API、SDK 或文档站点获取关键词、错误消息关键词列表、技术主题的需求规模，或想根据搜索需求决定创建哪些文档页面时使用，即使他们没有提到“关键词”。不撰写页面。不要用于页面或文档站点 SEO——请使用 samber/developer-relations-skills@docs-seo。
编写开发者社区行为准则及其配套的审核手册，涵盖范围、执行阶梯、举报渠道、事件响应手册、版主名单和平台控制措施。凡是用户提到行为准则、CODE_OF_CONDUCT.md、社区审核、招募版主、升级处理阶梯、封禁或暂停成员、骚扰、网络喷子、围攻、垃圾信息或 AI 垃圾内容泛滥，或需要处理行为举报时均使用；也适用于“我们的 Discord 快失控了”“我们需要社区规则”或“有人举报了一位维护者”等较含糊的说法。适用于公司运营和志愿者维护的开源社区。不要用于选择平台——请使用 samber/developer-relations-skills@developer-community-launch。
编写或审查重大变更的迁移指南：说明哪些内容会失效，按影响范围排序，为每项提供检测信号及变更前后的代码、弃用时间线、codemod 的覆盖边界，并通过对真实项目进行全新升级来验证。凡是有人提到迁移指南、升级指南、重大变更页面、主版本升级、“如何告知用户 v3 的变更”、API 版本切换、弃用或停止服务通知、codemod 或兼容构建时均使用，即使对方只说正在发布 v2。适用于库、SDK、CLI、框架、托管 API 和 schema 运维手册。不要用于发行说明——请使用 samber/developer-relations-skills@changelog-writing。
设计维护者一侧的开源赞助计划：面向个人与企业赞助方的档位阶梯及其定价、在赞助方数量增至十倍后仍能兑现的回馈、资金目标与可持续性的表述框架，以及公司付款前必须走通的发票与主体流程。只要维护者询问如何为项目争取赞助或资金、搭建或修复 GitHub Sponsors、Open Collective 或 FUNDING.yml、撰写赞助档位、回馈或赞助页面、不解为何广受欢迎的项目无人赞助、考虑 sponsorware，或希望由公司资助维护工作，就使用本技能——即使他们只是说项目难以持续。不适用于企业一侧——请用 samber/developer-relations-skills@oss-sponsors-brand-strategy。
一个开放协议，规定了 AI 应用如何以统一方式连接外部工具与数据源。客户端负责与模型对话，MCP 服务负责提供工具、资源和提示模板，两者通过标准消息通信，同一个服务可以被不同客户端复用。