@salesforce/afv-skills 1.65.0 → 1.66.0

package/skills/service-itsm-agentic-setup-incident-management/references/incident-persona-psg.md

@@ -51,7 +51,7 @@ licensing is part of the orchestrator's **Major Incident Management** feature).
   existing assignments (idempotency); assigning the missing backing PSL(s) and then the PSG; verifying by
   read-back.
 - **Out of scope**: the **Major Incident Manager** PSG; creating / editing / recalculating a PSG or its
-  membership; enabling ITSM / incident-management features (`service-itsm-incident-mgmt-configure`); the
+  membership; enabling ITSM / incident-management features (the `IncidentMgmt` SOR's master-feature steps); the
   `IncidentFulfiller` permission **set** for the Fulfiller **agent's** access
   (`service-itsm-agentic-setup-itsm-agentforce-permset-assign`); CMDB access
   (`service-itsm-agentic-setup-cmdb-access-assign`); generic, non-incident permission-set / PSG assignment
@@ -60,7 +60,8 @@ licensing is part of the orchestrator's **Major Incident Management** feature).
 ## Preconditions
 
 - **ITSM Incident Management must be provisioned** — the incident persona PSGs must exist on the org. If
-  neither is found, **stop and hand off** to `service-itsm-incident-mgmt-configure`; assign nothing.
+  neither is found, **stop and report that the personas are not provisioned**; the master-feature
+  prerequisite is handled by the orchestrator, but enabling it does not prove the PSGs exist.
 - **The acting user must be able to assign permission sets** (the SOR gates writes on it). A write that
   fails with an access error that is not a duplicate → surface it plainly and stop; an admin must do it.
 - **Each backing license consumes a seat.** A seat-exhausted license blocks that persona; report it.
@@ -68,8 +69,8 @@ licensing is part of the orchestrator's **Major Incident Management** feature).
 ## Operations (shapes come from `describe`)
 
 1. **Resolve which incident persona PSGs exist (read).** Look up the two PSGs by `DeveloperName`
-   (`IncidentFulfillerPSG`, `IncidentManagerPSG`) with **no `NamespacePrefix` filter**. None found → hand
-   off to `service-itsm-incident-mgmt-configure` and stop. Capture each PSG's Id and status.
+   (`IncidentFulfillerPSG`, `IncidentManagerPSG`) with **no `NamespacePrefix` filter**. None found →
+   stop and report that the personas are not provisioned. Capture each PSG's Id and status.
 2. **Resolve the target user (read).** To exactly one active user. For "me" / "the current user", read the
    API root's identity (the running user's `005…` Id) — **not** the `USER_ID()` SOQL function (Apex-only)
    and **not** the Chatter current-user endpoint (fails when Chatter is off). Zero / multiple → disambiguate.
