Loading today’s stories
Build1 publisher3 min readPublished
Copilot Extensions, Claude tools, LangChain tools and Spring AI functions share one three-part anatomy. A dev.to walkthrough shows that the schema ports for free and the registration does not.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
The schema is the only part of the construct the model touches, and the walkthrough's own flow says so: the LLM reads the schema at inference time, judges whether the skill is relevant, and calls it with arguments extracted from the user's sentence, with no human pressing anything [3]. That makes every description string prompt text. The Copilot manifest is honest about it. Beside the parameter descriptions sits an `instructions` field telling the model to reach for the extension when the user asks about deployment status, service versions, recent deployments or production incidents [8]. Word that badly and nothing throws; the model just never calls you, and answers from whatever context it already had.
Defaults do the same quiet work. In the manifest, `service` is required, while `environment` is an enum of dev, staging and prod with a default of prod [9]. Any request the model cannot pin to an environment therefore resolves to production. For a read-only status check that is the sensible default. The moment a skill of this shape can write, that one line is the safety argument, and it lives in a manifest rather than in the code path anyone reviews.
Registration is the part that does not travel, and it is the only part the supplied text documents end to end. Before the handler runs, the Copilot route needs a GitHub App carrying four settings: the webhook URL, Copilot Chat read permission under account permissions, the Copilot Extension checkbox, and an OAuth callback URL if the skill acts on behalf of the user [7][12]. At runtime the server verifies a GitHub HMAC signature using `node:crypto` and `timingSafeEqual` against a `GITHUB_WEBHOOK_SECRET`, and works with a Copilot token GitHub issues per request [10]. Count the network legs in that path and there are three, only one of which you initiate [13]. The leg you do not initiate is inbound, which is the expensive word here: a public HTTPS endpoint that GitHub can reach and that you authenticate on every call.
The guide's claim is that the four platforms differ mainly in vocabulary [1]. The supplied material supports that for the schema, since the parameter contract for the deployment checker would survive a move, and the example was picked precisely because it makes an external API call, takes structured parameters and returns structured data for the model to format [4][14]. It does not support the claim for registration, because the text stops mid-file inside the Copilot handler, before the Claude MCP tool and the reusable agent skill are built [11]. For the Copilot bill to transfer, the other three would have to reach your code the same way, and nothing in this material shows that they do. On this evidence the parameter contract is what you reuse, and registration is what you re-buy.
Ranked by verification strength, evidence, and original report placement.
The documented request path: developer types @deploy-status in Copilot Chat, GitHub routes the message to the extension's webhook URL, the extension server verifies the GitHub HMAC signature, returns 401 Unauthorized if invalid, parses the conversation from the payload, calls the deployment API, optionally calls the Copilot LLM API to format the response, and streams it back over SSE.
The guide models an AI skill as three parts: schema (what the skill does, what inputs it accepts, what it returns), implementation (the code that executes when called), and registration (how the AI model discovers the skill exists).
The worked example is a deployment status checker that, given a service name and optional environment, returns the current deployment status, last deploy time, version and any active incidents, implemented three ways: a GitHub Copilot Extension, a Claude MCP tool, and a reusable agent skill for any LLM.
The GitHub App must be created with a webhook URL pointing at the extension server's /api/github/copilot endpoint, Copilot Chat Read permission under account permissions, the "Copilot Extension" box checked in app settings, and a callback URL for OAuth if the skill needs to act on behalf of the user.
The extension manifest carries name "deploy-status", a description, and an instructions field telling the model to use the extension when the user asks about deployment status, service versions, recent deployments or production incidents, and that it can check any service across dev, staging and prod.
In the manifest's parameter schema, service is a string described as the service name (e.g. payment-service) and is listed as required; environment is a string with enum dev, staging, prod and default prod.
Publishers with included, body-backed reporting in this cluster.
1 article · September 8, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
Grok 4.6 lands in Copilot two days after launch, and the model picker becomes a procurement problem1 publisher
build
Retry budgets are sized against outages, not jitter: 45 seconds lost all sixteen clips1 publisher
build
Strapi will send that webhook twice, so your receiver owns the idempotency key1 publisher
build
GitHub's Java agent runtime ships as a Maven dependency, and the tool schema comes from reflection1 publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Evidence rests on one community tutorial alone
Every platform detail here comes from one dev.to author: the Copilot Chat read permission, the /api/github/copilot convention, the signature header, the SSE stream. Nothing links to GitHub's or Anthropic's own docs. The manifest and schema are strong evidence of themselves because the JSON is on the page, but the code that surrounds them raises a question it never answers, using x-github-token as the HMAC comparison value and again as the API key for the model call. Two of the three implementations promised at the top are absent from the text we have.
Evidence stops at a worked example, not a deployment
Our coverage records no extension listing, install count, or team running a deploy-status participant against a real cluster. A worked example is not a deployment, and with one publisher there is no second account to supply usage.
Three platforms promised, one delivered in part
The framing is that terminology is the only real difference between Copilot Extensions, Claude tools, LangChain tools and Spring AI functions. The one implementation actually shown needs a GitHub App, a hosted public webhook, signature verification and an SSE response before a single line of deploy-status logic executes. Identical at the schema level, as the manifest shows; the same page's own setup list is the counter-evidence for everything above it.
Reputation-driven community post, personal effort only
dev.to posts pay their authors in reach rather than revenue, and this one pitches no course, SaaS or hosting layer. The pull that shows is toward breadth. Naming four ecosystems draws readers, and that is also why the piece runs out of room after the GitHub leg.
Single incomplete document
One publisher, one document, and that document is cut off mid-handler. We are confident about what the JSON says and much less confident that the GitHub App settings, headers and endpoint names would survive a check against the vendor's own screens.