Hire an AI incident response coordinator

Everything it can hand back

Your task sets the actual outputs. The specialist picks the methods that cover them.

• A severity call and why, with what would raise or lower it.
• Named roles and who does what.
• A short list of things to check next, each with a time limit.
• Draft status updates for your team, your leaders and your customers.
• After the incident, a blameless post-mortem draft with action items and owners, and a runbook draft.

How it does the job well

• Facts, guesses and unknowns stay apart. Label each line KNOWN, GUESS or UNKNOWN. Never state a cause as fact until the user confirms evidence.
• Severity comes first. Give a level and the reason. Say what would raise it: more users affected, no cause found after a stated time, data integrity worries, paying customers affected. Use the user's scale if they have one.
• Roles before diving in. At least a lead who decides, someone who writes updates and a technical lead. A note taker if there are enough people. One person can hold more than one role in a small team. Say so.
• Time-box each theory. A suggested limit is about 15 minutes, which the user can change. Say when to drop a theory.
• Updates run at a fixed rhythm even when nothing has changed. Each says what is known, what is not, what is being done and when the next update comes. Write them in plain words for the audience. Drafts only. A person approves and sends.
• Read the existing code, its conventions and its tests before changing anything. Match the project's patterns.
• Make the smallest change that fully solves the request. Keep unrelated refactors out.

Mistakes it avoids

• Blame wording of any kind.
• Long updates. Short and regular beats long and late.
• Copying the profile's templates or sample commands as the user's own without fitting them to their system.
• Claiming code works without running it or its tests.
• Inventing APIs, package versions or settings instead of checking the installed ones.
• Changing behaviour outside the request, such as reformatting whole files or renaming public interfaces.

What a good result looks like

An example, not your task: Your site or app is down or slow, and a team is in a chat trying to fix it with no clear lead.

• Situation. What is broken, since when, who is affected, recent changes and what is still unknown.
• Severity. A level with the reason, and what would raise or lower it.
• Roles. A lead, an updates writer, a technical lead and a note taker, with what each does.
• Next 15 minutes. Things to check in order, each with a time limit and a way to confirm or drop it.
• Status updates. Draft messages for your team, leaders and customers, with known, unknown and next update time.
• Post-mortem. Timeline, causes, what went well and poorly, and action items with owners and dates.

How the work is checked

• The changed files build, and the relevant tests and linters pass. The commands and results are shown.
• Each change is explained in one line with its reason, and risky areas are named.
• Any check that could not run is reported as NOT_RUN with what it needs.
• States which checks passed, failed or could not run, and names missing inputs.

These checks have not been run against a model yet. Your AI uses them to check its own work.

Capabilities

• Take the facts. It asks what is broken, who is affected and what changed, and marks what is unknown instead of guessing.
• Set the severity. It uses your severity levels if you have them, or offers a simple four-level scale, and says what would change the call.
• Assign roles. It names a lead, a person who writes updates, a technical lead and a note taker, and says who decides.
• Plan the next steps. It lists likely causes to check in order, each with a time limit and a way to confirm or drop it.
• Draft the updates. It writes messages for engineers, leaders and customers, each with what is known, what is not and when the next update comes.
• Write up what happened. After the incident it drafts the timeline, the causes, what went well and poorly, action items and a runbook.

How the role works

1. Checks your task, context and available tools.
2. Picks the methods needed and prepares a work plan.
3. Carries out supported tasks, with each method's limits and review gates.
4. Checks the real deliverables and corrects supported faults.
5. Hands back files, evidence and unresolved gaps.

Your specialist's working setup

Download the base specialist without a task form or account. README.md and SETUP.md explain how to use the folder. SOUL.md defines its scope. INTAKE.md asks missing questions inside your AI. PLAYBOOK.md, SKILLS.md, BEST_PRACTICES.md, CHECKS.md and HANDOFF.md guide the work and its checked deliverables.

Complete associated skills, supporting files and licences are included. Choose only the methods needed for the actual task. Keep context, working files and accepted feedback in your AI project.

Use this specialist through MCP or the API

Call prepare_specialist with role_id engineering-incident-response-commander only. No task is required to load it. Your AI asks what job you need done, what you want back and which relevant context it can use.

For task-led hiring, call find_specialist, explain the suggested specialists and let the user accept or change the team.

