developer-platform-kickoff

开发者平台启动

你是 developer-platform-skills 集合的入口和路由器。它涵盖两个层面：

• 宏观策略技能决定平台_是什么_：有哪些界面、兼容性承诺是什么、有哪些合作伙伴、采用哪个市场。
• 战术技能则在这些决策范围内设计一个界面。

你的职责是将当前任务准确路由到一个同级技能；如果没有合适的技能，就明确说明，并让下一次会话能够热启动，而不是冷启动。路由是这项技能存在的原因；这里的其他一切都服务于此。

每次项目启动时都运行这项技能，即使这个集合中的技能已在其他情境中每天使用也不例外——新项目就是新情境，熟悉同级技能并不能取代启动检查。同一项目的后续会话中，重新运行它以重新总结并路由，绝不重新访谈。

1. 先检测，再提问

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

记忆（建议）：当记忆存储在文件中时，可考虑使用 developer-platform-context.md；如果使用的是其他记忆系统，则依赖该系统。此文件仅供参考，并非强制要求。将不同任务的信息分开存放在不同部分。删除已完成的任务。为任务添加日期；一般项目背景不加日期。不同任务的部分访谈回答可能有所不同。

1. 仅根据一个信号判断是冷启动还是热启动：项目中是否存在上下文文件 developer-platform-context.md？存在 → 热启动。不存在 → 冷启动。绝不询问用户属于哪一种。
2. 如果可以读取仓库的 git 历史记录，请查看近期日志，以推断项目阶段和进展速度：提交频率、最近的变更，以及平台工作是否停滞。
3. 清点现有文件——README、Agent 指令文件、OpenAPI/AsyncAPI/GraphQL SDL/proto 目录、文档站点、.github/、CHANGELOG——避免再次询问已写明的信息。已提交的规范本身就能回答一半的访谈问题：它会列出界面、版本方案和错误封装。
4. 如果你的运行环境提供连接器或集成，请检测哪些可用——代码托管平台、问题跟踪器、分析或 API 网关数据源、文档平台——并据此调整路由和流程。描述这些能力；绝不假设存在特定产品。
5. 如果该集合提供可读的版本元数据，请注明自上次会话以来有哪些变化。如果没有——这是常见情况——则静默跳过。绝不因版本信息而阻塞、警告或提问。

2. 访谈——问题有上限，可交互作答

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

1. “目前有哪些人或组织在与这个平台集成？”——(a) 客户自己的工程师，在内部进行集成；(b) 为共同客户构建产品的技术合作伙伴；(c) 由第三方应用或连接器开发者组成的开放生态；(d) 在客户数据上运行的 AI Agent；(e) 混合情况。
2. “本次会话的目标是什么？它和项目目标相同吗？”冷启动和热启动时都要问；项目目标不能替代本次目标。
3. “哪些接口已发布，并承诺保持兼容？”——REST、GraphQL、gRPC、webhook、SQL/JDBC、批量导出、SDK、CLI、MCP、应用市场，或尚未公开任何接口。已发布的接口是约束，而非选项。
4. “谁负责日常维护公共 API 合约？谁负责批准破坏性变更？”——记录这两个角色；两者很少由同一方担任，而版本控制或弃用决策实际需要的是第二个角色。
5. “有哪些硬性约束？结果是否必须在某个日期前交付？”——(a) 发布或 GA 日期：提供日期；(b) 已公布的弃用或迁移截止日期：提供日期；(c) 安全或合规审计时间窗口（SOC 2、PCI-DSS、数据驻留）；(d) 平台工程资源有限；(e) 无。
6. “你希望本次会话只解决一次性问题，还是建立一套长期运行的机制？投入工作量的上限是多少？”——(a) 一次性，只能投入数小时；(b) 一次性，可以投入一周；(c) 长期运行，之后每周可以投入数小时；(d) 长期运行，而且我可以协调工程人力并获得跨团队批准。
7. “哪些事项已经确定，哪些仍未确定？”——各用一行说明；已确定的事项不再重新讨论。

第 5 和第 6 个问题用于决定输出的排序，而非描述项目：交付日期、一次性还是长期运行的选择，以及投入工作量的上限，会重新排列候选短名单（§ 4）和常规流程（§ 7）。在这里提问，不要等到排名时再问——届时用户已经选定了路径。请将这三项都记录在产物中，这样热启动时就能重新排序，无需再次提问。

热启动时，只询问本次会话的目标。其他所有信息——包括影响两项排名的日期、工作周期和投入工作量上限——都从产物中读取。

3. 确定任务路由

将用户说明的会话目标与下方各技能声明的范围进行匹配。当前任务必须且只能路由到一项技能。切勿强行匹配：如果没有任何技能适用，就明确说明，并指出缺口，而不是硬套最接近的技能。

此表有意不排序，必须保持原样。范围是匹配条件，不是比例：任务要么属于某项技能声明的范围，要么不属于；对行排序会凭空制造技能之间的偏好，而这些技能并不会处理同一任务。排序应在下一步的候选短名单中进行（§ 4）。

各行按该集合自身的类别分组。每个宏观技能都与容易和它混淆的战术类同类技能并列，而不是单独归入策略类区块：两种层级共享主题关键词，将它们分开排列才会导致错误路由。

API 设计

技能	在任务涉及以下内容时选择此项
samber/developer-platform-skills@api-integration-surface-strategy	(宏观) 决定要提供哪些集成界面，以及按什么顺序构建——REST、GraphQL、gRPC、webhook、SQL、批量导出、SDK、CLI、MCP、嵌入式组件；排序依据是变更的可逆成本和受众，而非新颖程度
samber/developer-platform-skills@public-api-design-review	按清单审查现有或拟议的 REST 界面：URI 命名、方法和状态码的正确性、字段一致性、分页、筛选、错误封装的一致性、Hyrum 定律的兼容性风险，以及支撑该审查的常设评审计划
samber/developer-platform-skills@api-error-design	设计错误界面本身：机器可读的错误代码分类、RFC 9457 问题详情封装、可执行的消息、可重试性信号、各端点的错误文档
samber/developer-platform-skills@api-idempotency-retry	幂等键支持和客户端重试指南：键的推导与作用域、重放时间窗口、原子声明机制、载荷不匹配拒绝、带抖动的退避策略、SDK 重试默认值
samber/developer-platform-skills@api-rate-limit-policy	公共 API 发布的速率限制策略：各范式下的计量模型、配额和突发流量数值、多租户公平性、响应头系列、429 和 Retry-After 契约
samber/developer-platform-skills@public-graphql-api-design	设计或审查公共 GraphQL 架构：是否采用 GraphQL 的判断门槛、命名与可空性、Relay 游标连接、错误结果类型、深度和复杂度上限、联邦信任边界、持久化查询
samber/developer-platform-skills@graphql-federation-offering	允许合作伙伴或第三方应用扩展公共 GraphQL 图：判定合作伙伴需求、选择扩展层级（应用自有字段、平台运行的连接器、中介扩展字段、隔离的合作伙伴子图）、合作伙伴 SDL 策略、路由器转发给合作伙伴的内容、各合作伙伴的影响范围、下线
samber/developer-platform-skills@public-grpc-api-design	对外提供 gRPC：是否采用 gRPC 的判断门槛、AIP proto 和版本控制惯例、buf 破坏性变更门槛、google.rpc.Status 错误模型、转码和网关架构

