sohaibtariq

> Have you vetted your skills for accuracy and conciseness? Accuracy, yes. Conciseness could be better.

> Regarding harness-level skill usage, that should be relatively easy...

Users can analyse their own sessions, but I'm wondering if there's a feedback channel from the harness back to the skill author. Something that respects the users' privacy while still surfacing useful feedback.

Thanks for sharing! In your case, since the skill terminates in an MCP/API call, you have a closed feedback loop.

I was wondering about skills that don't have that feedback loop, where the output the agent produced doesn't touch an external server. For instance, the frontend-design skill from Anthropic.

How would someone get insights into the user's experience of using that kind of skill?

The key insight for us was that the context needs to be language-specific and structured around actual SDK methods, not just an API Reference or OpenAPI Spec. Both of those provide context on the shape of the API but leave it to AI agents to figure out exactly how to call API endpoints and then translate that into code - handling auth, errors, pagination, rate limits etc.

That's 2 levels of inference, one of which can be avoided by providing SDKs and context for those SDKs. The SDK wraps all the plumbing for interacting with the API; AI agents just need to figure out which methods to call.

If you get a chance to try one of the examples in the showcase, we'd love to hear your feedback.

Very cool.

If we want AI assistants to contribute to a codebase like a productive member of the team, they need the same kind of context you’d give a new hire. Coding standards, infra conventions, testing patterns, and the shape of the system all matter.

We’re focused on a narrower version of that same problem.

First, we want to make it simple for any team to adopt a new library or SDK without reading a pile of docs or spending hours writing and debugging integration code. The goal is to make it easy for an agentic coding workflow to absorb a new API library quickly and use it correctly.

Second, a lot of teams are already maintaining their own AI context across AGENTS.md files, skills, and MCP servers. That means API providers, and really maintainers of any library at this point, need to provide a context layer that fits into what teams have already built. Adding a new dependency shouldn’t force every team to create and maintain a separate context layer just to consume that API well.

That’s the part we care about a lot: SDK context should be generated and maintained automatically, stay in sync with the SDK and docs, and avoid becoming extra work for either the API provider or the API consumer.

Good question. In our case, Context Plugins are not maintained as a separate context layer that can drift from the rest of the API surface.

APIMatic offers an entire Developer Experience Platform where everything is generated from the same API spec. We already generate SDKs, API portals and API Copilots from that source. Context Plugins are another artefact generated from that same pipeline.

That means when an API provider updates their spec and runs their release pipeline, the SDKs, docs, and Context Plugins all update together. So in practice, there’s virtually no lag between a release and the context reflecting that release, because they’re all produced from the same source at the same time.

On the stale context question, there’s also a useful signal there. If a developer has an older SDK version installed and starts a new session after a newer release is available, the Context Plugin can see both the installed SDK version and the latest published version. So it can surface that a newer SDK version exists.

That sync is a big part of the value for us. The goal is to keep docs, SDKs, and AI-facing context aligned so developers and AI assistants always have up-to-date information about an API, without adding maintenance overhead for API teams.

From our benchmarks and internal tests, we’ve noticed a few trust signals developers look for.

The first is simply what the model appears to be grounding on. If it’s pulling up SDK method names and library docs, developers feel much better about the result than when it looks like the model is piecing things together from web search, blogs, GitHub snippets, or other unofficial sources.

We’ve also found that even among authoritative sources, there’s a real difference between an OpenAPI spec or API reference, and SDK documentation. An OpenAPI spec or API reference is authoritative, but it still leaves the model with a lot to figure out. It has to infer how to authenticate, how to handle pagination, what to do in case of errors/failure, and then turn all of that into working code in the right place in an existing app.

That’s a long chain of inference, and every extra step is another place where things can go wrong.

SDK context cuts out a lot of that. Much of the complexity is already wrapped in the library, so the model is usually figuring out which SDK method to call and how to wire it up, instead of inventing the integration from scratch.

In practice, the biggest trust builder is the outcome: does the generated code run on the first try?

That’s the outcome developers care about most, and it’s the pattern we saw in our user tests. Context Plugins help get much closer to that outcome.

We’ve published a case study that goes deeper into the numbers here: https://www.apimatic.io/product/context-plugins/case-study

Try out https://www.apimatic.io/transformer/ for converting Swagger Specs to OpenAPI