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 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.