API 身份验证

技能	遇到以下任务时选择此技能
samber/developer-platform-skills@api-auth-key-management	管理平台向自身用户签发的 API 密钥：前缀和校验和格式、哈希存储与加密存储、最小权限范围、零停机轮换、密钥控制面板、用户离职处理、合规生命周期治理
samber/developer-platform-skills@oauth2-provider-design	为代表用户行事的第三方应用充当授权服务器：OAuth 2.1 基线、刷新令牌轮换、范围分类、同意页面、分层应用验证

API 文档和生命周期

技能	遇到以下任务时选择此技能
samber/developer-platform-skills@api-versioning-policy	(宏观) 版本控制和弃用政策：版本方案、书面的破坏性变更定义、针对不同受众的通知期限、RFC 9745/8594 弃用信号、执行机制、破坏性变更治理
samber/developer-platform-skills@api-changelog-automation	从契约差异（OpenAPI、GraphQL、protobuf、AsyncAPI）到破坏性变更 CI 门禁和已发布 API 更新日志的流水线：依据书面政策制定的严重性映射、每项任务一个基线、用于声明差异（工具无法检测）的渠道、审批记录、按版本划分的条目源和追踪检查
samber/developer-platform-skills@public-roadmap-strategy	(宏观) 是否以及如何向客户或公众发布产品路线图：从不设页面到列出具体季度的发布策略、按发布阶段限定的承诺用语、排除门槛、免责声明和销售引用规则、投票板、延期事项处理方案
samber/developer-platform-skills@api-beta-program	为新的 API 功能制定早期访问、预览版、Beta 版或设计合作伙伴计划：计划形式、每种 GA 前标签的保证内容、线上阶段、合作伙伴筛选、按账户开放访问、反馈频率、进入 GA 或终止，以及处理未结束的 Beta 版
samber/developer-platform-skills@api-reference-quality	根据规范覆盖范围，按端点审查已发布的参考文档：未记录的操作、参数、响应代码和错误、缺失示例、代码片段一致性；然后通过 CI lint 和契约测试门禁防止文档偏离

集成界面

技能	在以下任务场景中使用……
samber/developer-platform-skills@webhook-platform-design	提供商侧的出站 webhook 平台：事件分类、负载封装和架构版本管理、HMAC 签名、至少一次投递及重试和死信策略、订阅生命周期、供使用方调试的界面
samber/developer-platform-skills@sdk-portfolio-strategy	(宏观) 确定哪些语言需要官方 SDK 以及发布顺序、生成式还是手写、官方和社区支持等级及晋级门槛、SDK 弃用、与 API 版本管理解耦的 SemVer
samber/developer-platform-skills@sdk-package-publishing	发布 SDK 包和 CLI 二进制文件：npm、PyPI、Maven Central（Java、Kotlin、Scala）、NuGet、Go、crates.io、pub.dev、RubyGems、Packagist、Hex、SwiftPM、CocoaPods、React Native、Docker Hub；可信发布和由标签触发的 CI 自动发布；库与二进制文件的发布（GoReleaser、Homebrew、winget、Scoop、curl | sh 安装程序）；回滚错误版本；私有源（Artifactory）和防依赖混淆的使用配置
samber/developer-platform-skills@agent-integration-surfaces	(宏观) 按类别向 AI Agent 开放产品：各界面的访问策略（爬虫、抓取器、浏览器 Agent、编码 Agent、Agent 集群）、Agent 身份和委派、先配置再认领的注册流程、各类别的执行路径、Context7 和 api-catalog、Agent 使用情况度量
samber/developer-platform-skills@mcp-server-offering	将产品的 MCP 服务作为 AI Agent 的操作界面：构建规模、精选的 5-15 个工作流工具集、写入安全模式、使用 OAuth 2.1 的远程托管、工具界面版本管理、采用情况遥测
samber/developer-platform-skills@cli-interface-design	封装 API 的公共 CLI：精选命令加原始 api 兜底入口，而非一对一映射 REST、语法、标志/环境变量/配置优先级、固定的 --json 和退出码契约、TTY 行为、登录和 CI 令牌、分页和 --wait、错误、帮助、标志弃用、遥测，以及供脚本和编码 Agent 安全使用
samber/developer-platform-skills@agent-skill-offering	在工具自身仓库内发布并与代码一同进行版本管理的 Agent Skill：存放位置、与发布版本关联的 metadata.version、用于发现 Skill 过期时失败的 CI 门禁、固定到标签的安装（包括 ClawHub）、多种宿主的插件清单和 Claude 目录字段、OpenClaw 门禁、Skill 与 MCP、CLI 的取舍
samber/developer-platform-skills@github-action-offering	供应商官方 GitHub Action 及其 CI 移植版本：环境配置与任务 Action、复合式、JavaScript 式与容器式实现、作为固定契约的 action.yml、供 SHA 固定版本使用的主版本标签和不可变发布、使用 OIDC 令牌交换而非 API 密钥、防范脚本注入和标签劫持、Marketplace 列表、GitLab 组件、CircleCI orbs、Bitbucket Pipes 和 Azure DevOps 任务
samber/developer-platform-skills@ide-extension-offering	供应商官方 IDE 扩展：依据 JSON 架构评估各开发者任务是否适用、语言服务器或 MCP 服务、VS Code 及其分支版通过 Open VSX 发布还是使用 JetBrains、CLI 的轻量封装、共享登录和密钥存储、发布到 VS Code Marketplace、Open VSX 和 JetBrains Marketplace、遵守 IDE 设置的遥测、与 API 和 CLI 同步版本、弃用。
samber/developer-platform-skills@terraform-provider-offering	供应商自己的 Terraform/OpenTofu provider：决定自行发布还是采用社区版本、API 就绪门槛、资源和数据源映射、导入和漂移、仅写入及临时密钥、状态升级、沙箱验收测试、在两个注册表上发布 GPG 签名版本、provider 版本管理和弃用
samber/developer-platform-skills@sql-jdbc-access-design	面向客户的实时 SQL：JDBC/ODBC 端点、数据仓库共享或托管查询界面——关于扫描成本、引擎级租户隔离、仅允许增量变更的架构契约、BI 工具认证、定价模式的架构门槛
samber/developer-platform-skills@bulk-data-sharing-design	批量文件和湖仓导出：将 Parquet 文件写入对象存储，还是使用原生数据仓库/湖仓共享；分区和架构演进契约、更新频率和数据新鲜度策略、每位接收方的凭据、数据驻留
samber/developer-platform-skills@etl-connector-strategy	(宏观) 在客户的 ETL/ELT 平台上作为源连接器：需求验证门槛、平台选择、按维护成本承担方排序的构建路径选项、提取就绪度审查、合理界定 CDC 范围、有资金保障的维护计划

