Agent Plugins 1.0: The Plugin Is Easy. The Spec Is the Skill.

Packaging a workflow just got easy

On August 6, 2026, Agent Plugins 1.0 was published as an open, vendor-neutral standard for bundling Agent Skills and MCP servers into one portable package. A plugin is a folder with a plugin.json at its root, and compatible agent clients, including Codex, Cursor, GitHub Copilot and VS Code, can find it and load it.

That matters because I had skills that worked for me and connectors that worked for me, and no clean way to hand a teammate the whole thing. Now I can: install this, it does what I do.

What my plugin does, with a person at every decision

Cost-saving work usually starts as a sentence buried in a message, such as high-billed, highly volatile resources that keep popping up like a game of whack-a-mole. Turning that sentence into action used to take me a few hours: find the lead, research it, confirm the numbers, write the ticket, write the email.

My plugin reads the email or chat message and restates the claim for me to confirm. It then searches private data through the data platform's own command-line tool, so the numbers come from the company's own system instead of the model's memory. When I approve the finding, it creates the ticket in the ticketing system. Then it drafts the follow-up email, and I edit and send it. The same shape works with any data platform that has a command-line tool and any ticketing system. What took a few hours now takes a few minutes. I built it for an enterprise client I provide consulting services to, so I can't show the findings; the pattern is the part I can share.

Notice what this is not. It is not a traditional web application, and it is not a chatbot. A web application is a fixed set of screens and forms that someone designed in advance, and you work inside them. A chatbot answers a question in a window and stops. This workflow has no screens and no chat window to live in. It is a series of actions, read a message, query a data platform, file a ticket, draft an email, across tools that were never built to talk to each other, and the agent connects them together, coming back to me only at the decisions that are mine. That is outside the common sense most of us learned from building web apps, and it is why I think of a skill as automation more than as software.

“The agent does the searching and the drafting. I keep the judgment and the send button.”

Finding the right person, then the right words

A finding changes nothing until it reaches someone who can act on it. So the plugin does not just draft an email to whoever is on the thread. I ask it to work out which owner or team the finding belongs to, tell me who it would talk to and why, and I confirm, like every other step. Then it drafts in a tone that fits the person and the moment. A heads-up to a peer on Slack reads differently from a note asking a finance lead for a decision, and both differ from a message to an engineering manager whose team's work is affected.

Sending a well-aimed message is the easy case, the low-hanging fruit. It is what my 7 Figures of Impact work is built on: personalized outreach that drew a 10% email response rate against 70% Slack engagement within 24 hours. Automating that kind of nudge is now simple.

Some changes go deeper than a nudge. Changing how a shared system is set up, or retiring something, touches use cases I may not know about. For those, I have the agent research the different use cases first: who depends on this and for what. Then I ask it to write down the boundaries: what is in scope, what is not, and what must not change. The message that follows says plainly what we are asking for and what we are leaving alone. Clear boundaries are what let a deeper change be raised without alarming anyone. The research is a starting point, and I check it with the people who live with the system.

How I built it: the spec first, and an interview before the spec

I did not start by writing the plugin. I started with GitHub Spec Kit, the spec-driven development path from principles to a spec, a plan, tasks and then code. Before I wrote the spec, I ran the Grill Me skill on my own idea. It interviews you about the plan until the gaps and hidden assumptions are out in the open.

The key to the data step is that I never write the commands. The platform vendor already ships a command-line tool that handles sign-in and permissions, and the agent is smart enough to translate a plain-English request into the full command, flags and all. What it needs from me is clear instructions: which question to ask, which system to ask it in, what to report back, and when to stop and wait for me. Writing those instructions clearly is the real work, and it is exactly what a spec is. That interview is also where the three approval points came from: confirm the claim, confirm the evidence, review the email. An agent that files tickets and writes to people without asking is a liability. The speed comes from removing the searching and typing, not the person who answers for the result.

One caution before you share a plugin with a whole team. Analyses of version 1 note that it does not yet define provenance, permissions or signing. Treat a plugin like any script from a teammate: read what it does, limit its access to what the job needs, and install only what you trust.

Humbled and anxious, and what I do with both

The same jump in the agent harness shows up in the courses I have finished teaching at CSTU. Students are building fully functional shopping-cart sites and subscription-based platforms. Some are repackaging my own material into something ten times better than my original. I am humbled, and I am anxious.

Here is where I landed. If a student can out-produce their teacher in a semester, then what I teach cannot be the typing. It has to be the part that came before the code in my plugin: being asked the right questions, writing down what good looks like, and checking the result against it. That is a skill, it can be practiced, and it is the one thing a plugin cannot package for you.