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

API authentication

API documentation and lifecycle

Integration surfaces

Testing, portal, and developer-facing operations

Integration partnerships

Publishing-platform playbooks

Connector marketplace (operator side)

Meta

The altitude rule. Nine 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.
• sample-app-strategy decides which sample repos exist and when they retire, while api-test-mode-design builds the sandbox they run against.
• 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.
• public-roadmap-strategy decides what the platform publicly promises next, while api-versioning-policy and api-status-communication handle what it retires and what is broken now.
• api-versioning-policy governs a surface once it is GA, while the tactical api-beta-program runs everything before GA, including retiring one preview version for the next.

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, docs cited at the right version by AI assistants, docs translation, how the docs track several versions (switcher, archives, backports), routing developer feedback to product and back, coordinated vulnerability disclosure for an open-source SDK, the release and versioning policy of an open-source SDK or library (SemVer vs CalVer, 1.0, supported versions, backports), a maintainer burning out on or stepping down from an open-source SDK, a maintainer wanting to earn money from an open-source SDK or library, the product-to-platform decision upstream of a marketplace, a developer certification or badge program for people (not apps), a Show HN or the company's conduct on Hacker News, a vendor's or maintainer's dev.to presence (cross-posting, tags, AI disclosure), a launch or relaunch on Product Hunt, 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, api-changelog-automation. Buys the documented contract, and its enforcement, that prevents the noisy-neighbour, leaked-credential and surprise-breaking-change incidents before they happen. Costs a policy session plus gateway, credential-store or CI configuration and a rotation or approval path - and a published limit or scope is reversible only in the generous direction.
4. Debuggability - integration-error-observability, integration-health-monitoring, api-test-mode-design, api-status-communication, stackoverflow-playbook. Buys integrators who diagnose themselves at 2am, partners who learn their integration broke before the customer tells them, and a searched error that lands on a current canonical answer. 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, sdk-package-publishing, sample-app-strategy, developer-portal-design, github-engagement-playbook. Buys the step-change in what integration feels like: push instead of polling, an idiomatic client instead of raw HTTP, a maintained sample to fork instead of a blank file, one place answering every self-service question, an SDK repository whose releases reach the people watching it. 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, cli-interface-design, github-action-offering, ide-extension-offering, terraform-provider-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, graphql-federation-offering, integration-listing-optimization, app-marketplace-review, connector-certification-program, app-marketplace-listing-standards, app-marketplace-monetization-model, app-marketplace-launch-marketing, zapier-integration-playbook, salesforce-appexchange-playbook, slack-app-directory-playbook, atlassian-marketplace-playbook, github-marketplace-playbook, aws-marketplace-playbook, microsoft-appsource-playbook, shopify-app-store-playbook, hubspot-marketplace-playbook, chrome-web-store-playbook, google-workspace-marketplace-playbook, wordpress-plugin-directory-playbook. 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, public-roadmap-strategy, etl-connector-strategy, integration-partnership-strategy, connector-marketplace-strategy, agent-integration-surfaces. 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.