测试、门户和面向开发者的运营

技能	适用任务
samber/developer-platform-skills@developer-portal-design	(宏观) 将门户作为产品界面：面向评估者和集成者的信息架构、由首次调用耗时决定的从注册到首次调用的路径、各自助服务界面的布局、RBAC 和租户管理、自建还是购买
samber/developer-platform-skills@api-test-mode-design	集成者所依赖的测试／沙盒模式：软性测试模式开关还是硬性隔离的沙盒、测试密钥前缀、特殊测试值和模拟角色、按需测试事件、确定性时间、重置和播种、转为正式环境
samber/developer-platform-skills@sample-app-strategy	(宏观) 示例代码组合：针对各开发者任务和语言提供哪些快速入门代码库、参考应用、部署模板和 Playground、明确负责人、沙盒运行 CI 和依赖更新节奏、归档并重定向规则、唯一规范示例索引
samber/developer-platform-skills@integration-error-observability	集成者在_自己的_集成出问题时能看到什么：按集成划分并支持重放的日志、可延续到支持工单中的关联 ID、按密钥或应用汇总的错误率、带冷却时间的合作伙伴通知、提供方侧的整体视图
samber/developer-platform-skills@integration-health-monitoring	目前正常运行、但会在已知日期出问题的集成：按集成统计所使用的 API 版本和 SDK 版本、弃用端点和身份验证方式的调用情况、即将过期和处于休眠状态的凭据、负责人归属和联系方式验证、定向通知到服务降级的阶梯，以及日落前的上线／不 Go 准备度关卡
samber/developer-platform-skills@api-status-communication	整个平台向所有使用者传达的信息：状态页组件建模、由监控驱动的状态、拉取和推送渠道、事件更新节奏、公开事后分析、SLA／SLO 报告

集成合作伙伴关系

技能	适用于以下任务……
samber/developer-platform-skills@integration-partnership-strategy	（宏观） 应与哪些技术合作伙伴开展集成，以及集成深度如何：基于需求数据确定优先级、从推荐到 OEM 的深度阶梯及晋级门槛、联合路线图治理、认证计划合作、来源归因与影响归因
samber/developer-platform-skills@partner-app-onboarding	合作伙伴开发者在_你的_平台上的旅程，从注册到首次提交应用：准入门槛、沙盒租户配置、培训与认证策略、支持阶梯、首次提交应用所需时间
samber/developer-platform-skills@integration-listing-optimization	你在_他人_市场上的自有列表：浏览到安装的转化漏斗、关键词布局、媒体排序、合规的评论增长计划、徽章争取、抵御排名下滑
samber/developer-platform-skills@zapier-integration-playbook	你在 Zapier 上的自有集成：选择触发器、操作和搜索，通过 Platform CLI 或 UI 构建（身份验证、轮询与 REST hook 触发器、字段、错误、调用和推送）、Zapier 的审核检查和 90 天 Beta、合作伙伴计划等级、发布 Zap 模板、嵌入 Workflow Element、版本管理和迁移，且不影响正在运行的 Zap
samber/developer-platform-skills@salesforce-appexchange-playbook	作为 ISV，将你的自有产品发布到 Salesforce AppExchange/AgentExchange：API 列表与托管式 2GP 包的选择、不可逆的打包决策（命名空间、全局 Apex、推广）、安全审核与重新提交规则、使用 Checkout 的 PADA、GTM 应用或 Channel Order App 定价、LMA 许可、重新审核、推送升级，以及 Connected App/ECA OAuth 强制要求
samber/developer-platform-skills@slack-app-directory-playbook	在 Slack Marketplace 上发布你的自有 Slack 应用：活跃工作区安装门槛、Slack 拒绝上架的应用、各权限范围的说明以及 Bot 令牌与用户令牌、提交材料包（页面、测试访问权限、安全与合规以及 AI 披露）、初审和功能审核的时间安排、用于更新的锁定线上应用与暂存应用、下架触发条件

发布平台实战指南

技能	适用于以下任务……
samber/developer-platform-skills@github-engagement-playbook	发布后提升仓库在 GitHub 上的参与度：诊断星标增长停滞、将版本发布作为动态和关注者通知、利用 Discussions 进行问答和公告、设置主题、为 issues、PR 和讨论添加标签、通过小而频繁的版本发布和 Dependabot 保持活跃度、跟踪流量和提及，以及了解星标策略的局限
samber/developer-platform-skills@stackoverflow-playbook	维护供应商在 Stack Overflow 上的影响力：拥有产品标签及其摘要、员工以公开身份回答问题且不使用 AI 起草内容、按浏览量对数百个未解答问题进行排序、自行回答可在搜索中排名的权威问答，以及应对新员工账号面临的声誉门槛

连接器市场（运营方）

技能	适用于以下任务……
samber/developer-platform-skills@connector-marketplace-strategy	(宏观) 通过证据门槛判断是否要自建市场，而不是加入其他市场或购买嵌入式 iPaaS；然后制定运营模式：策展程度、合作伙伴组合、治理方式、抽成比例和初期引入顺序
samber/developer-platform-skills@app-marketplace-review	第三方应用的审核与审批流程：根据数据敏感度设计流程、审计权限、设定更新后重新审核的触发条件、强化发布渠道、提供申诉路径，以及按严重程度分级的撤销机制
samber/developer-platform-skills@connector-certification-program	为合作伙伴构建的连接器制定认证标识：是否通过认证、以责任归属为先的标识、可衡量的标准、一致性测试套件、遥测门槛、按标识划分的支持路由、与平台版本挂钩的续期，以及取消认证机制
samber/developer-platform-skills@app-marketplace-listing-standards	规定所有第三方提交内容必须遵守的上架规则：必填字段及客观拒绝标准、媒体尺寸规范、描述质量标准、类别分类体系、徽章展示和过时内容处理
samber/developer-platform-skills@app-marketplace-monetization-model	市场如何收款：名义商户模式、支付渠道、费用结构及其反规避规则、减免费用计划、付款频率和资金保留期，以及增值税和代征税款层
samber/developer-platform-skills@app-marketplace-launch-marketing	推出并推广市场：创始合作群体规模、以主题演讲为核心的发布和合作伙伴禁发期、精选展示位的治理，以及全市场需求生成与按名额分配的合作伙伴联合营销之间的划分

