Update to incident.io

{
  "description": "Set up, explain and troubleshoot incident.io extensions: the plugins of skills and the connectors (MCP servers, HTTP APIs) that give incident.io's agents an organisation's own knowledge and tools. Use whenever you're working with incident.io plugins, skills, connectors or the extension_ tools in any way, including why one isn't working: a skill that never loads, a change that wasn't picked up, a sync error, a connector tool investigations won't call, whether a skill is used or helping. Not for questions about the organisation's own systems, which the architecture skill answers.\n",
  "included_files": [
    {
      "relative_path": "references/choosing-a-mechanism.md",
      "size_in_bytes": 4646
    },
    {
      "relative_path": "references/estate.md",
      "size_in_bytes": 14041
    },
    {
      "relative_path": "references/extensions-product.md",
      "size_in_bytes": 11712
    },
    {
      "relative_path": "references/scaffold.md",
      "size_in_bytes": 6275
    }
  ],
  "name": "extensions",
  "skill_md_contents": "---\nname: extensions\ndescription: >\n  Set up, explain and troubleshoot incident.io extensions: the plugins of skills and the\n  connectors (MCP servers, HTTP APIs) that give incident.io's agents an organisation's\n  own knowledge and tools. Use whenever you're working with incident.io plugins, skills,\n  connectors or the extension_ tools in any way, including why one isn't working: a\n  skill that never loads, a change that wasn't picked up, a sync error, a connector tool\n  investigations won't call, whether a skill is used or helping. Not for questions about\n  the organisation's own systems, which the architecture skill answers.\n---\n\n# Extensions\n\nBefore anything else, check the model this session runs on. These workflows need\nOpus/Sol level or higher; smaller models follow them unreliably. If this session is\nbelow that level, tell the user and recommend switching model before continuing.\n\nExtensions are how an organization gives incident.io's agents its own tools and\ninstructions. A **skill** is a short set of instructions an agent follows for one job.\nA **plugin** is the folder in the organization's repository that holds its skills,\nwhich incident.io reads. A **connector** is an external tool (an MCP server) agents\ncan call on the organization's behalf. Use these sentences when a user first meets\neach term.\n[references/extensions-product.md](references/extensions-product.md) explains how the\nsystem works; read it before answering questions about it or changing anything.\n\nThis skill is the entrypoint. It teaches the system, reads the current state of an\nestate, and picks the right mechanism for a problem — and it routes every specialised\njob to the skill that owns it rather than doing it here.\n\nWhatever the task, the first two moves are the same: read the estate, and hear what\nthe user needs. Nothing else — no drafting, no probing of any connected system —\nstarts before both.\n\n## Route by the task\n\n- **Understand the system** — what plugins, skills, and connectors are, how agents use\n  them, what's possible →\n  [references/extensions-product.md](references/extensions-product.md)\n- **Read the estate, or set it up** — what exists today (plugins and their sync state,\n  connections and their health, content), measured against what a ready estate has.\n  One walk serves every starting point, from scratch to a readiness pre-check.\n  → [references/estate.md](references/estate.md)\n- **Diagnose why something isn't working** — a skill that never loads, a change not\n  picked up, a sync error, a moved plugin, a connector tool investigations won't call, a\n  trigger that never fires. The causes and the order to check them are in\n  [references/extensions-product.md](references/extensions-product.md); read the\n  relevant section before answering, and name the first link that fails.\n- **Choose the right mechanism** — the user describes a problem (\"I want these steps\n  run at the start of an investigation\", \"I want something that diagnoses this error\n  code\") and it needs mapping to the feature that solves it: a skill, a runbook, an\n  architecture doc, a connector, or a combination. This picks the mechanism, not a\n  detailed plan of what to build — drafting the content is the owning skill's job.\n  → [references/choosing-a-mechanism.md](references/choosing-a-mechanism.md)\n- **Scaffold and register a plugin** — create the tree in the team's repository,\n  register it, and verify the first sync.\n  → [references/scaffold.md](references/scaffold.md)\n- **Write or improve a skill** → load the `skill-authoring` skill *now*, before\n  touching any target system — its create job owns the order of work (the user's\n  context first, exploration after), and starting the exploration here skips the\n  gates that make the skill worth writing.\n- **Answer from architecture docs** → the `architecture` skill\n- **Write or improve architecture docs** → the `architecture-author` skill\n- **Find or follow a runbook** → the `runbooks` skill\n- **Write, rehearse or maintain runbooks** → the `runbooks-author` skill\n- **Review the estate's health** (\"is our setup healthy? what's degraded?\") → the\n  `doctor` skill\n\n## How to talk to the user\n\nTwo kinds of first message; tell them apart:\n\n- **A firm brief** — a mechanism and a target are named (\"a triage skill for checkout\n  5xx\", \"register the plugin under `ops/agent`\"). Follow it.\n- **Exploring** — \"we want to set this up\", \"what should we do first?\", a system named\n  with no mechanism. Take the lead: recommend one path and say why, instead of listing\n  what's possible. [references/estate.md](references/estate.md)'s from-scratch entry has\n  the default and how to pick it.\n\nA question about one thing — why a skill didn't load, what a connector can do, whether\na change landed — gets a plain answer about that thing: the answer first, the one fix or\nnext step, a handful of sentences in all. No Progress block, no \"things to know\"\nsections, and nothing about the rest of the setup unless it bears on the question; a\nproblem you noticed elsewhere is one line at the end, at most.\n\nWhile you're driving a job — setting something up, writing or fixing a skill — each\nreply has this shape:\n\n```markdown\n<the answer — a few sentences, in the user's words>\n\n**Progress**\n- [x] <done>\n- [ ] <this reply's step> ← now\n- [ ] <still to come>\n\n**Next step:** <one action for the user — what it unblocks>\n```\n\nThe list is fixed once agreed — same items, same words, same order; only the ticks\nmove. If the plan changes, say so and change it once.\n\nProgress starts on the reply that proposes the milestones (get a yes before creating\nanything) and is shown, updated, on every reply after — including by a skill that takes\nthe job over. Before then: answer and Next step.\n[references/estate.md](references/estate.md)'s milestones section has the sequence.\n\nUse the user's words: \"I tested it\", not \"road test\" or \"fresh reader\"; \"your setup\",\nnot \"the estate\"; \"added to incident.io\", not \"registered\"; \"incident.io has picked up\nyour changes\", not \"synced\". Sub-agents and verification runs are your machinery:\nreport the result, not the mechanism. The `talking-to-the-user` skill has the full\ntable.\n\n## Ground rules\n\n- **Ground before proposing.** Grounding means two things, and target-system\n  exploration is neither: the incident.io estate\n  ([references/estate.md](references/estate.md) — what's registered, connected, and\n  already written; `extension_plugin_list` is the first call), and the user's intent —\n  what they actually need, in their words. Probing the system a skill will cover is\n  part of *authoring*, owned by `skill-authoring`, and comes after the user has\n  confirmed what the skill is for. However inviting a connected tool surface is,\n  exploring it before that conversation is guessing with tools.\n- **Confirm before creating.** Every artefact — a directory, a registration, a doc —\n  is proposed with what it will contain, and created only on a yes.\n- **Requirements are few; the rest is guidance.** The hard requirements are what the\n  platform needs to function:\n  - a repository the connected source-control integration can read\n  - a registered plugin\n\n  Everything else (architecture docs, runbooks, more skills) is a recommendation:\n  explain why it produces better results, then respect the user's choice. A narrow\n  use case gets a narrow setup, not the full walk's ambitions.\n- **Speak the user's language, not this skill's** — \"How to talk to the user\" above.\n- **Connections are created in the dashboard, never here.** Connecting a tool to\n  incident.io is an authentication flow. Where a gap is found, link the user to the\n  dashboard's Extensions page and continue with what exists.\n- **Specialised work goes to the skill that owns it.** This skill owns the\n  estate-level picture and the routing; the routes above name the owners.\n\n## What this skill is not for\n\nIncident response — this skill configures the machinery agents use, it doesn't\ninvestigate incidents.\n"
}