Skip to main content
Extensions are available to every organization with Investigations.
The incident.io skills plugin is an open source plugin for your coding agent. Install it in Claude Code, Claude Desktop, Cursor, Codex, or another agent that reads the plugin format, and your agent learns how to build extensions that work well with our agents: what makes a skill get selected and followed, how to check your existing setup before drafting, how to register and sync a plugin, and how to read the feedback we record about each skill once it’s live. The plugin bundles the incident.io MCP server, which is how your agent reads your plugins, connectors, and skill feedback, and registers and verifies changes.

​
Installing

Install the plugin in your coding agent following the installation instructions on the remote MCP server page, which cover Claude Code, Claude Desktop, Cursor, Codex, VS Code, and other agents. The first time a skill uses the incident.io connection, your agent will ask you to sign in to your incident.io account.
These skills need a large model. Run them on Claude Opus, GPT-5, or equivalent. Smaller models follow the workflows unreliably, and the skills say so when they detect one.

​
What the plugin gives you

A set of skills, each owning one job. Your agent picks the one that fits what you ask, or you can invoke one directly with /incident-io:<skill>. They help with:
  • Building extensions: working out whether a plugin or a connector solves your problem, writing and verifying skills from your team’s knowledge, and checking the health of your setup.
  • Documenting your systems: writing architecture docs that our agents read during an incident.
  • Working with incident.io: checking who’s on call, and querying the telemetry you’ve connected.
The repository README has the current list of skills. The plugin carries our guidance, not your content. Your skills and docs live in your own repository, next to the code they describe and reviewed like it.

​
Getting started

The guides below run in your coding agent. You can invoke a skill directly, or just say what you want in plain language and let the agent pick the one that fits.

​
Creating your first plugin

Invoke the extensions skill and your agent checks what you already have before proposing anything. It will confirm every file and registration with you before creating it.
Example session
From here the agent asks about the case you have in mind, drafts the skill from what you tell it, and proposes where in your repository the plugin should live. It’s your knowledge that goes in: the agent asks for the specifics an experienced responder would know rather than writing a generic skill about a topic. See Writing skills that work for what makes the difference. You can also start with reference material about your architecture, or just create an empty placeholder to fill in later. A plugin needs at least one skill to sync, so an empty one can be registered but shows a sync error until its first skill merges.
Example session

​
Syncing to incident.io

The agent registers the plugin as part of creating it, and the first sync starts right away. Two things need to be true for it to land:
  • The repository is connected to incident.io. Plugins sync through your connected GitHub or GitLab integration, so connect the code repository first.
  • Your changes are on the default branch. Syncs read the default branch, so the plugin’s skills appear once your branch merges, not before.
To confirm it landed, open Extensions in your dashboard, or just ask your agent. A healthy plugin shows a completed sync with your skills listed; an unreachable repository or malformed plugin shows a sync error with the reason. From then on we re-sync hourly, and your agent can trigger a sync whenever you push a change you want picked up now. See Plugins.

​
Adding a skill

Once you have a plugin, the flow is shorter, because the setup is done. The agent still checks first: whether a similar skill already exists that should be edited instead, and whether the systems the skill would lean on are actually connected.
Example session
Connecting a system is done in the dashboard, as a connector. The agent links you there and carries on with what exists.

​
Turning runbooks into skills

If your team already has runbooks, ask your agent to find them and it looks wherever they live: your repository, a Notion or Confluence space you’ve connected as documentation, or somewhere you point it at. Ask it to turn a runbook into a skill and skill-authoring rewrites the procedure for an agent: what to establish, which tools to use, how to read what comes back, and what to do when a step can’t be completed. Several runbooks about the same system usually become one skill with a reference file per case. See Adapting existing runbooks for why the translation matters.

​
Verifying a skill before you merge

Before a skill ships, the agent can verify it against incident.io. A fresh agent that has the skill, and no knowledge of what you meant it to do, is handed a realistic request, and what it does is graded against what should have happened. Nothing needs to merge first: the agent can verify a change to a plugin that’s already synced, the files on your disk before they’re committed anywhere, or a branch you’ve pushed. Uploaded files are held to the same size limits as a sync.
Example output

​
Limits of verification

Verification calls your telemetry and connectors for real where it’s safe to, and simulates the rest. For a simulated call, the agent assumes a likely result and carries on. That shows the skill picks the right tool, but not that the tool returns what the skill expects. Some calls are always simulated:
  • Calls that change something. Any tool classed Write, Destructive, or Unknown (see Tool classes). We won’t delete a record or send a message just to test a skill.
  • Calls you aren’t allowed to make. A verification runs as you, with nobody watching. It only makes reads you could make yourself from an MCP client (see Permissions). A tool that’s switched off, limited to other people or teams, or needs a person present is simulated.
Verification is our best check before a skill ships, but it can’t give complete certainty. The best evidence comes once the skill is live. Check the issues on the skill’s page in the dashboard (see Seeing how a skill is used), then ask your agent to fix them, as described in Improving skills over time.

​
Improving skills over time

​
From real usage

Every time an agent loads a skill during an incident or a chat, we record it and, once the run is scored, assess it: was the skill followed, did following it help, and what specifically held it back. You can read this on each skill’s page in the dashboard, described under Seeing how a skill is used. Ask your agent to improve a skill and skill-authoring reads the same feedback, fixes the issues by theme without undoing what the feedback credits, and verifies the fix where it can.
Example session

​
Keeping your setup healthy

Run doctor on a schedule as well as on demand. It reviews your plugins, skills, and connections and says what to fix: a plugin that stopped syncing, a skill that keeps loading but never gets followed, feedback issues worth acting on. It never edits anything itself, so it’s safe to run weekly.

Plugins

What a plugin contains, and how skills are selected and synced.

Connectors

Connect an MCP server or HTTP API so skills have something to call.

Remote MCP server

Installation for each coding agent, and everything else the MCP server can do.

Extensions overview

How plugins and connectors fit together.