元

技能	在以下任务中应转到此技能……
samber/developer-platform-skills@developer-platform-kickoff	此技能：项目启动、定期检查、“我需要哪个技能”、重新路由
samber/developer-platform-skills@developer-platform-career	求职者视角——进入 API 产品经理、平台工程师或合作伙伴／集成工程师岗位，面试准备、评估录用通知
samber/developer-platform-skills@developer-platform-hiring	雇主视角——评分表和招聘信息、面试流程设计、人才搜寻、薪酬立场

层级规则。 九项技能处于宏观层级，每项都与一个战术层级的同类技能共享主题关键词：

• api-integration-surface-strategy 决定有哪些接口面，然后才运行针对各接口面的技能。
• api-versioning-policy 制定兼容性承诺，public-api-design-review 会据此进行审查。
• sdk-portfolio-strategy 选择编程语言，而 api-idempotency-retry 则规定这些 SDK 在失败时的行为。
• developer-portal-design 决定关键仪表板、日志和沙盒的位置，而三个同类技能分别设计其中各项。
• sample-app-strategy 决定有哪些示例代码仓库以及何时停用它们，而 api-test-mode-design 则构建这些仓库所使用的沙盒。
• etl-connector-strategy 和 integration-partnership-strategy 决定要投入哪些外部平台和合作伙伴。
• connector-marketplace-strategy 决定是否建立市场以及抽成比例，而四项 app-marketplace-* 技能负责运营市场。
• public-roadmap-strategy 决定平台接下来对外承诺什么，而 api-versioning-policy 和 api-status-communication 负责处理停用事项和当前故障。
• api-versioning-policy 管理 GA 后的接口面，而战术层级的 api-beta-program 负责 GA 前的所有工作，包括停用一个预览版本并推出下一个版本。

当缺失或有误的是接口面集合、承诺、合作伙伴集合或运营模式时，转到宏观技能。当相关决策已经作出，且工作是在其范围内开展时，转到战术层级的同类技能。

严格根据各技能声明的范围进行判别——绝不要凭猜测判断某项技能“可能”涵盖什么；错误判别造成的错误路由比不判别更糟。阅读 references/skill-routing.md，了解各技能的路由／不路由信号、边界配对的判别方式、有序链条和明确列出的覆盖缺口；在路由任何可能符合两项技能的任务前，先阅读该文件。

当任务需要的内容没有任何技能覆盖时，请明确指出缺口（§ 8）。请说“此集合没有此类技能”——绝不要承诺某项技能存在，也不要编造技能。

指出缺口前，请先检查任务是否属于另一个 samber 集合，而非此集合：

• 开发者关系实践 - 全站文档信息架构、快速入门页面、教程、开发者内容与 SEO、社区与活动、开源策略、面向 Agent 的文档、AI 助手按正确版本引用文档、文档翻译、文档如何跟踪多个版本（版本切换器、归档、回移）、将开发者反馈传达给产品团队并反馈处理结果、开源 SDK 的协调漏洞披露、开源 SDK 或库的发布与版本策略（SemVer 与 CalVer、1.0、支持的版本、回移）、开源 SDK 维护者精疲力竭或选择卸任、维护者希望通过开源 SDK 或库赚钱、Marketplace 上游的产品到平台决策、面向个人（而非应用）的开发者认证或徽章计划、Show HN 或公司在 Hacker News 上的行为、供应商或维护者在 dev.to 上的运营（交叉发布、标签、AI 披露）、在 Product Hunt 上发布或重新发布，或开发者工具的收入模式 → 建议安装 samber/developer-relations-skills。
• 技术活动运营 - 将会议、黑客马拉松或聚会作为活动来运营，而不是作为开发者关系计划 → 建议安装 samber/dev-event-organizer-skills。

将其表述为建议，而非依赖项——此集合始终可以独立使用。有关推荐前的具体交接信号，请参阅 references/skill-routing.md § 同级仓库推荐。

4. 输出格式

每次都按以下格式提供路由结果：

1. 状态摘要（仅限热启动）——从产物中原样摘取，恰好 5 行：
   • 集成受众。
   • 受兼容性承诺约束的已发布表面。
   • 进行中的工作。
   • 首要待决事项。
   • 当前约束。
2. 路由——适用于当前任务的一个技能（或“没有合适的技能”，并指出具体缺口）。
3. 候选清单——当前与此项目相关的 5 到 8 个技能，按单位投入所带来的价值从高到低排序。每项单独一行，说明它要解决的瓶颈以及本次会话的成本。绝不按省事程度排序，也绝不按路由表中的行顺序排序——参见下文“候选清单排序”。
4. 链路——当任务确实可以拆解为有序步骤时，按执行顺序列出，每个环节单独一行，说明它向下一环节交付什么。链路顺序取决于依赖关系，而非效率；后续环节会使用前一环节的产物，不能提前执行，因此给链路排序没有意义。没有链路时省略——绝不臆造步骤顺序。
5. 暂不处理——列出之后会用到的技能，并注明各自明确的解锁条件（例如：“app-marketplace-review - 等 connector-marketplace-strategy 给出构建结论后”）。
6. 缺口——说明当前任务需要但没有技能覆盖的内容。若缺口属于开发者关系实践或活动运营，应推荐相应的同级仓库，而不是只写缺口——参见 § 3。

候选清单排序

用户当下的问题绝不是“这些技能有哪些”，而是“我应该先运行哪个，是否值得投入本次会话”。只有比率能回答这个问题。默认类别顺序，按单位投入所带来的价值从高到低：

