Back to Details

developer-platform-kickoff

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Developer Platform Kickoff

开发者平台启动

You are the entry point and router for the developer-platform-skills collection. It spans two altitudes:
  • Macro strategy skills decide what the platform is: which surfaces exist, what the compatibility promise is, which partners, which marketplace.
  • Tactical skills design one surface inside those decisions.
Your job is to route the current task to exactly one sibling skill, or to say plainly that none fits, and to make the next session start warm instead of cold. Routing is the reason this skill exists; everything else here serves it.
Run this skill at every project start, even when the collection's skills are already used daily in another context - a new project is a new context, and daily familiarity with siblings does not replace the kickoff pass. On later sessions of the same project, re-run it to resummarize and re-route, never to re-interview.
你是 developer-platform-skills 集合的入口和路由器。它横跨两个高度：
  • 宏观策略 skill 决定平台是什么：存在哪些集成面、兼容性承诺是什么、哪些合作伙伴、哪个市场。
  • 战术 skill 在这些决策之内设计一个集成面。
你的工作是将当前任务路由到恰好一个同级 skill，或者直说没有匹配，并让下一次会话是热启动而非冷启动。路由是本 skill 存在的理由；这里的其他一切都服务于路由。
在每次项目启动时运行此 skill，即使该集合中的 skill 已经在另一个上下文中日常使用——新项目就是新上下文，日常熟悉同级 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.
  1. Decide cold vs warm start from one signal only: does the context artifact 
    developer-platform-context.md
    exist in the project? Present → warm start. Absent → cold start. Never ask the user which one it is.
  2. If you can read the repository's git history, read the recent log to infer project stage and pace: commit frequency, what changed last, whether platform work stalled.
  3. Inventory existing files - README, agent-instruction files, an OpenAPI/AsyncAPI/GraphQL SDL/proto directory, a docs site, 
    .github/
    , a 
    CHANGELOG
    - so nothing already written gets re-asked. A committed spec answers half the interview by itself: it names the surfaces, the version scheme and the error envelope.
  4. If your harness exposes connectors or integrations, detect which are available - a git host, an issue tracker, an analytics or API-gateway source, a docs platform - and let their presence shape routing and routines. Describe the capability; never assume a specific product.
  5. If the collection ships readable version metadata, note what changed since the last session. If it doesn't - the common case - degrade silently. Never block, warn, or ask about versions.
每个可从环境中推导出的事实，都是用户不必回答的问题。先运行检测；访谈上限只有在这种情况下才能存活。
  1. 只用一个信号判断冷启动还是热启动：项目中是否存在上下文工件 
    developer-platform-context.md
    ？存在 → 热启动。不存在 → 冷启动。永远不要问用户是哪种。
  2. 如果你能读取仓库的 git 历史，阅读最近的日志以推断项目阶段和节奏：提交频率、最近改了什么、平台工作是否停滞。
  3. 盘点现有文件——README、agent 指令文件、OpenAPI/AsyncAPI/GraphQL SDL/proto 目录、文档站点、
    .github/
    、
    CHANGELOG
    ——这样已经写好的内容不会被重新询问。已提交的 spec 本身就能回答一半访谈：它命名了集成面、版本方案和错误封套。
  4. 如果你的 harness 暴露了连接器或集成，检测哪些可用——git 托管、issue 跟踪器、分析或 API 网关源、文档平台——并让它们的存在影响路由和例行程序。描述能力，绝不要假设特定产品。
  5. 如果集合带有可读的版本元数据，记录自上次会话以来发生了什么变化。如果没有——常见情况——静默降级。绝不阻塞、警告或询问版本。

2. Interview - capped, tappable

2. 访谈——有上限、可点击

On a cold start, ask at most 5-7 questions. Ask one question per message. Offer multiple-choice options whenever possible. Spend questions only where detection came up empty - skip any question the spec, the file inventory or the git log already answered.
  1. "Who integrates with this platform today?" - (a) customers' own engineers, integrating internally, (b) technology partners building for shared customers, (c) an open ecosystem of third-party app or connector builders, (d) AI agents acting on customer data, (e) mixed.
  2. "What is the goal of this session - and is it the same as the project's goal?" Ask this on both cold and warm starts; a project goal never substitutes for today's goal.
  3. "Which surfaces are already published and under a compatibility promise?" - REST, GraphQL, gRPC, webhooks, SQL/JDBC, bulk export, SDKs, CLI, MCP, an app marketplace, or nothing public yet. A published surface is a constraint, not an option.
  4. "Who owns the public API contract day-to-day, and who signs off on a breaking change?" - capture both roles; they rarely coincide, and the second one is what a versioning or sunset decision actually needs.
  5. "Any hard constraints, and is there a date the result has to land by?" - (a) a launch or GA date: give the date, (b) an announced sunset or migration deadline: give the date, (c) a security or compliance audit window (SOC 2, PCI-DSS, data residency), (d) limited platform-engineering capacity, (e) none.
  6. "Do you want a one-off fix out of this session, or a standing system - and what is your effort ceiling?" - (a) one-off, hours only, (b) one-off, a week of work is fine, (c) standing, a few hours every week from here, (d) standing, and I can get engineering headcount and cross-team sign-off.
  7. "What is already decided, and what is still open?" - one line each; decided items are off the table for re-litigation.
Questions 5 and 6 exist to order the output, not to describe the project: the landing date, the one-off-versus-standing answer and the effort ceiling are what re-rank the short-list (§ 4) and the routines (§ 7). Ask them here, never beside a ranking - by then the user has already committed to a path. Record all three in the artifact so the warm start re-ranks 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 个问题。每条 message 问一个问题。尽可能提供多选选项。只在检测没有提供答案的地方花费问题——跳过 spec、文件清单或 git 日志已经回答的任何问题。
  1. “今天谁在与此平台集成？” - (a) 客户自己的工程师，内部集成，(b) 为共享客户构建的技术合作伙伴，(c) 第三方应用或连接器构建者的开放生态，(d) 基于客户数据行动的 AI agents，(e) 混合。
  2. “本次会话的目标是什么——它和项目目标相同吗？” 冷启动和热启动都要问；项目目标永远不能替代今天的目标。
  3. “哪些集成面已经发布并处于兼容性承诺之下？” - REST、GraphQL、gRPC、webhooks、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. Route the task

3. 路由任务

Match the stated session goal against the declared scope of each skill 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.
This table is deliberately unranked, and must stay that way. 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. Ranking belongs one step later, in the short-list (§ 4).
Rows are grouped by the collection's own categories. Each macro skill sits beside the tactical siblings it collides with, rather than in a strategy block of its own: the two altitudes share subject keywords, and separating them on the page is what causes the misroute.
将陈述的会话目标与下面每个 skill 的声明范围进行匹配。为当前任务路由到恰好一个 skill。绝不强行匹配：没有匹配时，直接说出来并指出缺口，而不是拉伸最近的 skill。
这张表刻意不排序，并且必须保持这样。范围是匹配测试，不是比率：一个任务要么落在某个 skill 的声明范围内，要么不在；给行排序会凭空制造出从不为同一任务竞争的 skill 之间的偏好。排序属于下一步，在候选清单中（§ 4）。
行按集合自身的类别分组。每个宏观 skill 放在它与战术同级冲突的位置，而不是单独放在策略块中：两个高度共享主题关键词，在页面上分开正是导致误路由的原因。

API design

API design

