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.