@salesforce/afv-skills 1.44.0 → 1.45.0

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

@@ -2,13 +2,12 @@
 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."
 metadata:
-  version: "3.4"
+  version: "3.6"
   domains: ["Service"]
   minApiVersion: "67.0"
   relatedSkills:
     - "service-itsm-incident-mgmt-configure"
     - "service-itsm-incident-priority-configure"
-  accessCheck: []
   mcpTools:
     headless-360:
       tools: ["describe", "discover", "dispatch", "dispatch_readonly"]
@@ -23,25 +22,23 @@ allowed-tools: |
 
 # Configuring Incident SLA (End-to-End)
 
-Configures a complete **Incident SLA pipeline** for Service Cloud ITSM — the chain that derives
-an EntityMilestone (with a computed TargetDate) on every Incident that has an Entitlement. Every
-operation runs through the **Salesforce-hosted Headless-360 MCP server** (server key `headless-360`)
-via its four meta-tools (`discover`, `describe`, `dispatch_readonly`, `dispatch`). The org is derived
-from the OAuth JWT — the skill never handles an org id, alias, or credentials. It also needs the
-org-level **SLA Management for IT Service** setup item — a Setup Discovery feature plus a separate,
-permanent **SLA Versioning** bit, both gated by Phase 0.5. Setup has four parts:
-
-1. **MilestoneType** — define what you're measuring (e.g., "First Response").
-2. **SLA Policy** — the SlaProcess scoped to Incident with entry/exit criteria.
-3. **Milestone** — attach to the policy with a time trigger and filter criteria.
-4. **Entitlement** — wire to an Account so Incidents with that Entitlement engage the SLA.
+Configures a complete **Incident SLA pipeline** for Service Cloud ITSM — the chain that derives an
+EntityMilestone (with a computed TargetDate) on every Incident with an Entitlement. Every operation
+runs through the Salesforce-hosted **`headless-360`** MCP server; the org is derived from the OAuth
+JWT — the skill never handles an org id, alias, or credentials. It also needs the org-level **SLA Management for IT
+Service** setup item (the Phase 0.5 gate — see below). Setup has four parts:
+**MilestoneType** (what you measure) → **SLA Policy** (SlaProcess scoped to Incident, entry/exit
+criteria) → **Milestone** (time trigger + filter criteria) → **Entitlement** (wired to an Account so
+Incidents engage the SLA).
 
 ## Scope
 
 - **In scope**: Creating MilestoneTypes, SLA Policies (SlaProcess), Milestones with criteria,
   Entitlements, and verifying SLA engagement on Incident records — all via `headless-360` MCP.
-- **In scope — prerequisite**: checking and (on confirmation) enabling the **SLA Management for IT
-  Service** setup item — the feature + SLA Versioning (Phase 0.5).
+- **In scope — prerequisite**: checking and (on consent) enabling **SLA Management for IT Service**
+  (Phase 0.5); halts if not fully enabled or consent declined.
+- **In scope — predefined vs custom** (Phase 0.6): offering the OOB *Standard Support for Incidents*
+  policy (Incident only) vs a custom one.
 - **Out of scope**: Case SLA/entitlements; Assignment Rules; Escalation Rules; Notification
   Rules; general Entitlement CRUD not related to Incident SLA; SLA reporting.
 
@@ -49,43 +46,27 @@ permanent **SLA Versioning** bit, both gated by Phase 0.5. Setup has four parts:
 
 ## Routes at a glance
 
