incident.io

Answer questions about how the organisation builds, deploys, and runs its software — what a system is, where it runs, what it depends on, and the real names of things (cloud projects, clusters, namespaces, hostnames, buckets) — from architecture docs wherever they live. Use when asked "how does X run", "what is Y", "where does Z live", or when grounding a component before debugging it.

Write and maintain architecture docs — the documents that say what each system is, where it runs, what it depends on, and the real names of things (cloud projects, clusters, namespaces, hostnames, buckets). The heart of it is an interview that pins down what each system name actually means before anything is written. Use when asked to write, extend or improve architecture documentation, to document a system, or to fill a gap the `architecture` skill could not answer.

Review the health of your incident.io agent estate — plugins, skills, connections — and say what to fix, without fixing anything itself. Use whenever anyone asks whether their incident.io setup is healthy, what's degraded, or what to improve, in any phrasing — one-off or as a recurring review. Every finding routes to the thing that fixes it.

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.

Reading and changing incidents in incident.io: status, severity, roles, fields, updates, channel messages and the AI investigation. Use whenever you're working with an incident in any way, even a single read or change. Load it before the first incident, update, follow-up or investigation tool call: the tools accept changes the organisation's rules then reject, and this skill says what to check first. Not for fleet-wide statistics, runbooks or who is on call.

Who is on call in incident.io and how they get paged: schedules, rotas and shifts, overrides, cover requests, escalation paths, and pages (escalations). Use whenever you're working with any of these in any way, including plain reads ("who's on call tonight?", "when am I next on?") and paging ("page Ava", "ack my page", "has anyone acked?"). Load it before the first schedule, escalation or cover-request tool call: the tools return raw shifts and levels, and this skill says how to read them.

Work with an incident's postmortem document — the write-up a team produces after an incident. Use when the conversation is about a postmortem, post-incident review, debrief or retro document: finding it, creating one, reading it, changing its text, or reviewing it against what actually happened. Covers rewriting a section, fixing a claim, adding a timeline entry or a learning, and also judging whether its claims hold up, what is missing, and what should become a follow-up. Not for general questions about an incident, which is the incidents skill.

Create and improve the skills in your own plugins — the ones incident.io's agents and your coding agents load. Use whenever you're writing, editing, or reviewing a skill in any way: creating one, improving one from usage feedback or a review brief, or asking what makes a good skill.

How the incident.io skills speak to the person in the session: what the user hears and what goes in the record, ending each reply with one next step, keeping a fixed milestone list through a multi-step job, and using the user's words instead of the skills' own vocabulary. Load it before you reply to the user while running any other incident.io skill.

Query an organization's observability data — logs, metrics, traces, profiles, dashboards, Kubernetes, SQL databases — with the incident.io telemetry tools. Use when answering a question that needs evidence from its monitoring: what errors fired, when latency moved, which pod restarted, what a dashboard showed, what its databases hold. Not for questions the incident record already answers, and not for querying incident.io's own data.