Find the likely cause of a ServiceNow incident, fast

**Objective:** Build a full picture of incident `{incident-number}` and suggest the most likely cause, in the order an experienced analyst would look.

**Step 1: Read the incident**

Call `servicenow-get-incident` with number `{incident-number}`. Note state, priority, opened, caller, category, configuration-item, service and short-description.

**Step 2: SLA and outage exposure**

* Call `servicenow-get-task-sla` with task `{incident-number}`: is anything breached or close?
* Call `servicenow-get-outages-task-link` with task `{incident-number}`: is an outage already recorded?

**Step 3: What else is affected**

* Call `servicenow-get-ci-affected` with task `{incident-number}` for the affected configuration items.
* Call `servicenow-get-impacted-ci` with task `{incident-number}` for the impacted services.

**Step 4: Look for a cause, in this order**

1. Recent change: for each configuration item from the incident and Step 3, call `servicenow-get-ci-affected` with configuration-item set to its name. Every task number starting CHG is a change; read it with `servicenow-get-change-request` by number and keep changes whose planned window ended within 7 days before the incident opened, or is still open. A change landing just before the incident is the strongest lead.
2. Monitoring: call `servicenow-get-alert` with configuration-item set to the same name and created.from 2 days before the incident opened. Open alerts that predate the incident point at the failing component.
3. Known problem: call `servicenow-get-problem` with short-description.contains set to two or three distinctive words from the incident, and known-error true. A match means there may already be a workaround.
4. Similar incidents: call `servicenow-get-incident` with short-description.contains using the same words and opened.from 30 days back. Several matches suggest a problem record is needed.

**Step 5: Report**

* Summary: one paragraph on the incident and its current state.
* Exposure: SLA status, outage links, impacted services.
* Leads, strongest first: each with the evidence (record numbers and dates) and a confidence of High, Medium or Low.
* Next steps: at most three concrete actions.

**Rules & Guidelines:**

* Read-only. Do not call `servicenow-update-incident`, `servicenow-add-problem`, `servicenow-update-alert` or any other add- or update- tool.
* Correlation in time is a lead, not proof. Say so when the only evidence is timing.

**Validation:**

* If `{incident-number}` is not found, say so and stop.
* If the incident has no configuration-item, skip the CI-based checks in Step 4 and say that the missing CI limited the investigation.