@salesforce/afv-skills 1.61.0 → 1.62.0

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

@@ -1,15 +1,10 @@
 ---
 name: service-itsm-agentic-setup-incident-sla-configure
-description: "End-to-end Incident SLA setup for Service Cloud ITSM — creating a MilestoneType, an Incident-scoped SLA Policy (SlaProcess), attaching a Milestone with criteria, and wiring an Entitlement so Incidents derive an EntityMilestone with a computed TargetDate. Use when the user asks to configure SLA milestones on Incidents, create an SLA policy for Incident records, set up entitlement processes for ITSM, wire milestones so they appear on the Incident page, or enable SLA tracking for incident management. 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."
+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.8"
+  version: "3.10"
   domains: ["Service"]
   minApiVersion: "67.0"
-  accessCheck:
-    - type: "userPerm"
-      value: "CustomizeApplication"
-    - type: "orgPerm"
-      value: "IncidentMgmt.orgHasITSMOrgPermission"
   relatedSkills:
     - "service-itsm-incident-mgmt-configure"
     - "service-itsm-incident-priority-configure"
@@ -31,21 +26,22 @@ allowed-tools: |
 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
-**SLA Management for IT Service** setup item (the Phase 0.5 gate).
+**IT Service Management enablement** (the Phase 1a gate) and **SLA Management for IT Service**
+setup item (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 —
 matching Incidents then engage the SLA **per-Incident via `EntitlementId`**, with no Account). An
 org-wide auto-apply **entitlement criterion** is an *optional* fifth write, dispatched **only** on an
-explicit always-match request (Phase 2 step 12) — never by default. (The predefined/OOB
+explicit always-match request (Phase 4A step 6) — never by default. (The predefined/OOB
 seed fork differs — it does none of this by hand: a single seed call provisions the whole active
-bundle — policy, milestones, and Entitlement — in one shot; see Phase 0.6 / Phase 2-OOB.)
+bundle — policy, milestones, and Entitlement — in one shot; see Phase 2 / Phase 4B.)
 This skill owns all the Incident-SLA **interaction** (gates, forks, milestone strategy,
-verification); the raw **write** operations are **delegated to the approved CSP-Sun SLA
+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 0.5 **enable** (+ Versioning) and Phase 2-OOB **seed** writes delegate to
+The Phase 1b **enable** (+ Versioning) and Phase 4B **seed** writes delegate to
 **`itsm-shakti/SLASettings`** (owns the SLA-Management settings surface) — same discover → describe → dispatch.
 
 ## Scope
@@ -54,8 +50,8 @@ The Phase 0.5 **enable** (+ Versioning) and Phase 2-OOB **seed** writes delegate
   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 0.5); offering the OOB *Standard Support for Incidents*
-  policy vs a custom one (Phase 0.6, Incident only) — all via `headless-360` MCP.
+  **SLA Management for IT Service** (Phase 1b); 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.
 
@@ -68,7 +64,7 @@ masked** (`557VW…R3XVYA0` still leaks) — in **any** user-facing text: interi
 final report. Holds for artifacts you **created** *and* ones you **detected/reused** — name each (the
 name you supplied on create, or matched on reuse), keep its Id internal (chaining only). Verifying or
 matching via SOQL? Report the **verified attributes/name**, never the Id you queried by. **Looking *up*
-an Id is the same rule** — resolving the default **BusinessHours** or an existing policy returns
+an Id is the same rule** — resolving **Business Hours** (resolved, user-selected, or created in Phase 4A step 1) or an existing policy returns
 `{Id, Name}`; narrate the resolved **name only** and keep the returned Id internal — **never** echo it
 back as `Resolved "<name>" (001VW…)`. One
 exception: on a **halt** you may relay the raw error body verbatim even if it embeds an Id —
