Building Reusable Plugins with WIQD: Skills and Connectors

Here is a word that has been quietly doing too much work: plugin. For most of the history of Microsoft 365 Copilot extensibility, a plugin was something you bolted inside one agent, which made the agent the only real unit of reuse, so the same capability in three agents meant three copies you then maintained badly. WIQD flips that: in Work IQ Developer Tools, a plugin is a first-class, independently shippable deliverable, and the agent is just one of the things a plugin can contain.

What Is a Plugin in the WIQD Model?

A plugin is a Teams app package that composes one or more capabilities into a single unit you can validate, package, provision, and share on its own. Those capabilities are:

• Skills, which are SKILL.md folders describing a workflow in natural language
• Agent connectors, most often a remote MCP server endpoint
• Declarative agents, the familiar declarativeAgent.json component

No parallel format was invented for this. The app manifest is the plugin schema, and skills, connectors, and agents are things the manifest references. That decision matters because it means a plugin is not a new artifact type you have to learn to publish. It is the artifact you already know, used as a container.

The disambiguation that trips people up on day one:

You want	The construct
A standalone, reusable deliverable with its own lifecycle	A plugin
A capability composed inside one existing agent’s manifest	An agent with an API or MCP action
A declarative agent as the primary artifact	An agent

If you are unsure, the useful question is: do you want something you can validate and ship on its own, or a capability added into an agent you already have?

This is not a Microsoft-only idea anymore. The Agentic AI Foundation announced Agent Plugins 1.0.0, an open, vendor-neutral packaging format for exactly this pattern: a directory with a plugin.json manifest, an optional skills/ folder, and an optional mcp.json for tool configuration, built to work across ChatGPT, Cursor, GitHub Copilot, and other compatible clients. WIQD’s wiqd.plugin.json descriptor and its agentConnectors/agentSkills composition are Microsoft’s take on the same underlying shape, so the mental model in this post, a plugin as a directory of composed capabilities rather than code baked into one agent, is now an industry-wide convention rather than a WIQD-specific one.

Composing a Plugin in One Conversation

The primitive is composition. You create a bare container, then add capabilities into it one at a time. Each add writes the artifacts and updates the plugin descriptor so the manifest and the descriptor never drift apart.

Here is the request I make most often: a skill that knows how to drive a remote MCP server.

Note what happened in the middle there. It fetched the MCP server’s tool list before writing the skill. That is the difference between a SKILL.md that references real tool names and one that references plausible-sounding tool names, which is the single most common way an agentic authoring flow produces something that reads beautifully and does nothing.

What Lands on Disk

The descriptor is deliberately light. It tracks what has been composed into the plugin, and it is maintained by the tooling rather than by hand:

{
  "name": "incident-response",
  "capabilities": [
    { "type": "connector", "name": "Ops MCP", "url": "https://ops.contoso.com/mcp" },
    { "type": "skill", "name": "Incident Triage", "path": "appPackage/skills/incident-triage" }
  ]
}

The connector lands in the app manifest’s agentConnectors array, at the root, where any component in the package can reach it. The skill lands as a folder with a SKILL.md inside, registered in agentSkills. And the skill itself is the interesting artifact, because it is the part that carries judgment:

# Incident Triage

Triage a production incident from first report to an assigned owner.

## Workflow

1. Call `list_incidents` filtered to status `open`. If the user named a
   specific incident, call `get_incident` instead.
2. Classify severity from the blast radius reported in the incident body.
   Never invent a severity that the incident data does not support.
3. For Sev 1 and Sev 2 only, propose paging the on-call engineer.

## Guardrails

- `page_oncall` is a side-effecting tool. Always show the user who will be
  paged and wait for explicit confirmation before calling it.
- `post_status_update` writes to the public status page. Draft the text,
  show it, and get approval. Never post directly.
- If `get_incident` returns nothing, say so. Do not summarize from memory.

That is the whole point of separating the two capabilities. The connector tells the agent what it can reach. The skill tells it what it should do and what it must not do. Bundling both into one reusable package means the guardrails travel with the tools, which is not true when you wire an MCP server directly into an agent’s actions array and hope the instructions cover it.

Validation Is the Gate

A plugin is not ready because it looks composed. It is ready because validation is clean. WIQD validates the descriptor and every component artifact together, which catches the class of problem that only shows up at composition time: a skill registered in the manifest but missing on disk, a connector URL that no longer resolves, an agent component referencing a capability the package does not declare.

The rule I hold to, and that the tooling holds to on my behalf: never call a plugin ready without a clean validate. Not “one warning we understand.” Clean.

wiqd plugin validate

That is the only command in this post, and you will mostly get there by saying “validate my plugin” instead. The commands exist, they take --json, and they drop into a pipeline unchanged. But the authoring loop is a conversation.

Reuse Is the Payoff

Once a plugin validates, it becomes a component you can pull into agents rather than a pattern you re-implement. The same incident-response plugin can front a dedicated support agent, get composed into a broader operations agent, and ship on its own to a team that only wants the triage skill. One artifact, one validation pipeline, one place to fix a guardrail when you discover it was too loose.

This is where the plugin-first model pays off against the old habit of wiring MCP servers straight into a single agent. That approach still works and is still correct for a one-off. But the moment a capability is worth using twice, the unit of reuse should be the plugin, not the copy-paste.

Packaging the capability this way also opens up where it can run. A plugin built once is not tied to a single declarative agent; it is a portable unit that other agentic surfaces, like Copilot Cowork and Microsoft Scout, can pick up and run with, which turns a single build effort into distribution across the whole Microsoft 365 Copilot agentic ecosystem.

The Value You Just Unlocked

• A real unit of reuse: Capabilities live in a package with its own lifecycle instead of being duplicated across agent manifests.
• Guardrails that travel with tools: The skill’s safety rules ship in the same artifact as the connector that exposes the side-effecting tools.
• Grounded skill authoring: Tool discovery happens before the SKILL.md is written, so instructions reference tools that actually exist.
• A descriptor you never hand-edit: Every composition step keeps wiqd.plugin.json and the app manifest in sync automatically.
• One validation gate: Descriptor and component artifacts get validated together, catching composition errors that per-file checks miss.

The mental shift is treating extensibility as something you compose rather than something you embed. Once the plugin is the deliverable, agents get cheaper to build, because most of what they need already exists as a package somebody validated.

Resources

• Agent Plugins specification (agent-plugins.org)
• Work IQ Developer Tools documentation
• Work IQ Developer Tools on GitHub
• Microsoft 365 Copilot extensibility overview
• API plugins overview
• Build API plugins with a new API for Microsoft 365 Copilot
• Build MCP plugins
• Declarative agent manifest schema 1.8
• Microsoft 365 Agents Toolkit overview
• MCP servers for declarative agents
• Dynamic tool discovery for MCP plugins