@salesforce/afv-skills 1.65.1 → 1.66.0

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

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

@@ -11,34 +11,65 @@ tools. Call shapes / templates / response envelope / gotchas live in `references
 Each Phase 3a read carries a **skip-if-already-known** clause: skip only when the same fact was
 produced **this session** by a successful `dispatch_readonly` on the current org and unwritten since —
 a user statement is never cache-eligible. Cacheable: IT Service Management enablement (Phase 1a,
-only if `ENABLED`), master Incident Mgmt pref (step 1, only if
-`ENABLED`), SLA feature + Versioning (Phase 1b), Incident describe (3, incl. the `Incident.Priority`
+only if `ENABLED`), master Incident Mgmt pref (Phase 1b, only if
+`ENABLED`), SLA feature + Versioning (Phase 1c), Incident describe (3, incl. the `Incident.Priority`
 picklist), the priority-matrix flag (Phase 2 step 2), `BusinessHoursId` (4), SLA Connect ops (2). (Step 5 resolves no Account — Incident has
 none.) **When in doubt, re-check.**
 
 ## Phase 1a — IT Service Management enablement gate
 
-**Resolve this gate first, before Phase 1b and before the Master Incident Mgmt pref below.**
+**Resolve this gate first. The Incident Management gate (Phase 1b) is resolved immediately after it and before Phase 1c.**
 "IT Service Management" (`service-cloud-itsm-setup`) is a higher-level org gate — it sits above every per-feature ITSM master toggle, including Master
 Incident Management. Read via the Setup Discovery Connect API
-(`GET .../connect/setup/discovery/features`), filtered client-side to the **exact** apiName
-`service-cloud-itsm-setup` — never a look-alike. It has two states, `ENABLED` /
-`NOT_ENABLED` (no `NOT_AVAILABLE` — treat any unexpected value as a halt).
-
-- `ENABLED` → proceed to Phase 1b.
-- `NOT_ENABLED` → tell the user plainly that IT Service Management is not enabled, then a single
-  `AskUserQuestion`: enable it now (note it's **reversible** — it can be disabled again later) or
-  stop.
-  - **Enable** → dispatch the enable route **directly** — there is no owning SOR to delegate this
-    write to yet (unlike the Master Incident Mgmt gate below, which delegates to
-    `service-itsm-incident-mgmt-configure`); this is a scoped, temporary exception to "delegate
-    every write," flagged for a future delegate swap once a dedicated SOR exists. Halt and surface
-    the raw error on any failure. Re-read to confirm `ENABLED` before continuing.
-  - **Stop** → halt, point to Setup for manual enablement.
+(`GET /services/data/v{version}/connect/setup/discovery/features`, using the org's full API version with its
+minor such as v68.0; if the read fails, stop and do not retry other version strings), filtered client-side to the **exact** apiName
+`service-cloud-itsm-setup` — never a look-alike. Exact `ENABLED` passes immediately. Only exact
+`NOT_ENABLED` with no blocked reasons is eligible for confirmed enablement.
+
+- `ENABLED` → continue to Phase 1b (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 it does not ask again. Run its
+    `read-itsm-setup-feature-status`, `enable-itsm-setup-feature`, and
+    `verify-itsm-setup-feature-status` steps. Halt on blocked reasons, an error, a missing entry, or
+    any verify result other than exact `ENABLED`.
+    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.
 
 Shapes: `references/mcp-invocation.md` (Phase 1a).
 
-## Phase 1b — SLA Management for IT Service prerequisite gate
+## Phase 1b — Incident Management prerequisite gate
+
+**Resolve this gate right after Phase 1a and before Phase 1c; it is a separate question from the SLA Management acks.**
+`service-cloud-itsm-incident` is the master ITSM Incident Management pref that every Incident SLA artifact
+depends on. Read via the same Setup Discovery Connect API as Phase 1a, filtered client-side to the
+**exact** apiName `service-cloud-itsm-incident` — never a look-alike (`service-cloud-incident-management`
+is generic Case-based Incident Management, not our target). Skip the read only when the cache clause in
+“Before you start” applies. Read `status`:
+
+- `ENABLED` → continue to Phase 1c.
+- `NOT_AVAILABLE` (license missing) → **halt and surface it** — cannot be enabled here, no delegate/ack.
+- `NOT_ENABLED` (empty blocked reasons) → ask “Incident Management is off — enable it now?” every time with a single
+  `AskUserQuestion` (single-select, exactly two options: Yes and No), never as plain text, and never auto-enable as an
+  implied SLA dependency.
+  - **Yes** → delegate to the `IncidentMgmt` SOR, stating that the user already confirmed this exact change so it must
+    not ask again. Run its `read-itsm-incident-feature-status`, `enable-itsm-incident-feature` and
+    `verify-itsm-incident-feature-status` steps; require exact `ENABLED`. 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 and point to Setup; every SLA artifact depends on the master being on.
+- Blocked reasons, error, missing entry or any other status → halt with a plain explanation and no question.
+
+Full shape + why setup-org-preferences 404s here: `references/mcp-invocation.md` (Phase 1b).
+
+## Phase 1c — SLA Management for IT Service prerequisite gate
 
 **Resolve this gate first, on its own. Reads are safe up front; confirm the org before any write.**
 "SLA Management for IT Service" is enabled only when **both** Simplified SLA Setup **and** SLA
@@ -50,13 +81,15 @@ settings surface) — discover → describe → dispatch rather than re-deriving
 Shapes / preconditions / `enableBlockedReasons` / ack wording: `references/mcp-invocation.md`.
 
 - **Read both** (`dispatch_readonly`); proceed to Phase 2 **only when both are on**.
-- **On an OFF org, read the master license first** (Phase 3a step 1, `service-cloud-itsm-incident`):
-  `NOT_AVAILABLE` → **HALT** — don't flip the permanent Versioning switch where Incident SLA can't run.
-- **Two separate `AskUserQuestion` acks — never merge.** (a) master Incident Mgmt `NOT_ENABLED` → ask
-  to enable it first (reversible, no permanence warning). (b) a *distinct* permanence ack: completing
-  the gate also turns on **SLA Versioning** (a **separate** write), which **can't be turned off** (SLA
-  Management disables later but Versioning stays on). Offer **enable**/**stop** — no "versioning-off";
-  a bare "enable SLA" is **not** consent.
+- **The master license was already resolved in Phase 1b** (`service-cloud-itsm-incident`): `NOT_AVAILABLE` halted there, so
+  the permanent Versioning switch is never flipped where Incident SLA can't run.
+- **Two separate `AskUserQuestion`s before any write — never merge, never skip.** (Q1) SLA Management
+  off → ask “SLA Management for IT Service is off — enable it now?” (Yes/No, no permanence warning; skip
+  only when SLA Management already reads on). (Q2) a *distinct* permanence ack: completing the gate also
+  turns on **SLA Versioning** (a **separate** write), which **can't be turned off** (SLA Management
+  disables later but Versioning stays on). Offer **enable**/**stop** — no "versioning-off". A Yes at
+  Phase 1a/1b, a bare "enable SLA" or the original request is **not** consent for either write; do not
+  preview later steps before each question is answered. Incident Management was already asked at Phase 1b.
 - **Decline (b), non-empty `enableBlockedReasons`, or a re-read mismatch → HALT** — enable no SLA
   Mgmt/Versioning, don't proceed to Phase 2/3a (a reversible master enable from (a) stands). **After
   any write, re-read both and report the REAL state** — never trust `201`/`204`.
@@ -65,7 +98,7 @@ Shapes / preconditions / `enableBlockedReasons` / ack wording: `references/mcp-i
 
 Once the gate passes, offer the OOB policy **before** any custom-flow questions. **Incident only.**
 