-Reads dispatch through `mcp__headless-360__dispatch_readonly`, writes through
-`mcp__headless-360__dispatch`. Both take raw HTTP:
-`{"url": "<path>", "method": "GET|POST|PATCH|...", "body"?: {...}, "query_params"?: {...}}` — **not**
-`{operation_id, arguments}`. Full request/response shapes live in `references/mcp-invocation.md`.
-
-| Concern | Method + path | Body |
-|---------|---------------|------|
-| Master Incident Mgmt pref (read) | `GET /services/data/v67.0/connect/setup/discovery/features`, filter `apiName == "service-cloud-itsm-incident"` for `status` | — |
-| SLA Mgmt prerequisite (Phase 0.5) | Feature `status`/`enable` + SLA Versioning read/PATCH on `EntitlementSettings` — see `references/mcp-invocation.md` | see ref |
-| Preflight (Incident on) | `GET /services/data/v67.0/sobjects/Incident/describe` | — |
-| Default BusinessHours | `GET /services/data/v67.0/query` (q via `query_params.q`) | — |
-| Create MilestoneType | `POST /services/data/v67.0/connect/sla-management/milestone-types` | `{"name","description","recurrenceType"}` |
-| Create SLA Policy | `POST /services/data/v67.0/connect/sla-management/sla-policies` | `{"name","processType":"Incident","businessHourId",...}` |
-| Attach Milestone | `POST /services/data/v67.0/connect/sla-management/sla-policies/<id>/milestones` | `{"milestoneTypeId","timeTrigger","milestoneCriteria":[...]}` |
-| Create Entitlement | `POST /services/data/v67.0/sobjects/Entitlement` | `{"Name","AccountId","SlaProcessId","BusinessHoursId","StartDate","EndDate"}` |
-| Create test Incident | `POST /services/data/v67.0/sobjects/Incident` | `{"Subject","EntitlementId",...}` |
-| Verify SLA policy | `GET /services/data/v67.0/query` (q for `SlaProcess`) | — |
-| Verify engagement | `GET /services/data/v67.0/query` (q for `EntityMilestone`) | — |
-
-**Response envelope**: SLA Management Connect, `/sobjects/…`, and `/query` are standard REST — the
-`dispatch*` MCP tool returns the REST response directly (`{status_code, body}`); read `body`. Only
-`/headless/invoke/…` Aura-controller routes are doubly wrapped (`body.body`) — this skill uses none.
+Reads → `mcp__headless-360__dispatch_readonly`, writes → `mcp__headless-360__dispatch`. Both take raw
+HTTP: `{"url","method","body"?,"query_params"?}` — **not** `{operation_id, arguments}`. **Response
+envelope**: standard REST — read `body` from `{status_code, body}`. The full route table — create
+MilestoneType / SLA Policy / Milestone, Entitlement, BusinessHours, test Incident, the Phase 0.5
+feature calls, and the `create-milestone-action` op — with request/response shapes lives in
+`references/mcp-invocation.md`.
 
 ---
 
 ## Clarifying Questions
 
-Ask only what you cannot infer from conversation context (pre-populate and note "(from
-conversation)"). **Resolve the Phase 0.5 gate first, on its own.**
+Ask only what you cannot infer from context (pre-populate; note "(from
+conversation)"). **Resolve the Phase 0.5 gate first.**
 
 - **Which org?** `headless-360` binds to the current OAuth session; confirm the target before mutating.
-- **Milestone strategy?** See Phase 1.4 — skipped when the prompt already names a shape, when the branch is a no-op, or when up-front authorization + a derivable shape are given.
-- **Target Account?** Account to attach the Entitlement to.
+- **Milestone strategy?** See Phase 1.4 (skipped per its skip conditions).
+- **Target Account?** For the Entitlement.
 - **Milestone criteria?** Default `Status != Closed`, plus pattern-specific filters.
 
-Default suggestion: SLA Policy `Incident SLA Policy`, default BusinessHours, first active Account,
-Entitlement `today → today + 1 year`, milestone strategy resolved per Phase 1.4.
+Default suggestion: SLA Policy `Incident SLA Policy`, default BusinessHours, the Account the user
+picks, Entitlement `today → today + 1 year`, milestone strategy resolved per Phase 1.4.
 
 ---
 
@@ -96,62 +77,66 @@ All steps are sequential. **Always read before you write.** Every call goes thro
 
 ### Phase 0 — Reuse what the session already knows
 
-Each Phase 1 read below carries a **skip-if-already-known** clause: skip only when the
-same fact was produced this session **from a successful `dispatch_readonly` response
-tied to the current org**. A user statement is not cache-eligible — a mistaken assertion
-would produce a stale create. When the only source is a user statement, re-read.
-
-- **Master Incident Management pref** — reuse only when the pref was read live this
-  session (successful `dispatch_readonly` on Setup Discovery, or a live read by
-  `service-itsm-incident-mgmt-configure`) AND `status` was `ENABLED` AND no write since.
-  A cached "not enabled" / unknown / user-asserted value is NOT cache-eligible — fall
-  through to step 1.
-- **SLA Management feature + SLA Versioning** — reuse only if both were read live this session
-  (Phase 0.5) and unwritten since; else re-run Phase 0.5.
-- **Incident describe / SLA-field presence** — if `Incident.describe` was already run against
-  the current org this session and the presence of `EntitlementId` / `SlaStartDate` /
-  `SlaExitDate` is in context, skip step 3 and reuse the answer.
-- **Default BusinessHours id** — if a `BusinessHoursId` for the current org's default is
-  already captured, skip step 4.
-- **Account id** — if the Account the user named (or the fallback first-active Account)
-  was already resolved to an `Id` this session, skip step 5.
-- **Discover / describe of SLA Connect operations** — if the routes were already verified
-  as indexed this session, skip step 2.
-
-**When in doubt, re-check.** Skip only when the earlier fact is unambiguously in context
-AND you have not switched orgs — the `headless-360` MCP session binds to one org via the
-JWT, so an org change is only possible if the session was re-authed mid-conversation. If
-the user hints at a different org, or you cannot tell which org the earlier fact came
-from, re-run the read. A wrong skip on a live org write is worse than a duplicated read.
+Each Phase 1 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: master Incident Mgmt pref (step 1, only if
+`ENABLED`), SLA feature + Versioning (Phase 0.5), Incident describe (3), `BusinessHoursId` (4), Account
+id (5), SLA Connect ops indexed (2). **When in doubt, re-check** — a wrong skip on a live write is
+worse than a re-read.
 
 ### Phase 0.5 — SLA Management for IT Service prerequisite gate
 
