samber/developer-platform-skills已通過檢查
SKILL DETAIL
developer-platform-kickoff
samber/developer-platform-skills/developer-platform-kickoff
Before starting any developer-platform, public-API, or integration work - or whenever no other platform skill has been chosen - route the task to the right skill in samber/developer-platform-skills, or say plainly that none fits, then bootstrap or resume the project's shared platform context. Fires at every API or platform project start, at each recurring platform review, and whenever routing is unclear. Use whenever the user mentions a developer platform kickoff, a new public API program, an integration-surface roadmap, "which platform skill do I need", "where do I start with our public API", platform skill routing, or a recurring platform check-in - even if they never name a skill or ask to be routed. It spans REST, GraphQL and gRPC design, webhooks, SDKs, MCP, OAuth and API keys, rate limits, versioning, developer portals, docs, sandboxes, marketplaces, and partner strategy, so an ambiguous platform question belongs here first. Outputs a short-list and an ordered skill chain, never the design itself.
安裝量 · 331查看來源
Installation
npx skills add https://github.com/samber/developer-platform-skills --skill developer-platform-kickoff
技能檔案
SKILL.md
最近同步 · 2026年10月23日
evals/evals.json›
{
"skill_name": "developer-platform-kickoff",
"evals": [
{
"id": 1,
"prompt": "I'm the platform PM at Larkspur Freight - B2B freight-visibility SaaS, 60 people, about $9M ARR. Right now every integration is a bespoke CSV drop per customer and it's eating two engineers full time. Our CRO wants 'an API for partners' in the next planning cycle. Nothing is public today: no published endpoints, no docs site, no spec file anywhere in the repo, and honestly nobody has ever said who would approve breaking something once it is public. The repo is a plain monorepo with a README and a CHANGELOG, that's it. Where do I start?",
"expected_output": "A cold-start kickoff that detects the absent context artifact without asking, caps the interview, deletes the surface-audit class because nothing is published, promotes macro strategy to the top rung, routes to api-integration-surface-strategy, gives a dependency-ordered chain, and writes developer-platform-context.md.",
"files": [],
"expectations": [
"Treats the missing `developer-platform-context.md` as the cold-start signal instead of asking the user whether this is a new or a resumed project",
"Asks at most 7 interview questions, one per message",
"Outputs a route and a short-list rather than a proposed API design, endpoint list, or specification",
"Deletes the surface-audit class from the short-list entirely rather than placing it last, because nothing is published yet",
"Promotes the macro-strategy class to the first rung of the short-list",
"Names the absent breaking-change sign-off as an independent second reason macro strategy sits at rung 1",
"Routes the immediate task to `samber/developer-platform-skills@api-integration-surface-strategy`",
"The chain ends at `samber/developer-platform-skills@api-versioning-policy`",
"States that the chain is ordered by dependency, not ranked by value or effort",
"The short-list holds between 5 and 8 entries",
"Every short-list entry names both the bottleneck it attacks and what the session costs",
"Writes `developer-platform-context.md`, including a session-log line, before the session ends"
]
},
{
"id": 2,
"prompt": "Picking our platform work back up after two sprints away. `developer-platform-context.md` is committed at the root of our repo - it says audience is technology partners, published surfaces are REST v1 and outbound webhooks, both under a compatibility promise, contract owner is Priya on platform, breaking-change signer is our VP Eng, constraints are a SOC 2 Type II window closing in March plus 'standing, a few hours a week' as the horizon and a two-engineer ceiling, and the top open decision is whether partner apps get OAuth. Today I want to sort out why three partners silently stopped calling us last month.",
"expected_output": "A warm-start kickoff that asks only the session-goal question, produces a five-line state summary from the artifact, routes to integration-error-observability, re-ranks on the partner audience and the compliance window without re-asking horizon or effort, and appends a session-log line.",
"files": [],
"expectations": [
"Asks only the session-goal question and no other interview question",
"Opens with a state summary of exactly five lines",
"The state summary covers integration audience, published surfaces under a compatibility promise, in-flight work, the top open decision, and the active constraint",
"Re-uses the horizon and the effort ceiling recorded in the artifact instead of re-asking them",
"Routes the immediate task to `samber/developer-platform-skills@integration-error-observability`",
"Promotes `samber/developer-platform-skills@integration-partnership-strategy` on the stated grounds that the audience is technology partners",
"Promotes the published-policy-surfaces class because a compliance or audit window is open",
"Keeps `samber/developer-platform-skills@oauth2-provider-design` live in the short-list or chain on the strength of the open partner-app auth decision rather than treating it as settled",
"Patches only the artifact fields that changed rather than rebuilding the artifact",
"Appends a session-log line to `developer-platform-context.md`",
"Proposes between 2 and 4 routines, each shown as a dry run and each with an explicit output channel",
"States out loud which recorded answer moved which class off its default place"
]
},
{
"id": 3,
"prompt": "Nimbus Rota - shift-scheduling SaaS, about $14M ARR, 900 customers. Our CEO announced internally that we're launching an app marketplace at our user conference in June. I've been handed the submission rulebook to write: what screenshots partners have to supply, what gets rejected, and a 15% cut on paid apps. For context we have eleven integrations live today, nine of which we built ourselves, and two partners have asked unprompted about building on us. Can you help me draft the review criteria?",
"expected_output": "A route to connector-marketplace-strategy on the altitude rule, with the evidence gate flagged against the thin partner-built demand, the app-marketplace skills moved to Not now with unblocking conditions, a dependency-ordered chain, and the ecosystem question handed to the DevRel sibling collection.",
"files": [],
"expectations": [
"Routes the immediate task to `samber/developer-platform-skills@connector-marketplace-strategy` rather than to `app-marketplace-listing-standards` or `app-marketplace-review`",
"Names the altitude error explicitly: the operating-model decision has not been made, so a listing rulebook is work at the wrong altitude",
"Flags that nine of the eleven integrations being first-party is thin two-sided demand evidence and puts the build verdict behind that evidence gate",
"Assigns the 15% figure to the strategy skill as a take-rate level rather than to `samber/developer-platform-skills@app-marketplace-monetization-model`",
"States that `samber/developer-platform-skills@app-marketplace-monetization-model` owns collection mechanics under whatever take-rate level the strategy sets",
"Moves `samber/developer-platform-skills@app-marketplace-review` to \"Not now\" with an explicit unblocking condition tied to the strategy verdict",
"Moves `samber/developer-platform-skills@app-marketplace-listing-standards` to \"Not now\" with an explicit unblocking condition rather than dropping it silently",
"The chain runs `connector-marketplace-strategy`, then `app-marketplace-listing-standards`, then `app-marketplace-review`, then `app-marketplace-monetization-model`, then `app-marketplace-launch-marketing`, in that order",
"States that the chain is in dependency order and is not ranked",
"Notes that launching before listing standards exist means grandfathering every early listing",
"Recommends `samber/developer-relations-skills@developer-ecosystem-strategy` as the upstream should-we-be-a-platform question, framed as an optional sibling collection and not a dependency",
"Does not draft the review criteria or the screenshot specifications itself"
]
},
{
"id": 4,
"prompt": "Quick one. At Vantage Ledger we have a REST API with about 140 endpoints, published for three years, roughly 400 integrators on it. We want to rename `customer_ref` to `counterparty_id` across eight endpoints and drop two response fields nobody should be reading anyway. Half the team says that's fine because it's 'just a rename', the other half says it's breaking. Nobody can point at a document that settles it. Can you review the API and tell us whether it's safe?",
"expected_output": "A route to api-versioning-policy rather than the design review the user asked for, with the missing written breaking-change definition and the missing sign-off owner named as the blocking gaps and macro strategy promoted to rung 1.",
"files": [],
"expectations": [
"Routes the immediate task to `samber/developer-platform-skills@api-versioning-policy` rather than to `public-api-design-review`, despite the user asking for a review",
"States the boundary explicitly: what are we allowed to change is policy, is this surface well designed is review",
"Names the absence of a written breaking-change definition as the blocking gap instead of just answering whether the rename is breaking",
"Names the absence of a breaking-change sign-off owner as a second gap the session must close",
"Promotes the macro-strategy class to rung 1 regardless of the session's stated goal",
"Places `samber/developer-platform-skills@public-api-design-review` in the short-list or in \"Not now\", not as the route",
"The short-list holds between 5 and 8 entries",
"Every short-list entry names both the bottleneck it attacks and what the session costs",
"Does not rank the routing table or present the collection's skills as ordered by preference",
"Writes or updates `developer-platform-context.md`, including a session-log line",
"Names no skill outside the collection's routing table and invents none"
]
},
{
"id": 5,
"prompt": "Crestline Payroll here. We publish an app on the Orbiton Suite marketplace - live 14 months, about 2,100 listing views a month, converting around 1.4% to install, which our head of growth calls terrible. We also want to work out what our own listing standards should be. And honestly what I want most is the exact Orbiton submission checklist, because their reviewer rejected us twice over screenshot sizing and I still don't know their rules.",
"expected_output": "A route to integration-listing-optimization on the side-of-the-table rule, refusing the operator-side listing-standards skill, naming per-marketplace submission playbooks as a coverage gap, and inventing neither the marketplace's rules nor a skill that covers them.",
"files": [],
"expectations": [
"Routes the immediate task to `samber/developer-platform-skills@integration-listing-optimization`",
"Explicitly rejects `samber/developer-platform-skills@app-marketplace-listing-standards` on the grounds that it is the operator's rulebook, not the submitter's playbook",
"States the side-of-the-table test: which side of the review gate the user sits on decides any marketplace-listing question",
"Names per-marketplace submission playbooks as a coverage gap this collection does not fill",
"Declines to supply the named marketplace's own submission checklist or reviewer criteria and does not invent them",
"Promises no skill that does not exist and presents no unshipped skill as if it were available",
"Keeps `samber/developer-platform-skills@app-marketplace-review` and `samber/developer-platform-skills@app-marketplace-launch-marketing` out of the short-list, since the user is not the operator",
"Carries the 1.4% view-to-install figure through as the funnel metric the route attacks",
"Every short-list entry names both the bottleneck it attacks and what the session costs",
"Writes or updates `developer-platform-context.md`, including a session-log line",
"Asks at most 7 interview questions, one per message"
]
},
{
"id": 6,
"prompt": "Helios Dispatch. Two things landed on my desk this week. First, a customer got charged three times for one job because their client library retried a POST /jobs that had actually succeeded but timed out at 30 seconds. Second, and separately, our own outbound event callbacks to customer endpoints sometimes fire twice, and one customer has built a dedupe table to cope with it. My VP wants 'one fix for the duplicate problem'. What am I doing first?",
"expected_output": "A split by direction of the call: the double-charge goes to api-idempotency-retry, the duplicate outbound callbacks go to webhook-platform-design, with one route named for the immediate task and the at-least-once delivery contract explained.",
"files": [],
"expectations": [
"Separates the two problems by the direction of the call rather than treating them as one duplicate-delivery problem",
"Routes the double-charge problem to `samber/developer-platform-skills@api-idempotency-retry`",
"Assigns the duplicate outbound event callbacks to `samber/developer-platform-skills@webhook-platform-design`, not to `api-idempotency-retry`",
"States explicitly that no single skill and no single fix covers both directions",
"Names at-least-once delivery as the provider-side contract that makes consumer-side dedupe expected rather than a defect",
"Names exactly one skill as the route for the immediate task rather than offering a menu as the route",
"If a chain is given, `samber/developer-platform-skills@webhook-platform-design` precedes `samber/developer-platform-skills@integration-error-observability` in it",
"Keeps `samber/developer-platform-skills@api-error-design` distinct, as the shape of one response body rather than as retry mechanics",
"The short-list holds between 5 and 8 entries, each naming the bottleneck it attacks and what the session costs",
"Does not design the idempotency-key scheme or the webhook signing scheme itself",
"Writes or updates `developer-platform-context.md`, including a session-log line"
]
},
{
"id": 7,
"prompt": "Saltmarsh Analytics. We're about to let outside developers build apps that read and write our customers' dashboards on those customers' behalf. Security wants us to just issue long-lived API keys per app because it's simpler to operate; our solutions architect wants OAuth. I need that decision made, and then whatever we pick, we need to know how we'd meter and bill it, and how we'd tell a customer which app broke. Which of these do I run?",
"expected_output": "A route to api-auth-key-management, which owns the unresolved keys-or-OAuth boundary, with OAuth named as a prerequisite for this audience, a dependency chain through rate-limit policy into error observability, and ecosystem execution promoted above debuggability.",
"files": [],
"expectations": [
"Routes the unresolved keys-or-OAuth decision to `samber/developer-platform-skills@api-auth-key-management`, which owns that decision boundary",
"States that `samber/developer-platform-skills@oauth2-provider-design` designs the issuer surface once the decision lands rather than deciding between the two",
"Names the split test: a customer's own backend calling on its own behalf takes API keys, a third-party app acting on the users' behalf needs delegated consent",
"Flags that apps acting on end-user data cannot ship on long-lived API keys, making OAuth a prerequisite rather than an option for this audience",
"The chain runs `api-auth-key-management`, then `samber/developer-platform-skills@api-rate-limit-policy`, then `samber/developer-platform-skills@integration-error-observability`",
"States the dependency reason: you cannot meter or attribute traffic you cannot identify",
"Promotes the ecosystem-execution class above the debuggability class because the audience is a third-party builder ecosystem",
"States out loud which answer moved which class",
"Presents the chain in dependency order and does not rank it",
"The short-list holds between 5 and 8 entries, each naming the bottleneck it attacks and what the session costs",
"Does not specify the key format, the token lifetimes, or the scope taxonomy itself"
]
},
{
"id": 8,
"prompt": "Three things queued up at Tern Robotics and I don't know which to hand you first. One: we're finally shipping Python and Go client libraries and I need to know how to publish them properly - PyPI classifiers, the Docker Hub description, trust signals, all of that. Two: finance wants usage-based pricing on the API - per call, per seat, credits, I genuinely don't know which. Three: our first-run tutorial page is where everyone drops off and I want it rewritten. We're 30 people with one platform engineer.",
"expected_output": "A kickoff that names package-registry publishing mechanics and API monetization as coverage gaps, hands the tutorial to the DevRel sibling collection as a recommendation, says plainly that no skill fits the immediate task, and cuts the code-heavy classes on the one-engineer capacity constraint.",
"files": [],
"expectations": [
"Names package-registry publishing mechanics as a coverage gap this collection does not fill, rather than stretching `samber/developer-platform-skills@sdk-portfolio-strategy` onto it",
"States that `sdk-portfolio-strategy` decides which languages ship, not how each artifact is published",
"Names API monetization, meaning usage-based pricing and packaging, as a second coverage gap",
"Invents no skill name for either gap and presents no forthcoming skill as if it were available",
"Recommends `samber/developer-relations-skills` for the first-run tutorial page, naming `developer-quickstart-guide`",
"Frames the sibling collection as a recommendation to install and explicitly not as a dependency of this collection",
"Says plainly that no skill in this collection fits the immediate task, rather than forcing a match onto the nearest one",
"Does not route the tutorial rewrite to `samber/developer-platform-skills@api-reference-quality`",
"Treats one platform engineer as limited capacity and removes the second-surfaces and specialist-protocol-surface classes from this session's short-list",
"Moves the removed classes to \"Not now\" with capacity named as the unblocking condition",
"Leaves the macro-strategy class in the short-list, on the stated grounds that it ships no code",
"Writes or updates `developer-platform-context.md`, including a session-log line"
]
},
{
"id": 9,
"prompt": "Honestly I have maybe three hours before I go back to firefighting. Beacon Rostering, 22 people. We have a REST API, about 60 endpoints, published two years, an OpenAPI file checked into the repo that's mostly current, a docs site generated from it, and roughly 40 integrators. No sandbox, no status page, no webhooks, no SDKs, no marketplace. What's the single highest-leverage thing I can do today? And don't give me a roadmap.",
"expected_output": "A two-entry short-list of surface-audit skills, macro strategy deleted outright rather than parked, the committed OpenAPI file cited from detection as making reference quality near-free, and exactly one routine proposed as a dry run with an output channel.",
"files": [],
"expectations": [
"Cuts the short-list to exactly two entries, both from the surface-audit class",
"Names `samber/developer-platform-skills@public-api-design-review` and `samber/developer-platform-skills@api-reference-quality` as those two entries",
"Deletes the macro-strategy class outright rather than parking it at the bottom of the short-list",
"States that the committed OpenAPI file makes `api-reference-quality` near-free, citing detection rather than an interview answer",
"Proposes exactly one routine, the periodic re-invocation of the kickoff itself",
"Gives that routine an explicit output channel",
"Shows the routine as a dry run before installing it",
"Does not propose building a sandbox, a status page, webhooks, or SDKs in this session",
"States that the short-list is ordered by value per unit of effort rather than by cheapness",
"Each short-list entry names both the bottleneck it attacks and what the session costs",
"Writes or updates `developer-platform-context.md`, including a session-log line",
"Asks at most 7 interview questions, one per message"
]
},
{
"id": 10,
"prompt": "Ridgeway Clinical. GA of our public API is locked for 6 November - that's eleven weeks out and already announced to three design partners. The surface is REST, 90 endpoints, spec in the repo, docs generated from it. Separately my director keeps pushing me to 'figure out the partner ecosystem story' and a board member asked about an app marketplace last week. I have two engineers for those eleven weeks. What goes in the plan?",
"expected_output": "A plan promoting surface audit and the error contract inside the eleven-week window, with macro strategy and ecosystem execution moved to Not now carrying the 6 November date as their unblocking condition rather than ranked low or deleted.",
"files": [],
"expectations": [
"Promotes the surface-audit class and the self-serve error-contract class on the strength of the 6 November date",
"Names `samber/developer-platform-skills@api-error-design` and `samber/developer-platform-skills@api-idempotency-retry` as the error-contract entries",
"Moves the macro-strategy class to \"Not now\" rather than deleting it",
"Moves the ecosystem-execution class to \"Not now\" rather than leaving it at the bottom of the short-list",
"Uses the 6 November GA date as the stated unblocking condition for both",
"Places neither `samber/developer-platform-skills@connector-marketplace-strategy` nor any `app-marketplace-*` skill inside the pre-GA plan",
"States out loud that the launch date is what moved those classes",
"Notes that the error contract and the surface audit ship additively under responses already published, which is why they fit inside the window",
"The short-list holds between 5 and 8 entries, each naming the bottleneck it attacks and what the session costs",
"Presents any chain in dependency order and does not rank it",
"Writes or updates `developer-platform-context.md`, recording 6 November as the landing-date constraint"
]
},
{
"id": 11,
"prompt": "Coppermill Inventory. Two of our biggest accounts have told us their internal AI agents will be doing stock reconciliation against our API next year, and one asked whether we 'have an MCP thing'. Meanwhile a different customer's engineer told us our SDK is basically unusable by a coding agent because the README never says what the auth environment variable is called and every example lives on a docs site the agent can't reach. Our error bodies are literally 'bad request' with no code today. Where do I point my team?",
"expected_output": "A split between building a new agent-facing tool surface and documenting an existing one, with mcp-server-offering promoted to the second rung on the AI-agent audience, api-error-design pulled up with it, and the SDK docs problem recommended to the DevRel sibling collection.",
"files": [],
"expectations": [
"Routes the agent-facing tool surface to `samber/developer-platform-skills@mcp-server-offering`",
"Sends the SDK README and examples problem to `samber/developer-relations-skills@coding-agent-docs-optimization` rather than to `mcp-server-offering`",
"States the boundary: MCP builds a new agent-facing tool surface, the sibling documents an existing one",
"Frames the sibling collection as a recommendation to install and not as a dependency",
"Promotes `mcp-server-offering` out of the specialist-protocol-surfaces class to the second rung of the short-list",
"Pulls `samber/developer-platform-skills@api-error-design` up alongside it",
"Gives the reason that an agent only recovers from errors it can parse",
"States out loud that the AI-agent audience is the answer that moved both",
"Does not specify the MCP tool list, the tool names, or the error taxonomy itself",
"The short-list holds between 5 and 8 entries, each naming the bottleneck it attacks and what the session costs",
"Names no skill outside the two collections' routing tables and invents none",
"Writes or updates `developer-platform-context.md`, recording AI agents as an integration audience"
]
},
{
"id": 12,
"prompt": "Kestrel Billing. We announced on 2 August that /v1 sunsets on 1 February - that's the date in the email that went to all 260 integrators, and our stated deprecation notice window is six months. Right now I genuinely do not know who is still on v1. My setup can run scheduled jobs. What should I set up, and what do I work on this week?",
"expected_output": "Versioning policy promoted to rung 1 with error observability alongside it, the deprecation sweep installed as the first routine anchored a full notice period ahead of 1 February, the routine set capped and each entry shown as a dry run with an output channel.",
"files": [],
"expectations": [
"Promotes `samber/developer-platform-skills@api-versioning-policy` to the first rung of the short-list",
"Promotes `samber/developer-platform-skills@integration-error-observability` alongside it, on the grounds that a cutoff cannot be enforced without knowing who is still calling",
"Installs the deprecation-window sweep as the first routine and the pre-release design review as the second",
"Anchors the deprecation sweep a full notice period ahead of the 1 February cutoff rather than on the cutoff date itself",
"Proposes no more than 4 routines in total",
"Proposes at least 2 routines",
"Shows every proposed routine as a dry run before installing it",
"Gives every proposed routine an explicit output channel",
"Prefers an event trigger over a calendar date wherever the event exists, for example a spec diff or a release tag",
"States out loud that the announced sunset date is what reordered the routines",
"Does not draft the migration guide or the sunset email itself",
"Writes or updates `developer-platform-context.md`, recording 1 February as the sunset constraint"
]
},
{
"id": 13,
"prompt": "Before we go further - my setup keeps persistent memory across sessions and I want you to remember our platform context so I stop re-explaining it every time. Here's the state at Fenwick Retail Cloud: audience is technology partners plus a handful of customer engineering teams; REST v2 and webhooks are public; we've signed a 12% rev-share with Marlowe Logistics that isn't public; our webhook signing secret rotates quarterly and the current one is whsec_7c1de40ab93f; we plan to kill the v1 SOAP bridge in March but haven't told anyone yet; and our last app review found an unpatched SSRF in Marlowe's connector. The repo is a git monorepo the whole company works in. Store all of that.",
"expected_output": "Memory derived from the context artifact rather than written straight from the answer, with the secret, the negotiated rev-share, the unannounced sunset, the security finding and the partner-traffic link all excluded and the exclusion stated, a memories directory in the repo recommended, and nothing committed without a diff and approval.",
"files": [],
"expectations": [
"Writes the captured state into `developer-platform-context.md` first and derives any memory entry from that artifact, never the reverse",
"Excludes the webhook signing secret from memory entirely",
"Excludes the 12% negotiated rev-share from memory",
"Excludes the unannounced March sunset of the v1 SOAP bridge from memory",
"Excludes the unpatched SSRF finding from the partner connector review from memory",
"Excludes the partner name tied to its API traffic from memory",
"States the exclusion policy out loud at the point memory is first written",
"Recommends a `memories/` directory inside the git repository over a team knowledge base or a local-only store, given the whole company works in that repo",
"Gives the reason as reviewable diffs and teammates reading it where they already read the spec",
"Commits nothing to memory in the repository without showing the diff and getting approval first",
"Proposes an index file listing each memory entry with a one-line hook",
"Does not echo the signing secret back anywhere in its output"
]
},
{
"id": 14,
"prompt": "Hollowbrook Freight. Rough month. Two partners' integrations had been failing 40% of calls for nine days and nobody noticed until the partner's own customer called our AE. During the same window we had a 50-minute outage and customers found out from Twitter before they heard it from us. And separately, integrators keep opening tickets that just say 'got a 400, no idea why'. Our audience is technology partners - eighteen of them. My boss wants 'better error handling'. Where do I start?",
"expected_output": "Three failure altitudes separated into three skills, one route named for the immediate task, the partner audience used to promote the partner-facing entries, and the fleet-health routine proposed only against a named owner with a data-policy-covered channel.",
"files": [],
"expectations": [
"Separates the three problems into three distinct skills rather than collapsing them into one error-handling route",
"Maps the silent partner failures to `samber/developer-platform-skills@integration-error-observability`",
"Maps the outage customers heard about from Twitter to `samber/developer-platform-skills@api-status-communication`",
"Maps the unhelpful 400 response bodies to `samber/developer-platform-skills@api-error-design`",
"Names exactly one skill as the route for the immediate task rather than naming all three as the route",
"Promotes a partner-facing entry on the stated grounds that the audience is technology partners",
"Proposes the integration fleet-health review only on the condition that a named person owns chasing each failing partner",
"Gives that routine an explicit output channel and shows it as a dry run",
"Notes that the fleet-health output names partners and their traffic volumes, so its channel must already be covered by the data policy",
"The short-list holds between 5 and 8 entries, each naming the bottleneck it attacks and what the session costs",
"Writes or updates `developer-platform-context.md`, including a session-log line"
]
}
],
"trigger_queries": [
{ "query": "Which platform skill do I need for this?", "should_trigger": true },
{ "query": "Where do I start with our public API?", "should_trigger": true },
{ "query": "Run my platform check-in.", "should_trigger": true },
{ "query": "Start a new developer platform project.", "should_trigger": true },
{ "query": "We're opening our API to partners - kick this off with me.", "should_trigger": true },
{ "query": "I don't know which of these skills applies to my API problem.", "should_trigger": true },
{ "query": "kick off a developer platform project", "should_trigger": true },
{ "query": "platform skill routing", "should_trigger": true },
{ "query": "We want an app marketplace and I have no idea if we're ready.", "should_trigger": true },
{ "query": "Our integrations are a mess and I don't know what to tackle first.", "should_trigger": true },
{ "query": "quarterly platform review time", "should_trigger": true },
{ "query": "Can you route this to the right API skill?", "should_trigger": true },
{ "query": "New public API program starting next quarter - help me scope it.", "should_trigger": true },
{ "query": "I need an integration-surface roadmap.", "should_trigger": true },
{ "query": "Resume our platform work from last time.", "should_trigger": true },
{ "query": "What should my platform team work on this quarter?", "should_trigger": true },
{ "query": "Bootstrap the context for our API program.", "should_trigger": true },
{ "query": "Our CEO wants 'an API strategy' and I have no idea where to begin.", "should_trigger": true },
{ "query": "Help me pick which of your API skills to run.", "should_trigger": true },
{ "query": "We're a 40-person SaaS and customers keep asking to integrate. What now?", "should_trigger": true },
{ "query": "I inherited the public API and nobody documented any decisions. Help.", "should_trigger": true },
{ "query": "Where do I begin with all this integration work?", "should_trigger": true },
{ "query": "Give me a short-list of what to fix on our platform.", "should_trigger": true },
{ "query": "First session on our developer platform - set me up.", "should_trigger": true },
{ "query": "It's been two months since we touched the API program. Pick it back up.", "should_trigger": true },
{ "query": "Which of these should I do first: webhooks, SDKs, or a sandbox?", "should_trigger": true },
{ "query": "Our partners keep asking for things and I can't prioritize them.", "should_trigger": true },
{ "query": "platform kickoff", "should_trigger": true },
{ "query": "I'm the first platform PM here. What do I do?", "should_trigger": true },
{ "query": "Help me plan the API roadmap for next half.", "should_trigger": true },
{ "query": "Re-route me, the last skill wasn't the right one.", "should_trigger": true },
{ "query": "We have an API but no strategy behind it. Where to?", "should_trigger": true },
{ "query": "Do you have something for starting an integrations program?", "should_trigger": true },
{ "query": "Set up recurring reviews for our API platform.", "should_trigger": true },
{ "query": "What's the right order to build our integration surfaces in?", "should_trigger": true },
{ "query": "I have three API problems and limited time - triage them for me.", "should_trigger": true },
{ "query": "Check in on our platform project.", "should_trigger": true },
{ "query": "Can you look at where our developer platform stands and tell me what's next?", "should_trigger": true },
{ "query": "We're two weeks from GA on the public API. What am I missing?", "should_trigger": true },
{ "query": "Our integration work keeps stalling. Diagnose it and point me somewhere.", "should_trigger": true },
{ "query": "Which skill covers 'partners can't tell when their integration breaks'?", "should_trigger": true },
{ "query": "Not sure if this is a versioning thing or a design thing.", "should_trigger": true },
{ "query": "I don't know if what I need is a marketplace skill or a partnership skill.", "should_trigger": true },
{ "query": "Start the platform context file for our repo.", "should_trigger": true },
{ "query": "Give me the ordered chain of skills for launching a public API.", "should_trigger": true },
{ "query": "We're deciding between GraphQL and more REST and I don't know who to ask.", "should_trigger": true },
{ "query": "Warm start on the platform project please.", "should_trigger": true },
{ "query": "Every quarter I forget where we left off on the API. Fix that.", "should_trigger": true },
{ "query": "Help me figure out what's worth a session this week on the platform.", "should_trigger": true },
{ "query": "My VP asked for an 'ecosystem plan' - unpack that for me.", "should_trigger": true },
{ "query": "We just hired a partner engineer and I need to give them a plan.", "should_trigger": true },
{ "query": "What's the highest-leverage platform work I can do in three hours?", "should_trigger": true },
{ "query": "Route this: integrators say our errors are useless and partners churn silently.", "should_trigger": true },
{ "query": "Which developer platform skill should I load?", "should_trigger": true },
{ "query": "I need help choosing among your API skills.", "should_trigger": true },
{ "query": "Our API is public, our docs drifted, and nobody owns breaking changes. Start somewhere.", "should_trigger": true },
{ "query": "Platform review - what changed and what's next?", "should_trigger": true },
{ "query": "We want to be a platform, not just a product. First step?", "should_trigger": true },
{ "query": "Open a session on the integrations program.", "should_trigger": true },
{ "query": "Take stock of our API platform and give me a plan.", "should_trigger": true },
{ "query": "What should we decide before we build any more surfaces?", "should_trigger": true },
{ "query": "Help me sequence the platform work behind our November launch.", "should_trigger": true },
{ "query": "I keep re-explaining our API setup every session. Can we fix that?", "should_trigger": true },
{ "query": "Is there a skill for 'we don't know what to do with our API'?", "should_trigger": true },
{ "query": "Give me the skill chain for standing up an app ecosystem.", "should_trigger": true },
{ "query": "Nothing's public yet and a deal is blocked on a missing API. Help me decide.", "should_trigger": true },
{ "query": "Which one of your skills handles 'should we build this surface at all'?", "should_trigger": true },
{ "query": "Recurring platform check-in, please set it up.", "should_trigger": true },
{ "query": "I want a short-list ranked by what's actually worth the session.", "should_trigger": true },
{ "query": "Point me at the right place - this could be three different skills.", "should_trigger": true },
{ "query": "We're starting our developer platform from zero next month.", "should_trigger": true },
{ "query": "Our API program has no owner and no plan. Where does that start?", "should_trigger": true },
{ "query": "Help me decide what my platform team stops doing.", "should_trigger": true },
{ "query": "What skills do I need for an API-first rebuild?", "should_trigger": true },
{ "query": "The partner integrations backlog is 30 items. Order it for me.", "should_trigger": true },
{ "query": "Onboard me to how this collection works for my API project.", "should_trigger": true },
{ "query": "Is there anything here for a developer platform strategy session?", "should_trigger": true },
{ "query": "Design our RFC 9457 problem-details envelope.", "should_trigger": false },
{ "query": "What should our rate-limit headers look like - X-RateLimit or the IETF fields?", "should_trigger": false },
{ "query": "Audit these 40 REST endpoints for naming and status-code consistency.", "should_trigger": false },
{ "query": "Write the HMAC signing scheme for our outbound webhooks.", "should_trigger": false },
{ "query": "Should our Idempotency-Key be scoped per account or per key?", "should_trigger": false },
{ "query": "Pick our version scheme: URI path or date-based account pinning.", "should_trigger": false },
{ "query": "Find every undocumented endpoint in our published reference.", "should_trigger": false },
{ "query": "Design the consent screen for third-party apps on our OAuth server.", "should_trigger": false },
{ "query": "What prefix and checksum format should our API keys use?", "should_trigger": false },
{ "query": "Set the depth and complexity ceilings on our public GraphQL schema.", "should_trigger": false },
{ "query": "Configure buf breaking-change gates for our public protos.", "should_trigger": false },
{ "query": "Which languages should get official SDKs first - Python, Go, or Ruby?", "should_trigger": false },
{ "query": "Curate the 12 tools our MCP server should expose.", "should_trigger": false },
{ "query": "Should we offer a JDBC endpoint or a warehouse share for customer BI?", "should_trigger": false },
{ "query": "Design our Parquet drop partitioning and schema-evolution contract.", "should_trigger": false },
{ "query": "Get us listed as a source connector on the big ETL platform catalogs.", "should_trigger": false },
{ "query": "Restructure our developer portal IA and cut time to first call.", "should_trigger": false },
{ "query": "Design magic test values and simulated personas for our sandbox.", "should_trigger": false },
{ "query": "Build a developer-facing request log with replay for integrators.", "should_trigger": false },
{ "query": "Write the incident update template for our status page.", "should_trigger": false },
{ "query": "Tier our technology partners on a referral-to-OEM ladder.", "should_trigger": false },
{ "query": "Design the partner signup-to-first-app journey.", "should_trigger": false },
{ "query": "Our marketplace listing converts at 1%. Fix the screenshots and keywords.", "should_trigger": false },
{ "query": "Set the take-rate and curation posture for our app store.", "should_trigger": false },
{ "query": "Define the re-review triggers after a partner updates their app.", "should_trigger": false },
{ "query": "Write the screenshot geometry and description quality bar for listings.", "should_trigger": false },
{ "query": "Should we be merchant of record for paid apps?", "should_trigger": false },
{ "query": "Size the founding cohort for our marketplace launch keynote.", "should_trigger": false },
{ "query": "How do I prep for an API product manager interview?", "should_trigger": false },
{ "query": "Write a job posting for a partner integration engineer.", "should_trigger": false },
{ "query": "Set up a Discord server for our developer community.", "should_trigger": false },
{ "query": "Write the quickstart page for our SDK.", "should_trigger": false },
{ "query": "Plan our conference booth and sponsorship package.", "should_trigger": false },
{ "query": "Draft a CFP submission for my platform talk.", "should_trigger": false },
{ "query": "Run a hackathon for our API next spring.", "should_trigger": false },
{ "query": "Design our developer advocate hiring loop.", "should_trigger": false },
{ "query": "Write an engineering blog post about our rate limiter.", "should_trigger": false },
{ "query": "Plan the meetup program for our user groups.", "should_trigger": false },
{ "query": "Build our DevRel metrics dashboard.", "should_trigger": false },
{ "query": "Choose an open-source license for our core library.", "should_trigger": false },
{ "query": "Write the release-notes changelog for this sprint.", "should_trigger": false },
{ "query": "Script a five-minute product demo video.", "should_trigger": false },
{ "query": "Optimize our docs site for search.", "should_trigger": false },
{ "query": "Plan the venue and catering for our user conference.", "should_trigger": false },
{ "query": "How much should we budget for developer marketing next year?", "should_trigger": false },
{ "query": "Give me a project kickoff meeting agenda template.", "should_trigger": false },
{ "query": "Write an onboarding checklist for new engineering hires.", "should_trigger": false },
{ "query": "Set up Backstage as our internal developer portal.", "should_trigger": false },
{ "query": "Design golden paths for our internal platform team.", "should_trigger": false },
{ "query": "Our Kubernetes platform team needs an operating model.", "should_trigger": false },
{ "query": "Configure rate limiting in our API gateway.", "should_trigger": false },
{ "query": "Generate an OpenAPI spec from our Express routes.", "should_trigger": false },
{ "query": "Scaffold an MCP server with the TypeScript SDK.", "should_trigger": false },
{ "query": "Write the Terraform for our edge proxy.", "should_trigger": false },
{ "query": "Set up an internal service catalog.", "should_trigger": false },
{ "query": "Build a CI pipeline for our client libraries.", "should_trigger": false },
{ "query": "Sprint planning for the platform team for the next two weeks.", "should_trigger": false },
{ "query": "Write user stories for the integrations epic.", "should_trigger": false },
{ "query": "Facilitate a sprint retrospective for my squad.", "should_trigger": false },
{ "query": "Help me consume a payments vendor's API from our Node backend.", "should_trigger": false },
{ "query": "Integrate with a CRM's REST API from our app.", "should_trigger": false },
{ "query": "We need to authenticate against a third party's OAuth from our server.", "should_trigger": false },
{ "query": "Write a client wrapper around a vendor's webhook receiver.", "should_trigger": false },
{ "query": "Debug a 429 we're getting from a third-party API we call.", "should_trigger": false },
{ "query": "Migrate our database schema to the next Postgres major.", "should_trigger": false },
{ "query": "Review this Go service for concurrency bugs.", "should_trigger": false },
{ "query": "Write unit tests for our payment handler.", "should_trigger": false },
{ "query": "Set up code-execution sandboxing for user-submitted scripts.", "should_trigger": false },
{ "query": "Design our internal microservice contracts.", "should_trigger": false },
{ "query": "Enable reseller partners to quote and sell our product.", "should_trigger": false },
{ "query": "Write a SOC 2 evidence collection plan.", "should_trigger": false },
{ "query": "Plan our product launch PR and press outreach.", "should_trigger": false },
{ "query": "Build a pricing page for our SaaS.", "should_trigger": false },
{ "query": "Write a customer-facing product roadmap.", "should_trigger": false },
{ "query": "Create an affiliate program for our app.", "should_trigger": false },
{ "query": "Optimize our GitHub profile README.", "should_trigger": false },
{ "query": "Run an A/B test on our signup flow.", "should_trigger": false }
]
}
references/skill-routing.md›
# Routing detail - developer-platform-skills collection
Route only from the declared scopes below. Every "do not route here" line comes from the skill's own description, not from inference. The kickoff's own routing table states what each skill covers; this file states where each one _stops_, which is what a two-way keyword collision actually needs.
Nothing here is ranked, and nothing in it should be. Scope is a match test, not a ratio. Ranking lives in the kickoff's short-list and routine set, where several skills compete for one session (see `samber/developer-platform-skills@developer-platform-kickoff` § 4 and § 7).
Seven skills sit at macro altitude:
- `api-integration-surface-strategy`
- `api-versioning-policy`
- `sdk-portfolio-strategy`
- `developer-portal-design`
- `etl-connector-strategy`
- `integration-partnership-strategy`
- `connector-marketplace-strategy`
Each shares subject keywords with a tactical sibling and is separated from it by altitude, not by topic.
Three further pairs split by _side of the table_, where the keywords are identical and the advice inverts:
- Operator vs submitter.
- Issuer vs consumer.
- Provider vs client.
Both kinds are collected under Boundary pairs below.
## Table of Contents
- [Per-skill signals](#per-skill-signals)
- [Boundary pairs](#boundary-pairs)
- [Ordered chains](#ordered-chains)
- [Sibling-repo recommendations](#sibling-repo-recommendations)
## Per-skill signals
### `samber/developer-platform-skills@api-integration-surface-strategy`
- Route here: "which API should we build first", "should we add GraphQL or MCP", "a deal is blocked on a surface we don't have", API-first vs embedded-first sequencing.
- Do not route here: designing any chosen surface - it hands off to the per-surface sibling once the surface is picked.
### `samber/developer-platform-skills@public-api-design-review`
- Route here:
- Audit a REST surface against design rules, bucketing findings Must-change or Improvement.
- Stand up the review program (lifecycle triggers, reviewer authority, linting, federation).
- "Review this API before we publish it."
- Do not route here: generating a spec or server code; error taxonomy, versioning, idempotency, auth, rate limits and docs depth each belong to a named sibling.
### `samber/developer-platform-skills@api-error-design`
- Route here: "our errors just say 400", designing the code taxonomy and the RFC 9457 envelope, making messages actionable, signalling retryability.
- Do not route here: client-side retry mechanics, whole-surface consistency review, incident or status-page communication.
### `samber/developer-platform-skills@api-idempotency-retry`
- Route here: "make POST safe to retry", "customers are double-charged", adding an `Idempotency-Key` header, writing retry guidance, setting SDK backoff defaults.
- Do not route here: what the error response signals (`api-error-design`); webhook delivery retries (`webhook-platform-design`).
### `samber/developer-platform-skills@api-rate-limit-policy`
- Route here: setting and publishing quota and burst numbers, the header family, the 429 and `Retry-After` contract, noisy-neighbour fairness, enterprise limit-increase paths.
- Do not route here: throttling infrastructure or gateway configuration; the 429 envelope shape, client backoff mechanics and deprecation machinery belong to siblings.
### `samber/developer-platform-skills@public-graphql-api-design`
- Route here: "should this be GraphQL", designing or reviewing a public schema, Relay cursor connections, error result types, depth and complexity ceilings, the federation trust boundary, persisted queries.
- Do not route here: published cost/quota policy (`api-rate-limit-policy`), deprecation and versioning policy, push-event architecture.
### `samber/developer-platform-skills@public-grpc-api-design`
- Route here: "should we expose gRPC at all", proto governance and AIP conventions, buf breaking-change gates, the `google.rpc.Status` error model, transcoding and gateway architecture, the pre-exposure audit.
- Do not route here: language-specific server implementation; internal-only gRPC, which this skill's own gate usually sends back to REST.
### `samber/developer-platform-skills@api-auth-key-management`
- Route here: key format and storage, least-privilege scoping, rotation UX, the key dashboard, offboarding, compliance lifecycle governance - and the unresolved "keys or OAuth?" question, which this skill owns.
- Do not route here:
- Consuming another vendor's API.
- OAuth flow design.
- Webhook signing schemes.
### `samber/developer-platform-skills@oauth2-provider-design`
- Route here: "let third-party apps act on our users' behalf", "add Sign in with X plus delegated access", defining scopes, designing consent, setting token lifetimes, gating app publishing behind verification.
- Do not route here: integrating against someone else's OAuth; API-key design.
### `samber/developer-platform-skills@api-versioning-policy`
- Route here: picking a version scheme, writing the breaking-change definition, setting notice windows, sunset signalling and enforcement, breaking-change governance. Asks the API paradigm first - REST's version-and-sunset and GraphQL's continuous evolution are different policies.
- Do not route here: client SDK versioning, which is plain SemVer; auditing whether one surface is well-designed.
### `samber/developer-platform-skills@api-reference-quality`
- Route here: "find our undocumented endpoints", measuring docs completeness against a spec, missing examples or snippet parity, broken try-it, "stop our reference drifting" via CI lint and contract-test gates.
- Do not route here: site-wide docs information architecture, the quickstart page, sample-corpus policy, agent-facing docs - all `samber/developer-relations-skills`.
### `samber/developer-platform-skills@webhook-platform-design`
- Route here: "add webhooks to our API", event taxonomy, payload envelope and schema versioning, HMAC signing, delivery guarantees and dead-letter policy, subscription lifecycle, the consumer debugging surface.
- Do not route here: consumer-side retry mechanics, signing-key storage lifecycle, sandbox mechanics.
### `samber/developer-platform-skills@sdk-portfolio-strategy`
- Route here: "which SDK languages first", generated vs handwritten, tiering and promoting community SDKs, sunsetting a low-usage SDK, release cadence, decoupling SDK SemVer from API versioning.
- Do not route here: single-SDK ergonomics, registry publishing mechanics, whether to offer SDKs as a surface at all.
### `samber/developer-platform-skills@mcp-server-offering`
- Route here: "should we ship an MCP server", choosing which tools to expose, securing write-capable tools, versioning the tool surface, judging MCP ROI.
- Do not route here: code-generation MCP builder skills, which scaffold what this skill specifies; documenting an existing SDK for agent consumption (`samber/developer-relations-skills@coding-agent-docs-optimization`).
### `samber/developer-platform-skills@sql-jdbc-access-design`
- Route here: "offer SQL access to customers", a JDBC/ODBC endpoint, connecting customer BI tools to product data, tenant isolation, the schema-stability contract, pricing a SQL add-on.
- Do not route here: bulk file delivery (`bulk-data-sharing-design`); ETL-platform connectors (`etl-connector-strategy`).
### `samber/developer-platform-skills@bulk-data-sharing-design`
- Route here: "ship customer data as Parquet", offering a warehouse or lake share, setting an export freshness posture, partitioning and schema-evolution contracts, egress cost allocation, cross-border residency.
- Do not route here: live SQL endpoints, ETL-platform connectors, surface selection.
### `samber/developer-platform-skills@etl-connector-strategy`
- Route here: "get us listed in an ETL platform catalog", build vs partner-built for a source connector, adding CDC to a SaaS product (honestly: API sources ship pseudo-CDC, never log-based), justifying connector engineering spend.
- Do not route here: pipeline-building for data teams; the vendor's own inbound connector marketplace.
### `samber/developer-platform-skills@developer-portal-design`
- Route here: designing or restructuring a portal, console or API dashboard, cutting time to first call, deciding where each self-service surface sits, portal search, RBAC and tenancy, build vs buy.
- Do not route here: internal service catalogs; designing any individual surface the portal hosts - each has its own sibling.
### `samber/developer-platform-skills@api-test-mode-design`
- Route here: designing a sandbox or test mode, choosing the isolation model, magic test values and simulated personas, on-demand test events, reset and seeding, graduation to live.
- Do not route here: code-execution sandboxing, unit-test mocking, a marketing try-it playground, partner sandbox _provisioning timing_ (`partner-app-onboarding`).
### `samber/developer-platform-skills@integration-error-observability`
- Route here: "build a developer-facing error dashboard", exposing request logs to integrators, correlation IDs that survive into a support ticket, alerting partners when their integration breaks, "cut integration support tickets".
- Do not route here: platform-wide incident comms (`api-status-communication`), webhook delivery mechanics, the shape of a single error response.
### `samber/developer-platform-skills@api-status-communication`
- Route here: designing or auditing a status page, writing incident updates or a public postmortem, uptime and SLA reporting, announcing planned maintenance.
- Do not route here: deprecation and breaking-change notices (`api-versioning-policy`), per-integration error surfacing, webhook delivery status.
### `samber/developer-platform-skills@integration-partnership-strategy`
- Route here: picking integration partners from demand data rather than relationships, tiering partnership depth on the referral-to-OEM ladder, evaluating a certification-program join, fixing sourced-vs-influenced partner attribution, where the function reports.
- Do not route here: your own marketplace, ETL-platform listings, integration-surface choice.
### `samber/developer-platform-skills@partner-app-onboarding`
- Route here: designing or auditing the partner-developer entry flow, self-service vs application-gated registration, when sandbox tenancy is provisioned, whether certification gates submission, cutting time-to-first-submitted-app.
- Do not route here: review-gate mechanics, sandbox isolation architecture, post-launch partner tier ladders, listing content, reseller sales enablement.
### `samber/developer-platform-skills@integration-listing-optimization`
- Route here: improving your own listing's conversion or search rank on someone else's marketplace, winning installs and compliant reviews, badge pursuit, defending rank against decay.
- Do not route here: anything the marketplace _operator_ decides - standards, review, monetization, promotion.
### `samber/developer-platform-skills@connector-marketplace-strategy`
- Route here: "should we build an app store", "is our ecosystem ready", setting the take-rate _level_ and curation posture, governing third-party apps at the policy level, seeding a two-sided ecosystem from zero, build vs join vs embedded iPaaS.
- Do not route here: partner onboarding, app review, listing standards, monetization _mechanics_ - all execution siblings; being a connector on others' data platforms is `etl-connector-strategy`.
### `samber/developer-platform-skills@app-marketplace-review`
- Route here: designing the review pipeline, setting approval criteria, what re-triggers review after an update, auditing app permissions, hardening the publish channel, appeal paths, delisting and revocation policy.
- Do not route here: submitter onboarding, listing-content standards, marketplace strategy.
### `samber/developer-platform-skills@app-marketplace-listing-standards`
- Route here: defining what every listing must contain, screenshot and media requirements, the description quality bar, category taxonomy design, rejection criteria, when stale listings get downgraded or delisted.
- Do not route here: optimizing your own listing on someone else's marketplace; the security review behind admission.
### `samber/developer-platform-skills@app-marketplace-monetization-model`
- Route here: merchant-of-record posture, billing rails, the fee stack and its anti-circumvention rule, fee waivers, payout cadence and hold windows, the facilitator/VAT tax layer.
- Do not route here: the take-rate _level_ and tier structure (`connector-marketplace-strategy`); this skill designs the collection mechanics under whatever level that skill set.
### `samber/developer-platform-skills@app-marketplace-launch-marketing`
- Route here: launching a marketplace, sizing the founding cohort, coordinating the reveal and partner embargoes, featured-app and spotlight rotations, allocating MDF and per-partner co-marketing budget.
- Do not route here: a vendor optimizing its own listing on someone else's marketplace.
### `samber/developer-platform-skills@developer-platform-career`
- Route here: breaking into an API Product Manager, Platform Engineer/Architect, or Partner/Integration Engineer role, prepping a platform-engineering or API-PM interview, evaluating an offer against this track's own ladder and comp benchmark.
- Do not route here: hiring for these roles (`developer-platform-hiring`), or a developer advocate, community manager, developer educator, or DevRel-flavored DX engineer target - `samber/developer-relations-skills@devrel-career`.
### `samber/developer-platform-skills@developer-platform-hiring`
- Route here: writing a posting, building a scorecard or interview loop, sourcing candidates, or setting a compensation stance for an API Product Manager, Platform Engineer/Architect, or Partner/Integration Engineer role.
- Do not route here: candidate-side prep (`developer-platform-career`), or hiring a developer advocate, community manager, developer educator, or DevRel-flavored DX engineer - `samber/developer-relations-skills@devrel-hiring`.
### `samber/developer-platform-skills@developer-platform-kickoff`
- Route here: project start, periodic check-in, "which skill do I need", re-routing mid-project. This skill routes; it never performs a sibling's job itself.
## Boundary pairs
Where two or more siblings collide on keywords, decide from these declared-scope boundaries.
**Split by altitude.** The kickoff's altitude rule names each macro/tactical pair; these are the questions that decide them at the boundary:
- **api-integration-surface-strategy vs every per-surface skill** - "Should we add GraphQL?" → strategy. "Design our GraphQL schema" → the surface skill. A surface question arriving with no audience attached is always the strategy question in disguise.
- **api-versioning-policy vs public-api-design-review** - "What are we allowed to change?" → policy. "Is this surface well-designed?" → review. A review that finds no agreed breaking-change definition escalates up to the policy.
- **sdk-portfolio-strategy vs api-idempotency-retry** - "Which SDKs first?" → portfolio. "What should the SDK do on a 503?" → idempotency-retry.
- **developer-portal-design vs api-auth-key-management / api-test-mode-design / integration-error-observability / api-reference-quality** - "Where does the key dashboard live and what else belongs on that page?" → portal. "What does a key look like and how does rotation work?" → key management. The portal decides which self-service surfaces exist and where; each sibling designs one of them.
- **connector-marketplace-strategy vs the four app-marketplace skills** - "Should we build one?" and "what take-rate?" → strategy. "How do we collect it?" → monetization-model. "What must a listing contain?" → listing-standards. "What gets rejected?" → review. "How do we launch it?" → launch-marketing.
- **integration-partnership-strategy vs partner-app-onboarding / etl-connector-strategy / integration-listing-optimization** - "Which partners matter?" → strategy. "How does a partner get from signup to first app?" → onboarding. "How do we get listed on their ETL catalog?" → etl-connector-strategy. "Why is our listing not converting?" → listing-optimization.
**Split by side of the table:**
- **integration-listing-optimization vs app-marketplace-listing-standards / app-marketplace-launch-marketing** - same words, opposite chairs. You are the submitter optimizing a listing you own on a marketplace you don't → listing-optimization. You are the operator writing the rules and promoting the catalog → standards and launch-marketing. Ask which side of the review gate the user sits on before routing any "marketplace listing" question.
- **api-auth-key-management vs oauth2-provider-design** - both are credentials you issue, split by whose data the caller acts on. The customer's own backend calling your API on its own behalf → API keys. A third-party app acting on your _users'_ behalf, needing consent → OAuth. Key management owns the decision boundary itself, so an unresolved "keys or OAuth?" starts there.
- **webhook-platform-design vs api-idempotency-retry** - both concern retries, split by direction. You delivering events to a consumer, with your retry schedule and dead-letter policy → webhook-platform-design. A client retrying its call into you, with idempotency keys and backoff → idempotency-retry.
**Split by scope of the audience:**
- **api-error-design vs integration-error-observability vs api-status-communication** - three altitudes of "something failed":
- One response body an integrator receives → api-error-design. "Our error messages are useless" routes here.
- One integration's history, aggregated and replayable, visible to the integrator who built it → integration-error-observability. "Partners don't know their integration is broken" routes here.
- The whole platform's health, visible to everyone at once → api-status-communication. "Customers didn't know we were down" routes here.
- **sql-jdbc-access-design vs bulk-data-sharing-design vs etl-connector-strategy** - three ways to give customers the data, split by who runs the pipe:
- You expose a live queryable endpoint or share → SQL/JDBC.
- You deliver files or a lake share on a cadence → bulk sharing.
- A third-party ETL platform pulls from your API on the customer's behalf → etl-connector-strategy.
Scan frequency and freshness expectations decide between the first two; who the customer already pays decides the third.
- **api-rate-limit-policy vs public-graphql-api-design** - GraphQL's depth and complexity ceilings are schema design decisions and live with the schema; the published quota, tier numbers, headers and 429 contract are policy and live with rate-limit-policy. A GraphQL cost model needs both, in that order.
- **partner-app-onboarding vs app-marketplace-review vs api-test-mode-design** - three stages of the same partner's path:
- Getting to a first submission → onboarding.
- What happens to that submission → review.
- How the sandbox they build in is actually isolated → test-mode-design.
## Ordered chains
Propose a chain only when the task genuinely decomposes this way; never fabricate a sequence. Each chain is listed in dependency order, not efficiency order - a later link consumes what the earlier one produces, so there is no ratio to rank.
- `api-integration-surface-strategy` → the chosen surface skill → `api-versioning-policy` - decide which surface, design it, then commit to what you will and won't break in it. Publish before the promise exists and every later change is negotiated case by case.
- `public-api-design-review` → `api-error-design` → `api-idempotency-retry` → `api-reference-quality` - audit, fix the error contract the audit exposed, make failing calls safe to retry, then document. Documenting first just freezes the flaws in prose.
- `api-auth-key-management` → `api-rate-limit-policy` → `integration-error-observability` - you cannot meter or attribute what you cannot identify; the identity issued first is what limits key on and what error rates split by.
- `oauth2-provider-design` → `partner-app-onboarding` → `app-marketplace-review` - apps need delegated auth before a partner journey means anything, and a journey before there are submissions to review.
- `connector-marketplace-strategy` → `app-marketplace-listing-standards` → `app-marketplace-review` → `app-marketplace-monetization-model` → `app-marketplace-launch-marketing` - settle whether and at what curation level, write what a listing must contain, define what gets rejected, wire up collection, then launch. Launching first means grandfathering every early listing.
- `developer-portal-design` → `api-test-mode-design` → `api-reference-quality` - the portal decides which self-service surfaces exist and where; the sandbox and the reference each land in a slot it already reserved.
- `integration-partnership-strategy` → `etl-connector-strategy` or `integration-listing-optimization` - the prioritization decides which platform is worth the connector or listing. Building either first pays a maintenance tax for a platform nobody's customers use.
- `webhook-platform-design` → `integration-error-observability` - delivery logs and replay are the debugging surface for the deliveries the first link creates.
## Sibling-repo recommendations
`developer-platform-skills` owns the _platform surface_: the API and its lifecycle, the integration surfaces around it, the portal, and the partner and marketplace ecosystem. Two sibling `samber` collections cover adjacent ground this collection intentionally excludes. Recommend installing the sibling instead of stretching a task onto a skill above that doesn't cover it; never frame it as a dependency - this collection stays fully usable standalone.
### `samber/developer-relations-skills` - DevRel practice
Recommend the sibling repo, not a skill above, when the task is:
- Site-wide docs information architecture, rather than endpoint-level reference completeness → `samber/developer-relations-skills@developer-docs-structure-audit`.
- The quickstart page and its first-run narrative → `samber/developer-relations-skills@developer-quickstart-guide`.
- Making an existing SDK, API or protocol consumable by a coding agent unattended → `samber/developer-relations-skills@coding-agent-docs-optimization`. Distinct from `mcp-server-offering`, which builds a _new_ agent-facing tool surface rather than documenting an existing one.
- Whether to evolve from product to platform at all, and how far up the openness ladder → `samber/developer-relations-skills@developer-ecosystem-strategy`. Upstream of `connector-marketplace-strategy`: the ecosystem question is "should we be a platform", the marketplace question is "should we run a catalog".
- The devtools revenue model, or what to open-source → `samber/developer-relations-skills@devtools-business-model`, `samber/developer-relations-skills@oss-distribution-strategy`.
- Anything else in the DevRel practice - developer content and SEO, community, events, open-source program operations. Start at `samber/developer-relations-skills@developer-relations-kickoff` when the boundary is unclear.
Distinguish from this collection: `developer-platform-skills` owns what the platform _is_ and what integrating with it costs; `developer-relations-skills` owns how developers hear about it, learn it, and stay. "Design our webhook platform" stays here; "write the tutorial that teaches it" goes to the sibling.
**Career and hiring split by what the role is screened on, not by the word "platform" in a title.** `developer-platform-career`/`-hiring` cover API Product Manager, Platform Engineer/Architect, and Partner/Integration Engineer - roles screened on API and system design judgment as a primary skill. `samber/developer-relations-skills@devrel-career`/`devrel-hiring` cover developer advocate, community manager, developer educator, and DevRel's own DX-engineer flavor - roles screened on communication and community craft. A "platform engineer" title is doubly ambiguous on top of this split: it can also mean internal developer platforms (Kubernetes, Backstage, golden paths), a population neither pair of skills covers - see `developer-platform-career`'s own disambiguation step before routing any "platform engineer" hiring or career task.
### `samber/dev-event-organizer-skills` - technical event operations
Recommend the sibling repo when the task is running a conference, hackathon, meetup or developer event as an _event_ - venue, sponsorship, CFP, speakers, budget, logistics - rather than as a DevRel program. A marketplace launch keynote is `app-marketplace-launch-marketing` here; producing the conference the keynote happens at is the sibling repo.
Coverage gaps this collection does not fill at all - per-marketplace submission playbooks, package-registry publishing mechanics, API changelog automation, federated-graph offerings, API monetization, connector certification programs, and deployed-integration health monitoring - are listed with their boundaries in `samber/developer-platform-skills@developer-platform-kickoff` § 8. Name the gap from there; never promise a skill exists.
SKILL.md›
---
name: developer-platform-kickoff
description: Before starting any developer-platform, public-API, or integration work - or whenever no other platform skill has been chosen - route the task to the right skill in samber/developer-platform-skills, or say plainly that none fits, then bootstrap or resume the project's shared platform context. Fires at every API or platform project start, at each recurring platform review, and whenever routing is unclear. Use whenever the user mentions a developer platform kickoff, a new public API program, an integration-surface roadmap, "which platform skill do I need", "where do I start with our public API", platform skill routing, or a recurring platform check-in - even if they never name a skill or ask to be routed. It spans REST, GraphQL and gRPC design, webhooks, SDKs, MCP, OAuth and API keys, rate limits, versioning, developer portals, docs, sandboxes, marketplaces, and partner strategy, so an ambiguous platform question belongs here first. Outputs a short-list and an ordered skill chain, never the design itself.
license: MIT
metadata:
author: Samuel Berthe
version: "1.0.2"
---
# 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.
## 1. Detect before asking
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.
**Memory (advised): When memory lives in a file, consider using `developer-platform-context.md`; if a different memory system is in use, rely on that instead. This file is an advisory reference, not a mandatory requirement. Separate task info in different sections. Remove finished tasks. Add a date to a task; no date for general project context. Some interview responses may differ between 2 tasks.**
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.
## 2. Interview - capped, tappable
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. **Use an interactive question mechanism (e.g. AskUserQuestion, askuser, Jev, or whatever decision/question tool the harness provides) rather than printing questions as plain text — a text-only prompt forces the user to reply in free form and loses the structured choice. Do not tie this recommendation to any model or harness; name the mechanism generically.**
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.
## 3. Route the task
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.
### API design
| Skill | Route 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 |
### API authentication
| Skill | Route 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 |
### API documentation and lifecycle
| Skill | Route 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 |
### Integration surfaces
| Skill | Route 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 |
### Testing, portal, and developer-facing operations
| Skill | Route 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 |
### Integration partnerships
| Skill | Route 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 |
### Connector marketplace (operator side)
| Skill | Route 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 |
### Meta
| Skill | Route 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.
## 4. Output shape
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.
### 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.
## 5. Context artifact
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.
## 6. Memory
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.
## 7. Routines
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.
## 8. Coverage gaps (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.
## 9. Invocation examples
- "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."
## 10. Failure modes
- **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.
## 11. Pass bar
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.
## References
- [`references/skill-routing.md`](./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.