Skills
收录 96,981 个为 Agent 打包的专项能力与操作指引，复制一行命令即可安装。
全部
Ultracite 是适用于 JavaScript/TypeScript 项目的零配置代码检查与格式化预设。以下情况使用：（1）在项目中设置或初始化 Ultracite，或将现有代码检查和格式化配置迁移到 Ultracite（ultracite init）；（2）运行代码检查或格式化命令（check、fix、doctor）；（3）在使用 Ultracite 的项目中编写或审查 JS/TS 代码，以遵循其代码规范；（4）排查代码检查或格式化问题；（5）升级 Ultracite 或将其配置更新到较新版本（ultracite upgrade）；（6）在已安装 Ultracite 的项目中，用户提及“ultracite”、“lint”、“format”、“code quality”或“biome/eslint/oxlint”。
为开发者工具设计定价与打包架构——价值计量单位（席位、用量、容量、成果或混合方式）、免费额度限制、从入门到企业级门槛的分层阶梯、以上限利润为下限并受自托管与自建版本上限约束的价格点，以及在不引发反弹的情况下调整价格的方案。当有人询问开发者工具该收多少钱、分层如何打包、免费与付费的边界在哪、按席位还是按用量计费、如何与自家的开源版本定价竞争，或如何安全地提价时使用——即使他们只是说定价页面感觉不对。不用于选择商业模式——请使用 samber/developer-relations-skills@devtools-business-model。也不用于定价页文案。
面向雇主的 DevRel 招聘——撰写职位发布和基于结果的评分卡，跨该领域的形式（演讲轮、带作品作业、DevRel 观点轮）设计面试循环和题库，按六信号评分标准评估作品集，设计有偿工作样本而非无薪命题作业，并以摩擦日志为基础构建 30-60-90 天融入计划。按公司类型和资金驱动因素拆分。当用户询问如何招聘开发者倡导者、撰写 DevRel 职位发布、为社区经理或教育者设计面试循环、评估候选人作品集或规划融入计划时使用。不适用于候选人侧准备（samber/developer-relations-skills@devrel-career）或组织设计（samber/developer-relations-skills@devrel-team-structure）。
将开发者关系预算按各支柱——活动、内容、社区、工具、教育、OSS 赞助——拆分为若干预算项，每项都包含现金成本、工时成本、预设回报阈值、复审日期和重新分配规则，并附带一份按优先级排序的削减清单。当有人询问如何规划或拆分 devrel 预算、活动与内容与社区之间各该投入多少、某个预算项是否物有所值、如何在评审中为 devrel 预算据理力争，或预算缩水时最先该削减什么时，均可使用——即使他们只是说"我们在会议上花得太多"。不适用于指标框架（samber/developer-relations-skills@devrel-metrics）或单个活动的 ROI（samber/developer-relations-skills@developer-event-sponsorship）。
从候选人角度规划、落地并推进开发者关系（DevRel）职业路径——开发者布道师、开发者传教士、DevRel 工程师、社区经理、开发者教育讲师、DX 工程师。内容涵盖：对照真实招聘信号的作品集审计、从零到可被录用的作品课程、六级 IC 阶梯、DevRel 面试采用的面试形式（演讲环节、内容与编码作业、DevRel 观点环节）、招聘贴中的守门人与陷阱模式，以及先看汇报线再看薪酬的 offer 评估。凡有人询问如何进入 DevRel、如何准备开发者布道师面试、如何打造 DevRel 作品集、如何选择方向、规划下一级台阶或权衡 DevRel offer 时使用——哪怕他们只说“这个布道师岗位我该不该接”。这不是求职工具。
在开始任何开发者关系工作之前——以及在现有 DevRel 项目的每个新会话开始时——将当前任务路由到 samber/developer-relations-skills 系列中合适的技能，或直接说明没有匹配的技能，随后引导创建或恢复项目的共享 devrel-context.md 产物。覆盖文档、开源、社区、活动、技术内容、项目策略、开发者工具业务战略、雇主品牌和度量；输出是一份路由候选清单加一条有序技能链。即使该系列的技能已在其他地方日常使用，也应在每个项目开始时运行；在每次定期 DevRel 复盘时运行；以及在任何路由不明确的情况下运行——例如 DevRel 启动、新的开发者关系项目、询问该用哪个 DevRel 技能、文档或开源技能路由，或定期的开发者项目评审——即使用户只是描述了一个 DevRel 问题而从未询问该用哪个技能。
从顶层设计公司的开发者关系项目——为其提供资金的业务驱动力、它被允许服务的两个目标、契合其阶段的支柱组合（倡导、市场营销、赋能、社区）、受众优先级、每项投入的自建与采购取舍、人员配置顺序，以及一份写明的拒绝清单。当有人询问是否要开始做 DevRel、新的 devrel 项目应首先做什么、为什么 devrel 工作很忙却没有成效、如何向高管论证该项目、下一个该投入哪个支柱、下一步该招谁，或是否应把内容、活动或社区外包时使用——即使对方从未说出“战略”一词。不适用于前 90 天计划——请使用 samber/developer-relations-skills@developer-relations-kickoff。不涉及指标、组织架构图或预算测算。
端到端规划和执行开源项目发布：名称和许可证审查、准备度门槛、定位和一句话介绍、渠道排序、发布日作战室、star 增长速度与 GitHub Trending 机制，以及发布后衡量。适用于即将发布、宣布或开源仓库，或在 "Show HN" 展示仓库；询问如何登上 GitHub Trending、如何为新库争取首批真实用户或 star、计划发布 Product Hunt 帖子或多日发布周，或询问发布为何效果不佳（即使只是说要将仓库公开）。涵盖个人开发者和公司采用。发布后的持续推广不适用——改用 samber/developer-relations-skills@oss-distribution-strategy。非 HN 网站规则——改用 samber/developer-relations-skills@hackernews-playbook。非 Product Hunt 网站规则——改用 samber/developer-relations-skills@producthunt-playbook。
判断何时委派给 genshijin 风格子 Agent 的指南：可生成 `genshijin-investigator`（定位代码）、`genshijin-builder`（编辑 1–2 个文件）或 `genshijin-reviewer`（审查 diff），而不是在当前上下文中直接处理或使用原版 `Explore`。子 Agent 输出会按 genshijin 风格压缩，使返回主上下文的工具结果减少约 60%，有助于维持长会话。触发词：“subagent 委派”“使用 genshijin-crew”“启动 investigator/builder/reviewer”“节省上下文”或“压缩 Agent 输出”。
决定是否、在哪里以及何时启动开发者社区，并规划其冷启动和前 90 天——场地选择、创始成员招募、go/no-go 标准、不建社区的更廉价替代方案以及关停标准。每当有人询问是否为用户开设 Discord、Slack 或论坛、选择哪个社区平台、如何从零启动或冷启动开发者社区、如何达到临界规模时使用——即使他们只是说"我们应该有个 Discord"。不适用于已存在的社区；衡量指标使用 samber/developer-relations-skills@developer-community-health，版主管理使用 samber/developer-relations-skills@developer-community-moderation。
实验性功能，尚未针对 Twilio 线上环境验证，而且会花费真实费用——每条消息都会计费；如果生产号码要发往美国，还需要完成 A2P 10DLC 注册（收费，且需要数周的前置时间）。在动手构建之前，先把这两点都告诉用户。尽管如此，如果某个 Caffeine 构建确实要从 canister 发送 SMS 或 MMS，或配置 Twilio 消息服务，那么使用 `twilio-client` mops 包（Twilio REST API）并由 canister 持有 HTTP Basic 凭据，是唯一受支持的路径。手写 `ic.http_request` 请求到 `api.twilio.com` 或 `messaging.twilio.com` 是被禁止的反模式——它会绕过类型化绑定、按操作划分的 host 路由、Basic 认证头的构建，以及最重要的是那个非复制的 outcall 默认设置（该设置可避免一次 `send` 变成约 13 条计费消息）。只要用户、规范或任何先前任务提到 SMS、MMS、"text message"、"send a text"、电话号码、Twilio、Messaging Service、A2P 10DLC、免费电话验证、短代码或字母数字发送方，就加载此技能——并且要在编写任何触及 Twilio 端点的代码之前加载。
建立个性化、有时间预算的开发者关系信息源观察清单——DevRel 播客、newsletter、实践中心、同行社区、大会日历、生态数据报告以及值得关注的从业者——并建立保持其经过验证和新鲜的例行机制。每当开发者倡导者、社区经理、DevRel 负责人或 OSS 维护者询问 DevRel 雷达、如何跟上开发者关系的最新进展、哪些 DevRel 播客、newsletter 或 Slack 社区值得投入时间、该参加或在哪演讲的开发者大会、DevRel 领域值得追随的人，或是刷新此前建立的雷达时使用——即使他们只是说自己跟不上了。不适用于追踪竞争厂商——使用 samber/developer-relations-skills@devrel-competitor-analysis。
判断是否以及如何投入结构化开发者教育，例如学习路径、开发者学院、实操实验室，或在此基础上增设徽章或认证阶梯，而不是继续制作零散内容；随后设计运营模式、人员配置、更新周期、衡量方式和停止规则。只要有人提到开发者学院、开发者课程体系、开发者培训、学习路径、合作伙伴或 SI 赋能培训，或希望将开发者入门培训扩展到文档之外，即适用；即使只说“我们需要更多培训内容”也适用。涵盖 B2B、合作伙伴和自下而上的推广模式。不会编写课程——使用 samber/developer-relations-skills@developer-tutorial。不要用于设计凭证本身——使用 samber/developer-relations-skills@developer-certification-program。
决定公司哪些部分开源、哪些保持专有，指出分界线两侧各自的战略动机，明确由谁做这个决定，并说明公司承诺永不关闭什么。每当有人问"我们该把这个开源吗""我们该开源什么""开放核心的分界线划在哪""哪些功能保持付费""开源这事由谁拍板"，或希望获得公司层面的开源战略而非单个项目的计划时使用——即使他们把它包装成许可问题。产出逐项资产的开放/封闭结论、价值捕获与不可逆性检查、公开的不反转承诺以及重新评估的触发条件。不用于许可选择——使用 samber/developer-relations-skills@oss-license-strategy。
Golang 重构——安全、大规模地重组现有 Go 代码：覆盖率自适应的安全网、保持行为不变的转换（gopls Rename/Extract、`gofmt -r`、`gopatch`）、映射到 Go 的 Fowler 重构目录、打破导入循环，以及小型堆叠 PR。当函数或类型过于庞大、代码异味阻碍功能开发，或用户要求重构 Go 代码时使用；也适用于大规模重命名、提取函数或接口、在包之间移动代码，或规划多步骤重构。目标风格由其他技能负责 → 参阅 `samber/cc-skills-golang@golang-naming`（重命名）、`samber/cc-skills-golang@golang-project-layout`（拆分）、`samber/cc-skills-golang@golang-modernize`（惯用法）、`samber/cc-skills-golang@golang-code-style`（控制流）、`samber/cc-skills-golang@golang-design-patterns`（模式/DI）。
基于真实 n8n 工作流总结的成熟工作流架构模式。构建新工作流、设计工作流结构、选择工作流模式、规划工作流架构，或咨询 Webhook 处理、HTTP API 集成、数据库操作、AI Agent 工作流、批处理或定时任务时使用。用户要求创建、构建或设计 n8n 工作流、自动化流程或连接服务时，始终查阅此技能，即使用户没有明确提到“模式”。涵盖 Webhook、API、数据库、AI、批处理和定时自动化架构。优化运行缓慢的工作流或加快大批量数据处理（节点数、batchSize、全部项目与逐项处理）时也使用。
构建公司的开源赞助组合：资助哪些项目和维护者、采用哪种分配模式、每项投入多少，以及如何证明有效。凡是企业、OSPO、DevRel 负责人或工程领导者询问该赞助哪些开源项目、开源资金预算多少、赞助维护者是否值得、如何运营员工提名的 FOSS 基金、如何大规模资助依赖项、如何在维护者的赞助阶梯上选择赞助档位，或如何衡量支付给维护者的资金回报时，都应使用本技能——即使他们只是说想回馈社区。不适用于维护者一方的赞助筹款，请使用 samber/developer-relations-skills@oss-sponsors-fundraising。不适用于活动赞助。
决定公司如何参与某个特定的开放标准或协议：忽略它、使用它、进行一致性认证、扩展它、向上游贡献、与同行共同创立规范，或将其推行为事实标准——以及采用何种载体（基于 Git 的规范、基金会、联盟、IETF/W3C/OASIS、ISO 转写）、何种专利许可模式、一致性方案和终止规则。当有人提及开放标准参与、协议策略、标准机构合作、标准之战、加入还是与新兴协议竞争、将规范捐赠给中立基金会、是否真的需要将某个接口标准化，或竞争对手的对立规范时使用——即使他们从未说出「标准」二字。不适用于项目治理——使用 samber/developer-relations-skills@oss-governance。
在发布窗口期之后设计开源项目的持续分发组合：注册表元数据、代码托管平台的发现入口、精选列表、下游打包、扩展与连接器市场、发布节奏、依赖图中的位置、创作者种子投放和采购信任信号——并结合维护者的真实产能进行排序。当维护者询问人们将如何持续找到该项目、应优先选择哪些注册表或 awesome 列表、为何发布后采用量停滞、为了曝光应多久发布一次，或如何把有限的维护时间投入分发时使用——即使他们只是说没人用也不适用。不适用于发布本身——使用 samber/developer-relations-skills@oss-launch。不适用于 build-in-public 实践。
决定开发者产品应否成为平台、向其他公司构建的平台开放到什么程度、以何种方式开放——扩展点、合作伙伴构建的集成、第三方应用、互补生态——以及这将对你造成何种长期约束。适用于有人询问产品是否应成为平台、是否要向第三方开放扩展点或应用模型、如何启动集成生态、为何没有人在 API 上开发、合作伙伴是否应自行构建连接器，或互补方必须保留多少价值时——即使他们只是说“我们想要一个集成故事”。不适用于市场运营或 API 设计。营收模式请使用 samber/developer-relations-skills@devtools-business-model。
撰写或审查开发者快速入门指南，让读者从零走向一次可验证的成功——最简路径、可复制粘贴的命令、每一步的预期输出、失败分支以及冷启动时间预算。适用于用户提到快速入门、入门页面、hello world 文档、“首次成功时间”或“首次价值时间”、API、SDK、命令行或可自托管工具的上手文档，或抱怨没人能完成他们的入门页面时——即使他们只是说“我们的配置太难了”。不要用于教学教程（samber/developer-relations-skills@developer-tutorial）或 README 改写（samber/developer-relations-skills@readme-optimization）。
为技术视频或屏幕录制撰写或审阅可直接开拍的脚本——包含视觉/解说双栏节拍表、30 秒开场钩子、屏幕代码节奏、章节、时长预算、无障碍解说、剪辑清单以及带单一行动号召（CTA）的 YouTube 描述。也为 2-5 分钟的动画或动态设计讲解视频制作分镜。当有人提到录屏脚本、演示或操作演示视频、视频教程脚本、YouTube Shorts、TikTok 或 Reels 脚本、动画讲解或分镜、代码讲解旁白、把博客文章、变更日志或文档页面转成视频、将字幕翻译成其他语言、添加 AI 合成配音，或询问为什么观众在第一分钟就流失时，使用此技能——即使对方只是说他们在录东西。不适用于现场舞台演示——请使用 samber/developer-relations-skills@developer-live-demo-design。不适用于视频剪辑或播客嘉宾邀请。
一个开放协议，规定了 AI 应用如何以统一方式连接外部工具与数据源。客户端负责与模型对话，MCP 服务负责提供工具、资源和提示模板，两者通过标准消息通信，同一个服务可以被不同客户端复用。