Escalate ServiceNow incidents to Jira once, with the trail intact

**Objective:** Escalate ServiceNow record `{record-number}` to a new Jira issue in project `{project-key}` with issue type `{issue-type}` (default Bug), then record the Jira key on the ServiceNow record. Write nothing until the user confirms.

**Step 1: Read the ServiceNow record**

If `{record-number}` starts with INC, call `servicenow-get-incident` filtered by `number`. If it starts with PRB, call `servicenow-get-problem` filtered by `number`. Any other prefix: say this prompt handles incidents and problems only, and stop. If nothing comes back, say the record was not found and stop. Keep its `sys-id`, number, short description, priority, state, configuration item, assignment group and assigned-to (and, for a problem, its related incidents).

**Step 2: Check Jira for an existing escalation**

The link between the two systems is the ServiceNow number written into the Jira summary as `[INC0010023]`. Call `jira-get-issue` with `summary.contains` set to the record number (and `project-key` set to `{project-key}`). If an issue comes back, report its key, status and assignee, say the record is already escalated, and stop without creating anything.

**Step 3: Resolve the Jira ids**

Call `jira-get-issue-type` with `project-key` set to `{project-key}` and `name` set to `{issue-type}` (Bug if blank). Take its `issue-type-id` and `project-id`. If the project or the type does not exist, list the issue types the project does have and stop.

If the ServiceNow record has an assignee, call `servicenow-get-user` filtered by `name` to read their email, then `jira-get-user` filtered by `email` to read their `user-account-id`. If either step finds nothing, leave the Jira issue unassigned and say so.

**Step 4: Confirm**

Show the user the Jira issue you will create: project, type, summary `[<record number>] <short description>`, proposed assignee, and the ServiceNow details you will put in a comment. Ask for confirmation. Do not continue without an explicit yes.

**Step 5: Write, once each**

1. Call `jira-add-issue` with `project-id`, `issue-type-id`, `summary` and, if resolved, `assignee-account-id`.
2. Call `jira-get-issue` with `summary.contains` set to the record number to read the new `issue-key`.
3. Call `jira-add-issue-comment` on that issue with the ServiceNow number, priority, state, configuration item, assignment group and description. Pass the issue key as `issue-id`; Jira accepts a key in place of the numeric id.
4. Call `servicenow-update-incident` (for an INC) or `servicenow-update-problem` (for a PRB) with the record's `sys-id` and a `work-notes` entry: "Escalated to Jira <issue key>".

**Step 6: Report**

The Jira issue key, its summary and assignee, and confirmation that the work note was added in ServiceNow.

**Rules & Guidelines:**

* `servicenow-get-incident`, `servicenow-get-problem`, `servicenow-get-user`, `servicenow-update-incident` and `servicenow-update-problem` are on the servicenow server. `jira-get-issue`, `jira-get-issue-type`, `jira-get-user`, `jira-add-issue` and `jira-add-issue-comment` are on the jira server.
* Create exactly one Jira issue. Never change the ServiceNow record's state, priority or assignment; only add the work note.
* Do not call `jira-update-issue`, `jira-assign-issue` or `servicenow-add-problem`.

**Validation:**

* If `jira-add-issue` fails, report the error and do not write the ServiceNow work note.
* If the new issue cannot be found in step 5.2, report that the issue was created but its key could not be read, and do not write the work note.
* If a Jira write rejects the issue key as `issue-id`, call `jira-get-issue-watcher` filtered by `issue-key` to read the numeric `issue-id`, and retry once.