@@ -76,7 +72,7 @@ don't hand-edit it.
 
 - **Wrong:** `SLA policy created (552VW…)` · `Incident created (0ny…)` · `First Response → 557VW…R3XVYA0` (reuse)
 - **Right:** `Created SLA policy "Standard Support for Incidents"` · `reusing the existing First Response
-  milestone type` · the test Incident is "the test Incident" until Phase 3, then its `IncidentNumber`;
+  milestone type` · the test Incident is "the test Incident" until Phase 6, then its `IncidentNumber`;
   milestones by `MilestoneType` name.
 
 ---
@@ -92,81 +88,49 @@ 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 0.5 gate first.** Then: **which org?** (`headless-360` binds to the current OAuth session —
-confirm before mutating); **milestone strategy?** (Phase 1.4); **milestone criteria?** (default
+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
 `Status != Closed` + pattern-specific filters). **Do not ask for an Account** — Incident has no
-Account field; engagement is per-Incident via `EntitlementId`.
+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.
 
-Default suggestion: SLA Policy `Incident SLA Policy`, default BusinessHours, Entitlement
+Default suggestion: SLA Policy `Incident SLA Policy`, suggested default Business Hours (confirmed at
+Phase 3c), Entitlement
 auto-provisioned on activation (no Account), engagement per-Incident via `EntitlementId`, milestone
-strategy resolved per Phase 1.4.
+strategy resolved per Phase 3b.
 
 ---
 
 ## Workflow
 
-All steps are sequential — **always read before you write**; every call goes through
-`mcp__headless-360__*`. **The full step-by-step detail — every phase's reads, delegated writes, and
-API quirks — lives in `references/workflow.md`; read it before executing.** The phases and their
-non-negotiable gates (constraints table + verification checklist below):
-
-- **Phase 0 — Reuse session state.** Skip a Phase 1 read 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. When in doubt, re-check.
-- **Phase 0.5 — SLA Management gate (resolve first, alone).** Enabled only when **both** SLA
-  Management and SLA Versioning are on — **two separate writes**: enabling SLA Management does **not**
-  turn on Versioning; Versioning is a distinct, **permanent, one-way** write. **Two separate
-  `AskUserQuestion` acks — never merged:** (a) a reversible master Incident-Mgmt enable if
-  `NOT_ENABLED`; (b) a distinct **permanence** ack for the irreversible Versioning switch — a bare
-  "enable SLA" is **not** consent. Decline (b) / non-empty `enableBlockedReasons` / re-read mismatch /
-  master `NOT_AVAILABLE` → **HALT**. After each write, re-read and report the REAL state — never trust
-  `200`/`204`. Enable + versioning writes **delegate to `itsm-shakti/SLASettings`**.
-- **Phase 0.6 — Predefined (OOB) vs Custom (Incident only).** Detect *Standard Support for Incidents*
-  first (already present → report seeded; no re-seed — the OOB seed isn't idempotent — and no
-  upsell). **Before** the fork prompt, read the live `Incident.Priority` picklist (Phase 1 step 3's
-  Incident describe, pulled forward): any custom active
-  value beyond the four standard tiers (e.g. `Emergency`) means OOB covers standard tiers only — say
-  so plainly and **redirect to Custom** by default; don't *proactively* bolt a custom milestone onto
-  the predefined policy (and never re-seed). Attach one only if the user **explicitly** asks — a direct
-  `csp-sun/create-milestone` against the seeded policy (resolved by name), never a re-seed.
-  Then one `AskUserQuestion`, **Predefined first/recommended**. Predefined → Phase 2-OOB → 2.5 →
-  verify → **STOP**; Custom → Phase 1 → 1.4 → 1.5 → 2 → 3.
-- **Phase 1 — Preflight & discovery.** Master Incident-Mgmt pref (exact `service-cloud-itsm-incident`,
-  never a look-alike; `NOT_AVAILABLE` → HALT, `NOT_ENABLED` → ack + delegate), `discover`/`describe`
-  the SLA Connect ops, Incident describe (`EntitlementId`/`SlaStartDate`/`SlaExitDate` **+ the live
-  `Incident.Priority` picklist** for Priority-tiered reconciliation), default BusinessHours,
-  idempotency probe. **No Account is resolved — Incident has no Account field; engagement is
-  per-Incident via `EntitlementId` (neither flow needs or asks for an Account).** Any
-  `401`/`403`/`404` → halt and surface the raw error.
-- **Phase 1.4 — Milestone strategy.** Load `examples/milestone-patterns.md` (skip conditions + the
-  five strategies, defaults, MilestoneType-reuse). Never silently default to Single.
-- **Phase 1.5 — Confirm before mutating.** Narrate the resolved plan (org, SLA name, engagement model
-  = per-Incident via `EntitlementId` (no Account), **full per-milestone list** — never collapse to "N
-  milestones"); require an explicit "yes" unless a skip
-  condition holds (up-front auth / no-op / prior confirmation). Everything after this mutates the org.
-- **Phase 2 — Create SLA artifacts (delegated writes, exact order).** The skill decides every input;
-  **delegate each raw write to its approved csp-sun SLA leaf**. The **four ordered core writes**:
-  `MilestoneTypes` → `create-sla-policy` (created inactive) → `create-milestone` ×N →
-  `activate-sla-policy` (auto-provisions the Entitlement). Do not re-derive Connect shapes.
-  `create-entitlement-criteria` is an **optional step 12** — dispatch it **only** on an explicit
-  org-wide always-match request; otherwise engagement is per-Incident via `EntitlementId` and no
-  criterion is written. The **Priority reconciliation** lands at the milestone step: match every value to
-  the live picklist, drop/rename unmatched standard rows, **and add a milestone for each custom active
-  value**. Verify via SOQL, not the write response; halt on any milestone-create failure (no
-  half-attached policy).
-- **Phase 2-OOB — Seed the predefined policy.** One call to the platform seeder route
-  (`PATCH /headless/invoke/platform/slasettings/save-selected-options`, body
-  `{"selectedOptions":["incident"]}` — values **lowercase**) provisions the whole active bundle:
-  the policy, its 2 MilestoneTypes + 6 milestones, and the Entitlement + auto-apply criteria — all
-  active, in one shot. No per-leaf csp-sun calls, no manual `POST /sobjects/Entitlement`, no activate
-  PATCH. Detect first (`GET /headless/invoke/platform/slasettings`, key `incident:true` = already
-  seeded) because the seeder isn't idempotent. Detect + seed **delegate to `itsm-shakti/SLASettings`**.
-- **Phase 2.5 — Milestone actions (optional).** Only if warn/escalate/notify asked; apply to **every**
-  named milestone; confirm from `body.success` + non-empty `actionMappings`, not the `201`.
-- **Phase 3 — Verify.** SOQL-confirm the policy read back `active=true`; create a test Incident on a
-  **non-lowest tier** (set `Urgency`/`Impact` — `Priority` is matrix-derived, not directly
-  insertable); confirm an `EntityMilestone` on the correct tier with a `TargetDate` (a null
-  `SlaStartDate` under auto-apply is a non-blocker). Then report.
+Sequential — **always read before you write**; every call goes through `mcp__headless-360__*`.
+**Per-phase detail (reads, delegated writes, API quirks) lives in `references/workflow.md` — read it
+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 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,
+  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.
+- **Phase 4A — Create** (Business Hours first if planned, step 1) → `MilestoneTypes` →
+  `create-sla-policy` → `create-milestone` ×N → `activate-sla-policy`; optional step 6 criterion
+  only on an explicit always-match request.
+- **Phase 4B — Seed** via `save-selected-options` (`{"selectedOptions":["incident"]}`), delegated
+  to `itsm-shakti/SLASettings`; verify and name its Business Hours.
+- **Phase 5 — Milestone actions** (only if asked) on every named milestone.
+- **Phase 6 — Verify** via SOQL + a non-lowest-tier test Incident with an `EntityMilestone`; matrix
+  off or still order-1 after one retry → stop and report the other tiers unchecked.
 
 ---
 
@@ -174,16 +138,18 @@ non-negotiable gates (constraints table + verification checklist below):
 
 | Constraint | Rationale |
 |-----------|-----------|
-| Gate **SLA Management** first (Phase 0.5) — **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 |
-| Offer **predefined (OOB)** first (Phase 0.6, Incident only); detect before seed; if chosen, seed → verify → **STOP** (no custom upsell) | OOB seed isn't idempotent — re-seed duplicates |
+| 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 |
+| 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 csp-sun 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 | Single contract-owner per write; the skill re-deriving Connect shapes drifts from the served leaves |
+| **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 |
+| **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) | The #1 retest failure; leaked Ids / internal framing look unprofessional |
+| **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 |
 | **Another Incident policy already active + Custom chosen → narrate coexistence only.** The custom policy is targeted **per-Incident via `EntitlementId`** (Incident has no Account field to scope on) and **additive**; the existing (predefined/broad) policy stays the org-wide one. **Never offer, plan, or perform — in the fork *or* the closing report —** deactivating an existing policy, reordering its entitlement criteria, **broadening the custom policy to match-all / auto-apply-to-all, or "deciding/resolving precedence" across policies**. Target specific Incidents via `EntitlementId`; the existing policy stays active (see `references/workflow.md` → Coexistence) | Changing a policy the user didn't ask to touch is out of scope — this skill configures a *new* coexisting custom policy, not edits to an existing one. Deactivating (`activate-sla-policy` *can* send `isActive=false`) or re-ranking another policy's criteria risks disrupting a live SLA, and no leaf arbitrates cross-policy precedence (predefined: no un-seed path, manual delete only). Both are meant to coexist — the agent otherwise improvises an out-of-scope deactivation/reorder/precedence upsell |
 
 Additional API quirks: `references/mcp-invocation.md`.
@@ -192,18 +158,19 @@ Additional API quirks: `references/mcp-invocation.md`.
 
 ## Verification Checklist
 
-- [ ] **SLA Management gated (Phase 0.5)** — 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 0.6/1, no artifacts.
-- [ ] **Predefined vs Custom offered (Phase 0.6)** — 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.
+- [ ] **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.
+- [ ] **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`.
-- [ ] Default BusinessHours found.
-- [ ] **Milestone strategy resolved** — Phase 1.4 skip condition OR `AskUserQuestion`; Priority-tiered / Custom reconciled every `Priority`/criteria value against the live picklist before dispatch (dropped/renamed unmatched standard rows **and** added a milestone for each custom active `Priority` value).
-- [ ] **Configuration confirmed OR skip condition met** (up-front auth / no-op / prior confirmation / "yes"); the resolved plan (org, SLA name, engagement model = per-Incident via `EntitlementId` (no Account), per-milestone list) narrated before Phase 2.
-- [ ] Writes **delegated to the csp-sun 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 2.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-1 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. `SlaStartDate` populated confirms it too, but may be null when the Entitlement is auto-applied via criteria — not a failure. Skip on no-op.
+- [ ] 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").
+- [ ] **Milestone strategy resolved** — Phase 3b skip condition OR `AskUserQuestion`; Priority-tiered / Custom reconciled every `Priority`/criteria value against the live picklist before dispatch (dropped/renamed unmatched standard rows **and** added a milestone for each custom active `Priority` value).
+- [ ] **Configuration confirmed OR skip condition met** (up-front auth / no-op / prior confirmation / "yes"); the resolved plan (org, SLA name, Business Hours by name, engagement model = per-Incident via `EntitlementId` (no Account), per-milestone list) narrated before Phase 4A.
+- [ ] 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.
 - [ ] **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".
 