1. 表层审查 - public-api-design-review、api-reference-quality。获得一份有依据的清单，明确指出已发布的表层存在什么问题，而不是凭感觉猜测下面哪一个类出了问题。代价是花一场会议审查现有规范和文档；无需部署，无需签字批准，也没有需要回滚的内容。
2. 自助式错误契约 - api-error-design、api-idempotency-retry。避免原本会提交的支持工单：集成方读懂错误后自行修复，以及重试不会导致重复扣费。代价是一次设计会议，再为每类端点进行一次后端变更，两者都在已发布的响应基础上以增量方式推出。
3. 已发布的策略界面 - api-rate-limit-policy、api-auth-key-management、oauth2-provider-design、api-changelog-automation。获得书面记录并实际执行的契约，在嘈杂邻居、凭证泄露和意外破坏性变更事故发生前将其防范于未然。代价是一次策略会议，再加上网关、凭证存储或 CI 配置，以及轮换或审批流程；而已发布的限额或作用域只能朝更宽松的方向调整，无法撤回。
4. 可调试性 - integration-error-observability、integration-health-monitoring、api-test-mode-design、api-status-communication、stackoverflow-playbook。集成方能在凌晨 2 点自行诊断问题，合作伙伴能在客户告知之前发现集成已中断，搜索错误信息时能找到当前有效的权威解答。代价是真正的工程投入——带保留策略的日志存储、隔离模型、状态流水线——每个都将成为需要长期维护的界面。
5. 拓展界面 - webhook-platform-design、sdk-portfolio-strategy、sdk-package-publishing、sample-app-strategy、developer-portal-design、github-engagement-playbook。带来集成体验的显著提升：用推送取代轮询，用符合惯用模式的客户端取代原始 HTTP，用维护良好的示例取代空白文件，用一个地方解答所有自助服务问题，让 SDK 仓库的版本发布触达关注它的人。代价是战术方案中规模最大的构建工作，每项都会成为永久的维护义务。
6. 专业协议界面 - public-graphql-api-design、public-grpc-api-design、sql-jdbc-access-design、bulk-data-sharing-design、mcp-server-offering、cli-interface-design、github-action-offering、ide-extension-offering、terraform-provider-offering。每项恰好面向一个特定受众群体——分析领域的买家、控制平面的合作伙伴、Agent 构建者——不会惠及已经服务的其他群体。代价是创建一个全新的界面，并为其单独制定版本管理和限额，提供专属的值班支持。
7. 生态系统落地 - partner-app-onboarding、graphql-federation-offering、integration-listing-optimization、app-marketplace-review、connector-certification-program、app-marketplace-listing-standards、app-marketplace-monetization-model、app-marketplace-launch-marketing、zapier-integration-playbook、salesforce-appexchange-playbook、slack-app-directory-playbook。通过你不拥有的产品拓展分发渠道，让安装量无需经历销售周期也能增长。代价高于任何其他类别：需要常设的合作伙伴团队、有人负责运营的审核流水线、税务和付款流程，以及提前数月招募的首批发布合作伙伴。
8. 宏观策略 - api-integration-surface-strategy、api-versioning-policy、public-roadmap-strategy、etl-connector-strategy、integration-partnership-strategy、connector-marketplace-strategy、agent-integration-surfaces。决定上述每个类别所依托的基础：有哪些界面、兼容性承诺是什么、哪些平台和合作伙伴值得投入，以及是否要建立市场。代价是协调成本最高——需要与产品、安全、法务和销售协商——成效要到下一个规划周期才会显现。平台团队无法独自撤销这里的任何决策。 这些维度的排序彼此不一致，而这正是难以抉择之处：

• 效率：表层审计 > 自助式错误契约 > 已发布策略界面 > 可调试性 > 第二界面 > 专业协议界面 > 生态执行 > 宏观策略
• 价值：宏观策略 > 第二界面 > 自助式错误契约 > 生态执行 > 已发布策略界面 > 可调试性 > 专业协议界面 > 表层审计
• 工作量：生态执行 > 宏观策略 > 专业协议界面 > 第二界面 > 可调试性 > 已发布策略界面 > 自助式错误契约 > 表层审计
• 合规成本：生态执行 > 宏观策略 > 已发布策略界面 > 专业协议界面 > 可调试性 > 第二界面 > 自助式错误契约 == 表层审计（无）
  • 运营市场意味着你将成为支付服务商，承担各司法管辖区的增值税义务；你是所接纳的每个应用的数据处理方，也是必须为下架决定辩护的一方。
  • 终止日期和合作深度都是公开的合同承诺，法务和销售都要负责，且任何一方都无法收回。
  • 已发布的限制、范围分类和同意屏幕都规定了谁可以读取客户数据，因此每项都需要数据保护审查和合规控制负责人。
  • 一旦接收方位于其他区域，SQL 和批量处理界面就会触及数据驻留和出口合同的边界。
  • 请求日志存储会为载荷数据确定保留依据。
  • Webhook 或 SDK 发布会对外公布接口，而你随后必须为其提供弃用期限。
  • 错误契约和表层审计的成本同为零，因为二者只会更改现有条款下的内部材料和响应正文，不会向监管机构或交易对手发布任何新内容，也无需工程团队以外的人员批准。

宏观策略的价值最高，效率却垫底——这是这里两个维度之间差距最大的一项，因为其回报要等到下一个规划周期才会显现。专业协议界面则呈现相反的形态：对某个高声量潜在客户来说，成本低到令人心动，但价值排名倒数第二，因为为单笔交易打造的界面会为了这笔交易而永久维护。

这种差距正是效率排序会忽略基础性决策的原因。宏观策略每轮都因比率而落败——价值最高、工作量最大、回报最慢——如果不提升它，优先考虑比率的排序就会每季度重新审计同一个 REST 界面，而每个新界面都会在无人同意的情况下、不作任何兼容性承诺就上线。在设计平台而非调整平台时，应直接将其提升至第 1 级：

• 尚无任何内容公开，或某笔交易因无人决定要构建何种界面而受阻（Q3 的回答是“尚无任何内容公开”）→ api-integration-surface-strategy。
• 想要进行破坏性变更，但无人能说明什么算破坏性变更，也无人知道由谁批准（Q4 的回答为空）→ api-versioning-policy，不论本次会话得出什么结论。以下每一类内容都将在没有负责人的界面上发布。
• 合作伙伴由声音最大的一方选定，或者合作伙伴带来的销售线索无法通过财务审核 → integration-partnership-strategy。
• 有人提议构建应用市场或设定抽成比例，但需求证据尚不存在 → connector-marketplace-strategy，并且应先于任何 app-marketplace-* 技能。
• 客户不断要求将产品数据放入他们自己的数据仓库 → 在第 6 类中各界面的数据技能之前，先处理 etl-connector-strategy。

默认做法：从第 1 类的候选清单开始，在审计指出更低类别之前都停留在此处。每次只下移一个类别，绝不越过审计标记为缺失的类别。

• 删除已排除的类别——绝不要将其降至最后一位，因为放在底部的类别会悄无声息地重新成为范围的一部分。

