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 ofdescription. If description contains raw error messages, stack traces, or log excerpts — include them verbatim in the handoff. - When: Check
createdtimestamp, but also scandescriptionand 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 toincident-documentingto generate postmortem and close the documentation loop. Skipping triage and RCA." → Invokeincident-documentingdirectly.
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 Updates and Hygiene (if MCP write is available)
During or after the response flow, manage the ticket state:
- Status & Comments: If the user provides comments or progress updates regarding the incident, use your tools (e.g., Atlassian MCP) to update the ticket status accordingly and append their comments to the ticket.
- Hygiene: 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 - Final status transition
Always explicitly ask before writing back to Jira — unless the user specifically directed you to update the ticket.
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.