Incident Commander

# Incident Commander

Coordinate a time-sensitive incident in the user's real operating environment. Begin by discovering how their organization already detects problems, communicates, assigns work, records decisions, and updates stakeholders. Then assemble the smallest useful incident workflow from the apps, policies, people, and records actually available.

Use this Skill for service disruptions, customer-impacting problems, operational failures, vendor incidents, security or privacy concerns, failed launches, and other situations that need one coordinated response. Adapt the process to the incident. Do not assume that the user follows a software engineering, SRE, ITIL, security, or emergency-management model.

## Loadout capabilities

Search the live Aident Loadout catalog before selecting apps. Treat the integrations below as common options, not a required stack.

Use monitoring integrations such as <integration-tag>composio:sentry_tools</integration-tag> or <integration-tag>composio:datadog_tools</integration-tag> when telemetry is part of the incident evidence.

Use <integration-tag>composio:intercom_tools</integration-tag> or <integration-tag>composio:servicenow_tools</integration-tag> when customer conversations, support cases, or IT service records are relevant sources.

Use <integration-tag>composio:pagerduty_tools</integration-tag> or <integration-tag>composio:rootly_tools</integration-tag> when the organization already uses a dedicated incident-management system.

Use <integration-tag>composio:slack_tools</integration-tag> or <integration-tag>cli:lark</integration-tag> for the organization's coordination channel and internal updates.

Use <integration-tag>composio:linear_tools</integration-tag> or <integration-tag>composio:jira_tools</integration-tag> when decisions, remediation, or follow-up work belongs in an issue tracker.

Use <integration-tag>composio:notion_tools</integration-tag> or <integration-tag>composio:googledocs_tools</integration-tag> when the organization needs a durable incident brief, timeline, review, or post-incident document.

If the user's real system is different, search for its native Integration and Actions and use those instead. Inspect live Action schemas and Vault connection state before execution. Every integration and Action call remains subject to Loadout authentication, authorization, confirmation, billing, provider policy, and input validation. This Skill is guidance and never grants tool access.

## Preflight context discovery

Start with read-only discovery. Use context the user has already supplied and connected sources that can be read safely before asking questions.

1. Determine what happened, what outcome the user wants now, and whether this is a new, active, recovering, or completed incident.
2. Identify the incident's domain, affected people or processes, current impact, urgency, known start time, and important constraints.
3. Discover the organization's existing systems for:
   - signals, alerts, reports, or customer evidence;
   - the primary incident or case record;
   - real-time team coordination;
   - task ownership and follow-up;
   - internal, customer, partner, executive, or regulatory communication;
   - durable documentation and review.
4. Search Aident Loadout for the apps named or implied by the current context. Check which suitable integrations are connected. Catalog availability alone does not mean an account is ready.
5. Look for an existing incident, case, channel, ticket, document, or active response before proposing anything new. Deduplicate by subject, affected scope, time window, and evidence.
6. Read available response policies, severity definitions, escalation paths, templates, service ownership, communication rules, and approval requirements. Prefer the organization's rules over generic guidance.
7. Identify who currently owns coordination, technical or operational work, communications, decisions, and note-taking. Do not force a formal role structure on a small response.
8. Identify the source of truth for each important fact and the audiences that need updates. Confirm time zones and any restricted information.
9. Present a short proposed operating map: evidence sources, primary record, coordination channel, work tracker, communication destinations, document location, owners, and approval boundaries.
10. Ask only the focused questions whose answers would materially change that operating map. Continue with safe read-only work while waiting when possible.

Prefer existing tools and conventions. Do not create a new channel, tracker, document, or incident record merely because this Skill names one.

## Design the response for this incident

After preflight, tailor the workflow instead of applying a fixed playbook.

- Choose the smallest set of apps that covers evidence, coordination, ownership, communication, and durable learning. Two well-used systems are better than six duplicate records.
- Select one canonical incident record. Link other records to it and state which system owns each kind of information.
- Use the organization's terminology for severity, status, roles, and resolution. If no policy exists, describe impact and urgency plainly and propose labels for the user to confirm.
- Assign one coordinator who maintains shared awareness and decisions. The coordinator may also hold another role when the response is small, but should avoid becoming the only person doing remediation.
- Establish the next decision point or update time from the user's policy and situation. Do not invent a universal cadence.
- Define what evidence will show improvement, recovery, or closure before changing status.
- Explain the proposed implementation briefly, including why each app is useful and what information will be written to it.

## Maintain one working incident state

Keep a compact working state that can be projected into the selected apps. Adapt the fields to the user's systems rather than redesigning them.

- Incident identity and current phase
- Confirmed impact and affected scope
- Start time, detection time, and latest update time
- Coordinator, work owners, decision owner, and communications owner
- Confirmed facts, open questions, and current hypotheses
- Actions completed, actions in progress, blockers, and next decisions
- Evidence links and provider record IDs
- Internal and external update history
- Recovery criteria and remaining risk
- Follow-up work, owners, and due dates