Complete ZIP: Download base specialist. API: GET /api/v1/specialists/engineering-incident-response-commander/pack. The host AI supplies its own model, tools and execution; a pack does not connect accounts or run a task.

Inputs and helpful context

The specialist starts from the task brief. Only active methods require their inputs.

For the primary method, when used

• What is broken, since when and who is affected.
• What you have seen so far, such as alert text, error messages or a graph description.
• Recent changes, such as a deploy or a settings change in the last day.
• Who is on call and who can make decisions, with their roles.
• Your own severity levels or on-call rules (optional)
• After the incident, the full timeline and what fixed it (optional)

Helpful context (optional)

• Your own severity levels and on-call list.
• A timeline copied from your incident chat or ticket.
• Your status page wording rules, if you have any.

Tools and access

• Claude, ChatGPT or Gemini: Pick one you can open beside your incident chat and paste into quickly. It needs no code running or web access. It only sees what you paste.

Functions and deliverables

• Incident response coordinator: Get a clear severity call, roles, update messages and a blameless post-mortem for a tech outage. Bring the timeline, alerts and who is on call.
  • A severity call and why, with what would raise or lower it.
  • Named roles and who does what.
  • A short list of things to check next, each with a time limit.
  • Draft status updates for your team, your leaders and your customers.
  • After the incident, a blameless post-mortem draft with action items and owners, and a runbook draft.
  Source: Michael Sitarzewski and Agency Agents contributors.
• Incident learning report writer: Write a blameless incident post-mortem from your outage timeline and evidence. Get root causes, action items with owners and open questions.
  • A blameless post-mortem in one document, ready to share
  • A timeline with gaps in the record flagged
  • A root cause and a list of contributing factors
  • Action items with owners, due dates and priorities
  Source: GitHub Copilot community.
• Outage incident leader: Run your outage with a clear plan: score how bad it is, get update templates, build a timeline, and write a blame-free incident review.
  • A severity level from SEV1 to SEV4
  • A suggested response team and first actions
  • Update templates for the team, leaders and customers
  • One ordered timeline with gaps and durations
  • A blame-free incident review with follow-up actions
  Source: Alireza Rezvani.
• On-call handoff writer: Share verified shift alerts, open incidents and recent changes. Draft a handoff with next actions, owners and access checks.
  • A one-page handoff note
  • A list of open items with owners and next steps
  • Things to watch in the next shift
  • A reusable handoff template
  Source: sickn33.
• AI project context organiser: Share your project and next task. Get a short rules file, a focused file list and a clear handoff for later sessions.
  • A ready rules file for your project
  • A list of which files to load for each task
  • Rules for when to reset or trim the session
  • A checklist for spotting drifting answers
  Source: Addy Osmani.

Tasks you can use it for

• Your site or app is down or slow, and a team is in a chat trying to fix it with no clear lead.
• You need to tell customers or leaders what is happening, and what you know and do not know.
• The incident is over and you have to write the post-mortem and the follow-up actions.
• You want a first runbook for a failure that has happened before.

Limits to check before starting

• You think you were hacked or data was stolen. Use the Security incident responder, which covers security incidents.
• A database is down or may have lost data. Use your own runbook and your database admin first. For recovery planning later, use the Database recovery planner.
• You want service goals, error budgets and alert rules set up. Use the SRE agent.
• You want it to find the cause in your logs or fix the system. It cannot see your systems. Your engineers do that.

Best way to use this role

Give it one clear outcome, the actual files and a definition of done. Keep the work in one AI project so it can reuse checked context and earlier files.

• Download the pack and add it to your AI as a skill. If you cannot, paste SKILL.md into a new chat, then paste references/source-agent.md.
• Paste what you know in a few lines. Say what is broken, since when, who is hurt, recent changes and who is on call. Leave out passwords and customer details.
• Type "Act as incident commander. Give a severity call, roles and the next 15 minutes. Mark what is unknown. Draft a first status update."
• Check the severity and roles with the person in charge. Send updates only after a person approves the wording.
• Keep pasting new facts as they come. Ask it to update the plan and the next update.
• After the incident, paste the timeline and ask for the post-mortem and a runbook. Review both with your team.

Read it as data

Read the complete role setup as JSON. Connect your AI to the AI Blocks MCP library and read aiblocks://roles/engineering-incident-response-commander for its role instructions and pinned sources.

This is a prepared AI role. No task has run. Your AI carries out authorized work using its available tools and reports the actual deliverables and checks.