@@ -219,11 +186,11 @@ Use the `examples/output-templates.md` templates; fill placeholders as-is. The s
 
 | File | When to read |
 |------|--------------|
-| `references/workflow.md` | Executing — the full step-by-step Phase 0–3 detail (per-phase reads, delegated writes, API quirks); the constraints table + verification checklist stay in this SKILL.md body |
+| `references/workflow.md` | Executing — the full step-by-step Phase 1–6 detail (per-phase reads, delegated writes, API quirks); the constraints table + verification checklist stay in this SKILL.md body |
 | `references/mcp-invocation.md` | Every phase — call shapes, templates, response envelope, discovery, gotchas |
-| `examples/milestone-patterns.md` | Phase 1.4 — the five strategies: times, criteria, MilestoneType reuse, filter extensions |
-| `assets/attach-milestone.json` | Phase 2 step 10 — milestone POST body; substitute ids/timeTrigger/order; append `filterItems` |
-| `assets/attach-milestone-action.json` | Phase 2.5 — Warn/Escalate action body templates (Field Update); pair with mcp-invocation.md (Milestone Actions) |
+| `examples/milestone-patterns.md` | Phase 3b — the five strategies: times, criteria, MilestoneType reuse, filter extensions |
+| `assets/attach-milestone.json` | Phase 4A step 4 — milestone POST body; substitute ids/timeTrigger/order; append `filterItems` |
+| `assets/attach-milestone-action.json` | Phase 5 — Warn/Escalate action body templates (Field Update); pair with mcp-invocation.md (Milestone Actions) |
 | `examples/output-templates.md` | Output Format — success/partial report templates; fill placeholders, no record Id |
 
 ---