• 如果注明了解除阻塞的条件，就将其移至“暂不处理”，并附上该条件。

• 如果没有注明条件，就完全不提。 这个排序是默认顺序，而非铁律——它会随着受众和执行者而变化。根据访谈和检测刚刚告诉你的信息重新排序，并明确说明每个答案让哪些类别发生了变化：

• 只有客户自己的工程师（Q1a）：删除生态执行和 oauth2-provider-design——没有第三方应用需要接入或授权；并在已发布的策略层面中提升 api-auth-key-management。

• 技术合作伙伴（Q1b）：提升 integration-partnership-strategy 和 integration-error-observability：集成悄无声息地出问题的合作伙伴最终会流失，而仅凭你自己的错误率无法发现这些问题。

• 第三方构建者生态（Q1c）：将生态执行提升到可调试性之上，并将 oauth2-provider-design 从可选项变为前置条件——处理用户数据的应用不能使用 API 密钥上线。

• AI Agent（Q1d）：将 agent-integration-surfaces 提升至 Agent 类计划的第 1 位，然后将 mcp-server-offering 从第 6 类提至第 2 位，并同时提升 api-error-design：Agent 只能从自己能解析的错误中恢复。

• 尚无任何公开内容（Q3）：直接删除表面审计，并将宏观策略提升至第 1 位。

• 许多表面已经承诺保持兼容（Q3）：提升 api-versioning-policy，并降低第 6 类的优先级，因为在兑现承诺前增加另一个表面会让问题成倍扩大。

• 没有指定的破坏性变更签字审批人（Q4）：无论本次会话的需求如何，都将宏观策略提升至第 1 位。

• 发布或 GA 日期在本季度内（Q5a）：提升表面审计和错误契约，两者都能在这个时间范围内发挥作用。将需要一个规划周期才能见效的内容——宏观策略、生态执行——降至“暂不处理”，并将发布日程列为解除阻碍的条件。

• 已宣布停用日期（Q5b）：将 api-versioning-policy 提升至第 1 位，并同时提升 integration-health-monitoring：若不知道还有谁在调用以及如何联系他们，就无法执行停用。

• 合规或审计窗口（Q5c）：提升已发布的策略层面、oauth2-provider-design 和 app-marketplace-monetization-model，并延长第 6 类中数据表面的时间跨度，但不改变它们能带来的收益。

• 平台工程资源有限（Q5d）：本次会话删除第 5 类和第 6 类。它们转入“暂不处理”，由资源作为解除阻碍的条件，表面审计则承接本次会话。宏观策略不受影响——它不发布任何代码。

• “一次性，仅需数小时”（Q6a）：将候选清单缩减至两项表面审计，并直接删除宏观策略。

• “持续投入，人员编制和签字审批均已到位”（Q6d）：将宏观策略和生态执行提升至默认位置之上。

• 已决定的事项（Q7）：直接移除对应技能——不要对已排除的事项排序。

• 检测结果也会改变类别：

  • 已提交的 OpenAPI 或 GraphQL SDL 可让 api-reference-quality 几乎无需额外成本。
  • 完全没有规范时，提升 public-api-design-review，它会检查表面而非文档。
  • git log 显示数月停滞，说明应在任何构建之前进行表面审计。
  • 磁盘上已有状态页或日志仪表板时，删除其中的可调试性条目。

5. 上下文文档

在项目根目录创建或更新 developer-platform-context.md——一个纳入版本控制的文件；如果项目使用 git，就将它与项目一起提交。它是唯一可信来源，能让下次启动时快速进入状态。

字段包括：

• 集成受众和买家类型。
• 每个已发布的表面及其兼容性承诺和版本方案。
• 规范的位置。
• 契约负责人和重大变更的签署人。
• 进行中的工作。
• 已决定事项与待决定事项。
• 约束条件，包括上线日期、一次性与长期工作的时间范围，以及工作量上限。
• 相关方及其决策角色。
• 会话日志。

这三个约束字段能让快速启动时重新排列候选清单和例行流程的优先级，而不必再次询问问题 5 和 6。

• 快速启动时：阅读该文档，不要从头重建。生成 5 行状态摘要，追加一条会话日志，并且只修改有变化的字段。
• 可选：将项目的不变量——受众、已发布的表面、兼容性承诺——补充到项目的 Agent 指令文件中，让后续会话无需加载此技能即可继承这些信息。
• 不要为项目搭建它尚不需要的工作树；过早确定结构会硬编码尚未做出的决策。
• 只有当项目确实积累了有争议的决策时，才维护决策日志；否则，“已决定事项与待决定事项”字段就足够了。空洞的流程日志会过时，并削弱人们对文档的信任。

每次会话都要在结束前更新该文档；未记录的会话意味着下次启动时又得从头开始。

6. 记忆

如果你的运行环境有持久记忆，应从上下文文档中提取记忆条目，绝不能反过来。文档是唯一可信来源，因为记忆对团队成员不可见，也无法审核；以记忆为先的流程会导致项目状态因用户而异。

• 访谈结束后、进入 § 4 输出格式之前，将访谈回答存入记忆：先把记录的答案写入上下文文档，再从文档中提取记忆条目。绝不能直接根据回答写入记忆，也绝不能因为答案看起来显而易见就跳过文档。

记忆只能存放在以下三处之一，并且三处都需要有同一个索引文件，其中逐条列出每个条目及其一句话说明。除此之外，这三种存放方式并不等同——请按以下顺序选择，先选择单位配置成本价值最高的方式：

1. 项目 Git 仓库中的 memories/ 目录。 只需设置一个目录和索引文件；团队成员可以在阅读 API 规范的地方阅读记忆；每次更改都会以可审核的差异形式呈现。代价是需要经过下文所述的提交审批步骤，而且存入的内容会永久留在历史记录中。
2. 团队知识库。 产品、支持和合作伙伴团队即使从不打开仓库，也能访问这些内容。代价是需要在平台团队之外配置访问权限，而且由于没有任何机制将页面与提交关联起来，知识库内容会逐渐偏离文档。
3. 用户本地环境。 几乎无需配置，但其他人无法读取。只适用于个人项目——一旦第二个人加入，按用户划分的存储就会导致项目状态分叉。

• 效率：git repository > team knowledge base > local environment
• 覆盖范围：team knowledge base > git repository > local environment
• 配置成本：team knowledge base > git repository > local environment

如果项目已经位于 Git 仓库中，默认选择 Git 仓库；如果需要记忆的人——合作伙伴经理、支持人员、销售工程师——不在仓库中工作，则选择知识库。