-1. **Prerequisite + detect.** Confirm master Incident Mgmt pref `ENABLED` (Phase 3a step 1). Then
+1. **Prerequisite + detect.** Confirm master Incident Mgmt pref `ENABLED` (Phase 1b). Then
    `dispatch_readonly` `GET /headless/invoke/platform/slasettings` (get-existing-checkbox-states) —
    its lowercase-keyed map's `incident` value is the authoritative "is the OOB default seeded?"
    answer (this is the seeder's own dedup read; it maps to display name **"Standard Support for
@@ -93,7 +126,7 @@ Once the gate passes, offer the OOB policy **before** any custom-flow questions.
    matrix flag). The predefined policy is priority-tiered, and with the matrix **off** every Incident
    gets the org's default priority, so only that tier's milestones fire. If it is off, say so plainly
    in the fork prompt (when the fork is skipped, on the Priority-tiered option of the strategy
-   question instead) and point to `service-itsm-incident-priority-configure` to turn it on. This is a
+   question instead) and point to the Priority Matrix setting in Setup to turn it on. This is a
    warning, not a gate — never enable the matrix from this skill.
    **Business Hours note (only when the user specified hours).** The seeder takes **no** Business Hours
    input — it always attaches the org's active **default** Business Hours (`IsDefault = true`), or none
