developer-platform-kickoff

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…

...