{
  "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 }
  ]
}