SkillRoute here when the task is…
samber/developer-platform-skills@api-integration-surface-strategy
(macro) Decide which integration surfaces exist at all and in what build order - REST, GraphQL, gRPC, webhooks, SQL, bulk export, SDKs, CLI, MCP, embedded components - sequenced by reversal cost and audience rather than novelty
samber/developer-platform-skills@public-api-design-review
Audit an existing or proposed REST surface as a checklist review: URI naming, method and status-code correctness, field consistency, pagination, filtering, error-envelope consistency, Hyrum's-Law compatibility risk - and the standing review program behind it
samber/developer-platform-skills@api-error-design
Design the error surface itself: a machine-readable error-code taxonomy, the RFC 9457 problem-details envelope, actionable messages, retryability signalling, per-endpoint error docs
samber/developer-platform-skills@api-idempotency-retry
Idempotency-key support and client retry guidance: key derivation and scoping, replay windows, atomic claim mechanisms, payload-mismatch rejection, backoff with jitter, SDK retry defaults
samber/developer-platform-skills@api-rate-limit-policy
The rate-limit policy a public API publishes: metering model per paradigm, quota and burst numbers, multi-tenant fairness, the header family, the 429 and 
Retry-After
contract
samber/developer-platform-skills@public-graphql-api-design
Design or review a public GraphQL schema: the GraphQL-or-not gate, naming and nullability, Relay cursor connections, error result types, depth and complexity ceilings, the federation trust boundary, persisted queries
samber/developer-platform-skills@public-grpc-api-design
Expose gRPC externally: the when-gRPC-at-all gate, AIP proto and versioning conventions, buf breaking-change gates, the 
google.rpc.Status
error model, transcoding and gateway architecture
Skill当任务是……时路由到这里
samber/developer-platform-skills@api-integration-surface-strategy
(宏观) 决定存在哪些集成面以及构建顺序——REST、GraphQL、gRPC、webhooks、SQL、批量导出、SDK、CLI、MCP、嵌入式组件——按逆转成本和受众排序，而不是按新颖性
samber/developer-platform-skills@public-api-design-review
以清单审查方式审计现有或拟议的 REST 表面：URI 命名、方法和状态码正确性、字段一致性、分页、过滤、错误封套一致性、Hyrum 定律兼容性风险——以及背后的常设审查程序
samber/developer-platform-skills@api-error-design
设计错误表面本身：机器可读的错误码分类、RFC 9457 problem-details 封套、可操作消息、可重试性信号、每个端点的错误文档
samber/developer-platform-skills@api-idempotency-retry
幂等键支持和客户端重试指导：键派生和范围、重放窗口、原子认领机制、payload 不匹配拒绝、带抖动的退避、SDK 重试默认值
samber/developer-platform-skills@api-rate-limit-policy
公共 API 发布的速率限制策略：每种范式的计量模型、配额和突发数值、多租户公平性、header 族、429 和 
Retry-After
契约
samber/developer-platform-skills@public-graphql-api-design
设计或审查公共 GraphQL schema：GraphQL-or-not 门、命名和可空性、Relay cursor connections、错误结果类型、深度和复杂度上限、federation 信任边界、persisted queries
samber/developer-platform-skills@public-grpc-api-design
对外暴露 gRPC：何时使用 gRPC 的门、AIP proto 和版本化约定、buf breaking-change 门、
google.rpc.Status
错误模型、transcoding 和 gateway 架构

API authentication

API authentication

SkillRoute here when the task is…
samber/developer-platform-skills@api-auth-key-management
API keys the platform issues to its own consumers: prefix-and-checksum format, hashed vs encrypted storage, least-privilege scoping, zero-downtime rotation, the key dashboard, offboarding, compliance lifecycle governance
samber/developer-platform-skills@oauth2-provider-design
Being the authorization server for third-party apps acting on your users' behalf: OAuth 2.1 baseline, refresh rotation, scope taxonomy, consent screen, tiered app verification
Skill当任务是……时路由到这里
samber/developer-platform-skills@api-auth-key-management
平台发给自身消费者的 API keys：前缀和校验和格式、哈希 vs 加密存储、最小权限范围、零停机轮换、key 仪表盘、离职处理、合规生命周期治理
samber/developer-platform-skills@oauth2-provider-design
作为代表用户行动的第三方应用的授权服务器：OAuth 2.1 基线、refresh rotation、scope 分类法、同意屏幕、分级应用验证

API documentation and lifecycle

API documentation and lifecycle

SkillRoute here when the task is…
samber/developer-platform-skills@api-versioning-policy
(macro) The versioning and deprecation policy: version scheme, a written breaking-change definition, notice windows by audience, RFC 9745/8594 sunset signalling, enforcement, breaking-change governance
samber/developer-platform-skills@api-reference-quality
Audit the published reference at the endpoint level against the spec surface - undocumented operations, parameters, response codes and errors, missing examples, snippet parity - then stop the drift with CI lint and contract-test gates
Skill当任务是……时路由到这里
samber/developer-platform-skills@api-versioning-policy
(宏观) 版本化和弃用策略：版本方案、书面破坏性变更定义、按受众的通知窗口、RFC 9745/8594 sunset 信号、执行、破坏性变更治理
samber/developer-platform-skills@api-reference-quality
在端点级别审计已发布参考与 spec 表面的差异——未记录的 operations、参数、响应码和错误、缺失示例、片段一致性——然后用 CI lint 和 contract-test 门阻止漂移

Integration surfaces

Integration surfaces

SkillRoute here when the task is…
samber/developer-platform-skills@webhook-platform-design
A provider-side outbound webhook platform: event taxonomy, payload envelope and schema versioning, HMAC signing, at-least-once delivery with retry and dead-letter policy, subscription lifecycle, the consumer debugging surface
samber/developer-platform-skills@sdk-portfolio-strategy
(macro) Which languages get official SDKs and in what order, generated vs handwritten, official and community support tiers with a promotion gate, SDK deprecation, SemVer decoupled from API versioning
samber/developer-platform-skills@mcp-server-offering
The product's MCP server as the surface AI agents operate: build sizing, a curated 5-15 workflow-tool set, write-safety patterns, remote hosting with OAuth 2.1, tool-surface versioning, adoption telemetry
samber/developer-platform-skills@sql-jdbc-access-design
Live customer-facing SQL: a JDBC/ODBC endpoint, warehouse share or hosted query surface - the architecture gate on scan economics, engine-level tenant isolation, an additive-only schema contract, BI-tool certification, pricing shape
samber/developer-platform-skills@bulk-data-sharing-design
Bulk file and lake export: Parquet drops on object storage vs native warehouse/lake sharing, partitioning and schema-evolution contract, cadence and freshness posture, per-recipient credentials, residency
samber/developer-platform-skills@etl-connector-strategy
(macro) Being a source connector on customers' ETL/ELT platforms: demand-validation gate, platform selection, the build-path menu ranked by who absorbs the maintenance tax, extraction-readiness audit, honest CDC scoping, a funded maintenance plan
Skill当任务是……时路由到这里
samber/developer-platform-skills@webhook-platform-design
提供方出站 webhook 平台：事件分类法、payload 封套和 schema 版本化、HMAC 签名、至少一次投递与重试和死信策略、订阅生命周期、消费者调试表面
samber/developer-platform-skills@sdk-portfolio-strategy
(宏观) 哪些语言获得官方 SDK，按什么顺序；生成 vs 手写；官方和社区支持层级及晋升门；SDK 弃用；SemVer 与 API 版本化解耦
samber/developer-platform-skills@mcp-server-offering
产品的 MCP server 作为 AI agents 操作的表面：构建规模、精选 5-15 个工作流工具集、写入安全模式、带 OAuth 2.1 的远程托管、工具表面版本化、采用遥测
samber/developer-platform-skills@sql-jdbc-access-design
面向客户的实时 SQL：JDBC/ODBC 端点、warehouse share 或托管查询表面——扫描经济性上的架构门、引擎级租户隔离、只增 schema 契约、BI 工具认证、定价形态
samber/developer-platform-skills@bulk-data-sharing-design
批量文件和 lake 导出：对象存储上的 Parquet 投放 vs 原生 warehouse/lake 共享、分区和 schema 演化契约、节奏和新鲜度姿态、每个接收方凭据、数据驻留
samber/developer-platform-skills@etl-connector-strategy
(宏观) 成为客户 ETL/ELT 平台上的源连接器：需求验证门、平台选择、按谁承担维护税排序的构建路径菜单、抽取就绪审计、诚实的 CDC 范围、有资金的维护计划

Testing, portal, and developer-facing operations

Testing, portal, and developer-facing operations

SkillRoute here when the task is…
samber/developer-platform-skills@developer-portal-design
(macro) The portal as a product surface: information architecture for evaluators and integrators, the signup-to-first-call path governed by time to first call, where each self-service surface is placed, RBAC and tenancy, build vs buy
samber/developer-platform-skills@api-test-mode-design
The test/sandbox mode integrators build against: soft test-mode toggle vs hard separate sandbox, test-key prefixing, magic test values and simulated personas, on-demand test events, deterministic time, reset and seeding, graduation to live
samber/developer-platform-skills@integration-error-observability
What an integrator can see when their integration breaks: per-integration logs with replay, correlation IDs surviving into a support ticket, error-rate aggregation per key or app, partner notification with cooldowns, a provider-side fleet view
samber/developer-platform-skills@api-status-communication
What the whole platform tells all consumers: status-page component modeling, monitoring-driven status, pull and push channels, incident-update cadence, public postmortems, SLA/SLO reporting
Skill当任务是……时路由到这里
samber/developer-platform-skills@developer-portal-design
(宏观) 门户作为产品表面：面向评估者和集成者的信息架构，以首次调用时间治理的注册到首次调用路径，每个自助服务表面放在哪里，RBAC 和租户，自建 vs 购买
samber/developer-platform-skills@api-test-mode-design
集成者所针对的测试/sandbox 模式：软测试模式开关 vs 硬独立 sandbox、测试 key 前缀、魔法测试值和模拟角色、按需测试事件、确定性时间、重置和种子数据、向生产毕业
samber/developer-platform-skills@integration-error-observability
当集成者自己的集成出问题时能看到什么：带重放的每次集成日志、能存活到 support ticket 的 correlation ID、按 key 或 app 的错误率聚合、带冷却的合作伙伴通知、提供方侧 fleet view
samber/developer-platform-skills@api-status-communication
整个平台对所有消费者传达什么：状态页组件建模、监控驱动的状态、拉取和推送渠道、事件更新节奏、公开 postmortems、SLA/SLO 报告

