Update to incident.io

{
  "description": "Understand the extensions so that you can help a user configure and manage their incident.io agent estate. Use whenever you're working with incident.io plugins, skills, connectors or MCPs in any way (\"I want to set up an incident plugin\"), when someone new wants to give incident.io's agents their own knowledge and doesn't yet know the pieces, or when you need to understand the user's existing configuration before editing a plugin or skill.\n",
  "included_files": [
    {
      "relative_path": "references/choosing-a-mechanism.md",
      "size_in_bytes": 4646
    },
    {
      "relative_path": "references/estate.md",
      "size_in_bytes": 13933
    },
    {
      "relative_path": "references/extensions-product.md",
      "size_in_bytes": 7909
    },
    {
      "relative_path": "references/scaffold.md",
      "size_in_bytes": 6275
    }
  ],
  "name": "extensions",
  "skill_md_contents": "---\nname: extensions\ndescription: >\n  Understand the extensions so that you can help a user configure and manage\n  their incident.io agent estate. Use whenever you're working with incident.io plugins,\n  skills, connectors or MCPs in any way (\"I want to set up an incident plugin\"), when\n  someone new wants to give incident.io's agents their own knowledge and doesn't yet\n  know the pieces, or when you need to understand the user's existing configuration\n  before editing a plugin or skill.\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- **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\nWhile you're driving a job — setting something up, writing or fixing a skill — each\nreply has this shape; a one-off question gets a plain answer:\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"
}