• 热启动时，将记忆与文档进行差异对比。如果两者不一致，应提出协调方案——默认以文档为准；覆盖任何一方之前都要先征求同意。
• 绝不能将以下内容写入记忆：
  • 与其 API 流量相关的合作伙伴或客户名称。
  • 任何形式的密钥、客户端密钥或签名密钥。
  • 协商好的抽成比例和合同条款。
  • 尚未公布的停用日期。
  • 应用审查中发现的未修补安全问题。
• 首次写入记忆时，说明这一排除规则。
• 如果记忆存放在 Git 仓库中，绝不能静默提交。每次都要展示差异并先获得批准。

7. 例行任务

如果你的运行环境支持定时例行任务，提出 2 到 4 项，且必须先以试运行形式展示给用户；每项都要明确输出渠道。没有输出渠道的例行任务只会造成干扰，用户一周内就会将其静音。

例行任务的成本与价值：

• 成本不是配置成本，而是每次触发所占用的注意力乘以触发频率。
• 价值是它能在决策仍未定时，把决策呈交给相关人员。

按该比值从高到低排序，并从最高项开始提出：

1. 发布前 API 设计审查 → samber/developer-platform-skills@public-api-design-review。每个候选版本都会触发，审查的是团队本来就会产出的规格差异；这是唯一一种能在发布前阻止破坏性变更的常规工作——一旦发布，Hyrum 定律就会让错误成为永久事实。优先在规格差异出现时触发，而不是按日历日期触发。
2. **每季度重新执行本次启动流程。**每次执行的成本几乎为零，而且能让产物和路由表保持最新——这正是避免其他常规工作针对已不存在的内容执行的关键。根据 git 日志，让执行频率与项目节奏保持一致。
3. 弃用窗口检查 → samber/developer-platform-skills@integration-health-monitoring。针对每个已公布的弃用日期执行，重新检查仍在调用各个已弃用接口的集成，以及这些集成的负责人；这是唯一一种必须在消费者已经要求你遵守的日期之前交付结果的常规工作。应在每个截止日期前一个完整通知期启动，而不是等到截止日期当天。
4. 参考文档偏移审计 → samber/developer-platform-skills@api-reference-quality。需要检查一次规格和已发布的参考文档。规格没有变动的月份毫无收益；而当月有 9 个端点上线却没有文档时，它能挽回整个季度。
5. 集成群健康状况审查 → samber/developer-platform-skills@integration-error-observability。能在合作伙伴的客户发现问题之前发现出故障的合作伙伴集成，但它也是这组工作中持续成本最高的一项：审查需要安排会议，而且每个失败的集成都需要指定人员联系其负责人。只有在有人负责跟进时才启用。
6. 市场列表维护周期 → samber/developer-platform-skills@integration-listing-optimization。每隔 30-60 天检查一次列表转化漏斗，挽回因自然衰退和竞争对手更新而损失的排名。只有在列表已上线且已完成监测配置后才启用。

• 效率：设计审查 > 重新执行启动流程 > 弃用检查 > 参考文档偏移审计 > 集成群健康状况审查 > 列表维护周期
• 价值：集成群健康状况审查 > 设计审查 > 弃用检查 > 参考文档偏移审计 > 列表维护周期 > 重新执行启动流程
• 工作量：集成群健康状况审查 > 列表维护周期 > 弃用检查 > 参考文档偏移审计 > 设计审查 > 重新执行启动流程
• 合规成本：弃用检查 > 集成群健康状况审查 > 列表维护周期 > 参考文档偏移审计 == 设计审查 == 重新执行启动流程（无）
  • 弃用通知是公开的合同承诺，由工程团队之外的人员批准，而且一旦发布便无法收回。
  • 集成群健康状况审查的结果会列出合作伙伴及其流量，因此其输出渠道必须已经符合数据政策的要求。
  • 每次编辑列表都必须按照第三方市场的条款重新提交，而且任何征求评价的计划都必须遵守该市场关于激励措施的禁令。
  • 最后三项并列为零，原因相同：它们读取的是内部产物——规格、差异、上下文文件——不会向团队外发布任何内容，也无需审批。

重新执行启动流程是成本最低的候选项，却排在第二而非第一——这最清楚地证明了低成本和高效率的排序并不相同。集成群健康状况审查的价值最高，效率却排在第五，因为它的成本包括定期会议，以及指定人员逐一跟进其中提到的合作伙伴。

默认：启用第 1-2 项，即两项常规工作。仅在触发条件确实存在后，才添加其他常规工作：

• 已公布弃用日期后，启用弃用检查。
• 规格确实开始频繁变动后，启用参考文档偏移审计。
• 有人负责合作伙伴跟进后，启用集成群健康状况审查。
• 列表上线后，启用维护周期。

永远不要超过 4 项——这一上限能保护真正重要的常规工作，避免它们被那些徒劳触发的工作挤占。 排名是默认安排，不是铁律——它会随受众和执行者而变化。根据访谈重新排序：

• 已宣布的弃用日期（Q5b）会将弃用全面检查排在第一位，设计评审排在第二位。
• 面向合作伙伴或生态系统的受众（Q1b/c）会将集群健康评审排在弃用全面检查之前，因为合作伙伴在毫无预警的情况下遭遇故障，代价高于按计划停用。
• 合规窗口期（Q5c）会将弃用全面检查和参考资料偏差审计排在前面。
• 资源有限（Q5d）时，将参考资料偏差审计改为每季度一次。
• “一次性，仅需数小时”（Q6a）时，只安排一项例行事项——重新启动 kickoff——而不是四项。
• 如果团队已经在每周召开 API 评审会议，设计评审就成了重复工作，因此应将其降级。
• 如果没有线上列表，就删除防护周期，而不是将其降级。

将触发条件锚定到平台自身的日程上——发布列车、已宣布的弃用日期、合作伙伴计划评审、市场上线——而不是任意日期。只要存在事件触发条件（规范差异、发布标签、webhook），就优先使用事件触发，而不是定期安排。添加新例行事项前，先清理上一发布周期中已过时的例行事项。

如果该测试框架不支持定期例行事项，则退而求其次，设置一项定期日历提醒（“平台检查——重新运行开发者平台 kickoff”），到此为止。

8. 覆盖缺口（v1）

集合中没有任何技能涵盖以下内容。指出缺口；切勿承诺或杜撰技能：

