Jira Incident Intake Skill

Your job is to bridge an existing Jira ticket to the Incident Commander's response flow. A ticket already exists — meaning someone already identified the problem. Your goal is to extract everything the incident response pipeline needs so it can proceed without asking the developer to repeat information that's already in Jira.

Phase 0: Resolve the Ticket Reference

Accept any of these input forms:

• Bare key: OPS-412 , PROD-88 , INC-7

• Full URL: https://company.atlassian.net/browse/OPS-412

• Natural language: "the Jira for the checkout outage", "look at the incident ticket"

If a bare key or URL is provided, extract the issue key and proceed directly to fetch. If the reference is ambiguous (e.g., "the checkout Jira"), use Jira search to find the most likely match before fetching.

Phase 1: Fetch the Ticket

Use the Atlassian MCP (getJiraIssue ) to retrieve the full ticket. Request these fields:

Field Purpose

summary

Short incident title

description

Full symptom description, error messages, logs pasted by the reporter

priority

Jira priority → use to inform initial severity hint

status

Current workflow state (helps assess if incident is active or resolved)

issuetype

Bug, Incident, Task — affects routing

labels

May include incident , severity-p0 , production , security , etc.

components

Affected services/systems

assignee

Who currently owns the ticket

reporter

Who filed it

created

When the ticket was created (proxy for incident onset if no better signal)

updated

Last activity — signals if investigation is recent or stale

comment

Comments thread — often contains diagnostic steps already taken, stack traces, and timeline

attachment

Log files, screenshots, exported metrics

customfield_*

Any custom fields: environment, affected region, linked runbook, SLA fields

Also fetch linked issues (getJiraIssueRemoteIssueLinks ) to identify:

• Linked PRs (hotfixes in progress)

• Duplicate or related incidents

• Parent epics (for service context)

Phase 2: Extract Incident Context

Map ticket data to the standard incident intake fields. Fill every field — use "unknown" rather than leaving anything blank.

Priority mapping

Use the Jira priority as a hint only — do not blindly trust it. Jira priorities are often set by reporters who may not follow the severity matrix. The Incident Commander will classify severity properly during triage.

Jira Priority Severity Hint

Blocker / Critical Likely P0 or P1 — flag immediately

Major Likely P1 or P2

Minor Likely P2 or P3

Trivial Likely P3

Not set Unknown — defer to triage

Status mapping

Jira Status Signal

Open / To Do Incident may not yet have an active responder

In Progress Someone is actively working it — check assignee and comments for context

Resolved / Done Incident is over — route to incident-documenting for postmortem/summary only

Reopened Regression — treat as new active incident

Context extraction rules

• Symptom: Pull from summary

• first paragraph of description . If description contains raw error messages, stack traces, or log excerpts — include them verbatim in the handoff.

• When: Check created timestamp, but also scan description and early comments for phrases like "started at", "began around", "first noticed at". Use the most specific time.

• Scope: Look for user counts, error rates, affected regions, or service names in the description and comments. Extract them explicitly.

• Trigger: Scan for mentions of deploys, config changes, dependency upgrades, traffic spikes, or cron jobs that correlate with onset.

• Actions taken: Read the full comment thread. Extract any diagnostic steps, attempted fixes, and their outcomes into a bullet list. This prevents the team from retrying failed approaches.

• Attachments: Note any attached log files or exports. If the AI assistant can read them, extract key error signals and include in the handoff package.

Phase 3: Build the Intake Package

Produce a structured intake package that the Incident Commander consumes as if a developer had reported it directly. Do not summarize or lose fidelity — include the raw error messages and stack traces verbatim.

JIRA INCIDENT INTAKE ──────────────────── Source Ticket : [KEY] — [title] Ticket URL : [https://...] Status : [Jira status] Reporter : [name] at [timestamp] Assignee : [name or "unassigned"] Priority Hint : [Jira priority] → estimated [P0/P1/P2/P3/unknown]

Stage : [prod | staging | ci | local | unknown] Symptom : [precise observable symptom extracted from description] Raw Error : [Verbatim error messages, stack traces, or log excerpts from ticket — or "none in ticket"]

When : [Onset time from ticket — or "unknown, ticket created at HH:MM UTC"] Scope : [Users/services/endpoints affected — or "unknown"] Trigger : [Deployment, config change, dependency, traffic spike — or "unknown"]

Actions Already Taken: [Bullet list from comment thread — or "none documented in ticket"]

• [action] → [outcome]
• [action] → [outcome]

Linked Context :

• PRs: [links or "none"]
• Related incidents: [links or "none"]
• Runbook: [link or "none referenced"]

Attachments : [list filenames or "none"]

Phase 4: Route to Incident Commander

After building the intake package, pass it to the Incident Commander with a clear handoff note.

If the ticket status is Resolved/Done:

"Ticket [KEY] is already resolved. Routing to incident-documenting to generate postmortem and close the documentation loop. Skipping triage and RCA." → Invoke incident-documenting directly.

If the ticket status is active (Open, In Progress, Reopened):

"Ticket [KEY] is an active incident. Handing full context to the Incident Commander to begin the response flow." → Pass the intake package to the Incident Commander. The Commander will invoke incident-triaging

as the first step, using the extracted context instead of asking the developer to re-enter it.

If priority hint is Blocker/Critical:

Flag immediately: "Jira priority is [Blocker/Critical] — treating as potential P0/P1. Proceeding to triage at high urgency."

Phase 5: Jira Ticket Hygiene (optional, if MCP write is available)

After the response flow completes, offer to update the Jira ticket with:

• Severity classification from triage (add label severity-p<N> )

• Link to escalation brief, runbook, or postmortem artifact written to disk

• Status transition if appropriate (e.g., move to "In Progress" if it was "Open")

Always ask before writing back to Jira — do not update tickets automatically.

Constraints

• Never ask for information already in the ticket. Read the full description and comment thread before determining what context is missing.

• Preserve raw error messages verbatim. Summarizing stack traces loses signal. Include them in the intake package exactly as they appear.

• Do not classify severity yourself. Provide a hint based on Jira priority, but defer final severity classification to incident-triaging .

• Comments are part of the incident record. A ticket with 20 comments may have the root cause already identified. Read them all before handing off.

• Stale tickets need a freshness check. If the ticket was last updated >24 hours ago and is still "In Progress", flag this to the developer before proceeding — the incident state may have changed without the ticket being updated.