> ## Documentation Index > Fetch the complete documentation index at: https://docs.incident.io/llms.txt > Use this file to discover all available pages before exploring further. # Extensions > Bring your own systems, docs, and procedures to Investigations and the @incident agent. Extensions are currently in **Private Beta**. Get in touch by [email](mailto:support@incident.io) or our shared Slack channel if you'd like to try them out. Extensions are the skills, docs, and tools you bring to incident.io's agents, Investigations and `@incident`. With them, the agents can reach internal systems we have no integration for, read the data those systems return the way your team does, and follow the procedures you want used for a particular kind of incident. There are two kinds: * **[Plugins](/nexus/extensions/plugins)** are content agents follow: skills and docs, synced from one of your repositories. A skill teaches an agent how to work in your environment, and a plugin is the bundle that carries it. * **[Connectors](/nexus/extensions/connectors)** are systems agents call: a remote MCP server or an HTTP API you've connected, so an agent can query something we have no native integration for. Most teams end up with both, because a skill is what tells an agent when to use a connector and what its results mean. Plugins use the open [agent skills](https://agentskills.io) and [Claude Code plugin](https://code.claude.com/docs/en/plugins) formats, and connectors speak [MCP](https://modelcontextprotocol.io/) or plain HTTP. A plugin you write for us also loads in your own coding agents, so everything you write stays portable. ## How agents use extensions Extensions sit alongside the telemetry, code, and docs that [Nexus](/nexus/overview) already gives our agents, and are used in the same two places. ### Investigations Skills, docs, and connectors are picked up automatically. A skill is loaded when its description matches the work in front of the investigation, and connector tools are queried the way any other source is. Whatever comes back is interpreted alongside everything else the investigation has found, and shapes its conclusions. A skill that owns a system or a class of incident is followed at the very start, alongside the initial searches, so you get a more accurate first hypothesis, faster. See [Triage skills](/nexus/extensions/plugins#triage-skills). ### The agent Ask [`@incident`](/ai/at-incident) something, wherever you talk to it, and it reaches for the same skills and connectors. Ask for an impact assessment and it can combine the incident's alerts, a skill that says how your team sizes impact, and a connector to your data warehouse to produce one on demand. ## A worked example Here's a small plugin and connector working together, modeled on how we use extensions ourselves. **The problem.** A customer reports that a feature has stopped working for them, and only them. Nothing is down. The most common cause is a feature flag whose targeting changed in a way that caught that customer. Investigations already see your change events. A connector adds the flag system itself, and a skill adds how your flags are structured. **The connector.** You connect your feature flag provider's MCP server as a connector and allow its read-only tools: get a flag, list flags, read targeting. Investigations can now call it. On its own, though, an agent will use it the way a new hire would, taking flag names and targeting rules at face value. **The paired skill.** A skill named after the flag system teaches the agent to use those tools the way your team does: ```markdown skills/feature-flags/SKILL.md theme={null} --- name: feature-flags description: > Look up feature flags: find the flag behind a described behavior, work out which customers or environments have it enabled, and read its targeting correctly. Use before any flag lookup, and whenever asked "is on for ". --- # Feature flags Two registries, and using the wrong one is the usual mistake. `flags.go` in the backend declares every flag with a comment saying what it gates, so that's where a flag's meaning lives. The flag provider holds current targeting: who has it on, in which environment. ## Reading who has a flag on Customer IDs appear in two idioms. Older rules target the `organisation` attribute on a user context, newer rules target an `organisation` context directly. Both are live, so check both before saying a customer isn't targeted. A rule that targets a segment names none of the customers in it. Expand the segment before reporting who is enabled. Resolve IDs to names through the catalog before reporting them. `01ET65M7...` is our own organization and appears in most flags as the dogfood rule, not as a customer. ... ``` None of that is in the tool definitions. It's the knowledge an experienced responder holds. **The triage skill.** A second skill owns the incident class rather than a system. Its description says it applies to incidents affecting a single customer, so it's picked up at the start of any incident that looks like that. Its procedure is the opening moves your team would make: establish which customer, check the change events for flag flips in the window, then use the `feature-flags` skill to read what changed for them. Its findings are in hand when the first hypothesis is formed. ```markdown skills/single-customer/SKILL.md theme={null} --- name: single-customer description: > Opening procedure for incidents affecting one customer while the platform is otherwise healthy. Use when an incident names a single customer, tenant, or account as the only party affected. --- # Single-customer incidents 1. Establish which customer. Take the account from the incident's fields or the reporting message, and record it as inferred if you had to guess. 2. Check change events for feature flag changes in the hour before the report. 3. Follow the `feature-flags` skill to read what each changed flag serves that customer, and whether a segment or rule change explains the timing. ... ``` The connector provides access, the paired skill provides the understanding to use it, and the triage skill provides the procedure. ## Getting started Connectors are set up and plugins are registered from [Extensions](https://app.incident.io/~/nexus/extensions) in your dashboard. Writing the plugin itself is best done in your repository with your own coding agent, using the [official incident.io skills plugin](/nexus/extensions/incident-skills-plugin), which knows how to author skills that work well with our agents and can register and verify them for you. Create your first plugin with your coding agent. Bring your team's skills and docs. Connect your MCP servers and HTTP APIs. ## Related The sources Investigations draw on, and how to set each one up. How evidence becomes a finding.