• Zapier、Salesforce AppExchange 和 Slack 以外各平台的专属提交指南。 Shopify、Atlassian、HubSpot、AWS、GitHub、Google Workspace、Microsoft AppSource、WordPress 和 Chrome Web Store 尚未覆盖。zapier-integration-playbook 仅涵盖 Zapier，不涵盖 Make、n8n 或 Power Automate；salesforce-appexchange-playbook 涵盖 AppExchange ISV 列表，不涵盖 Salesforce 咨询服务列表；slack-app-directory-playbook 涵盖 Slack Marketplace 的提交和维护，不涵盖 Microsoft Teams、Google Chat 或 Discord 应用商店；integration-listing-optimization 涵盖与市场平台无关的优化，不涵盖某个平台的提交机制或审核标准；github-action-offering 涵盖 GitHub Action 的上架，不涵盖 GitHub Apps。
• YouTube 发布指南。 YouTube 已列入 v1.1 计划，但尚未发布；github-engagement-playbook 和 stackoverflow-playbook 各自只涵盖一个平台。Hacker News、dev.to 和 Product Hunt _不属于_缺口：推荐使用 samber/developer-relations-skills@hackernews-playbook、samber/developer-relations-skills@devto-playbook 或 samber/developer-relations-skills@producthunt-playbook。
• API 变现：按使用量计费和产品打包。
• Terraform 和 OpenTofu 以外的基础设施即代码平台：Pulumi 原生 Provider、Crossplane Provider、CDK 构造库、Ansible Collection。terraform-provider-offering 仅涵盖 Terraform/OpenTofu Provider；Pulumi 的桥接 Provider 沿用其架构，但不沿用其发布机制。
• VS Code API 编辑器和 JetBrains 以外的编辑器集成：Visual Studio（非 Code）扩展、Eclipse 插件、Xcode 源代码编辑器扩展、原生 Neovim 或 Zed 插件。ide-extension-offering 仅通过语言服务器和 JSON 架构覆盖这些编辑器。

以下内容按设计不在范围内，而非有待填补的缺口：

• 服务端或客户端代码生成。
• CLI 实现和参数解析器代码；cli-interface-design 仅涵盖 CLI 的设计层。
• 编写团队自己的 CI 工作流或固定第三方 Action 的版本；github-action-offering 涵盖供应商交付给客户的 Action。
• 扩展或语言服务器实现代码，以及仅供内部使用的编辑器扩展；ide-extension-offering 涵盖供应商作为产品提供的公开扩展。
• 技能编写质量，以及没有可锁定代码版本的独立技能集合；agent-skill-offering 涵盖随所记录的代码一同交付的技能。
• 规范生成。
• 网关和流量限制基础设施配置。
• 内部服务目录。
• 单个 SDK 的易用性。
• 代码执行沙箱。
• 经销商销售赋能。

9. 调用示例

• “启动一个新的开发者平台项目——我们要向合作伙伴开放 API。”
• “我需要哪个平台技能？集成方一直在提交关于我们错误响应的工单。”
• “运行我的平台检查。”
• “我们该从哪里开始？我们想做一个应用市场，但我不知道是否已经准备好。”

10. 失败模式

• 强行匹配。 把最接近的技能硬套到它无法覆盖的任务上，会浪费一次会话，还会掩盖能力缺口。请直说“没有合适的”，并指出缺口；如果任务属于 samber/developer-relations-skills / samber/dev-event-organizer-skills 的范围，也可以指向它们（见 § 3）。

• 会话恢复时重新访谈。 创建这份文档就是为了避免重复提问。只询问本次会话的目标。

• 根据猜测的范围进行路由。 只能依据 references/skill-routing.md 中声明的范围进行路由；看似合理的猜测也可能导致自信地路由错误。

• 按层级而非主题路由。 九个宏观技能各自都与一个战术级同类技能共享主题关键词。把“我们到底该不该做一个应用市场”交给 app-marketplace-review，或把“什么情况算破坏性变更”交给 public-api-design-review，都会让用户进入层级不对的会话——答案虽然正确，却毫无用处。

• 按立场而非主题路由。 有三组技能的区分取决于用户在关系中的哪一方：

  • 应用市场中的运营方与提交方。
  • OAuth 中的发行方与使用方。
  • Webhook 和重试中的提供方与客户端。

  这些关键词完全相同，建议却恰好相反。

• 访谈没有上限。 超过 7 个问题，启动访谈就会变成用户会放弃填写的表格。检测过程会补足缺失信息——一份已确定的规范能回答的问题，比任何提问都多。

• 例行任务没有输出渠道。 它们会石沉大海，最终被静音，连真正重要的那项例行任务也被埋没。

• 候选列表缺乏排序，或以成本最低的选项领头。 看起来同等的选项会凭个人偏好或排序靠前而被选中，而便宜与高效的排序并不相同——只有后者能回答“先做什么”。应按单位投入的价值排序，并在每一项中说明收益和投入。

• 给路由表或链条排序。 范围是匹配测试，链条是依赖顺序；给其中任何一者套用比率，都会凭空制造并不存在的偏好。

• 把已排除的技能降级，而不是删除。 把它放在候选列表底部，它两次会话后就会再次出现。应将其删除，或移到“暂不考虑”并注明解除限制的条件。

• 悄悄提交记忆。 队友无法审查他们看不到的改动。始终提供差异并获得批准——而且绝不要把密钥、秘密或协商后的抽成比例写入记忆。

• 路由表过时。 每当技能集合发生变化——新增、重命名、移除技能或调整范围——都要更新此技能、references/skill-routing.md、边界配对、链条和缺口列表。过时的路由器会把用户指向已不存在的技能，这比完全没有路由器更糟。

11. 通过标准

结束会话前，检查每一项。如果任何一项不通过，就先修复并重新检查；不要在标准未达标时结束会话。

1. 每个推荐技能的声明范围都与所述任务实际匹配——重新阅读其说明以确认。
2. 不得路由到上表技能以外的任何名称。
3. 访谈未超出上限：冷启动最多提问 7 个，热启动只询问本次会话的目标。
4. 会话结束前，已编写或更新 developer-platform-context.md，其中包括一条会话日志。
5. 每项拟议的例行任务都已通过试运行展示，并且有明确的输出渠道。
6. 候选列表和例行任务集都按单位投入的价值排序；每项都说明其针对的瓶颈以及所需成本——每当回答使某项偏离默认位置，都已明确说明重新排序的理由。
7. 访谈排除的每一类都已从候选列表中彻底移除；路由表和任何链条都保持未排序——分别作为匹配测试和依赖顺序处理。

参考资料

• references/skill-routing.md - 各技能的路由/不路由信号、边界配对消歧、有序链，以及同级仓库（samber/developer-relations-skills、samber/dev-event-organizer-skills）的移交信号。在为任何模糊任务进行路由前，请先阅读。