package/skills/service-itsm-agentic-setup-incident-sla-configure/assets/attach-milestone-action.json

@@ -1,5 +1,5 @@
 {
-  "_notes": "Phase 2.5 request-body templates for POST /connect/sla-management/sla-policies/<slaId>/milestones/<milestoneId>/actions. Send EXACTLY ONE action sub-object per call. timeLength/timeUnit live INSIDE checkpoint. timeUnit is Minutes|Hours|Days only. Never send isInitiationCheckpoint. Confirm success from body.success + non-empty body.actionMappings (+ triggerId for timed checkpoints), not the 201. UNIQUENESS: the actionFieldUpdate name/developerName must be unique per milestone (a WorkflowFieldUpdate DeveloperName is unique on the Incident object) — attaching the same-named action to a second milestone fails with DUPLICATE_DEVELOPER_NAME. Suffix both with the milestone (e.g. _FR for First Response, _RES for Resolution). These mirror the example bodies in references/mcp-invocation.md (Milestone Actions — see 'Milestone-action bodies', pending live verification) — keep the two in sync.",
+  "_notes": "Phase 5 request-body templates for POST /connect/sla-management/sla-policies/<slaId>/milestones/<milestoneId>/actions. Send EXACTLY ONE action sub-object per call. timeLength/timeUnit live INSIDE checkpoint. timeUnit is Minutes|Hours|Days only. Never send isInitiationCheckpoint. Confirm success from body.success + non-empty body.actionMappings (+ triggerId for timed checkpoints), not the 201. UNIQUENESS: the actionFieldUpdate name/developerName must be unique per milestone (a WorkflowFieldUpdate DeveloperName is unique on the Incident object) — attaching the same-named action to a second milestone fails with DUPLICATE_DEVELOPER_NAME. Suffix both with the milestone (e.g. _FR for First Response, _RES for Resolution). These mirror the example bodies in references/mcp-invocation.md (Milestone Actions — see 'Milestone-action bodies') — keep the two in sync.",
 
   "warningAction": {
     "_notes": "Warn BEFORE target. timeLength = round(targetMinutes * (1 - X/100)). 2-hr (120-min) milestone, warn at 75% -> 30 min before. Default action = Field Update raising Urgency = High. NOTE: Incident.Priority is DERIVED from Impact x Urgency and is NOT directly updateable (createable:false/updateable:false) — a Field Update targeting Priority fails INVALID_FIELD_FOR_INSERT_UPDATE, so escalate by driving its updateable inputs (Urgency here, Impact on breach). Replace <MS> in name/developerName with a per-milestone suffix. For a custom-field target, put its 00N... CustomField id in columnEnumOrId (not the __c API name).",
@@ -34,7 +34,7 @@
   },
 
   "istBusinessHours": {
-    "_notes": "'IST business hours' is a POLICY-level BusinessHours, not a milestone-action field. Resolve-then-create: reuse an existing BusinessHours with TimeZoneSidKey='Asia/Kolkata' if present, else POST /sobjects/BusinessHours with this body (confirm first; BusinessHours is NOT API-deletable). Attach via the policy/Entitlement BusinessHoursId. If the org has ignoreMilestoneBusinessHours=true, milestone timers run 24/7 and ignore this - disclose that.",
+    "_notes": "'IST business hours' is a POLICY-level BusinessHours, not a milestone-action field. Resolve-then-create: reuse an existing BusinessHours with TimeZoneSidKey='Asia/Kolkata' if present, else POST /sobjects/BusinessHours with this body (confirm first; BusinessHours is NOT API-deletable). Attach via the policy/Entitlement BusinessHoursId. ignoreMilestoneBusinessHours only changes how time remaining is displayed; target dates still follow these Business Hours.",
     "Name": "IST Business Hours",
     "TimeZoneSidKey": "Asia/Kolkata",
     "MondayStartTime": "09:00:00.000Z",

package/skills/service-itsm-agentic-setup-incident-sla-configure/assets/attach-milestone.json

@@ -1,6 +1,6 @@
 {
-  "milestoneTypeId": "<milestoneTypeId from Phase 2 step 8>",
-  "businessHoursId": "<businessHoursId resolved in Phase 1>",
+  "milestoneTypeId": "<milestoneTypeId from Phase 4A step 2>",
+  "businessHoursId": "<businessHoursId resolved in Phase 3a>",
   "timeTrigger": 60,
   "order": 1,
   "startTimeBasedOn": "MILESTONE_CRITERIA",

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

@@ -1,14 +1,14 @@
 # Milestone Strategy Patterns — Incident SLA
 
-Phase 1.4 of the SLA workflow either infers the milestone strategy from the user's prompt (see
-"Phase 1.4 skip conditions" below) or asks the user to pick one. This file lists each option with
+Phase 3b of the SLA workflow either infers the milestone strategy from the user's prompt (see
+"Phase 3b skip conditions" below) or asks the user to pick one. This file lists each option with
 its default configuration, MilestoneType-reuse rules, and the exact `Attach Milestone` payloads
-that Phase 2 step 10 dispatches. Every `filterItems.operator` value here uses the exact enum the
+that Phase 4A step 4 dispatches. Every `filterItems.operator` value here uses the exact enum the
 server accepts — `Equals`, `NotEqual` — never `!=` or `Equal`.
 
 ---
 
-## Phase 1.4 skip conditions (do NOT dispatch `AskUserQuestion` when any hold)
+## Phase 3b skip conditions (do NOT dispatch `AskUserQuestion` when any hold)
 
 Every SLA policy needs at least one milestone, but the strategy question is skipped when the
 milestone shape is already determined by the request:
@@ -17,14 +17,14 @@ milestone shape is already determined by the request:
   first-response trigger", "Response + Resolution defaults", "per-priority tiers". Extract the
   described milestone(s) verbatim (time, criteria, name) and use the pattern defaults below. Do
   NOT re-ask.
-- **(b) The eventual branch is an idempotent no-op** — Phase 1 step 6 established `noOp=true`
-  (every requested artifact already exists with matching configuration). Skip Phase 1.4, skip
-  Phase 2, and report the no-op verbatim citing the read evidence.
+- **(b) The eventual branch is an idempotent no-op** — Phase 3a step 6 established `noOp=true`
+  (every requested artifact already exists with matching configuration). Skip Phase 3b, skip
+  Phase 4A, and report the no-op verbatim citing the read evidence.
 - **(c) Explicit up-front authorization** — a phrase that unambiguously waives the confirm gate
   (`"you have my explicit authorization to create"`, `"do not re-ask me to confirm"`,
   `"proceed without asking"`) **and** a concrete milestone shape is derivable per (a). A passing
   mention ("build it", "go ahead") is NOT sufficient by itself. Waives the interactive confirm;
-  does NOT waive Phase 1.5 plan-narration — dispatch only after SLA Policy name, the engagement model
+  does NOT waive Phase 3c plan-narration — dispatch only after SLA Policy name, the engagement model
   (per-Incident via `EntitlementId`; no Account), and the per-milestone list have been written to the
   response.
 
@@ -34,7 +34,8 @@ dispatch `AskUserQuestion` with the five options below. Priority-tiered requires
 
 All strategies share these defaults unless overridden:
 
-- `businessHoursId`: the default BusinessHours resolved in Phase 1 step 4
+- `businessHoursId`: the Business Hours Id resolved in Phase 3a step 4, or created in Phase 4A step 1 (suggested default or
+  user-selected)
 - `startTimeBasedOn`: `MILESTONE_CRITERIA` (timer starts when the milestone's criteria first match; this is the OOB default — send this exact token, see `references/mcp-invocation.md` Attach Milestone)
 - `milestoneAgreementType`: `SLA` — inside each `milestoneCriteria[]` item (mandatory per the UI). Valid UI values are `SLA` (customer-facing) or `OLA` (internal); the API accepts any string because the underlying field is `Text(40)` with no server-side picklist, but the UI renders unrecognized values as blank
 - `milestoneState`: `ACTIVE` (**uppercase — the server matches this value case-sensitively**; `Active`/`active` silently fail to register the criterion) inside `milestoneCriteria[]`
@@ -44,7 +45,7 @@ All strategies share these defaults unless overridden:
 
 ---
 
-## AskUserQuestion prompt (Phase 1.4, only when no skip condition applies)
+## AskUserQuestion prompt (Phase 3b, only when no skip condition applies)
 
 ```text
 Question: How many milestones do you want on this SLA policy?
@@ -63,16 +64,16 @@ Before rendering options 3 and 5, confirm the live `Incident.Priority` picklist
 the pattern against them in **both** directions: if any value used in a default row is missing from
 the org's picklist, drop that milestone; and if the org has **added** active Priority values beyond
 the four default tiers, add a milestone for each so no active Priority value is left without one.
-Note both adjustments in the Phase-1.5 confirmation.
+Note both adjustments in the Phase-3c confirmation.
 
 **Hard gate — never assume the picklist.** The reconciliation above requires the *actual* live
 `Incident.Priority` picklist. Do **not** present the Priority-tiered milestone list, and do **not**
 state or imply that the picklist "is the four standard tiers" / "needs no reconciliation", **from
 assumption**. The four standard tiers (Critical/High/Moderate/Low) are only *defaults* — they are
 NOT what the org necessarily has. You may present the tier list **only after** the live
-`Incident.Priority` describe (Phase 1 step 3) has actually been dispatched **this session** and you
+`Incident.Priority` describe (Phase 3a step 3) has actually been dispatched **this session** and you
 have its `fields[].picklistValues` in hand. If it has not run yet — e.g. Custom was invoked
-**directly**, skipping the Phase 0.6 fork where the describe is normally pulled forward — run
+**directly**, skipping the Phase 2 fork where the describe is normally pulled forward — run
 `GET /services/data/v{version}/sobjects/Incident/describe` **now**, before offering or rendering any
 per-priority list, and derive the tiers from its **active** `picklistValues`. An org-added active
 value such as `Emergency` MUST appear as its own milestone; silently defaulting to four tiers leaves
@@ -84,11 +85,11 @@ those Incidents with no milestone and no SLA engagement.
 
 Dispatch every pattern below via `mcp__headless-360__dispatch` with `method: "POST"` and
 `url: "/services/data/v{version}/connect/sla-management/sla-policies/<slaId>/milestones"` (substitute
-the SLA policy id captured in Phase 2 step 9). The reusable request-body template lives at
+the SLA policy id captured in Phase 4A step 3). The reusable request-body template lives at
 `assets/attach-milestone.json` — load and populate it rather than reconstructing the JSON.
 
 Substitute per-pattern: `milestoneTypeId` is the id returned when you created the MilestoneType,
-`businessHoursId` is the id resolved in Phase 1, and `timeTrigger` + `order` come from the
+`businessHoursId` is the id resolved in Phase 3a, and `timeTrigger` + `order` come from the
 pattern's row. `filterItems` in the template carries the base "Status != Closed" row that every
 pattern shares; each pattern's table lists **additional** row objects to append to `filterItems`
 (same schema: `table`, `column`, `operator`, `order`, `value`) — do not replace the base row, add
@@ -136,7 +137,7 @@ concurrently on its own 8-hour timer.
 
 Assumes the standard `Critical / High / Moderate / Low` picklist (some orgs and prompts label the
 mid tier `Medium` instead of `Moderate` — same P3 tier, different label). Reconcile the four default
-rows against the **live `Incident.Priority` picklist** (from the Phase-1 Incident describe) before
+rows against the **live `Incident.Priority` picklist** (from the Phase-3a Incident describe) before
 dispatch, handling every difference:
 
 - **Renamed** value → rename the milestone's filter to the live label (e.g. `Medium` for the P3 tier).
@@ -145,7 +146,7 @@ dispatch, handling every difference:
 - **Added / custom active** value (any active Priority value not covered by the four default rows) →
   **add a milestone for it** so those Incidents still engage an SLA. Reuse the `Incident First Response`
   MilestoneType, filter `Incident.Priority Equals <customValue>`, and confirm its `timeTrigger` with the
-  user in Phase 1.5 (offer a sensible default from the nearest standard tier). Do **not** silently skip a
+  user in Phase 3c (offer a sensible default from the nearest standard tier). Do **not** silently skip a
   custom value — an uncovered active Priority means those Incidents get no milestone and no SLA engagement.
 
 The multi-item `filterItems` array combines with `AND` by default — both `Status != Closed` AND
@@ -168,7 +169,7 @@ Incident create (e.g. via the Priority Matrix), the milestone re-evaluates on th
 
 All three run concurrently once their criteria match (`startTimeBasedOn: MILESTONE_CRITERIA`) — the "ladder" is enforced by the timers,
 not by chaining. To fire automation at a milestone's warning/violation checkpoint (warn before
-target, escalate on breach), attach a **milestone action** in Phase 2.5 — see
+target, escalate on breach), attach a **milestone action** in Phase 5 — see
 `references/mcp-invocation.md` (Milestone Actions). (Strictly *sequential* chaining across separate
 milestones is a different mechanism — workflow SLA actions — and remains out of scope.)
 
@@ -191,7 +192,7 @@ For each milestone `i` from 1 to N (where N is confirmed up front):
 5. **Criteria value** — validated against the live picklist for picklist fields; free-form
    otherwise.
 
-After collecting all N milestones, render the full list in Phase 1.5 confirmation and require an
+After collecting all N milestones, render the full list in Phase 3c confirmation and require an
 explicit "yes" before dispatching the create loop.
 
 **Custom-mixed example** (Response for all + per-category resolution):
@@ -211,7 +212,7 @@ before creating the MilestoneType or attaching the milestone.
 ## Predefined preset — "Standard Support for Incidents" (OOB)
 
 This is Salesforce's out-of-box predefined Incident SLA policy — a fixed priority-tiered preset offered
-at the Phase 0.6 fork (not one of the Phase 1.4 custom options above). It pairs an **Acknowledge Within**
+at the Phase 2 fork (not one of the Phase 3b custom options above). It pairs an **Acknowledge Within**
 and a **Resolve Within** milestone per priority tier:
 
 | tier | Acknowledge Within | Resolve Within |
@@ -239,7 +240,7 @@ never a re-seed).
 | Issue | Detail |
 |-------|--------|
 | MilestoneType reuse vs. create | Priority-tiered = 1 MilestoneType reused 4 times. Response + Resolution = 2 types. Escalation ladder = 3 types. |
-| Priority-tiered needs a Priority | The test Incident in Phase 3 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), or create one test Incident per tier. |
+| 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 always derived from the Impact × Urgency matrix (a default matrix always exists). The Priority Matrix skill configures the *mapping* (which Impact × Urgency combination yields which Priority) — it does not turn derivation on or off. Run it first if you need a mapping other than the default. |
+| 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). |

package/skills/service-itsm-agentic-setup-incident-sla-configure/examples/output-templates.md

@@ -12,7 +12,7 @@ Display the error from the `dispatch` response (`{status_code, body}`) exactly a
 Incident SLA Setup Complete (via service-itsm-agentic-setup-incident-sla-configure)
 
 Artifacts created:
-  Milestone Type: <name> (OneTime)
+  Milestone Type: <name> (No Recurrence)
   SLA Policy:     <name> (Active, Incident)
   Milestone:      <time> min, criteria: <criteria summary>
   Entitlement:    <name> (auto-provisioned; no Account — Incident engages per-Incident via EntitlementId)
@@ -35,7 +35,7 @@ Incident SLA Setup Complete (via service-itsm-agentic-setup-incident-sla-configu
 Strategy: <Response + Resolution | Priority-tiered | Escalation ladder | Custom>
 
 Artifacts created:
-  Milestone Types: <name1>, <name2>, ... (OneTime)
+  Milestone Types: <name1>, <name2>, ... (No Recurrence)
   SLA Policy:      <name> (Active, Incident)
   Milestones:
     #1  <MilestoneType name>   <time> min   criteria: <summary>
@@ -62,7 +62,7 @@ Verification:
   No test Incident was created, so EntityMilestone firing was not exercised in this run.
 ```
 
-## Success — milestone actions (Phase 2.5, when Warn/Escalate was requested)
+## Success — milestone actions (Phase 5, when Warn/Escalate was requested)
 
 Append this **Milestone Actions** block to the multi-milestone success report above — do not emit it
 alone. The report must still carry the policy, both milestones (name, time, criteria), the