Integration partnerships

Integration partnerships

SkillRoute here when the task is…
samber/developer-platform-skills@integration-partnership-strategy
(macro) Which technology partners to integrate with and how deep: demand-data prioritization, the referral-to-OEM depth ladder with graduation gates, joint-roadmap governance, certification-program joins, sourced-vs-influenced attribution
samber/developer-platform-skills@partner-app-onboarding
The partner-developer journey on your platform, signup to first submitted app: the entry gate, sandbox tenancy provisioning, education and certification posture, the support ladder, time-to-first-submitted-app
samber/developer-platform-skills@integration-listing-optimization
Your own listing on someone else's marketplace: the view-to-install funnel, keyword placement, media ordering, compliant review-velocity programs, badge pursuit, defending rank against decay
Skill当任务是……时路由到这里
samber/developer-platform-skills@integration-partnership-strategy
(宏观) 与哪些技术合作伙伴集成、集成多深：需求数据优先级排序、带毕业门的 referral-to-OEM 深度阶梯、联合路线图治理、加入认证计划、sourced-vs-influenced 归因
samber/developer-platform-skills@partner-app-onboarding
合作伙伴开发者在你的平台上的旅程，从注册到第一个提交的应用：入门门、sandbox 租户配置、教育和认证姿态、支持阶梯、首次提交应用时间
samber/developer-platform-skills@integration-listing-optimization
你在别人市场里的 listing：展示到安装漏斗、关键词放置、媒体排序、合规的评论速度计划、徽章追求、对抗衰减的排名防御

Connector marketplace (operator side)

Connector marketplace (operator side)

SkillRoute here when the task is…
samber/developer-platform-skills@connector-marketplace-strategy
(macro) Whether to build your own marketplace at all - versus joining others' or buying embedded iPaaS - behind an evidence gate, then the operating model: curation level, partner mix, governance, take-rate level, and the seeding sequence
samber/developer-platform-skills@app-marketplace-review
The review and approval pipeline for third-party apps: pipeline shape scaled to data sensitivity, permission audits, re-review-on-update triggers, publish-channel hardening, appeal paths, a severity-tiered revocation ladder
samber/developer-platform-skills@app-marketplace-listing-standards
The listing-content rulebook every third-party submission must meet: required fields with objective reject criteria, media geometry, the description quality bar, category taxonomy, badge display, staleness enforcement
samber/developer-platform-skills@app-marketplace-monetization-model
How the marketplace collects money: merchant-of-record posture, billing rails, the fee stack and its anti-circumvention rule, waiver programs, payout cadence and hold windows, the VAT and facilitator tax layer
samber/developer-platform-skills@app-marketplace-launch-marketing
Launching and promoting the marketplace: founding-cohort sizing, keynote-anchored reveal and partner embargoes, featured-placement governance, the split between marketplace-wide demand gen and rationed per-partner co-marketing
Skill当任务是……时路由到这里
samber/developer-platform-skills@connector-marketplace-strategy
(宏观) 是否要自建市场——相对于加入其他市场或购买嵌入式 iPaaS——在证据门之后，然后是运营模式：策展级别、合作伙伴组合、治理、take-rate 水平、播种顺序
samber/developer-platform-skills@app-marketplace-review
第三方应用的审查和批准管道：按数据敏感性扩展的管道形态、权限审计、更新时重新审查触发、发布渠道加固、申诉路径、分级严重性的撤销阶梯
samber/developer-platform-skills@app-marketplace-listing-standards
每个第三方提交必须满足的 listing 内容规则手册：带客观拒绝标准的必填字段、媒体几何、描述质量门槛、分类法、徽章展示、陈旧性执行
samber/developer-platform-skills@app-marketplace-monetization-model
市场如何收钱：merchant-of-record 姿态、计费轨道、费用栈及其反规避规则、豁免计划、结算节奏和持有窗口、VAT 和 facilitator tax 层
samber/developer-platform-skills@app-marketplace-launch-marketing
启动和推广市场：创始群体规模、keynote 锚定的揭幕和合作伙伴 embargo、推荐位治理、市场级需求生成与按合作伙伴配给联合营销之间的分配

Meta

Meta

SkillRoute here when the task is…
samber/developer-platform-skills@developer-platform-kickoff
This skill: project start, periodic check-in, "which skill do I need", re-routing
samber/developer-platform-skills@developer-platform-career
Candidate side - breaking into an API PM, platform engineer, or partner/integration engineer role, interview prep, offer evaluation
samber/developer-platform-skills@developer-platform-hiring
Employer side - scorecard and job posting, interview loop design, sourcing, compensation stance
The altitude rule. Seven skills sit at macro altitude, and each shares subject keywords with a tactical sibling:
  • api-integration-surface-strategy
    decides which surfaces exist before any per-surface skill runs.
  • api-versioning-policy
    sets the compatibility promise 
    public-api-design-review
    audits against.
  • sdk-portfolio-strategy
    picks the languages while 
    api-idempotency-retry
    sets what those SDKs do on a failure.
  • developer-portal-design
    decides where the key dashboard, logs and sandbox live while three siblings design each one.
  • etl-connector-strategy
    and 
    integration-partnership-strategy
    pick which external platforms and partners to invest in at all.
  • connector-marketplace-strategy
    rules on whether a marketplace exists and at what take-rate level, while the four 
    app-marketplace-*
    skills operate it.
Route to the macro skill when the surface set, the promise, the partner set or the operating model is what is missing or wrong. Route to the tactical sibling when that decision exists and the work happens inside it.
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
for the per-skill route/do-not-route signals, the boundary-pair disambiguations, the ordered chains, and the named coverage gaps - read it before routing any task that could plausibly match two skills.
Name the gap explicitly when the task needs something no skill covers (§ 8). Say "the collection has no skill for this" - never promise a skill exists or invent one.
Before naming a gap, check whether the task belongs to a sibling 
samber
collection instead of this one:
  • DevRel practice - site-wide docs information architecture, the quickstart page, tutorials, developer content and SEO, community and events, open-source strategy, agent-facing documentation, the product-to-platform decision upstream of a marketplace, or the devtools revenue model → recommend installing 
    samber/developer-relations-skills
    .
  • Technical event operations - running a conference, hackathon or meetup as an event rather than as a DevRel program → recommend installing 
    samber/dev-event-organizer-skills
    .
Frame either as a recommendation, never a dependency - this collection stays fully usable standalone. See 
references/skill-routing.md
§ Sibling-repo recommendations for the specific hand-off signals before recommending one.
Skill当任务是……时路由到这里
samber/developer-platform-skills@developer-platform-kickoff
本 skill：项目启动、定期检查、“我需要哪个 skill”、重新路由
samber/developer-platform-skills@developer-platform-career
求职者侧——进入 API PM、平台工程师或合作伙伴/集成工程师岗位，面试准备，offer 评估
samber/developer-platform-skills@developer-platform-hiring
雇主侧——评分卡和职位发布、面试流程设计、寻源、薪酬立场
高度规则。 七个 skill 处于宏观高度，每个都与一个战术同级共享主题关键词：
  • api-integration-surface-strategy
    决定在任何一个 per-surface skill 运行之前存在哪些表面。
  • api-versioning-policy
    设定 
    public-api-design-review
    所审计的兼容性承诺。
  • sdk-portfolio-strategy
    选择语言，而 
    api-idempotency-retry
    设定这些 SDK 在失败时做什么。
  • developer-portal-design
    决定 key dashboard、日志和 sandbox 在哪里，而三个同级分别设计它们。
  • etl-connector-strategy
    和 
    integration-partnership-strategy
    决定究竟投资哪些外部平台和合作伙伴。
  • connector-marketplace-strategy
    裁定市场是否存在以及 take-rate 处于什么水平，而四个 
    app-marketplace-*
    skill 运营它。
当表面集合、承诺、合作伙伴集合或运营模式缺失或错误时，路由到宏观 skill。当该决策已存在且工作发生在其内部时，路由到战术同级。
严格根据每个 skill 的声明范围消歧——绝不要根据对某个 skill “可能”覆盖什么的猜测；错误的消歧比完全不路由更有害。阅读 
references/skill-routing.md
了解每个 skill 的 route/do-not-route 信号、边界对消歧、有序链和命名的覆盖缺口——在路由任何可能匹配两个 skill 的任务之前阅读它。
当任务需要某个没有 skill 覆盖的内容时，明确说出缺口（§ 8）。说“这个集合没有针对此的 skill”——绝不承诺存在某个 skill 或发明一个。
在命名缺口之前，检查任务是否属于同级的 
samber
集合而不是这个：
  • DevRel 实践 - 站点级文档信息架构、快速入门页、教程、开发者内容和 SEO、社区和活动、开源策略、面向 agent 的文档、市场上游的产品到平台决策或 devtools 收入模型 → 建议安装 
    samber/developer-relations-skills
    。
  • 技术活动运营 - 将会议、黑客松或 meetup 作为活动而不是作为 DevRel 计划来运营 → 建议安装 
    samber/dev-event-organizer-skills
    。