@@ -120,15 +153,7 @@ Once the gate passes, offer the OOB policy **before** any custom-flow questions.
 
 **On any `401` / `403` / `404` from a step below, halt and surface the raw error** — the org/client is misconfigured. `401` → MCP auth (ECA/token). `403` → user perm OR ITSM Incident Management license/pref missing. `404` → `headless-360` not activated OR Entitlement Management not enabled for Incident.
 
-1. **Master Incident Management pref — direct read** *(skip conditions in “Before you start”)*.
-   `dispatch_readonly` `GET .../connect/setup/discovery/features`, filter `features[]` to the **exact**
-   `apiName == "service-cloud-itsm-incident"` — never a look-alike (`service-cloud-incident-management`
-   is generic Case-based Incident Management, not our target). Read `status`: `ENABLED` → proceed;
-   `NOT_AVAILABLE` (license missing) → **halt and surface it** — cannot be enabled here, no delegate/ack;
-   `NOT_ENABLED` → **explicit `AskUserQuestion` ack first (never auto-enable as an implied SLA
-   dependency)**, then delegate to `service-itsm-incident-mgmt-configure` inline — that ack is the
-   delegate's confirm-to-write, so never ask twice — and re-read; if declined, halt — every SLA artifact below depends on the master being on. Full shape + why
-   setup-org-preferences 404s here: `references/mcp-invocation.md` (Preflight A).
+1. **Master Incident Management pref** — already gated in Phase 1b; reuse that result. Do not re-ask or re-read unless a write happened since *(skip conditions in “Before you start”)*.
 2. **Discover the Connect operations** — *(skip if already verified this session — see “Before you start”)*.
    `mcp__headless-360__discover(query="sla-management milestone")` to confirm the SLA Management
    Connect API is indexed, then `mcp__headless-360__describe(id=<operation_id>)`
@@ -212,7 +237,7 @@ selection expands to N creates in Phase 4A step 4 (one delegation per milestone,
 
 ## Phase 3c — Confirm before mutating
 
-1. **Confirm the plan** — present the resolved config (target **org**, **SLA Policy** name,
+1. **Confirm the plan** — print the plan as text in the reply **first**, then ask; the `AskUserQuestion` must never refer to a plan that has not already been shown. Present the resolved config (target **org**, **SLA Policy** name,
    **Business Hours: `<name>`** (and, if Phase 3a step 4 planned a create, its time zone + weekly windows and
    that it will be **created** — a new record this skill does not remove later), the **engagement model** (per-Incident via `EntitlementId` — **no
    Account**, since Incident has no Account field), and the **full per-milestone list** — never
@@ -348,7 +373,7 @@ IST business-hours note: `references/mcp-invocation.md` (Milestone Actions).
     but the derived `Priority` is still the order-1 tier after **one** `Impact`/`Urgency` adjustment,
     stop creating test Incidents. Either way, report that the SLA engages but the other tiers were not
     checked, say why (matrix off / matrix maps these inputs to that tier), and point to
-    `service-itsm-incident-priority-configure`. Narrate by `IncidentNumber`, never the Id.
+    the Priority Matrix setting in Setup. Narrate by `IncidentNumber`, never the Id.
 3. **Verify engagement + tiering** — SOQL that an `EntityMilestone` landed on the **correct tier**
     (a Moderate/Low Incident → the 240/960 tier, NOT 30/120) with a `TargetDate` — that row is the
     reliable engagement proof. `Incident.SlaStartDate` is populated when you set `EntitlementId` at