-**Resolve this gate on its own first — not batched with the clarifying questions. Its reads are
-safe to run up front; still confirm the target org before the enable write.** Gate on the
-org-level **SLA Management for IT Service** setup item before any Phase 2 mutation — two
-independent bits: the Setup Discovery feature `service-cloud-itsm-manage-sla-policies` (Connect route,
-**not** Tooling) and the separate, **permanent** **SLA Versioning** bit
-(`EntitlementSettings.IsEntitlementVersioningEnabled`). Full call shapes, `enableBlockedReasons`
-handling, and the permanence rule are in `references/mcp-invocation.md`.
-
-- **Read both** (`dispatch_readonly`); feature `ENABLED` **and** versioning `true` → skip to Phase 1.
-- **Confirm, then enable only what's off** (`AskUserQuestion`) — stop and relay if `enableBlockedReasons`
-  is non-empty; if versioning is off, flag it's **permanent**.
-- **Enable, then re-read** — never trust the `201` / empty-`204` write response; require `ENABLED` /
-  `true` first.
+**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 (feature
+`service-cloud-itsm-manage-sla-policies`) **and** SLA Versioning
+(`EntitlementSettings.IsEntitlementVersioningEnabled`) are on; either off → not enabled. The one
+feature-`enable` turns on both, **permanently** enabling versioning — inseparable. Shapes /
+`enableBlockedReasons` / ack wording: `references/mcp-invocation.md`.
+
+- **Read both** (`dispatch_readonly`); proceed to Phase 0.6 **only when both are on**.
+- **On an OFF org, read the master license first** (Phase 1 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: enabling
+  **SLA Management** turns on **SLA Versioning**, which **can't be turned off** (the feature disables
+  later but Versioning stays on). Offer **enable**/**stop** — no "versioning-off"; a bare "enable SLA"
+  is **not** consent.
+- **Decline (b), non-empty `enableBlockedReasons`, or a re-read mismatch → HALT** — enable no SLA
+  Mgmt/Versioning, don't proceed to Phase 0.6/1 (a reversible master enable from (a) stands). **After
+  any write, re-read both and report the REAL state** — never trust `201`/`204`.
+
+### Phase 0.6 — Predefined (OOB) vs Custom
+
+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 1 step 1). Then `dispatch_readonly` `GET /connect/sla-management/sla-policies` with
+   `query_params.processTypes=Incident`; match display name **"Standard Support for Incidents"**.
+   - **Already present** → **no re-seed** (no idempotency), no custom upsell; report it is seeded.
+     **If warn/escalate actions were requested → resolve the named existing milestones → Phase 2.5 →
+     Phase 3 verify → STOP** (attach actions even though the policy was already seeded).
+2. **Fork** — one `AskUserQuestion`, **Predefined listed first / recommended**: use Salesforce's
+   predefined Incident SLA policy (*Standard Support for Incidents* — priority-tiered milestones)
+   **or** build a custom one. One-way note: predefined seeds an
+   **active** policy + Entitlement, no un-seed path (manual delete only).
+   - **Predefined →** resolve BusinessHours + Account (Phase 1 steps 4–5) → **Phase 2-OOB** → **Phase
+     2.5** (if actions requested) → Phase 3 verify → **STOP**.
+   - **Custom →** existing Phase 1 → 1.4 → 1.5 → 2 → 3, unchanged.
+
+**MUST read `references/mcp-invocation.md` (Predefined Incident Policy) before seeding.**
 
 ### Phase 1 — Preflight & discovery
 
-**On any `401` / `403` / `404` from a step below, halt and surface the raw error** — the org or client is not configured correctly. `401` → MCP auth (ECA not propagated / expired token). `403` → user perm missing OR ITSM Incident Management license/preference missing (`ITSMIncidentMgmtEnabled` / `IncidentMgmt.orgHasITSMOrgPermission`). `404` → `headless-360` server not activated OR Entitlement Management not enabled for Incident.
+**On any `401` / `403` / `404` from a step below, halt and surface the raw error** — the org/client is misconfigured. `401` → MCP auth (ECA not propagated / expired token). `403` → user perm OR ITSM Incident Management license/pref missing (`ITSMIncidentMgmtEnabled` / `IncidentMgmt.orgHasITSMOrgPermission`). `404` → `headless-360` not activated OR Entitlement Management not enabled for Incident.
 
 1. **Master Incident Management pref — direct read** *(skip conditions in Phase 0)*.
-   `dispatch_readonly` on `GET /services/data/v67.0/connect/setup/discovery/features`,
-   filter `features[]` client-side to `apiName == "service-cloud-itsm-incident"`, read
-   `status`. If `ENABLED`, proceed. **If not, delegate to `service-itsm-incident-mgmt-configure`
-   inline to enable** (it runs its own confirm-to-write), then re-read to verify. If the
-   user declines, halt — every SLA artifact below depends on the master being on. Full
-   call shape + why the setup-org-preferences endpoint 404s here is in
-   `references/mcp-invocation.md` (Preflight A).
+   `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 (confirms-to-write) 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).
 2. **Discover the Connect operations** — *(skip if already verified this session — see Phase 0)*.
    `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>)`
@@ -169,46 +154,37 @@ handling, and the permanence rule are in `references/mcp-invocation.md`.
    `query_params.q="SELECT Id, Name FROM BusinessHours WHERE IsActive = true AND IsDefault = true"`.
    If `body.records` is empty, stop with a message to create default Business Hours in Setup. Capture
    `BusinessHoursId`.
-5. **Resolve the target Account** — *(skip if the Account the user named — or, absent a name,
-   the fallback first-active Account — is already resolved to an Id this session)*. Otherwise the
-   Entitlement in Phase 2 requires an `AccountId`, so resolve it now, before any mutation. If the
-   user named an Account, look it up by name via a `dispatch_readonly`
-   SOQL: `SELECT Id, Name FROM Account WHERE Name = '<escaped name>' LIMIT 1`. If the named Account is
-   not found, **stop and ask** — do NOT silently substitute a different Account. Only when the user
-   did **not** name one, fall back to the first active Account
-   (`SELECT Id, Name FROM Account WHERE IsDeleted = false ORDER BY CreatedDate LIMIT 1`) and surface
-   which Account you chose in the confirmation gate below. If no Account exists at all, stop with a
-   message to create one first. Capture `AccountId` and the Account name.
-6. **Read existing SLA artifacts (idempotency probe)** — `dispatch_readonly` SOQL against
-   `SlaProcess` by name (`SELECT Id, Name FROM SlaProcess WHERE Name = '<name>' AND SObjectType = 'Incident' LIMIT 1` — the physical sObject field is `SObjectType`; `ProcessType` returns `INVALID_FIELD`),
-   `MilestoneType` by name for each type the strategy would create, `SlaMilestone` under the matched
-   `SlaProcess`, and `Entitlement` by name against the resolved Account. Record which artifacts
-   already exist. If **every** artifact the request would create already exists with the requested
-   configuration, Phase 1.4 skip condition (b) applies — set `noOp=true` and skip Phase 1.4 and
-   Phase 2. Any missing or divergent artifact means a mutation is required; proceed to Phase 1.4.
+5. **Resolve the target Account** — *(skip if already resolved this session)*. Phase 2's Entitlement
+   needs an `AccountId`. If the user **named** one → look up (`SELECT Id, Name FROM Account WHERE Name
+   = '<escaped>' LIMIT 1`); not found → **stop and ask**, never substitute. If the user **authorized
+   any/existing Account** → pick the most recently active (`... WHERE IsDeleted = false ORDER BY
+   LastModifiedDate DESC LIMIT 1`) and **surface which** in the plan. Otherwise → **ask via
+   `AskUserQuestion`**: list real candidates by **name only** + "type a name"; **never auto-pick,
+   pre-select, or expose an internal sort key** (e.g. recency). If none exists, stop. Capture `AccountId` + name.
+6. **Read existing SLA artifacts (idempotency probe)** — `dispatch_readonly` SOQL for `SlaProcess` by
+   name (`... WHERE Name = '<name>' AND SobjectType = 'Incident'` — the field is `SobjectType`;
+   `ProcessType` returns `INVALID_FIELD`), each `MilestoneType` the strategy would create,
+   `SlaMilestone` under the matched policy, and `Entitlement` by name on the resolved Account. If
+   **every** artifact already exists with the requested config, set `noOp=true` and skip Phase 1.4 +
+   Phase 2 (skip condition (b)); any missing/divergent artifact → proceed to Phase 1.4.
 
 ### Phase 1.4 — Milestone Strategy
 
 Every SLA policy needs at least one milestone. Load `examples/milestone-patterns.md` — it lists the
-Phase 1.4 skip conditions (concrete shape in prompt, idempotent no-op, explicit up-front
-authorization) and the five strategy options (Single, Response + Resolution, Priority-tiered,
-Escalation ladder, Custom/mixed) with their `AskUserQuestion` prompt, default numbers, and
-MilestoneType-reuse rules. Skip conditions (c) still requires Phase 1.5 plan-narration before
-dispatch. Multi-milestone selection expands to N milestone creates in Phase 2 step 10 (one POST per
-milestone, `order` 1..N, all attached to the same SlaProcess).
+skip conditions (concrete shape in prompt / idempotent no-op / explicit up-front authorization) and
+the five strategy options with their `AskUserQuestion` prompt, defaults, and MilestoneType-reuse
+rules. Skip condition (c) still requires Phase 1.5 plan-narration before dispatch. Multi-milestone
+selection expands to N creates in Phase 2 step 10 (one POST per milestone, `order` 1..N, same SlaProcess).
 
 ### Phase 1.5 — Confirm before mutating
 
-7. **Confirm the plan** — present the resolved configuration (target **org**, **SLA Policy** name,
-   resolved **Account** name, **Entitlement** date range, and the **full per-milestone list** from
-   Phase 1.4 — never collapse Priority-tiered / Custom to "N milestones").
-
-   **Skip the `AskUserQuestion` confirmation prompt** (still narrate the plan before dispatch)
-   when: up-front authorization was granted (note `(authorized in prompt)`); the branch is a no-op
-   (skip Phase 1.5 + Phase 2, report the no-op); or the plan was already confirmed in conversation
-   (note `(confirmed in conversation)`). Otherwise dispatch `AskUserQuestion` and require an
-   explicit "yes" before Phase 2. Everything before this step is read-only; everything after
-   mutates the org.
+7. **Confirm the plan** — present the resolved config (target **org**, **SLA Policy** name, resolved
+   **Account** name, **Entitlement** date range, and the **full per-milestone list** — never collapse
+   Priority-tiered / Custom to "N milestones"). **Skip the `AskUserQuestion`** (but still narrate the
+   plan before dispatch) when up-front authorization was granted (note `(authorized in prompt)`), the
+   branch is a no-op, or it was already confirmed in conversation (note `(confirmed in conversation)`);
+   otherwise require an explicit "yes" before Phase 2. Everything before this step is read-only;
+   everything after mutates the org.
 
 ### Phase 2 — Create SLA Artifacts (exact order — each depends on the previous)
 
@@ -224,24 +200,44 @@ milestone, `order` 1..N, all attached to the same SlaProcess).
     and, for each milestone in the strategy, populate `milestoneTypeId`, `timeTrigger`, `order`
     (1..N in the strategy's order) and any per-pattern `filterItems` additions from
     `examples/milestone-patterns.md`, then `POST /connect/sla-management/sla-policies/<slaId>/milestones`.
-    `milestoneCriteria` is mandatory (`filterType: RuleFilter`). Do **not** put `slaProcessId` in the
-    body — it is carried by the path. Multi-milestone strategies dispatch this call once per
-    milestone; if any milestone POST fails, halt and surface the raw error — do not continue with a
-    half-attached policy.
+    Each `milestoneCriteria[]` item needs `milestoneAgreementType` (`SLA`/`OLA`) and
+    `filterType: RuleFilter`. Do **not** put `slaProcessId` in the body — carried by the path.
+    Multi-milestone strategies dispatch once per milestone; on any milestone POST failure, halt
+    and surface the raw error — do not continue with a half-attached policy.
 11. **Create Entitlement** — `POST /sobjects/Entitlement` linking the resolved Account (from Phase 1
     step 5), the SLA Policy (`SlaProcessId`), and Business Hours. For immediate engagement, backdate
     `StartDate` to yesterday.
 
+### Phase 2-OOB — Seed the Predefined Incident Policy
+
+Reached only from Phase 0.6 Predefined (replaces Phase 1.4/1.5/2). Follow the seed recipe
+in `references/mcp-invocation.md` (**Predefined Incident Policy**) with the template in
+`assets/predefined-incident-policy.json` — it uses the **Phase 2 routes** (2 MilestoneTypes → SLA
+Policy `active:true` → 8 priority-tiered milestones → Entitlement), validates each `Priority`/`Status`
+against the live picklist, and avoids the Connect activate PATCH. Then run **Phase 2.5** (if actions
+requested), then **Phase 3** (Critical test Incident), and **STOP** — no *proactive* custom offer.
+
+### Phase 2.5 — Milestone Actions (optional: Warn / Escalate)
+
+After milestones exist (Phase 2 or 2-OOB), **only if** the user asked to warn/escalate/notify: apply
+the requested checkpoint(s) to **every milestone the user named** (not just one), computing each
+offset from that milestone's own target. Map "warn at X%" → an offset *before* target, "on breach" →
+*at/after* it; **confirm the full set before writing** (up-front auth waives the re-ask; narrate it
+regardless — no headless delete), then, per milestone, delegate to headless
+**`create-milestone-action`** (`discover` → `describe` → `dispatch`). **Confirm each from the response
+body** (`success` + non-empty `actionMappings`; a *timed* checkpoint also returns a `triggerId`), never
+the `201`. Formula, roles, proven body, defaults, and the IST business-hours note:
+`references/mcp-invocation.md` (Milestone Actions).
+
 ### Phase 3 — Verify
 
 12. **Verify the SLA Policy** — SOQL on `SlaProcess` (do not trust the create response).
-13. **Create a test Incident** with `EntitlementId` pointing at the new Entitlement. For
-    Priority-tiered strategies, set a specific `Priority` on the test Incident (or create one test
-    Incident per Priority) so at least one milestone's criteria matches — otherwise no
-    `EntityMilestone` will spawn even though the policy is wired correctly.
+13. **Create a test Incident** with `EntitlementId` set to the new Entitlement. For Priority-tiered
+    strategies, set a `Priority` that matches at least one milestone's criteria (or one test Incident
+    per Priority) — otherwise no `EntityMilestone` spawns even with the policy wired correctly.
 14. **Verify engagement** — SOQL confirming `Incident.SlaStartDate` is populated and the expected
-    `EntityMilestone` row(s) exist with the correct `TargetDate`(s). For multi-milestone
-    strategies, expect one `EntityMilestone` per milestone whose criteria the Incident satisfies.
+    `EntityMilestone` row(s) exist with correct `TargetDate`(s) — one per milestone whose criteria
+    the Incident satisfies.
 15. **Report results** using the output format below.
 
 ---
@@ -250,40 +246,42 @@ milestone, `order` 1..N, all attached to the same SlaProcess).
 
 | Constraint | Rationale |
 |-----------|-----------|
-| Gate on **SLA Management for IT Service** first (Phase 0.5) — feature `ENABLED` AND versioning `true`; confirm before enabling, versioning permanent, re-read after each write | Skipping risks a mid-flow 403/404; versioning can't be undone; writes don't confirm state |
+| Gate on **SLA Management for IT Service** first (Phase 0.5) — one enable turns on the feature **and**, one-way, **SLA Versioning**; **two separate acks (master, then permanence) — never merged**; decline / blocked / verify-fail → **HALT, no fall-through**; re-read + report real state | Versioning can't be undone; writes don't confirm state |
+| Offer the **predefined (OOB)** policy first (Phase 0.6, Incident only); detect before seed; if chosen, seed → verify → **STOP** (no custom upsell) | OOB seed has no server idempotency (re-seeding duplicates) |
 | Discover + describe before any mutation | Catches a missing SLA surface / disabled Incident Management early |
-| Ask (via `AskUserQuestion`) which milestone strategy to use — do not silently default to Single | Real ITSM policies almost always have more than one milestone; picking silently hides the choice from the user |
-| Reuse one MilestoneType per shared name; create a distinct MilestoneType per distinct concern | The runtime keys milestones by MilestoneType — sharing collapses distinct concerns |
-| For multi-milestone strategies, halt on any milestone POST failure — do not continue with a half-attached policy | The confirmation gate covers all N milestones together; partial attach diverges from the confirmed plan |
-| Priority-tiered strategy: validate every `Priority` value against the live Incident picklist before dispatch | The server accepts any string on `filterItems.value` — an unknown Priority value silently makes the milestone dead code |
+| Ask (via `AskUserQuestion`) which milestone strategy to use — don't silently default to Single | Real ITSM policies usually have >1 milestone; a silent default hides it |
+| Reuse one MilestoneType per shared name; create a distinct one per distinct concern | The runtime keys milestones by MilestoneType — sharing collapses distinct concerns |
+| For multi-milestone strategies, halt on any milestone POST failure (no half-attached policy) | Partial attach diverges from the confirmed plan |
+| Priority-tiered: validate every `Priority` value against the live Incident picklist before dispatch | The server accepts any string on `filterItems.value` — an unknown value silently makes the milestone dead code |
 | Entitlement is standard sObject DML (not Connect API); `StartDate` controls status (future = Inactive) | Not part of the `/connect/sla-management/` surface |
 | Verify SLA Policy via SOQL, not the create response | The create response echoes nulls |
-| Never show Salesforce record IDs to the user | Use human-readable names and IncidentNumber |
+| Never show record IDs **in any message, incl. interim narration** — the test Incident by **IncidentNumber**, milestones by **MilestoneType name**, never the 15/18-char Id; keep `AskUserQuestion` labels customer-facing (no "demo", "the skill", internal defaults) | Leaked Ids and internal/demo framing look unprofessional |
 
-Additional API quirks (payload rules, filter-operator enum, missing-criteria error) are documented in `references/mcp-invocation.md` — consult before dispatch.
+Additional API quirks (payload rules, operator enum, missing-criteria error): `references/mcp-invocation.md`.
 
 ---
 
 ## Verification Checklist
 
-- [ ] **SLA Management prerequisite gated (Phase 0.5)** — feature `ENABLED` AND `IsEntitlementVersioningEnabled` `true`; whatever was off was enabled only after confirmation (versioning flagged permanent) and re-read to verify, never trusting the write response; non-empty `enableBlockedReasons` halted the run.
-- [ ] Master Incident Management pref was confirmed `ENABLED` via a live Setup Discovery read this session (or via an inline delegation to `service-itsm-incident-mgmt-configure` when it came back off). A user-asserted state is NOT a substitute for the live read.
-- [ ] `discover` + `describe` (or the Incident describe) confirmed the SLA Management Connect operations.
+- [ ] **SLA Management gated (Phase 0.5)** — feature + SLA Versioning both on, only after the **permanence ack** (separate from the master ack); reported state matches a re-read, not the write. If it couldn't be enabled (declined / blocked / verify-fail), the run **HALTED** before Phase 0.6/1 — no artifacts.
+- [ ] **Predefined vs Custom offered (Phase 0.6)** — with the feature ON, the OOB *Standard Support for Incidents* policy was offered first; if it existed, reported not re-seeded; if chosen, seeded (2 MilestoneTypes + 8 tiered milestones + Entitlement), verified, **no** custom offer followed.
+- [ ] Master Incident Mgmt pref (exact `service-cloud-itsm-incident`) confirmed `ENABLED` via a live read, or delegated to `service-itsm-incident-mgmt-configure` when `NOT_ENABLED` (`NOT_AVAILABLE` → HALT) — not a user assertion, not a look-alike.
+- [ ] `discover`/`describe` (or the Incident describe) confirmed the SLA Connect operations.
 - [ ] Incident describe returned 200 with `EntitlementId`, `SlaStartDate`, `SlaExitDate`.
 - [ ] Default BusinessHours found.
-- [ ] **Milestone strategy resolved** — via a Phase 1.4 skip condition (prompt named a shape / no-op branch / up-front authorization + derivable shape) OR via `AskUserQuestion`. A skipped `AskUserQuestion` under a valid skip condition is honoring the contract, not violating it. For Priority-tiered / Custom, every `Priority` / criteria value was validated against the live Incident picklist before dispatch.
-- [ ] **Configuration confirmed OR skip condition met** — up-front authorization, no-op branch, prior confirmation in conversation, OR explicit "yes" via `AskUserQuestion`. In every case, the resolved plan (org, SLA name, account, entitlement range, per-milestone list) was narrated before Phase 2 dispatched.
-- [ ] Artifacts created in order (MilestoneType(s) → Policy → Milestone(s) → Entitlement); each POST returned 201; any milestone POST failure halted the run (no partial attach). Trivially satisfied on no-op runs.
-- [ ] SLA Policy verified via SOQL (not the create response). On no-op runs, the Phase-1 read is the verification.
-- [ ] Test Incident has `SlaStartDate` populated (Priority chosen to match at least one criterion for Priority-tiered). Skip on no-op runs.
-- [ ] At least one EntityMilestone exists with the correct TargetDate; for multi-milestone strategies, the expected milestone(s) are present. Skip on no-op runs.
-- [ ] Before/after and summary shown. On no-op runs, the summary states the pre-existing configuration verbatim and reports "no changes made".
+- [ ] **Milestone strategy resolved** — via a Phase 1.4 skip condition OR `AskUserQuestion`; for Priority-tiered / Custom, every `Priority`/criteria value was validated against the live Incident picklist before dispatch.
+- [ ] **Configuration confirmed OR skip condition met** (up-front authorization / no-op / prior confirmation / explicit "yes"); the resolved plan (org, SLA name, account, entitlement range, per-milestone list) was narrated before Phase 2.
+- [ ] Artifacts created in order (MilestoneType(s) → Policy → Milestone(s) → Entitlement); each POST 201; any milestone POST failure halted the run (no partial attach). Trivial on no-op runs.
+- [ ] **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 (on no-op, the Phase-1 read is the verification).
+- [ ] Test Incident has `SlaStartDate` populated (Priority chosen to match a criterion for Priority-tiered) and ≥1 EntityMilestone with the correct TargetDate; expected milestone(s) present for multi-milestone. Skip on no-op.
+- [ ] Before/after + summary shown; on no-op, the summary states the pre-existing configuration verbatim and reports "no changes made".
 
 ---
 
 ## Output Format
 
-See `examples/output-templates.md` for the canonical failure / single-milestone success / multi-milestone success templates. Fill in the placeholders as-is. No record IDs in user-facing output. No files are produced — the skill mutates org configuration in place through headless-360 MCP dispatch.
+See `examples/output-templates.md` for the canonical failure / single-milestone success / multi-milestone success templates. Fill in the placeholders as-is. No files are produced — the skill mutates org configuration in place through headless-360 MCP dispatch.
 
 ---
 
@@ -292,17 +290,17 @@ See `examples/output-templates.md` for the canonical failure / single-milestone
 | File | When to read |
 |------|--------------|
 | `references/mcp-invocation.md` | Every phase — exact `mcp__headless-360__*` call shapes, payload templates, response envelope, discovery, and gotchas (filter-operator enum, v67 routes, entitlement behavior) |
-| `examples/milestone-patterns.md` | Phase 1.4 — the five milestone strategies (Single, Response + Resolution, Priority-tiered, Escalation ladder, Custom) with default times, criteria, MilestoneType reuse rules, and per-pattern filter-item extensions |
+| `examples/milestone-patterns.md` | Phase 1.4 — the five milestone strategies with default times, criteria, MilestoneType reuse rules, and per-pattern filter-item extensions |
 | `examples/output-templates.md` | Output Format — canonical failure / single-milestone success / multi-milestone success templates |
-| `assets/attach-milestone.json` | Phase 2 step 10 — reusable request-body template for `POST /connect/sla-management/sla-policies/<slaId>/milestones`; substitute `milestoneTypeId`, `businessHoursId`, `timeTrigger`, `order`, and append per-pattern `filterItems` |
+| `assets/attach-milestone.json` | Phase 2 step 10 — request-body template for the milestone POST (`sla-policies/<slaId>/milestones`); substitute `milestoneTypeId`, `businessHoursId`, `timeTrigger`, `order`; append per-pattern `filterItems` |
+| `assets/predefined-incident-policy.json` | Phase 0.6 / Phase 2-OOB — the OOB *Standard Support for Incidents* seed template (policy + 2 MilestoneTypes + 8 priority-tiered milestones) |
+| `assets/attach-milestone-action.json` | Phase 2.5 — Warn/Escalate milestone-action body templates (Field Update); pair with `references/mcp-invocation.md` (Milestone Actions) |
 
 ---
 
 ## Related Skills
 
-This skill configures the end-to-end **Incident SLA** pipeline. Configuring the priority matrix
-(Impact × Urgency → Priority) is a separate concern handled by
-`service-itsm-incident-priority-configure` — if a Priority-tiered milestone strategy is requested
-but the org's `Incident.Priority` picklist is missing values, direct the user to that skill first.
-Other adjacent ITSM setup flows (Major Incident Management, custom fields on Incident / Problem /
-ChangeRequest) are out of scope; use their dedicated skill when available.
+The priority matrix (Impact × Urgency → Priority) is separate — `service-itsm-incident-priority-configure`;
+if a Priority-tiered strategy is requested but `Incident.Priority` is missing values, direct the user
+there first. Other adjacent ITSM flows (Major Incident Mgmt, custom fields on Incident/Problem/ChangeRequest)
+are out of scope.

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

@@ -0,0 +1,51 @@
+{
+  "_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 live-validated 'Proven bodies' in references/mcp-invocation.md (Milestone Actions) — 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 setting Priority = High. 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).",
+    "isSuccessCheckpoint": false,
+    "checkpoint": { "isWarning": true, "timeLength": 30, "timeUnit": "Minutes" },
+    "entityName": "Incident",
+    "actionFieldUpdate": {
+      "name": "SLA Warn 75pct <MS>",
+      "sourceTable": "Incident",
+      "targetTable": "Incident",
+      "columnEnumOrId": "Priority",
+      "developerName": "SLA_Warn_75_<MS>",
+      "operationString": "LITERAL",
+      "literal": "High"
+    }
+  },
+
+  "violationAction": {
+    "_notes": "Escalate ON breach = Violation with timeLength 0 (fires at target). Default: set Priority = Critical. Replace <MS> in name/developerName with the same per-milestone suffix used for the warning.",
+    "isSuccessCheckpoint": false,
+    "checkpoint": { "isWarning": false, "timeLength": 0, "timeUnit": "Minutes" },
+    "entityName": "Incident",
+    "actionFieldUpdate": {
+      "name": "SLA Escalate on Breach <MS>",
+      "sourceTable": "Incident",
+      "targetTable": "Incident",
+      "columnEnumOrId": "Priority",
+      "developerName": "SLA_Escalate_Breach_<MS>",
+      "operationString": "LITERAL",
+      "literal": "Critical"
+    }
+  },
+
+  "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.",
+    "Name": "IST Business Hours",
+    "TimeZoneSidKey": "Asia/Kolkata",
+    "MondayStartTime": "09:00:00.000Z",
+    "MondayEndTime": "18:00:00.000Z",
+    "TuesdayStartTime": "09:00:00.000Z",
+    "TuesdayEndTime": "18:00:00.000Z",
+    "WednesdayStartTime": "09:00:00.000Z",
+    "WednesdayEndTime": "18:00:00.000Z",
+    "ThursdayStartTime": "09:00:00.000Z",
+    "ThursdayEndTime": "18:00:00.000Z",
+    "FridayStartTime": "09:00:00.000Z",
+    "FridayEndTime": "18:00:00.000Z"
+  }
+}

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

@@ -7,7 +7,7 @@
   "milestoneCriteria": [
     {
       "milestoneState": "Active",
-      "milestoneAgreementType": "Warning",
+      "milestoneAgreementType": "SLA",
       "filterType": "RuleFilter",
       "filterItems": [
         {