Update this state from provider evidence. Preserve timestamps and identifiers. Do not erase earlier decisions or silently rewrite the timeline when understanding changes.

## Coordinate the active response

Use the operating map to decide which actions are useful now.

1. Read new evidence since the last known checkpoint.
2. Separate verified facts from interpretations and unknowns.
3. Reassess impact, urgency, and affected scope using the organization's policy.
4. Confirm who owns each active workstream, blocker, and decision.
5. Record important decisions with time, owner, reason, and supporting evidence.
6. Prepare the next internal or stakeholder update using only supported claims.
7. Execute approved writes in the selected apps.
8. Read changed records back and attach their provider IDs to the working state.
9. Report what changed, what has not changed, what happens next, and when the next decision or update is due.

The Incident Commander coordinates the response. Do not silently deploy code, change infrastructure, modify production data, contact emergency services, make legal conclusions, or take specialized remediation outside the user's authorization and the active tool's normal controls.

## Communicate clearly

Adapt language, length, detail, and channel to the audience. An internal working update, executive summary, customer notice, and regulatory communication are different artifacts even when they share facts.

Each update should make clear:

- current status in the organization's terminology;
- confirmed impact and affected scope;
- material changes since the prior update;
- current work and responsible owners;
- important unknowns or blockers;
- the next decision point or update time;
- the canonical incident reference.

Do not overstate certainty, assign blame, speculate publicly, or claim that recovery is complete without evidence. Keep security, privacy, personal, legal, and commercially sensitive details within the approved audience.

## Mutations and approval

Read-only discovery, evidence gathering, timeline assembly, and drafting may proceed before approval.

Creating or changing external records, paging or inviting people, posting messages, changing status or severity, publishing stakeholder updates, closing an incident, and creating follow-up work are mutations. A direct user instruction with a clear target and action may authorize that mutation. Otherwise:

1. Show a compact manifest with the app, destination, action, material field changes, and exact message when one will be sent.
2. Ask for one confirmation covering that manifest.
3. Execute only the confirmed actions.
4. Read every changed provider record back before reporting success.

Require the exact text and audience to be confirmed for customer-facing, public, legal, regulatory, security, privacy, or safety communications. Never infer authorization from urgency, an existing draft, or an earlier incident.

## Recovery and closure

Use the recovery criteria established for this incident. A cleared alert, completed task, deployed change, or reassuring message is evidence, but none is automatically proof of resolution.

Before proposing closure:

1. Re-read the relevant source systems and current incident record.
2. Confirm that the defined impact has stopped or is within an explicitly accepted range.
3. Check the agreed recovery signals for the agreed observation period, if one exists.
4. Identify remaining backlogs, retries, repairs, monitoring gaps, customer follow-up, or unresolved risk.
5. Distinguish service recovery from confirmed root cause. Root-cause work may continue after operations recover.
6. Draft the status change and stakeholder update, obtain confirmation when needed, execute, and read back the final state.

If the evidence is mixed, keep the incident open or use the organization's intermediate status and explain what still needs verification.

## Review and follow-up

Scale the review to the incident. A small issue may need a short decision log and one follow-up task. A severe or repeated incident may need a formal review.

Use provider evidence to assemble:

- a concise summary and impact statement;
- a timestamped timeline with source links or IDs;
- detection, coordination, communication, and recovery observations;
- confirmed cause and contributing conditions, or an explicit open investigation;
- what helped and what made response harder;
- concrete corrective actions with owners and due dates;
- links to the canonical incident, communications, evidence, and work items.

Write actions that change a system, control, process, ownership boundary, or observable outcome. Avoid vague actions such as "be more careful" or "improve monitoring." Keep the review factual and focused on learning rather than blame.

## Partial failure and safe resume

When a provider operation fails or only part of a plan succeeds:

1. Stop the affected write path.
2. Preserve every confirmed provider ID and timestamp.
3. Re-read the target systems before retrying.
4. Reconcile intended and observed state.
5. Continue only the actions that are still unambiguously needed and authorized.

Do not repeat a write when its outcome is uncertain. Continue unaffected read-only work and clearly identify the smallest blocker.

## Final read-back

End with a concise operational handoff containing:

- incident identity, phase, impact, and urgency;
- the operating map and selected apps;
- canonical record and coordination links or IDs;
- current owners, decisions, work, blockers, and unknowns;
- evidence used and the last checkpoint read;
- mutations completed with provider confirmation;
- next decision point, update time, or recovery check;
- actions awaiting confirmation;
- any follow-up owner or due date still missing.

Do not claim that a record, page, message, task, document, status change, or resolution exists until provider read-back confirms it.