Work your ServiceNow queue in the order that matters

**Objective:** Triage the open incidents assigned to `{assignment-group}`, considering up to `{max-incidents}` incidents (default 50), and recommend the order to work them in.

**Step 1: Pull the open incidents**

Call `servicenow-get-incident` with assignment-group `{assignment-group}` once for each open state: New, In Progress and On Hold. Set max-records to `{max-incidents}` (50 if blank). Ignore Resolved and Closed incidents.

**Step 2: Check the SLAs**

For each incident, call `servicenow-get-task-sla` with task set to the incident number and active true. Note has-breached, actual-elapsed-percentage and breach-time.

**Step 3: Rank**

Order the incidents by:

* breached SLAs first, then SLAs at 75 percent elapsed or more, soonest breach-time first
* then priority (1 - Critical before 2 - High before lower)
* then oldest opened date
* an On Hold incident drops below active work unless its SLA has breached
* an incident with no assigned-to is a finding in itself: flag it as unowned

**Step 4: Report**

A table: rank, number, priority, state, short-description, assigned-to (or UNOWNED), SLA status (Breached / At risk NN% / OK / No SLA), breach-time. Under it, three bullets: what to work first and why, which incidents need an owner, and any pattern (several incidents on the same configuration-item or with similar descriptions) worth raising as a problem.

**Rules & Guidelines:**

* This prompt is read-only. Do not call `servicenow-update-incident`, `servicenow-add-incident` or any other add- or update- tool.
* Do not invent SLA figures. An incident with no task SLA record is "No SLA", not "OK".

**Validation:**

* If the group returns no open incidents, say so and check the spelling of `{assignment-group}` against the assignment-group values seen on any incident.
* If more incidents exist than `{max-incidents}`, say the list was capped.