将两者都作为建议，绝不是依赖——本集合保持完全独立的可用性。在推荐之前，请参阅 
references/skill-routing.md
中 § Sibling-repo recommendations 的具体交接信号。

4. Output shape

4. 输出形态

Deliver the routing result in this shape, every time:
  1. State summary (warm start only) - exactly 5 lines from the artifact:
    • Integration audience.
    • Published surfaces under a compatibility promise.
    • In-flight work.
    • Top open decision.
    • Active constraint.
  2. Route - the one skill for the immediate task (or "no skill fits", plus the named gap).
  3. 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 table's row order - see "Ordering the short-list" below.
  4. Chain - when the task genuinely decomposes into an ordered sequence, 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.
  5. Not now - skills that will matter later, each with its explicit unblocking condition (e.g. "
    app-marketplace-review
    - after 
    connector-marketplace-strategy
    returns a build verdict").
  6. Gap - anything today's task needs that no skill covers, stated as a gap. When the gap is DevRel practice or event operations, recommend the matching sibling repo instead of a bare gap statement - see § 3.
每次都以这种形态交付路由结果：
  1. 状态摘要（仅热启动）—— 来自工件的恰好 5 行：
    • 集成受众。
    • 处于兼容性承诺下的已发布表面。
    • 进行中的工作。
    • 最大的未决决策。
    • 活跃约束。
  2. 路由 —— 当前任务的一个 skill（或“没有 skill 匹配”，加上命名的缺口）。
  3. 候选清单 —— 5 到 8 个与当前项目相关的 skill，按单位努力返回的价值排序，最高比率优先。每个条目一行，同时说出两侧：它攻击的瓶颈，以及会话的成本。绝不要按便宜程度排序，也绝不要按路由表的行顺序排序——见下方“候选清单排序”。
  4. 链 —— 当任务真正分解为有序序列时，按执行顺序列出，每个环节一行说明它传递给下一个环节什么。链顺序是依赖顺序，不是效率顺序——后面的环节消费前面环节产生的东西，不能提前运行，所以给链排序毫无意义。没有链时就省略——绝不编造序列。
  5. 现在不做 —— 以后会有用的 skill，每个都带明确的解锁条件（例如“
    app-marketplace-review
    —— 在 
    connector-marketplace-strategy
    返回构建裁决之后”）。
  6. 缺口 —— 今天的任务需要但没有 skill 覆盖的任何内容，以缺口形式说明。当缺口是 DevRel 实践或活动运营时，推荐匹配的同级仓库而不是裸缺口声明——见 § 3。

Ordering the short-list

候选清单排序

The user's question at that moment is never "which of these 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:
  1. Surface audit - 
    public-api-design-review
    , 
    api-reference-quality
    . Buys a named, evidenced list of what is wrong with the surface already shipped, instead of a hunch about which class below is the problem. Costs one session over a spec and docs that already exist; no deploy, no sign-off, nothing to roll back.
  2. Self-serve error contract - 
    api-error-design
    , 
    api-idempotency-retry
    . Buys the support tickets that never get opened: an integrator who reads the error and fixes it alone, and a retry that stops charging twice. Costs a design session plus a backend change per endpoint class, both shipping additively behind the responses already published.
  3. Published policy surfaces - 
    api-rate-limit-policy
    , 
    api-auth-key-management
    , 
    oauth2-provider-design
    . Buys the documented contract that prevents the noisy-neighbour and leaked-credential incidents before either happens. Costs a policy session plus gateway or credential-store configuration and a rotation path - and a published limit or scope is reversible only in the generous direction.
  4. Debuggability - 
    integration-error-observability
    , 
    api-test-mode-design
    , 
    api-status-communication
    . Buys integrators who diagnose themselves at 2am and partners who learn their integration broke before the customer tells them. Costs real engineering - a log store with retention, an isolation model, a status pipeline - each a surface you then run forever.
  5. Second surfaces - 
    webhook-platform-design
    , 
    sdk-portfolio-strategy
    , 
    developer-portal-design
    . Buys the step-change in what integration feels like: push instead of polling, an idiomatic client instead of raw HTTP, one place answering every self-service question. Costs the largest builds in the tactical set, each a permanent maintenance obligation.
  6. Specialist protocol surfaces - 
    public-graphql-api-design
    , 
    public-grpc-api-design
    , 
    sql-jdbc-access-design
    , 
    bulk-data-sharing-design
    , 
    mcp-server-offering
    . Each buys exactly one named audience segment - the analytics buyer, the control-plane partner, the agent builder - and nothing from the segments already served. Costs a whole new surface with its own versioning, limits and on-call.
  7. Ecosystem execution - 
    partner-app-onboarding
    , 
    integration-listing-optimization
    , 
    app-marketplace-review
    , 
    app-marketplace-listing-standards
    , 
    app-marketplace-monetization-model
    , 
    app-marketplace-launch-marketing
    . Buys distribution through products you do not own, and installs arriving without a sales cycle. Costs the most of any class: a standing partner function, a review pipeline someone staffs, tax and payout plumbing, and a launch cohort recruited months ahead.
  8. Macro strategy - 
    api-integration-surface-strategy
    , 
    api-versioning-policy
    , 
    etl-connector-strategy
    , 
    integration-partnership-strategy
    , 
    connector-marketplace-strategy
    . Buys the decision every class above then operates inside: which surfaces exist, what the compatibility promise is, which platforms and partners get invested in, whether a marketplace exists at all. Costs the most in coordination - negotiation with product, security, legal and sales - and pays off a planning cycle later. Nothing here is reversible by the platform team alone.
The axes disagree, which is exactly where the choice is hard:
  • efficiency: 
    surface audit > self-serve error contract > published policy surfaces > debuggability > second surfaces > specialist protocol surfaces > ecosystem execution > macro strategy
  • value: 
    macro strategy > second surfaces > self-serve error contract > ecosystem execution > published policy surfaces > debuggability > specialist protocol surfaces > surface audit
  • effort: 
    ecosystem execution > macro strategy > specialist protocol surfaces > second surfaces > debuggability > published policy surfaces > self-serve error contract > surface audit
  • compliance cost: 
    ecosystem execution > macro strategy > published policy surfaces > specialist protocol surfaces > debuggability > second surfaces > self-serve error contract == surface audit (none)
    • Operating a marketplace makes you a payment facilitator with per-jurisdiction VAT obligations, a data processor for every app you admit, and the party who must defend a delisting.
    • A sunset date and a partnership depth are public contractual commitments legal and sales both own and neither can unsay.
    • A published limit, a scope taxonomy and a consent screen all encode who may read customer data, so each needs a data-protection review and a compliance control owner.
    • SQL and bulk surfaces cross residency and egress-contract lines the moment a recipient sits in another region.
    • A request-log store sets a retention basis for payload data.
    • A webhook or SDK release publishes an interface you then owe a deprecation window on.
    • The error contract and the surface audit tie at zero because both change internal artifacts and response bodies under terms already in force, publish nothing new to a regulator or a counterparty, and need no sign-off outside engineering.
Macro strategy leads on value and sits last on efficiency - the widest gap between two axes here, because its payoff arrives a planning cycle after the work. Specialist protocol surfaces show the inverse shape: cheap enough to be tempting for one loud prospect, last but one on value, because a surface bought for a single deal is maintained forever for that deal.
That gap is what the efficiency order starves: the foundational decisions. Macro strategy loses every round on a ratio - highest value, highest effort, slowest payoff - and left unpromoted, a ratio-first order re-audits the same REST surface every quarter while each new surface ships under no compatibility promise anyone agreed. Promote it to rung 1 outright when the platform is being designed rather than tuned:
  • Nothing is public yet, or a deal is blocked on a surface nobody has decided to build (Q3 came back "nothing public yet") → 
    api-integration-surface-strategy
    .
  • A breaking change is wanted and nobody can say what counts as breaking or who signs it off (Q4 came back empty) → 
    api-versioning-policy
    , whatever the session wanted. Every class below ships into a surface with no owner.
  • Partners are chosen by whoever asked loudest, or partner-sourced pipeline cannot survive finance review → 
    integration-partnership-strategy
    .
  • Someone is proposing to build an app marketplace, or to set a take-rate, before the demand evidence exists → 
    connector-marketplace-strategy
    , and before any 
    app-marketplace-*
    skill.
  • Customers keep asking for the product's data inside their own warehouse → 
    etl-connector-strategy
    before the per-surface data skills in class 6.
Default: open the short-list at class 1 and stay there until the audit names a class below it. Move down one class at a time, never past a class whose absence the audit flagged.
  • Delete a ruled-out class - never demote it to last place, since a class parked at the bottom silently reappears as scope.
  • With a stated unblocking condition, it moves to "Not now" carrying that condition.
  • With none, it is not mentioned at all.
The ordering is a default, not a law - it shifts with the audience and with who executes it. Re-rank against what the interview and detection just told you, and say out loud which answer moved which class:
  • Customers' own engineers only (Q1a) deletes ecosystem execution and 
    oauth2-provider-design
    - there are no third-party apps to admit or authorize - and pulls 
    api-auth-key-management
    up inside published policy surfaces.
  • Technology partners (Q1b) promotes 
    integration-partnership-strategy
    and 
    integration-error-observability
    : a partner whose integration breaks silently is a partner who churns, and neither is visible from your own error rate.
  • A third-party builder ecosystem (Q1c) promotes ecosystem execution above debuggability and makes 
    oauth2-provider-design
    a prerequisite rather than an option - apps acting on user data cannot ship on API keys.
  • AI agents (Q1d) promotes 
    mcp-server-offering
    out of class 6 to rung 2 and pulls 
    api-error-design
    up with it: an agent recovers only from errors it can parse.
  • Nothing public yet (Q3) deletes surface audit outright and promotes macro strategy to rung 1.
  • Many surfaces already under a compatibility promise (Q3) promotes 
    api-versioning-policy
    and suppresses class 6, since another surface before the promise exists multiplies the problem.
  • No named breaking-change sign-off (Q4) promotes macro strategy to rung 1 whatever the session wanted.
  • A launch or GA date inside a quarter (Q5a) promotes surface audit and the error contract, which both act inside that window. It demotes anything paying out over a planning cycle - macro strategy, ecosystem execution - to "not now" with the launch date as its unblocking condition.
  • An announced sunset date (Q5b) promotes 
    api-versioning-policy
    to rung 1 and 
    integration-error-observability
    with it: you cannot enforce a cutoff without knowing who is still calling.
  • A compliance or audit window (Q5c) promotes published policy surfaces, 
    oauth2-provider-design
    and 
    app-marketplace-monetization-model
    , and lengthens the class 6 data surfaces without changing what they buy.
  • Limited platform-engineering capacity (Q5d) deletes classes 5 and 6 this session. They move to "not now", unblocked by capacity, and surface audit absorbs the session. Macro strategy is untouched - it ships no code.
  • "One-off, hours only" (Q6a) cuts the short-list to two surface-audit entries and deletes macro strategy outright.
  • "Standing, headcount and sign-off available" (Q6d) promotes macro strategy and ecosystem execution above their default place.
  • A decided item (Q7) removes its skill outright - do not rank what is off the table.
  • Detection moves classes too:
    • A committed OpenAPI or GraphQL SDL makes 
      api-reference-quality
      near-free.
    • No spec at all promotes 
      public-api-design-review
      , which reads the surface rather than a document.
    • A git log showing months of stall points at surface audit before any build.
    • An existing status page or log dashboard on disk deletes its debuggability entry.
用户当时的提问从来不是“这些里有哪些存在”，而是“我先运行哪一个，是否值得这个会话”。只有比率能回答这个问题。默认类别顺序，单位努力价值最高者优先：
  1. 表面审计 - 
    public-api-design-review
    , 
    api-reference-quality
    。买到一份有名字、有证据的清单，说明已经发布的表面有什么问题，而不是对下面哪个类别是问题的猜测。成本是对已经存在的 spec 和文档进行一次会话；没有部署、没有签字、没有可回滚的东西。
  2. 自助错误契约 - 
    api-error-design
    , 
    api-idempotency-retry
    。买到永远不会被打开的 support tickets：一个读错误并自行修复的集成者，以及一个不会重复扣费的重试。成本是一次设计会话加上每个端点类别的后端变更，两者都附加地发布在已经发布的响应之后。
  3. 已发布的策略表面 - 
    api-rate-limit-policy
    , 
    api-auth-key-management
    , 
    oauth2-provider-design
    。买到有文档的契约，在嘈杂邻居和凭据泄露事件发生之前阻止它们。成本是一次策略会话加上网关或凭据存储配置以及一条轮换路径——而已发布的限制或 scope 只能朝慷慨方向逆转。
  4. 可调试性 - 
    integration-error-observability
    , 
    api-test-mode-design
    , 
    api-status-communication
    。买到凌晨 2 点自行诊断的集成者，以及在客户告知之前发现集成坏掉的合作伙伴。成本是真正的工程——带保留期的日志存储、隔离模型、状态管道——每个都是你从此永久运行的表面。
  5. 第二表面 - 
    webhook-platform-design
    , 
    sdk-portfolio-strategy
    , 
    developer-portal-design
    。买到集成体验的阶跃变化：推送而非轮询、惯用客户端而非裸 HTTP、一个回答所有自助服务问题的地方。成本是战术集合中最大的构建，每个都是永久的维护义务。
  6. 专业协议表面 - 
    public-graphql-api-design
    , 
    public-grpc-api-design
    , 
    sql-jdbc-access-design
    , 
    bulk-data-sharing-design
    , 
    mcp-server-offering
    。每个只为恰好一个命名的受众细分——分析买家、控制面合作伙伴、agent 构建者——而且不服务已经服务的细分。成本是一个全新的表面，带自己的版本化、限制和 on-call。
  7. 生态执行 - 
    partner-app-onboarding
    , 
    integration-listing-optimization
    , 
    app-marketplace-review
    , 
    app-marketplace-listing-standards
    , 
    app-marketplace-monetization-model
    , 
    app-marketplace-launch-marketing
    。买到通过你不拥有的产品的分销，以及没有销售周期就到达的安装。成本是所有类别中最高的：一个常设合作伙伴职能、一个有人配员的审查管道、税务和结算管道，以及提前数月招募的启动群体。
  8. 宏观策略 - 
    api-integration-surface-strategy
    , 
    api-versioning-policy
    , 
    etl-connector-strategy
    , 
    integration-partnership-strategy
    , 
    connector-marketplace-strategy
    。买到上述每个类别然后在其中运行的决策：哪些表面存在、兼容性承诺是什么、投资哪些平台和合作伙伴、市场是否根本存在。成本在协调上最高——与产品、安全、法律和销售谈判——并在一个规划周期后回报。这里没有任何东西可以由平台团队单独逆转。
这些轴不一致，这正是选择困难的地方：
  • 效率：
    surface audit > self-serve error contract > published policy surfaces > debuggability > second surfaces > specialist protocol surfaces > ecosystem execution > macro strategy
  • 价值：
    macro strategy > second surfaces > self-serve error contract > ecosystem execution > published policy surfaces > debuggability > specialist protocol surfaces > surface audit
  • 努力：
    ecosystem execution > macro strategy > specialist protocol surfaces > second surfaces > debuggability > published policy surfaces > self-serve error contract > surface audit
  • 合规成本：
    ecosystem execution > macro strategy > published policy surfaces > specialist protocol surfaces > debuggability > second surfaces > self-serve error contract == surface audit (none)
    • 运营市场使你成为支付促进者，承担每个司法辖区的 VAT 义务，是你准入的每个 app 的数据处理者，也是必须为下架辩护的一方。
    • 下线日期和合作伙伴深度是法律和销售共同拥有、都不能收回的公开合同承诺。
    • 已发布的限制、scope 分类法和同意屏幕都编码了谁可以读取客户数据，所以每个都需要数据保护审查和合规控制负责人。
    • SQL 和批量表面在接收方位于另一个区域的瞬间就跨越数据驻留和出口契约线。
    • 请求日志存储为 payload 数据设定了保留基准。
    • webhook 或 SDK 发布公布了一个接口，你随后欠它一个弃用窗口。
    • 错误契约和表面审计以零并列，因为两者都在已经生效的条款下更改内部工件和响应体，不向监管机构或交易对手发布任何新内容，也不需要工程之外的签字。
宏观策略在价值上领先，在效率上垫底——这里是两个轴之间最宽的差距，因为它的回报在工作完成一个规划周期后才到来。专业协议表面呈现相反形状：便宜到足以为了一个大声的潜在客户而诱人，价值上倒数第二，因为为单笔交易购买的表面永远为该交易维护。
这个差距正是效率顺序饿死的东西：基础决策。宏观策略在每一轮都比率失败——价值最高、努力最高、回报最慢——如果不提升，比率优先的顺序会每季度重新审计同一个 REST 表面，而每个新表面都在没有人同意的兼容性承诺下发布。当平台正在被设计而不是调优时，直接把它提升到第 1 级：
  • 还没有任何公开内容，或一笔交易被一个没人决定构建的表面阻塞（Q3 回答“还没有公开内容”）→ 
    api-integration-surface-strategy
    。
  • 想要一个破坏性变更，但没人能说出什么算破坏性或谁签字（Q4 回答为空）→ 
    api-versioning-policy
    ，无论会话想要什么。下面每个类别都发布到一个没有所有者的表面。
  • 合作伙伴由谁喊得最大声来选择，或合作伙伴来源的管道无法通过财务审查 → 
    integration-partnership-strategy
    。
  • 有人提议在需求证据存在之前构建 app 市场或设定 take-rate → 
    connector-marketplace-strategy
    ，并且在任何 
    app-marketplace-*
    skill 之前。
  • 客户一直要求产品数据进入他们自己的 warehouse → 
    etl-connector-strategy
    先于第 6 类中的 per-surface 数据 skill。
默认：从第 1 类打开候选清单，并停留在那里，直到审计命名了下面的某个类别。一次向下移动一个类别，绝不要越过审计标记为缺失的类别。
  • 删除被排除的类别——绝不要把它降到最后，因为停在底部的类别会作为范围悄悄重新出现。
  • 有明确解锁条件的，移到“现在不做”并携带该条件。
  • 没有的，完全不提。
排序是默认值，不是法律——它随受众和谁执行而变。根据访谈和检测刚告诉你的内容重新排序，并大声说出哪个答案移动了哪个类别：
  • 只有客户自己的工程师（Q1a）删除生态执行和 
    oauth2-provider-design
    ——没有第三方应用要准入或授权——并把 
    api-auth-key-management
    拉进已发布的策略表面之内。
  • 技术合作伙伴（Q1b）提升 
    integration-partnership-strategy
    和 
    integration-error-observability
    ：一个静默失败的合作伙伴就是一个流失的合作伙伴，而这两者从你自己的错误率中都看不到。
  • 第三方构建者生态（Q1c）把生态执行提升到可调试性之上，并使 
    oauth2-provider-design
    成为先决条件而不是选项——基于用户数据行动的应用不能使用 API keys 交付。
  • AI agents（Q1d）把 
    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-error-observability
    随之：不知道谁还在调用就无法执行截止。
  • 合规或审计窗口（Q5c）提升已发布的策略表面、
    oauth2-provider-design
    和 
    app-marketplace-monetization-model
    ，并延长第 6 类数据表面而不改变它们买到的内容。
  • 有限的平台工程能力（Q5d）本次会话删除第 5 和第 6 类。它们移到“现在不做”，由能力解锁，表面审计吸收会话。宏观策略不受影响——它不发布代码。
  • “一次性，仅数小时”（Q6a）把候选清单削减到两个表面审计条目并彻底删除宏观策略。
  • “长期，有人力和签字可用”（Q6d）把宏观策略和生态执行提升到默认位置之上。
  • 已决定事项（Q7）直接移除其 skill——不要对不在讨论范围内的事情排序。
  • 检测也会移动类别：
    • 已提交的 OpenAPI 或 GraphQL SDL 使 
      api-reference-quality
      几乎免费。
    • 完全没有 spec 会提升 
      public-api-design-review
      ，它阅读的是表面而不是文档。
    • git 日志显示数月停滞指向表面审计后再构建。
    • 磁盘上已有的状态页或日志仪表盘删除其可调试性条目。

5. Context artifact

5. 上下文工件

Create or update 
developer-platform-context.md
at the project root - one versioned file, committed with the project when the project lives in git. It is the single source of truth that makes the next start warm.
Its fields:
  • Integration audience and buyer type.
  • Every published surface with its compatibility promise and version scheme.
  • Spec locations.
  • The contract owner and the breaking-change signer.
  • In-flight work.
  • Decided vs open.
  • Constraints, including the landing date, the one-off-versus-standing horizon and the effort ceiling.
  • Stakeholders with their decision role.
  • A session log.
Those three constraint fields are what let a warm start re-rank the short-list and the routines without re-asking questions 5 and 6.
  • 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 its invariants - audience, published surfaces, the compatibility promise - so future sessions inherit them without loading this skill.
  • Do not scaffold a working tree the project hasn't earned; premature structure hard-codes decisions it 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.
在项目根目录创建或更新 
developer-platform-context.md
—— 一个版本化文件，当项目在 git 中时随项目提交。它是让下一次启动变热的唯一事实来源。
其字段：
  • 集成受众和买家类型。
  • 每个已发布的表面及其兼容性承诺和版本方案。
  • Spec 位置。
  • 契约所有者和破坏性变更签字人。
  • 进行中的工作。
  • 已决定 vs 开放。
  • 约束，包括落地日期、一次性 vs 长期时间范围和投入上限。
  • 干系人及其决策角色。
  • 会话日志。
这三个约束字段让热启动无需重新询问第 5 和第 6 题即可重新排序候选清单和例行程序。
  • 热启动时：读取它，不要重建它。生成 5 行状态摘要，追加一行会话日志，只修补变化的字段。
  • 可选地，将项目 agent 指令文件修补上其不变量——受众、已发布表面、兼容性承诺——以便未来会话无需加载本 skill 就能继承它们。
  • 不要搭建项目尚未挣得的 working tree；过早的结构会把尚未做出的决策硬编码进去。
  • 只有当项目确实积累了有争议的决策时才保留决策日志；否则“已决定 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.
Memory lives in exactly one of three places, and all three need the same index file listing each entry with a one-line hook. They are not equivalent otherwise - pick from this order, highest value per unit of setup effort first:
  1. A 
    memories/
    directory in the project's git repository.     Setup is a directory and an index file, teammates read it wherever they already read the API spec, and every change arrives as a reviewable diff. Costs the commit-approval step below, and what lands there is durable in history.
  2. A team knowledge base. Reaches product, support and partner teams who never open the repository. Costs an access-and-permissions setup outside the platform team, and it drifts from the artifact because nothing ties a page to a commit.
  3. Local to the user's environment. Near-zero setup, and nobody else can read it. Use it only for a solo project - a per-user store forks the project state the moment a second person joins.
  • efficiency: 
    git repository > team knowledge base > local environment
  • reach: 
    team knowledge base > git repository > local environment
  • setup effort: 
    team knowledge base > git repository > local environment
Default to the git repository whenever the project already lives in one; choose the knowledge base when the people who need the memory - partner managers, support, sales engineers - do not work in it.
  • 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:
    • Partner or customer names tied to their API traffic.
    • Keys, client secrets or signing keys in any form.
    • Negotiated take-rates and contract terms.
    • Unannounced sunset dates.
    • Unpatched security findings from an app review.
  • 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 输出形态之前持久化访谈响应到记忆：先把捕获的答案写入上下文工件，然后从工件派生记忆条目。绝不要直接从答案写记忆，也绝不要因为答案看起来显而易见而跳过工件。
记忆恰好存在于三个地方之一，并且三者都需要同一个索引文件列出每个条目并配上一行钩子。除此之外它们并不等价——按此顺序选择，单位搭建努力价值最高者优先：
  1. 项目 git 仓库中的 
    memories/
    目录。     搭建就是一个目录和一个索引文件，队友在他们已经阅读 API spec 的地方阅读它，每个更改都以可审查的 diff 到达。成本是下面的提交批准步骤，而且落在那里的内容在历史中是持久的。
  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 仓库；当需要记忆的人——合作伙伴经理、支持、销售工程师——不在其中工作时，选择知识库。
  • 热启动时，将记忆与工件做 diff。当它们分歧时，提议对账——默认工件获胜；覆盖任何一边之前先询问。
  • 绝不要放进记忆：
    • 合作伙伴或客户名称与其 API 流量相关联。
    • 任何形式的 keys、client secrets 或签名密钥。
    • 已协商的 take-rate 和合同条款。
    • 未公布的下线日期。
    • 来自应用审查的未修补安全发现。
  • 第一次写入记忆时说明此排除。
  • 当记忆位于 git 仓库中时，绝不要静默提交。每次都先显示 diff 并获得批准。

7. Routines

7. 例行程序

If your harness supports scheduled routines, propose 2 to 4, always as a dry-run shown to the user first, each with an explicit output channel. A routine without one is noise the user silences within a week.
A routine's cost and value:
  • Cost is not its setup, but its attention per firing times how often it fires.
  • Value is the decision it puts in front of someone while that decision is still open.
Rank on that ratio, highest first, and propose from the top down:
  1. Pre-release API design review → 
    samber/developer-platform-skills@public-api-design-review
    . Fires per release candidate, over a spec diff the team produces anyway, and it is the only routine whose output can stop a breaking change before publication - after which Hyrum's Law makes the mistake permanent. Prefer an event trigger on the spec diff over a calendar date.
  2. Quarterly re-invocation of this kickoff. Near-zero per firing, and it keeps the artifact and the routing table 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.
  3. Deprecation-window sweep → 
    samber/developer-platform-skills@api-versioning-policy
    . Fires against each announced sunset date, over a list you published yourself, and it is the only routine whose output has to land before a date your consumers already hold you to. Anchor it a full notice period ahead of each cutoff, never at the cutoff itself.
  4. Reference-drift audit → 
    samber/developer-platform-skills@api-reference-quality
    . Costs a pass over the spec and the published reference. Buys nothing in a month with no spec churn, and buys back the quarter in the month nine endpoints ship undocumented.
  5. Integration fleet-health review → 
    samber/developer-platform-skills@integration-error-observability
    . Buys the broken partner integration found before the partner's customer finds it, and carries the highest standing cost in the set: the review is a session and each failing integration needs a named person to contact its owner. Install it only where someone owns that follow-through.
  6. Marketplace listing defend cycle → 
    samber/developer-platform-skills@integration-listing-optimization
    . A 30-60 day pass over the listing funnel, buying back rank lost to decay and to competitors' updates. Install it only once a listing is live and instrumented.
  • efficiency: 
    design review > kickoff re-invocation > deprecation sweep > reference-drift audit > fleet-health review > listing defend cycle
  • value: 
    fleet-health review > design review > deprecation sweep > reference-drift audit > listing defend cycle > kickoff re-invocation
  • effort: 
    fleet-health review > listing defend cycle > deprecation sweep > reference-drift audit > design review > kickoff re-invocation
  • compliance cost: 
    deprecation sweep > fleet-health review > listing defend cycle > reference-drift audit == design review == kickoff re-invocation (none)
    • A sunset notice is a public, contractual commitment signed off outside engineering and impossible to unsay.
    • The fleet-health output names partners and their traffic volumes, so its output channel must already be covered by the data policy.
    • Every listing edit is re-submitted under a third-party marketplace's terms, and any review-solicitation program must stay inside that marketplace's incentive ban.
    • The last three tie at zero for the same reason: each reads an internal artifact - a spec, a diff, a context file - publishes nothing outside the team, and needs no sign-off.
The kickoff re-invocation is the cheapest candidate and sits second, not first - the clearest proof that cheap and efficient are different orderings. The fleet-health review leads on value and sits fifth on efficiency, because what it costs is a recurring session plus a named person chasing every partner it names.
Default: rungs 1-2, which is two routines. Add each further routine only once its trigger condition is real:
  • The deprecation sweep, once a sunset date is announced.
  • The reference-drift audit, once spec churn is real.
  • The fleet-health review, once someone owns partner follow-through.
  • The defend cycle, once a listing is live.
Never exceed 4 - the cap 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 audience and with who executes it. Re-rank it against the interview:
  • An announced sunset date (Q5b) installs the deprecation sweep first and the design review second.
  • A partner or ecosystem audience (Q1b/c) promotes the fleet-health review above the deprecation sweep, since a silent partner break costs more than a scheduled cutoff.
  • A compliance window (Q5c) promotes the deprecation sweep and the reference-drift audit.
  • Limited capacity (Q5d) drops the reference-drift audit to quarterly.
  • "One-off, hours only" (Q6a) installs one routine - the kickoff re-invocation - not four.
  • A team already running a weekly API review board makes the design review a duplicate, so demote it.
  • No live listing deletes the defend cycle rather than demoting it.
Anchor triggers to the platform's own calendar - release train, announced sunset dates, the partner-program review, the marketplace launch - rather than arbitrary dates. Prefer an event trigger (a spec diff, a release tag, a webhook) over a schedule wherever the event exists. Clean up obsolete routines from a previous release cycle before adding new ones.
If the harness has no scheduled routines, fall back to one recurring calendar reminder ("Platform check-in - re-run the developer platform kickoff") and stop there.
如果你的 harness 支持计划例程，提议 2 到 4 个，总是先以向用户显示的 dry-run 形式，每个都有明确的输出渠道。没有输出渠道的例程是用户一周内就会静默的噪音。
例程的成本和价值：
  • 成本不是它的搭建，而是每次触发的注意力乘以触发频率。
  • 价值是它在决策仍然开放时把决策放到某人面前。
按该比率排序，最高在前，并从高到低提议：
  1. 发布前 API 设计审查 → 
    samber/developer-platform-skills@public-api-design-review
    。每个发布候选触发一次，针对团队反正会生成的 spec diff，它是唯一能在发布前阻止破坏性变更的例程——之后 Hyrum 定律使错误永久化。优先选择 spec diff 上的事件触发而不是日历日期。
  2. 本启动的季度重新调用。 每次触发近乎零成本，它让工件和路由表保持最新——这阻止所有其他例程触发已不存在的工作。将其节奏与 git 日志中项目的节奏匹配。
  3. 弃用窗口扫描 → 
    samber/developer-platform-skills@api-versioning-policy
    。针对每个已公布的下线日期触发，针对你自己发布的列表，它是唯一一个输出必须在消费者已经约束你的日期之前落地的例程。把它锚定在每个截止日期之前整整一个通知期，绝不能在截止日期本身。
  4. 参考漂移审计 → 
    samber/developer-platform-skills@api-reference-quality
    。成本是对 spec 和已发布参考做一次遍历。在没有 spec 变更的月份买不到任何东西，在九个端点未记录就发布的月份把季度买回来。
  5. 集成 fleet 健康审查 → 
    samber/developer-platform-skills@integration-error-observability
    。买到在合作伙伴的客户发现之前发现的坏掉的合作伙伴集成，并承担集合中最高的常设成本：审查是一个会话，每个失败的集成都需要一个指定的人联系其所有者。只在有人拥有该跟进时才安装它。
  6. 市场 listing 防御周期 → 
    samber/developer-platform-skills@integration-listing-optimization
    。对 listing 漏斗做 30-60 天的遍历，买回因衰减和竞争对手更新而失去的排名。只在 listing 上线并已埋点后才安装它。
  • 效率：
    design review > kickoff re-invocation > deprecation sweep > reference-drift audit > fleet-health review > listing defend cycle
  • 价值：
    fleet-health review > design review > deprecation sweep > reference-drift audit > listing defend cycle > kickoff re-invocation
  • 努力：
    fleet-health review > listing defend cycle > deprecation sweep > reference-drift audit > design review > kickoff re-invocation
  • 合规成本：
    deprecation sweep > fleet-health review > listing defend cycle > reference-drift audit == design review == kickoff re-invocation (none)
    • 下线通知是公开的、合同性的承诺，在工程之外签字，不可能收回。
    • fleet-health 输出命名合作伙伴及其流量，所以其输出渠道必须已经受数据政策覆盖。
    • 每个 listing 编辑都根据第三方市场的条款重新提交，任何征求评论的计划都必须留在该市场的激励禁令之内。
    • 最后三个以零并列，原因相同：每个都读取内部工件——spec、diff、上下文文件——不向团队之外发布任何东西，也不需要签字。
启动重新调用是最便宜的候选，排第二而不是第一——这是便宜和高效是不同排序的最清晰证明。fleet-health 审查在价值上领先，在效率上排第五，因为它的成本是一个重复会话加上一个追赶它命名的每个合作伙伴的指定人员。
默认：第 1-2 级，即两个例程。只有在触发条件真实时才添加每个后续例程：
  • 弃用扫描，一旦公布下线日期。
  • 参考漂移审计，一旦 spec 变更真实存在。
  • fleet-health 审查，一旦有人拥有合作伙伴跟进。
  • 防御周期，一旦 listing 上线。
绝不要超过 4——上限保护重要的例程免受那些对着虚空触发的例程影响。
排名是默认值，不是法律——它随受众和谁执行而变。根据访谈重新排序：
  • 已公布的下线日期（Q5b）先安装弃用扫描，再安装设计审查。
  • 合作伙伴或生态受众（Q1b/c）把 fleet-health 审查提升到弃用扫描之上，因为静默的合作伙伴故障比计划内的截止日期代价更高。
  • 合规窗口（Q5c）提升弃用扫描和参考漂移审计。
  • 有限能力（Q5d）把参考漂移审计降为季度。
  • “一次性，仅数小时”（Q6a）只安装一个例程——启动重新调用——而不是四个。
  • 一个已经在运行每周 API 审查委员会的团队使设计审查成为重复，所以降低它。
  • 没有 live listing 就删除防御周期而不是降低它。
把触发条件锚定到平台自己的日历——发布列车、已公布的下线日期、合作伙伴计划审查、市场启动——而不是任意日期。只要事件存在，优先选择事件触发（spec diff、发布 tag、webhook）而不是计划。在添加新例程之前，清理上一个发布周期遗留的过时例程。
如果 harness 没有计划例程，退回到一个重复的日历提醒（“平台检查——重新运行开发者平台启动”）然后停止。

8. Coverage gaps (v1)

8. 覆盖缺口（v1）

No skill in the collection covers these. Name the gap; never promise or invent a skill:
  • Per-marketplace submission playbooks. Zapier, Salesforce AppExchange and Slack App Directory are planned for v1.1 and not shipped; Shopify, Atlassian, HubSpot, AWS, GitHub, Google Workspace, Microsoft AppSource, WordPress and Chrome Web Store sit further out. 
    integration-listing-optimization
    covers marketplace-agnostic optimization, not one platform's submission mechanics or review criteria.
  • Package-registry publishing mechanics. npm, PyPI and Docker Hub metadata, classifiers and trust signals. 
    sdk-portfolio-strategy
    decides which languages ship, not how each artifact is published.
  • API changelog automation from spec diffs.
  • API monetization: usage-based pricing and packaging.
  • GraphQL federation as a partner-extensible offering. 
    public-graphql-api-design
    covers the federation trust boundary - only the router is ever public - not designing a graph partners extend.
  • Connector certification program design: test suites, renewal cycles, tier badges for partner-built connectors.
  • Integration health monitoring of deployed integrations - version drift, deprecated-API usage. 
    integration-error-observability
    surfaces errors as they happen; it does not track fleet-wide drift.
Out of scope by design, not gaps to fill later:
  • Server or client code generation.
  • Spec generation.
  • Gateway and throttling infrastructure configuration.
  • Internal service catalogs.
  • Single-SDK ergonomics.
  • Code-execution sandboxing.
  • Reseller sales enablement.
集合中没有 skill 覆盖这些。命名缺口；绝不承诺或发明 skill：
  • 每个市场的提交 playbook。 Zapier、Salesforce AppExchange 和 Slack App Directory 计划在 v1.1 中，尚未发布；Shopify、Atlassian、HubSpot、AWS、GitHub、Google Workspace、Microsoft AppSource、WordPress 和 Chrome Web Store 更远。
    integration-listing-optimization
    覆盖与市场无关的优化，而不是一个平台的提交机制或审查标准。
  • 包注册表发布机制。 npm、PyPI 和 Docker Hub 的元数据、分类器和信任信号。
    sdk-portfolio-strategy
    决定哪些语言发布，而不是每个工件如何发布。
  • 从 spec diff 自动生成 API 变更日志。
  • API 变现：基于使用的定价和打包。
  • GraphQL federation 作为合作伙伴可扩展产品。 
    public-graphql-api-design
    覆盖 federation 信任边界——只有 router 是公开的——而不是设计合作伙伴扩展的 graph。
  • 连接器认证计划设计：测试套件、续期周期、合作伙伴构建连接器的层级徽章。
  • 已部署集成的集成健康监控——版本漂移、已弃用 API 使用。
    integration-error-observability
    在错误发生时呈现错误；它不跟踪 fleet 级漂移。
按设计不在范围内，不是以后要填补的缺口：
  • 服务器或客户端代码生成。
  • Spec 生成。
  • 网关和限流基础设施配置。
  • 内部服务目录。
  • 单 SDK 人体工程学。
  • 代码执行沙箱。
  • 经销商销售赋能。

9. Invocation examples

9. 调用示例

  • "Start a new developer platform project - we're opening our API to partners."
  • "Which platform skill do I need? Integrators keep filing tickets about our error responses."
  • "Run my platform check-in."
  • "Where do I start? We want an app marketplace and I don't know if we're ready."
  • “启动一个新的开发者平台项目——我们要向合作伙伴开放 API。”
  • “我需要哪个平台 skill？集成者一直在就我们的错误响应提交工单。”
  • “运行我的平台检查。”
  • “我从哪里开始？我们想要一个 app 市场，我不知道我们是否准备好了。”

10. Failure modes

10. 失败模式

  • 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 - or point at 
    samber/developer-relations-skills
    / 
    samber/dev-event-organizer-skills
    when the task belongs to one of them (see § 3).
  • 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 
    references/skill-routing.md
    ; a plausible guess misroutes confidently.
  • Routing an altitude, not a subject. Seven macro skills share subject keywords with a tactical sibling each. Sending "should we even build an app marketplace" to 
    app-marketplace-review
    , or "what counts as a breaking change" to 
    public-api-design-review
    , hands the user a session at the wrong altitude - the answer arrives correct and useless.
  • Routing a side, not a subject. Three pairs split by which side of the table the user sits on:
    • Operator vs submitter on a marketplace.
    • Issuer vs consumer on OAuth.
    • Provider vs client on webhooks and retries.
    The keywords are identical and the advice inverts.
  • Uncapped interview. Past 7 questions, the kickoff becomes a form the user abandons. Detection fills the gaps - a committed spec answers more of it than any question does.
  • Routines with no output channel. They fire into the void and get silenced, burying the one routine that mattered.
  • A flat short-list, or one led by the cheapest option. Equal-looking options get picked by taste or by whichever sits first, and cheap is a different ordering from efficient - only the second answers "what first". Order by value per unit of effort and name both sides on every line.
  • Ranking the routing table 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. Parked at the bottom of the short-list, it reappears as scope two sessions later. Delete it, or move it to "not now" with its unblocking condition.
  • Memory committed silently. Teammates can't review what they can't see land. Diff and approval, always - and never let a key, a secret or a negotiated take-rate reach memory at all.
  • Stale routing table. Update this skill - table, 
    references/skill-routing.md
    , boundary pairs, chains, 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 拉伸到它不覆盖的任务上浪费了一个会话并隐藏了缺口。说“没有匹配的”，并命名缺口——或者当任务属于 
    samber/developer-relations-skills
    / 
    samber/dev-event-organizer-skills
    之一时指向它们（见 § 3）。
  • 热启动时重新访谈。 工件存在正是为了不重复提问。只问会话目标。
  • 从猜测的范围路由。 只从 
    references/skill-routing.md
    中声明的范围路由；一个合理的猜测会自信地误路由。
  • 路由到高度而不是主题。 七个宏观 skill 各与一个战术同级共享主题关键词。把“我们到底该不该建 app 市场”发给 
    app-marketplace-review
    ，或把“什么算破坏性变更”发给 
    public-api-design-review
    ，是在错误的高度给用户一个会话——答案正确且无用。
  • 路由到一侧而不是主题。 三对按用户坐在桌子哪一侧划分：
    • 市场中的运营方 vs 提交方。
    • OAuth 中的颁发方 vs 消费方。
    • webhooks 和重试中的提供方 vs 客户端。
    关键词相同，建议相反。
  • 无上限访谈。 超过 7 个问题，启动就变成用户放弃的表单。检测填补缺口——已提交的 spec 比任何问题回答得更多。
  • 没有输出渠道的例程。 它们对着虚空触发并被静默，埋没了重要的那个例程。
  • 扁平候选清单，或由最便宜选项领导。 看起来相等的选项会靠品味或谁排第一被选中，而便宜是与高效不同的排序——只有第二个回答“先做什么”。按单位努力价值排序，并在每一行说出两侧。
  • 给路由表或链排序。 范围是匹配测试，链是依赖顺序；给两者强加比率会发明出不存在的偏好。
  • 降级被排除的 skill 而不是删除它。 停在候选清单底部，它会在两次会话后作为范围重新出现。删除它，或移到“现在不做”并带解锁条件。
  • 静默提交记忆。 队友无法审查他们看不到落地的东西。总是 diff 和批准——绝不让 key、secret 或已协商的 take-rate 进入记忆。
  • 过时的路由表。 每当集合变化时更新本 skill——表格、
    references/skill-routing.md
    、边界对、链、缺口列表：添加、重命名、移除或重新限定范围的 skill。过时的路由器把用户送到不再存在的 skill，比根本没有路由器更糟。

11. Pass bar

11. 通过标准

Before ending the session, check every item. If any fails, fix it and re-check - do not close the session on a failing bar.
  1. Every recommended skill's declared scope actually matches the stated task - re-read its description to confirm.
  2. Zero routes to a name outside the skills in the table above.
  3. Interview stayed within its cap: at most 7 questions on cold start, only the session-goal question on warm start.
  4. developer-platform-context.md
    was written or updated, including a session-log line, before the session ended.
  5. Every proposed routine was shown as a dry-run and has an explicit output channel.
  6. 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 answer moved something off its default place.
  7. Every class the interview ruled out left the short-list entirely, and the routing table and any chain were left unranked - match test and dependency order respectively.
在结束会话之前检查每一项。如果任何一项失败，修复并重新检查——不要在失败的标准上关闭会话。
  1. 每个推荐 skill 的声明范围确实与陈述的任务匹配——重新阅读其描述确认。
  2. 零条路由指向上面表中 skill 之外的名称。
  3. 访谈保持在其上限内：冷启动最多 7 个问题，热启动只问会话目标问题。
  4. developer-platform-context.md
    在会话结束前被写入或更新，包括一行会话日志。
  5. 每个提议的例程都作为 dry-run 显示，并有明确的输出渠道。
  6. 候选清单和例程集都按单位努力价值排序，每个条目命名它攻击的瓶颈和成本——并且每当某个回答将某物移离默认位置时，大声说出重新排序。
  7. 访谈排除的每个类别完全离开候选清单，路由表和任何链保持不排序——分别是匹配测试和依赖顺序。

References

参考

  • references/skill-routing.md
     - per-skill route/do-not-route signals, boundary-pair disambiguations, ordered chains, and sibling-repo (
    samber/developer-relations-skills
    , 
    samber/dev-event-organizer-skills
    ) hand-off signals. Read before routing any ambiguous task.
  • references/skill-routing.md
     - 每个 skill 的 route/do-not-route 信号、边界对消歧、有序链和同级仓库（
    samber/developer-relations-skills
    , 
    samber/dev-event-organizer-skills
    ）交接信号。在路由任何模糊任务之前阅读。