@@ -124,13 +125,13 @@ Persona: <Incident Fulfiller | Incident Manager>
 ```
 
 Repeat the `Persona:` block per PSG if both were chosen. Report only what read-back confirmed. If the
-personas are not on the org, say so and name `service-itsm-incident-mgmt-configure`.
+personas are not on the org, say so without claiming master enablement will provision them.
 
 ## Common failures (surface in plain language)
 
 | Symptom | Likely cause | What to tell the user |
 |---------|--------------|-----------------------|
-| No incident PSG on the org | ITSM Incident Management not provisioned | The incident personas aren't set up yet — that's a separate step (`service-itsm-incident-mgmt-configure`) |
+| No incident PSG on the org | Incident persona PSGs not provisioned | The incident personas aren't set up yet — stop and report the missing PSGs |
 | Duplicate on assign | User already has that grant | Not an error — report as already assigned |
 | Seat / limit error on a license | An incident license has no free seats | A seat must free up (or more licenses added); the persona is incomplete without it |
 | PSG assigned but some actions missing | A backing license wasn't assigned, or the PSG is still recalculating | Confirm every backing license is assigned; if it's settling, retry in a moment |

package/skills/service-itsm-agentic-setup-incident-management/references/incident-preferences.md

@@ -6,7 +6,7 @@ Incident Management preferences** (the feature toggles on the Incident Managemen
 four meta-tools (`discover`, `describe`, `dispatch_readonly`, `dispatch`). The org comes from the OAuth JWT
 on the MCP session — never handle an org id, alias, or credentials. Minimum API version **67.0**.
 
-This is **not** the master Incident Management on/off switch (`service-itsm-incident-mgmt-configure`) nor
+This is **not** the master Incident Management on/off switch (the master-feature steps of the `IncidentMgmt` SOR) nor
 the Incident Priority Matrix (`service-itsm-incident-priority-configure`).
 
 ## Delegate to the Setup Operation Recipe
@@ -20,17 +20,16 @@ id; a `discover` miss is not proof an operation is unavailable.
 
 | SOR | Owns | Status |
 |-----|------|--------|
-| **`IncidentMgmt`** (owning team ITSM-Aditya; controller `IPCManagementSetupController`) | Read a preference; toggle a preference; verify a preference read-back | Served |
+| **`IncidentMgmt`** | Read a preference; toggle a preference; verify a preference read-back | Served |
 
 Discover by intent — e.g. `discover("configure ITSM incident management preferences: automatically triage
 incidents, assign incidents with Einstein, enable rich text for incident descriptions")`.
 
 > **Resolve the right node — load-bearing.** Two setup nodes share the "Incident" name. Target the
-> **ITSM Incident Management org-preferences** node (controller `IPCManagementSetupController`) whose
-> toggles are the six below — **not** the Service-Foundation "Incident Management" node
-> (`IncidentMgmtSetupController`), whose toggles are broadcast/notification channels (Email/Sites/Alerts/
-> Slack) and a master switch. If a `discover` result is about broadcast channels or a master on/off, it is
-> the wrong node.
+> **ITSM Incident Management org-preferences** node whose toggles are the six below — **not** the
+> Service-Foundation "Incident Management" node, whose toggles are broadcast/notification channels
+> (Email/Sites/Alerts/Slack). The `IncidentMgmt` SOR also owns the master on/off switch; a `discover`
+> result about broadcast channels is the wrong node.
 
 ## Operations (shapes come from `describe`)
 
@@ -78,7 +77,7 @@ phrasing and the known-name enumeration.
   surface the raw access error and stop.
 - **Incident Management provisioned**: these preferences are writable only when Incident Management is
   enabled at the feature/license level. If reads or writes fail with an availability error, say the feature
-  must be enabled first (`service-itsm-incident-mgmt-configure`) and stop.
+  must be enabled first (the `IncidentMgmt` SOR's master-feature steps) and stop.
 
 ## Workflow
 
@@ -124,7 +123,7 @@ and what it means (e.g. "that setting can't be turned on once incidents exist").
 |---------|--------------|-----------------------|
 | Enable of "Restrict Assigned Group…" fails | The org already has Incident records (server freezes it) | That setting can only be turned on before any incidents exist; it can't be enabled now |
 | Read/write blocked with an access error | Caller lacks ITSM setup access | An admin with setup access must make this change |
-| Read/write unavailable on the org | Incident Management not enabled | Enable Incident Management first (`service-itsm-incident-mgmt-configure`) |
+| Read/write unavailable on the org | Incident Management not enabled | Enable Incident Management first through the `IncidentMgmt` SOR's master-feature steps |
 | Change didn't persist on read-back | Write did not take | Report it as failed and show the current state; do not claim success |
 | `dispatch*` auth error | headless-360 session not authenticated / expired | Re-authenticate the connection and confirm it points at the intended org |
 
@@ -144,5 +143,5 @@ missing setup access or an unauthenticated session. A `404` = the operation is n
 - Read or write against the Service-Foundation `IncidentManagement` node (broadcast channels) — wrong node.
 - Read or write any preference name the SOR does not list — an unknown name reads as `false` and is
   rejected on write.
-- Toggle the **master** Incident Management switch here (`service-itsm-incident-mgmt-configure`) or the
+- Toggle the **master** Incident Management switch as part of this preferences feature (use the orchestrator's prerequisite over the `IncidentMgmt` SOR) or the
   **Incident Priority Matrix** (`service-itsm-incident-priority-configure`).

package/skills/service-itsm-agentic-setup-incident-management/references/major-incident-management.md

@@ -25,7 +25,7 @@ routes are not always ranked first; only a `404` from the dispatch itself means
 Read each step's `status` from `describe`: `implemented` = live; `proposed` = not served on every org yet.
 
 > **MIM is configured by the two surfaces below.** The only feature that must be *on* first is **base**
-> Incident Management (`service-itsm-incident-mgmt-configure`) — see Preconditions.
+> Incident Management (the master-feature steps of the `IncidentMgmt` SOR) — see Preconditions.
 
 ### Transports MIM uses (all via the same `dispatch*` tools)
 
@@ -44,7 +44,7 @@ Read each step's `status` from `describe`: `implemented` = live; `proposed` = no
   precondition, licensing approvers with the **Major Incident Manager permission-set license** and standing
   up the approvers **public group**. Verify every write by read-back.
 - **Out of scope**: base Incident Management enablement
-  (`service-itsm-incident-mgmt-configure` — a prerequisite); the Incident Fulfiller / Incident Manager
+  (the `IncidentMgmt` SOR's master-feature steps — a prerequisite); the Incident Fulfiller / Incident Manager
   **persona** PSG (the orchestrator's **Persona** feature — see `references/incident-persona-psg.md`);
   Problem / Change / Case Management; the Priority Matrix; SLA / entitlement setup; any MIM org preference
   **other than** the two allowlisted.
@@ -53,8 +53,8 @@ Read each step's `status` from `describe`: `implemented` = live; `proposed` = no
 
 The acting user needs **ITSM setup access** (the SOR gates every MIM route on it), and:
 
-1. **Base Incident Management must be enabled** — MIM layers on it. If it is off, **stop and hand off** to
-   `service-itsm-incident-mgmt-configure`; do not configure MIM without base Incident Management.
+1. **Base Incident Management must be enabled** — MIM layers on it. The orchestrator first follows the
+   `IncidentMgmt` SOR's read/confirm/enable/verify prerequisite; stop if it cannot confirm ENABLED.
 2. **Approvers must hold the Major Incident Manager permission-set license.** This is a **LICENSE** —
    granted via `PermissionSetLicenseAssign` (`{AssigneeId, PermissionSetLicenseId}`), **never** a
    `PermissionSetAssignment`. Group-user validation requires every direct and transitive user of a group
@@ -135,7 +135,7 @@ Major Incident Management
 ```
 
 Report only what read-back confirmed; omit lines for surfaces out of the requested scope. If base Incident
-Management is off, say so and name `service-itsm-incident-mgmt-configure`.
+Management cannot be confirmed on, say so and stop without configuring MIM.
 
 ## Common failures (surface in plain language)
 
@@ -158,5 +158,5 @@ Management is off, say so and name `service-itsm-incident-mgmt-configure`.
 - Designate a **group** approver without `validate-group-users` returning **true** first.
 - Reassign without removing the existing designation first (create is a silent no-op).
 - Send any preference name other than `AutoCreationOfProblem` / `AutoClosureChildIncidents`.
-- Attempt MIM setup when base Incident Management is off — hand off to `service-itsm-incident-mgmt-configure`.
+- Attempt MIM setup when base Incident Management is off — first complete the `IncidentMgmt` master-feature prerequisite.
 - Pass `dispatch` the `{operation_id, arguments}` shape — it takes raw HTTP.

package/skills/service-itsm-agentic-setup-incident-management/references/service-mgmt-privilege.md

@@ -70,7 +70,7 @@ keyed on the org preference **`PrivilegeAssignmentEnabled`**.
 - **In scope**: read / set the **Enable Privilege Assignment** master toggle; read / set the org-wide
   **escalation level**; list / create / update / delete **Service Management Privilege** definitions; bulk
   **add / remove employee assignments** for a privilege; verify by read-back where one exists.
-- **Out of scope**: base Incident Management enablement (`service-itsm-incident-mgmt-configure`); the
+- **Out of scope**: base Incident Management enablement (the `IncidentMgmt` SOR's master-feature steps); the
   Incident Fulfiller / Incident Manager **persona** PSG (the orchestrator's **Persona** feature); the Major
   Incident Manager approver licensing (the **Major Incident Management** feature); Problem / Change / Case
   Management; the Priority Matrix; SLA setup.

package/skills/service-itsm-agentic-setup-incident-sla-configure/SKILL.md

@@ -2,13 +2,10 @@
 name: service-itsm-agentic-setup-incident-sla-configure
 description: "End-to-end Incident SLA setup for Service Cloud ITSM — the policy's Business Hours (reuse a named schedule, or create one from described hours or a time zone), MilestoneTypes, an Incident-scoped SLA Policy (SlaProcess), Milestones with criteria, and the Entitlement so Incidents get an EntityMilestone with a computed TargetDate. Use when the user asks to create or set up an Incident SLA policy (predefined or custom, with or without specific business hours), configure SLA milestones on Incidents, set up entitlement processes for ITSM, or enable SLA tracking for incident management. For Incidents, use this instead of the single-step SLA policy, milestone, or activation skills. DO NOT TRIGGER when: the user asks about Case entitlements or Case SLA (not Incident), querying existing SLA policies without setup intent, general Entitlement sObject CRUD unrelated to Incident, or Milestone queries for reporting purposes only."
 metadata:
-  version: "3.10"
+  version: "3.11"
   domains: ["Service"]
   minApiVersion: "67.0"
   accessCheck: "(UserPermissions.CustomizeApplication) && (IncidentMgmt.orgHasITSMOrgPermission)"
-  relatedSkills:
-    - "service-itsm-incident-mgmt-configure"
-    - "service-itsm-incident-priority-configure"
   mcpTools:
     headless-360:
       tools: ["describe", "discover", "dispatch", "dispatch_readonly"]
@@ -24,11 +21,15 @@ allowed-tools: |
 
 # Configuring Incident SLA (End-to-End)
 
+**First action, before any question to the user:** read the IT Service Enablement gate (Phase 1a) with
+`dispatch_readonly` on `GET /services/data/v68.0/connect/setup/discovery/features`, filtered to the exact
+apiName `service-cloud-itsm-setup`. Ask nothing else until it is `ENABLED`.
+
 Configures a complete **Incident SLA pipeline** for Service Cloud ITSM — the chain deriving an
 EntityMilestone (with a computed TargetDate) on every Incident with an Entitlement, all via the
 Salesforce-hosted **`headless-360`** MCP server (org from the OAuth JWT). Requires the org-level
 **IT Service Management enablement** (the Phase 1a gate) and **SLA Management for IT Service**
-setup item (the Phase 1b gate).
+setup item (the Phase 1c gate), plus **Incident Management** (the Phase 1b gate).
 The custom pipeline (four ordered writes): **MilestoneType** (what you measure) → **SLA Policy**
 (SlaProcess, Incident-scoped, created inactive, entry/exit criteria) → **Milestone** (time trigger +
 criteria) → **activate the policy** (`createEntitlement=true`, which auto-provisions the Entitlement —
@@ -42,7 +43,7 @@ verification); the raw **write** operations are **delegated to the approved SLA
 leaf capabilities** (`csp-sun/MilestoneTypes`, `create-sla-policy`, `create-milestone`,
 `create-milestone-action`, `activate-sla-policy`, `create-entitlement-criteria`), which own the
 approved Connect contracts — discover → describe → dispatch each rather than re-deriving its shape here.
-The Phase 1b **enable** (+ Versioning) and Phase 4B **seed** writes delegate to
+The Phase 1c **enable** (+ Versioning) and Phase 4B **seed** writes delegate to
 **`itsm-shakti/SLASettings`** (owns the SLA-Management settings surface) — same discover → describe → dispatch.
 
 ## Scope
@@ -51,7 +52,7 @@ The Phase 1b **enable** (+ Versioning) and Phase 4B **seed** writes delegate to
   activation with its auto-provisioned Entitlement, and — only on an explicit org-wide always-match
   request — the optional auto-apply criterion) + verifying SLA
   engagement on Incident records; gating
-  **SLA Management for IT Service** (Phase 1b); offering the OOB *Standard Support for Incidents*
+  **SLA Management for IT Service** (Phase 1c); offering the OOB *Standard Support for Incidents*
   policy vs a custom one (Phase 2, Incident only) — all via `headless-360` MCP.
 - **Out of scope**: Case SLA/entitlements; Assignment Rules; Escalation Rules; Notification
   Rules; general Entitlement CRUD not related to Incident SLA; SLA reporting.
@@ -89,8 +90,7 @@ from `{status_code, body}`. Full route table with request/response shapes: `refe
 ## Clarifying Questions
 
 Ask only what you cannot infer from context (pre-populate; note "(from conversation)"). **Resolve the
-Phase 1a and Phase 1b gates first, in that order.** Then: **which org?** (`headless-360` binds to the current OAuth session —
-confirm before mutating); **milestone strategy?** (Phase 3b); **milestone criteria?** (default
+Phase 1a gate, then the Phase 1b Incident Management gate, then the Phase 1c gate, first and in that order.** Then: (`headless-360` binds to the current OAuth session, so do not ask which org); **milestone strategy?** (Phase 3b); **milestone criteria?** (default
 `Status != Closed` + pattern-specific filters). **Do not ask for an Account** — Incident has no
 Account field; engagement is per-Incident via `EntitlementId`. **Business Hours:** ask only when the
 user's choice is ambiguous or the org has none (Phase 3a step 4); never ask on the Predefined path.
@@ -110,17 +110,26 @@ before executing.** Phase index and their non-negotiable gates:
 
 - **Before you start — Reuse session state** only from a successful `dispatch_readonly` this session on this
   org, unwritten since; a user statement is never cache-eligible.
-- **Phase 1a — IT Service Management gate** (`service-cloud-itsm-setup`). `NOT_ENABLED` → one ack
-  (reversible) → direct enable → re-read.
-- **Phase 1b — SLA Management gate.** SLA Management **and** the permanent SLA Versioning switch — two
-  writes, two separate acks (master, then permanence); delegate to `itsm-shakti/SLASettings`.
+- **Phase 1a — IT Service Management gate** (`service-cloud-itsm-setup`). Exact `ENABLED` continues.
+  Exact `NOT_ENABLED` with no blocked reasons → ask “IT Service Enablement is off — enable it now?” via `AskUserQuestion` (Yes/No, never plain text; No halts) → delegate to
+  the `IncidentMgmt` SOR with that confirmation → use its verify step before continuing. Missing,
+  error, blocked, or any other status halts and points to Setup.
+- **Phase 1b — Incident Management gate** (`service-cloud-itsm-incident`). Exact `ENABLED` continues; `NOT_AVAILABLE` → HALT; exact
+  `NOT_ENABLED` with no blocked reasons → its own Yes/No “Incident Management is off — enable it now?” via `AskUserQuestion`, delegate to the
+  `IncidentMgmt` SOR (MCP steps, never `Skill`), verify exact `ENABLED`; No halts.
+- **Phase 1c — SLA Management gate.** SLA Management **and** the permanent SLA Versioning switch — two
+  writes; delegate to `itsm-shakti/SLASettings`. Read both flags first. If either is off, ask with
+  `AskUserQuestion` before ANY write, as two separate questions: **Q1** “SLA Management for IT Service
+  is off — enable it now?” (Yes/No; only when SLA Management is off), then **Q2** the SLA Versioning
+  permanence ack (Enable / Stop; exact wording in `references/mcp-invocation.md`). Never merge them, never
+  preview later steps before each is answered, and never treat a Yes at Phase 1a/1b or the original
+  request as consent; any No → HALT.
 - **Phase 2 — Predefined vs Custom** (Incident only). Detect the seeded policy first; read the live
   `Incident.Priority` picklist before the fork (custom values → recommend Custom); warn if the
   priority matrix is off (only the default tier fires); Business Hours note only if the user
   specified hours. Predefined → 4B → 5 (if asked) → 6 → **STOP**;
   Custom → 3a → 3b → 3c → 4A → 5 (if asked) → 6.
-- **Phase 3a — Preflight.** Master Incident Mgmt (`service-cloud-itsm-incident`; `NOT_AVAILABLE` →
-  HALT, `NOT_ENABLED` → one ack + delegate), `discover`/`describe` the SLA ops, Incident describe,
+- **Phase 3a — Preflight.** Step 1 only reuses the Phase 1b Incident Management result; then `discover`/`describe` the SLA ops, Incident describe,
   resolve Business Hours, idempotency probe. No Account. `401`/`403`/`404` → halt with the raw error.
 - **Phase 3b — Milestone strategy** per `examples/milestone-patterns.md`.
 - **Phase 3c — Confirm** the full plan (Business Hours by name, every milestone) before any write.
@@ -139,15 +148,15 @@ before executing.** Phase index and their non-negotiable gates:
 
 | Constraint | Rationale |
 |-----------|-----------|
-| Gate **IT Service Management enablement** first (Phase 1a, before Phase 1b) — exact apiName `service-cloud-itsm-setup`, never a look-alike; `NOT_ENABLED` → tell the user plainly + a single ack to enable (reversible) or stop; the enable write is dispatched **directly** (no owning SOR exists yet) and re-read to confirm | Higher-level org gate sits above every ITSM feature, including the Master Incident Mgmt pref below |
-| Gate **SLA Management** first (Phase 1b) — **two separate writes** (SLA Management, then the one-way **SLA Versioning**); **two separate acks (master, then permanence) — never merged**; decline/blocked/verify-fail → **HALT**; re-read + report real state | Versioning is irreversible; writes don't confirm state |
+| Gate **IT Service Management enablement** (Phase 1a), then **Incident Management** (Phase 1b, its own Yes/No) before Phase 1c — exact apiNames only, never a look-alike; rules as in the phase list above | Higher-level org gate sits above every ITSM feature |
+| Gate **SLA Management** first (Phase 1c) — **two separate writes** (SLA Management, then the one-way **SLA Versioning**); **two separate `AskUserQuestion`s before any write (Q1 SLA Management Yes/No, then Q2 permanence) — never merged, never inferred from an earlier gate's Yes**; decline/blocked/verify-fail → **HALT**; re-read + report real state | Versioning is irreversible; writes don't confirm state |
 | Offer **predefined (OOB)** first (Phase 2, Incident only); detect before seed; if chosen, seed → verify → **STOP** (no custom upsell) | OOB seed isn't idempotent — re-seed duplicates |
 | `discover` + `describe` before any mutation | Catches a missing SLA surface / disabled Incident Mgmt early |
 | Ask (`AskUserQuestion`) the milestone strategy — never silently default to Single | Real ITSM policies have >1 milestone |
 | Reuse one MilestoneType per shared name; a distinct one per distinct concern | Runtime keys milestones by MilestoneType |
 | Multi-milestone: halt on any milestone-create failure (no half-attached policy) | Partial attach diverges from the confirmed plan |
 | Priority-tiered: reconcile every `Priority` value against the live picklist before dispatch — drop/rename standard rows that don't match **and add a milestone for each custom active value** the org added | Server accepts any string → an unknown value is a dead milestone; a custom value with no milestone gets no SLA |
-| **Delegate every write to its approved SLA leaf** (`MilestoneTypes`, `create-sla-policy`, `create-milestone`, `create-milestone-action`, `activate-sla-policy`, `create-entitlement-criteria`) — the skill decides inputs, the leaf owns the contract. Scoped inline exceptions (no served owning SOR yet): the Phase 1a enable and the Phase 4A step 1 Business Hours create | Single contract-owner per write; the skill re-deriving Connect shapes drifts from the served leaves |
+| **Delegate every owned write** — prerequisite feature enables to the `IncidentMgmt` SOR; SLA writes to their approved SLA leaves (`MilestoneTypes`, `create-sla-policy`, `create-milestone`, `create-milestone-action`, `activate-sla-policy`, `create-entitlement-criteria`). The Phase 4A step 1 Business Hours create remains inline because no served SOR owns it | Single contract-owner per write; re-deriving an owned contract here would drift from its served owner |
 | **Business Hours** (Custom): honor a named schedule, described calendar, or time zone (time zone only → ask 24×7 (recommended) or custom hours; reuse a match, else create one after the Phase 3c confirm); zero active → offer a 24×7 create. Never set `IsDefault` or modify an existing record. Predefined: the seeder always uses the org default — warn only if the user specified hours | Default 24×7 or the customer's own calendar; `BusinessHours` is not API-deletable, so creates are confirmed first |
 | **Custom flow**: activation provisions the auto-Entitlement (`activate-sla-policy`: `isActive` + `createEntitlement` as **QUERY params**) — matching Incidents then engage **per-Incident via `EntitlementId`** (**not** a manual sObject Entitlement, and no Account). An org-wide auto-apply criterion via `create-entitlement-criteria` is **optional** — only on an explicit always-match request, never by default. **OOB seed path**: one seeder call (`save-selected-options`, lowercase `selectedOptions`) provisions the entire active bundle incl. the Entitlement — no per-leaf calls, no manual `POST /sobjects/Entitlement`, no activate PATCH | Custom: one call activates **and** provisions, so a manual `POST /sobjects/Entitlement` would duplicate it. OOB: the platform seeder builds and activates the whole default bundle server-side, so the skill neither rebuilds it leaf-by-leaf nor provisions the Entitlement by hand |
 | **No record Id in any message** (see Output contract, incl. reused artifacts); `AskUserQuestion` labels customer-facing (no "demo"/internal defaults) | Leaked Ids / internal framing look unprofessional to the customer |
@@ -159,10 +168,10 @@ Additional API quirks: `references/mcp-invocation.md`.
 
 ## Verification Checklist
 
-- [ ] **IT Service Management enablement gated (Phase 1a)** — exact apiName `service-cloud-itsm-setup` read `ENABLED` via live read, or the user explicitly acked an enable (reversible) that a re-read confirms; declined / unexpected status → **HALTED** before Phase 1b.
-- [ ] **SLA Management gated (Phase 1b)** — SLA Management + SLA Versioning both on (two separate writes), only after the **permanence ack** (separate from the master ack); reported state = a re-read, not the write. Declined / blocked / verify-fail → **HALTED** before Phase 2/3a, no artifacts.
+- [ ] **IT Service Management enablement gated (Phase 1a)** — exact apiName `service-cloud-itsm-setup` read exact `ENABLED`, or exact `NOT_ENABLED` with no blocked reasons received one Yes/No enable question delegated to the `IncidentMgmt` SOR and its verify step confirmed exact `ENABLED`; declined, blocked, missing, error, or unexpected status → **HALTED** before Phase 1b.
+- [ ] **Incident Management gated (Phase 1b)** — exact `service-cloud-itsm-incident` `ENABLED` via live read, or delegated to the `IncidentMgmt` SOR after its own Yes/No when `NOT_ENABLED` (`NOT_AVAILABLE` → HALT); its verify step confirmed `ENABLED` — not a user assertion, not a look-alike.
+- [ ] **SLA Management gated (Phase 1c)** — SLA Management + SLA Versioning both on (two separate writes), only after Q1 (SLA Management Yes/No) and the separate Q2 **permanence ack**, each asked via `AskUserQuestion`; reported state = a re-read, not the write. Declined / blocked / verify-fail → **HALTED** before Phase 2/3a, no artifacts.
 - [ ] **Predefined vs Custom offered (Phase 2)** — with the feature ON, OOB *Standard Support for Incidents* offered first; if present, reported not re-seeded; if chosen, seeded (2 MilestoneTypes + 6 milestones + Entitlement), verified, **no** custom offer after.
-- [ ] Master Incident Mgmt pref (exact `service-cloud-itsm-incident`) `ENABLED` via live read, or delegated when `NOT_ENABLED` (`NOT_AVAILABLE` → HALT) — not a user assertion, not a look-alike.
 - [ ] `discover`/`describe` confirmed the SLA Connect ops.
 - [ ] Incident describe returned 200 with `EntitlementId`, `SlaStartDate`, `SlaExitDate`.
 - [ ] Active Business Hours resolved and named in the confirmed plan — the user's named schedule / a matching calendar / the org default / a user-selected record, or a create (described calendar or 24×7 when none exist) confirmed at Phase 3c, then SOQL-verified active. Predefined: the seeded policy's Business Hours reported by name (or "none").
@@ -171,7 +180,7 @@ Additional API quirks: `references/mcp-invocation.md`.
 - [ ] Writes **delegated to the SLA leaves** in order — the four core writes: MilestoneType(s) → Policy → Milestone(s) → activate + auto-Entitlement (the optional org-wide auto-apply criterion only if explicitly requested); any milestone-create failure halted (no partial attach). Trivial on no-op.
 - [ ] **Milestone actions (Phase 5)** — if requested, attached to **every** named milestone; each confirmed from `body.success` + `actionMappings`, not the `201`; full set narrated before write.
 - [ ] SLA Policy verified via SOQL, not the create response (no-op: the Phase-3a read is the verification).
-- [ ] Test Incident has ≥1 EntityMilestone on the **correct tier** with a `TargetDate` (the engagement proof; Priority matched for Priority-tiered); expected milestone(s) present. Matrix off / still order-1 after one retry → reported "other tiers not checked" + pointed to `service-itsm-incident-priority-configure`, no recreate loop. `SlaStartDate` populated confirms it too, but may be null when the Entitlement is auto-applied via criteria — not a failure. Skip on no-op.
+- [ ] Test Incident has ≥1 EntityMilestone on the **correct tier** with a `TargetDate` (the engagement proof; Priority matched for Priority-tiered); expected milestone(s) present. Matrix off / still order-1 after one retry → reported "other tiers not checked" + pointed to the Priority Matrix setting in Setup, no recreate loop. `SlaStartDate` populated confirms it too, but may be null when the Entitlement is auto-applied via criteria — not a failure. Skip on no-op.
 - [ ] **No record Id in any message** — interim narration *and* final report; artifacts by name, test Incident by `IncidentNumber` (see Output contract).
 - [ ] Before/after + summary shown; no-op states the pre-existing config verbatim + "no changes made".
 
@@ -198,6 +207,6 @@ Use the `examples/output-templates.md` templates; fill placeholders as-is. The s
 
 ## Related Skills
 
-The priority matrix (Impact × Urgency → Priority) is separate — `service-itsm-incident-priority-configure`;
-if a Priority-tiered strategy is requested but `Incident.Priority` lacks values, direct the user there
-first. Other ITSM flows (Major Incident Mgmt, custom fields) are out of scope.
+The priority matrix (Impact × Urgency → Priority) is separate and not configured here;
+if a Priority-tiered strategy is requested but `Incident.Priority` lacks values, direct the user to the
+Priority Matrix setting in Setup first. Other ITSM flows (Major Incident Mgmt, custom fields) are out of scope.

package/skills/service-itsm-agentic-setup-incident-sla-configure/examples/milestone-patterns.md

@@ -243,4 +243,4 @@ never a re-seed).
 | Priority-tiered needs a Priority | The test Incident in Phase 6 must derive a `Priority` value matching one of the milestones — otherwise no EntityMilestone spawns. `Priority` is not directly insertable — set `Impact` and `Urgency` so the org's matrix derives the target Priority (see `references/mcp-invocation.md` → Verify SLA engagement) — subject to the Phase 6 step 2 stopping rule. |
 | Multi-milestone partial-failure | If milestone #2 of N fails to attach, halt and surface the raw error. Do NOT continue attaching #3..N — the policy will be half-configured. |
 | `order` field | Numeric 1..N. Not load-bearing for runtime evaluation (all milestones fire independently), but controls display order in the UI. |
-| Priority-tiered + Priority Matrix skill | `Incident.Priority` is derived from the Impact × Urgency matrix only when the matrix is **on** (`IncPriorityMatrixEnabled`); when it is off, every Incident gets the org's default priority, so only that tier's milestone fires. `service-itsm-incident-priority-configure` turns the matrix on and configures the mapping — run it first (see `references/mcp-invocation.md` → Priority matrix flag). |
+| Priority-tiered + Priority Matrix | `Incident.Priority` is derived from the Impact × Urgency matrix only when the matrix is **on** (`IncPriorityMatrixEnabled`); when it is off, every Incident gets the org's default priority, so only that tier's milestone fires. The Priority Matrix setting in Setup turns the matrix on and configures the mapping — do that first (see `references/mcp-invocation.md` → Priority matrix flag). |

package/skills/service-itsm-agentic-setup-incident-sla-configure/references/mcp-invocation.md

@@ -18,9 +18,9 @@ skill never handles credentials or an org alias — everything is derived from t
 - [Response envelope](#response-envelope)
 - [Routes](#routes)
 - [Phase 1a — IT Service Management enablement gate](#phase-1a--it-service-management-enablement-gate)
-- [Phase 1b — SLA Management for IT Service prerequisite gate](#phase-1b--sla-management-for-it-service-prerequisite-gate)
+- [Phase 1b — Incident Management prerequisite gate (direct read)](#phase-1b--incident-management-prerequisite-gate-direct-read)
+- [Phase 1c — SLA Management for IT Service prerequisite gate](#phase-1c--sla-management-for-it-service-prerequisite-gate)
 - [Discovery — always run first](#discovery--always-run-first)
-- [Preflight A — Master Incident Management pref (direct read)](#preflight-a--master-incident-management-pref-direct-read)
 - [Preflight B — SLA fields on the Incident sObject](#preflight-b--sla-fields-on-the-incident-sobject)
 - [Resolve Business Hours](#resolve-business-hours)
 - [Create MilestoneType](#create-milestonetype)
@@ -41,7 +41,7 @@ singly wrapped:
 { "status_code": 200, "body": <REST/Connect response> }
 ```
 
-Read `body`. The `/headless/invoke/platform/slasettings/…` routes (Phases 1b, 2 and 4B) return the
+Read `body`. The `/headless/invoke/platform/slasettings/…` routes (Phases 1c, 2 and 4B) return the
 same shape: the invoke envelope is unwrapped before the response reaches you, so read `body` for
 them too.
 
@@ -51,10 +51,10 @@ them too.
 
 | Method + path | Purpose |
 |---------------|---------|
-| `GET  /headless/invoke/platform/slasettings/get-sla-management-permission` | Phase 1b — read whether SLA Management is on (composite: Entitlements + Simplified SLA Setup + Pause Milestone). Delegated to `itsm-shakti/SLASettings` |
-| `PATCH /headless/invoke/platform/slasettings/set-sla-management-permission` | Phase 1b — turn SLA Management on (`isEnabled:true`; flips the three prefs atomically; requires Entitlements already on or it throws). **Reversible.** Delegated to `itsm-shakti/SLASettings` |
-| `GET  /headless/invoke/platform/slasettings/get-sla-versioning-permission` | Phase 1b — read whether SLA Versioning is on. Delegated to `itsm-shakti/SLASettings` |
-| `PATCH /headless/invoke/platform/slasettings/set-sla-versioning-permission` | Phase 1b — turn SLA Versioning on (`isEnabled:true`). **Separate write; permanent / one-way** — the controller refuses to disable it. Delegated to `itsm-shakti/SLASettings` |
+| `GET  /headless/invoke/platform/slasettings/get-sla-management-permission` | Phase 1c — read whether SLA Management is on (composite: Entitlements + Simplified SLA Setup + Pause Milestone). Delegated to `itsm-shakti/SLASettings` |
+| `PATCH /headless/invoke/platform/slasettings/set-sla-management-permission` | Phase 1c — turn SLA Management on (`isEnabled:true`; flips the three prefs atomically; requires Entitlements already on or it throws). **Reversible.** Delegated to `itsm-shakti/SLASettings` |
+| `GET  /headless/invoke/platform/slasettings/get-sla-versioning-permission` | Phase 1c — read whether SLA Versioning is on. Delegated to `itsm-shakti/SLASettings` |
+| `PATCH /headless/invoke/platform/slasettings/set-sla-versioning-permission` | Phase 1c — turn SLA Versioning on (`isEnabled:true`). **Separate write; permanent / one-way** — the controller refuses to disable it. Delegated to `itsm-shakti/SLASettings` |
 | `GET  /services/data/v{version}/setup/org/preferences/IncPriorityMatrixEnabled` | Phase 2 / 6 — is the Impact × Urgency priority matrix on? Read-only warning, not a gate |
 | `GET  /services/data/v{version}/sobjects/Incident/describe` | Preflight — Incident Management on + SLA fields present |
 | `GET  /services/data/v{version}/query` | SOQL reads (BusinessHours, SlaProcess, EntityMilestone) via `query_params.q` |
@@ -81,10 +81,10 @@ org-resolved version is always at or above that floor.
 
 ## Phase 1a — IT Service Management enablement gate
 
-**New, higher-level org gate — resolve before Phase 1b and before Preflight A below.** "IT Service
+**New, higher-level org gate — resolve first. Phase 1b (the Incident Management gate) follows immediately, before Phase 1c.** "IT Service
 Management" (apiName `service-cloud-itsm-setup`) is a higher-level org gate that sits
-above every per-feature ITSM master toggle, including Master Incident Management (Preflight A). Read
-via the same Setup Discovery Connect API used by Preflight A:
+above every per-feature ITSM master toggle, including Master Incident Management (Phase 1b). Read
+via the same Setup Discovery Connect API used by Phase 1b:
 
 ```json
 mcp__headless-360__dispatch_readonly({
@@ -94,35 +94,77 @@ mcp__headless-360__dispatch_readonly({
 ```
 
 Filter `body.features[]` client-side to the element where `apiName == "service-cloud-itsm-setup"` —
-the **exact** apiName, never a look-alike. Read its `status`. It has two states:
-`ENABLED` / `NOT_ENABLED` — no `NOT_AVAILABLE`. Treat any unexpected status
-value conservatively, the same as a halt.
+the **exact** apiName, never a look-alike. Only the exact status `ENABLED` passes immediately.
+Only exact `NOT_ENABLED` with no blocked reasons is eligible for confirmed enablement.
 
 **Status → action:**
 
-- `ENABLED` → proceed to Phase 1b.
-- `NOT_ENABLED` → tell the user plainly that IT Service Management is not enabled, then dispatch a
-  single `AskUserQuestion`: enable it now (note it's **reversible** — it can be disabled again later)
-  or stop.
-  - **Enable** →
-    ```json
-    mcp__headless-360__dispatch({
-      "url":    "/services/data/v{version}/connect/setup/discovery/feature/service-cloud-itsm-setup/enable",
-      "method": "POST"
-    })
-    ```
-    Success returns `201` with `{"success": true}`. If it 4xxs, or the re-read below doesn't
-    confirm `ENABLED`, halt, surface the raw error, and point to Setup as the manual fallback. There
-    is **no owning SOR** to delegate this write to yet (unlike Preflight A's master pref, which
-    delegates to `service-itsm-incident-mgmt-configure`) — dispatch it directly here as a scoped,
-    temporary exception to this skill's "delegate every write" rule; swap for a delegate once a
-    dedicated SOR for `service-cloud-itsm-setup` exists. Re-read to confirm `status == "ENABLED"`
-    before continuing.
-  - **Stop** → halt, point to Setup for manual enablement.
+- `ENABLED` → continue to Phase 1b (the Incident Management gate), then Phase 1c.
+- Exact `NOT_ENABLED` with no blocked reasons → ask every time, never as plain text, with a single
+  `AskUserQuestion` (single-select, exactly two options: Yes and No): **“IT Service Enablement is off —
+  enable it now?”** The options are exactly “Yes” and “No”, with no other text in the question
+  or options. Do not preview later steps before it is answered.
+  - **Yes** → delegate to the `IncidentMgmt` SOR, explicitly stating that the user already
+    confirmed this exact change in this conversation so the delegate does not ask again. Run
+    `read-itsm-setup-feature-status`, `enable-itsm-setup-feature`, and
+    `verify-itsm-setup-feature-status`. The delegate owns the empty-body POST and the read-back.
+    If blocked reasons are present, the call fails, the entry is missing, or the verify step does
+    not read exact `ENABLED`, halt, surface the raw error or blocked reasons, and point to Setup.
+    Delegating means the MCP tools, not a Claude Code skill: `describe` the `IncidentMgmt` SOR, read
+    its steps by `id`, and `dispatch` each step exactly as the SOR defines it. Never call `Skill` for
+    it and never invent an enable URL.
+  - **No** → halt, point to Setup for manual enablement.
+- Missing entry, error, blocked reasons, or any other status → halt and point to Setup; do not
+  ask to enable and do not delegate.
 
 ---
 
-## Phase 1b — SLA Management for IT Service prerequisite gate
+## Phase 1b — Incident Management prerequisite gate (direct read)
+
+The master ITSM Incident Management pref is exposed on the **Setup Discovery Connect API**
+under `apiName = service-cloud-itsm-incident`. The setup-org-preferences endpoint does not
+expose the master (`IncidentMgmtEnabled` / `ITSMIncidentMgmtEnabled` both 404) — read via
+Setup Discovery instead.
+
+```json
+mcp__headless-360__dispatch_readonly({
+  "url":    "/services/data/v{version}/connect/setup/discovery/features",
+  "method": "GET"
+})
+```
+
+The endpoint returns the full feature catalog (~763 entries, ~1.1 MB) and does not honor
+`?apiName=` server-side. Filter `body.features[]` client-side to the element where
+`apiName == "service-cloud-itsm-incident"` — the **exact** apiName. Read its `status`
+(`ENABLED` / `NOT_ENABLED` / `NOT_AVAILABLE`).
+
+> **Never substitute a look-alike.** The catalog also contains `service-cloud-incident-management`
+> — that is **generic Service Cloud Incident Management** (built on Case Management, so its
+> `dependencyStatuses` chain through `service-cloud-case-management` → Support Settings Default Case
+> Owner + Automated Case User). It is **not** the ITSM master this skill targets, and enabling it
+> (plus its Case chain) does **not** unlock ITSM Incident SLA. If `service-cloud-itsm-incident` is
+> absent or `NOT_AVAILABLE`, do **not** fall back to it — halt (see below).
+
+**Status → action** (never auto-enable the master as an implied SLA dependency):
+
+- `ENABLED` → proceed.
+- `NOT_AVAILABLE` (ITSM Incident Management license/entitlement not present on the org) → **halt and
+  surface it** — the master cannot be enabled here, so there is no ack and no delegate. This is the
+  correct terminal outcome on an unlicensed org (do not pursue Case Management / generic Incident
+  Management as a workaround).
+- `NOT_ENABLED` → get an explicit `AskUserQuestion` ack first (per `references/workflow.md` Phase 1b), phrased
+  as the delegate's own confirm payload — `Master Incident Management: NOT_ENABLED → ENABLED` — then
+  delegate to the `IncidentMgmt` SOR, stating that the user already confirmed this exact change
+  in this conversation. That "yes" **is** the delegate's confirm-to-write (same change, same session,
+  nothing written in between), so do **not** ask a second time. Run the delegate's
+  `read-itsm-incident-feature-status`, `enable-itsm-incident-feature`, and
+  `verify-itsm-incident-feature-status` steps, and require exact `ENABLED` before continuing. If the
+  user declines, halt — every downstream SLA artifact depends on the master being on.
+  Delegating means the MCP tools, not a Claude Code skill: `describe` the `IncidentMgmt` SOR, read
+  its steps by `id`, and `dispatch` each step exactly as the SOR defines it. Never call `Skill` for
+  it and never invent an enable URL.
+
+## Phase 1c — SLA Management for IT Service prerequisite gate
 
 **SLA Management for IT Service reads as fully enabled only when BOTH sub-settings are on —
 Simplified SLA Setup AND SLA Versioning.** In Setup it shows **In Progress** while either is off. Both
@@ -219,14 +261,17 @@ accept and conflates the two. Do **not** offer a "versioning-off" path (none exi
 the reads, not a fixed script.
 
 - If **both** SLA Management and Versioning are already on → skip the acks; the gate passes.
-- **Q1 — master prerequisite (only if master Incident Mgmt is `NOT_ENABLED`):** ask to enable it
-  first. It's **reversible** — present it as a prerequisite with **no** permanence warning. Offer
-  **Enable** or **Stop — make no changes**. A declined master → HALT.
-- **Q2 — enable + permanence ack (a distinct question, after the master is on):** if SLA Management
-  and/or Versioning are off → ask, in customer terms: completing SLA Management setup turns on **SLA
-  Management** and, as a separate step, **SLA Versioning**, which **can't be turned off once enabled**
-  — SLA Management itself can be turned off again later, but that will **not** turn Versioning back
-  off; Versioning is permanent. Offer **Enable** or **Stop — make no changes**.
+- **Q1 — SLA Management enable (only if SLA Management reads off), asked before the first write:** ask
+  **“SLA Management for IT Service is off — enable it now?”** (single-select, exactly two options: Yes and
+  No; never plain text; the options are exactly “Yes” and “No”, with no other text; ask every time and do
+  not preview later steps before it is answered). Present it as reversible with **no** permanence
+  warning. A No → HALT, point to Setup, make no changes. Incident Management was already asked at Phase 1b
+  and its Yes does not cover this write.
+- **Q2 — permanence ack (a distinct question, asked before the Versioning write and after Q1 is verified):**
+  if Versioning is off → ask via `AskUserQuestion`, in customer terms: enabling **SLA Versioning** **can't
+  be turned off once enabled** — SLA Management itself can be turned off again later, but that will
+  **not** turn Versioning back off; Versioning is permanent. Offer **Enable** or **Stop — make no
+  changes**. Ask it even when the user already said “enable SLA”.
 - **Any decline — including a request to enable SLA Management but *not* Versioning — means HALT.**
   The gate needs Versioning on, and there is no way to honor "SLA Management without Versioning" as a
   completed gate; enable **no further** writes and do not proceed to SLA/milestone setup (a reversible
@@ -267,47 +312,6 @@ does not index this surface — direct the user to Setup and stop.
 
 ---
 
-## Preflight A — Master Incident Management pref (direct read)
-
-The master ITSM Incident Management pref is exposed on the **Setup Discovery Connect API**
-under `apiName = service-cloud-itsm-incident`. The setup-org-preferences endpoint does not
-expose the master (`IncidentMgmtEnabled` / `ITSMIncidentMgmtEnabled` both 404) — read via
-Setup Discovery instead.
-
-```json
-mcp__headless-360__dispatch_readonly({
-  "url":    "/services/data/v{version}/connect/setup/discovery/features",
-  "method": "GET"
-})
-```
-
-The endpoint returns the full feature catalog (~763 entries, ~1.1 MB) and does not honor
-`?apiName=` server-side. Filter `body.features[]` client-side to the element where
-`apiName == "service-cloud-itsm-incident"` — the **exact** apiName. Read its `status`
-(`ENABLED` / `NOT_ENABLED` / `NOT_AVAILABLE`).
-
-> **Never substitute a look-alike.** The catalog also contains `service-cloud-incident-management`
-> — that is **generic Service Cloud Incident Management** (built on Case Management, so its
-> `dependencyStatuses` chain through `service-cloud-case-management` → Support Settings Default Case
-> Owner + Automated Case User). It is **not** the ITSM master this skill targets, and enabling it
-> (plus its Case chain) does **not** unlock ITSM Incident SLA. If `service-cloud-itsm-incident` is
-> absent or `NOT_AVAILABLE`, do **not** fall back to it — halt (see below).
-
-**Status → action** (never auto-enable the master as an implied SLA dependency):
-
-- `ENABLED` → proceed.
-- `NOT_AVAILABLE` (ITSM Incident Management license/entitlement not present on the org) → **halt and
-  surface it** — the master cannot be enabled here, so there is no ack and no delegate. This is the
-  correct terminal outcome on an unlicensed org (do not pursue Case Management / generic Incident
-  Management as a workaround).
-- `NOT_ENABLED` → get an explicit `AskUserQuestion` ack first (per `references/workflow.md` Phase 3a step 1), phrased
-  as the delegate's own confirm payload — `Master Incident Management: NOT_ENABLED → ENABLED` — then
-  delegate to `service-itsm-incident-mgmt-configure` inline, which writes
-  `POST .../setup/discovery/feature/service-cloud-itsm-incident/enable`. That "yes" **is** the
-  delegate's confirm-to-write (same change, same session, nothing written in between) — do **not**
-  ask the user a second time. Re-read this step to verify `status == "ENABLED"` before continuing. If
-  the user declines, halt — every downstream SLA artifact depends on the master being on.
-
 ## Preflight B — SLA fields on the Incident sObject
 
 ```json
@@ -321,7 +325,7 @@ Confirm `body.fields[]` includes `EntitlementId`, `SlaStartDate`, and `SlaExitDa
 describe 404s or the fields are missing, Entitlement Management is not enabled for Incident —
 stop and direct the user to **Setup → Incident Management / Entitlement Settings**. This is
 a **secondary sanity check on the SLA-field surface**, not the master-pref state signal;
-Preflight A above is the master-state signal.
+Phase 1b is the master-state signal.
 
 The response is large (~86 KB). If your host truncates it, filter with a grep-style search rather
 than reading the whole body — you only need to confirm those three field names exist.
@@ -712,8 +716,8 @@ mcp__headless-360__dispatch_readonly({
 
 `false` → the Impact × Urgency matrix is off and every Incident gets the org's default priority, so a
 priority-tiered policy (the predefined one, or Custom Priority-tiered) only fires that tier's
-milestones. Warn the user and point to `service-itsm-incident-priority-configure`; never enable the
-matrix from this skill (that skill owns the write). Read-only — not a gate.
+milestones. Warn the user and point to the Priority Matrix setting in Setup; never enable the
+matrix from this skill. Read-only — not a gate.
 
 ---
 
@@ -778,7 +782,7 @@ if the org's matrix mapped your `Impact`/`Urgency` to a different Priority, adju
 input derives the default priority. If the flag is `true` but the derived `Priority` is still the
 order-1 tier after one adjustment, stop. Either way report: the SLA engages (the `EntityMilestone` +
 `TargetDate`), the other tiers were **not** checked, why, and that
-`service-itsm-incident-priority-configure` configures the matrix. Never loop on recreates.
+the matrix is configured in Setup (Priority Matrix). Never loop on recreates.
 
 ---