@salesforce/afv-skills 1.66.0 → 1.67.0

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

@@ -1,16 +1,12 @@
 ---
 name: service-itsm-agentic-setup-incident-management
-description: "Orchestrator for Incident Management setup in Service Cloud ITSM: presents the features, tracks progress, and configures each — SLA & Milestones, Priority Matrix, Incident preferences, Major Incident Management, Incident persona PSG assignment, Service Management Privilege, and Incident audit tracking. Use for: set up or configure incident management, incident management walkthrough, what incident features can I configure; the incident preference toggles (default field validations, auto-close child incidents, auto-triage, assign with Einstein, restrict assigned group, rich text descriptions); Major Incident Management (approval group + MIM preferences); assigning the Incident Fulfiller or Incident Manager persona PSG; Service Management Privilege / privilege escalation setup. DO NOT TRIGGER for: the master on/off switch alone (use the IncidentMgmt SOR), the Priority Matrix, SLA, or field history tracking alone, the Major Incident Manager PSG, creating/editing PSGs, or Problem/Change/Case Management."
+description: "Orchestrator for Incident Management setup in Service Cloud ITSM: presents the features, tracks progress, and configures each — Incident preferences, Incident persona PSG assignment, Priority Matrix, SLA & Milestones, Incident dashboards, Email-to-Incident, Major Incident Management (approval group + MIM preferences), Broadcast Communications, Manage Incidents with AI, Service Management Privilege (privilege escalation), and audit tracking. Use for: set up or configure incident management, a walkthrough, what incident features can I configure; the incident preference toggles (default field validations, auto-close child incidents, auto-triage, assign with Einstein, restrict assigned group, rich text descriptions); assigning the Incident Fulfiller or Incident Manager persona PSG. DO NOT TRIGGER for: the master on/off switch alone (use the IncidentMgmt SOR), the Priority Matrix, SLA, or field history tracking alone, the Major Incident Manager PSG, creating/editing PSGs, or Problem/Change/Case Management."
 metadata:
-  version: "2.1"
+  version: "3.0"
   domains: ["Service"]
   minApiVersion: "67.0"
   relatedSkills:
-    - "dx-org-permission-set-assign"
-    - "service-itsm-agentic-setup-cmdb-access-assign"
-    - "service-itsm-agentic-setup-incident-sla-configure"
-    - "service-itsm-agentic-setup-itsm-agentforce-permset-assign"
-    - "service-itsm-incident-priority-configure"
+    - "service-itsm-manage-incidents-with-ai-configure"
   mcpTools:
     headless-360:
       tools: ["describe", "discover", "dispatch", "dispatch_readonly"]
@@ -27,9 +23,8 @@ allowed-tools: |
 # Incident Management Setup Orchestrator
 
 Guide the user through setting up Incident Management features in Salesforce Service Cloud ITSM by
-presenting the available capabilities, tracking progress, and — per feature — either **delegating** it (to
-a specialized child skill, or to a Setup Operation Recipe (SOR) whose own steps this skill follows), or
-**executing it inline** from this skill's reference file over its SOR.
+presenting the available capabilities, tracking progress, and **delegating** each feature to the Setup
+Operation Recipes (SORs) whose own steps this skill runs.
 
 ## Goal
 
@@ -39,50 +34,47 @@ until the user is done.
 
 ## How each feature is handled
 
-| # | Feature | Handled by |
-|---|---------|-----------|
-| 1 | SLA & Milestones | **Delegate** → `service-itsm-agentic-setup-incident-sla-configure` |
-| 2 | Priority Matrix | **Delegate** → `service-itsm-incident-priority-configure` |
-| 3 | Incident Preferences | **Inline over SOR** → `references/incident-preferences.md` |
-| 4 | Major Incident Management | **Inline over SOR** → `references/major-incident-management.md` |
-| 5 | Incident Persona PSG | **Inline over SOR** → `references/incident-persona-psg.md` |
-| 6 | Service Management Privilege | **Inline over SOR** → `references/service-mgmt-privilege.md` |
-| 7 | Audit Tracking | **Delegate** → `FieldHistoryTracking` (the Field History Tracking SOR) |
-
-**Delegated** features hand off to their child skill or SOR. A child skill runs its own confirmations and
-read-backs, so this skill only coordinates. A SOR is a recipe, not an agent: for a SOR hand-off this skill
-runs the SOR's steps itself and owns the confirmation and read-back (see the master switch and Audit Tracking below).
-**Inline** features are run by this skill directly through the `headless-360` MCP server — **read the
-matching reference file before executing that feature** and follow it. Every inline operation is fetched at
-runtime: `discover` by intent, `describe` for the current route/schema/labels, then `dispatch_readonly`
-(reads) / `dispatch` (writes). **Hardcode nothing — `describe` wins.**
-
-**Audit Tracking is delegated to the Field History Tracking SOR.** This skill has no reference file for it
-and re-derives none of its steps — the SOR's own steps and guidance decide *how*. This skill runs them and
-owns the user-facing gates:
-
-1. `discover` the SOR by intent (e.g. "field history tracking") and `describe` the id `discover` returns
-   (`FieldHistoryTracking`). Judge availability by what the calls return, not by a step's `status` label —
-   a step labelled `proposed` may still be served. A `discover` miss or a `401`/`403`/`404` means the
-   surface isn't available to this user or org: surface it and stop.
-2. Use the Incident fields the user already named, or ask which fields to track if the choice is missing
-   or ambiguous, plus anything else `describe` says it needs. If the user chooses no fields, leave the
-   feature `Not done` and stop; do not treat an empty choice as already configured.
-3. Through the SOR, check Setup access, read Incident with `get-single-entity-data-with-metadata`, and get
-   its per-object tracked-field limit. Use the returned tracking flag, field labels, `canBeTracked` values,
-   current tracked set, and `fieldEnumOrId` keys to resolve the user's choices; do not guess field keys.
-4. The save replaces the object's whole tracked-field set, so send the **union** of what's already tracked
-   and the chosen fields using their returned keys, with Incident's object-level tracking flag on — never
-   drop an already-tracked field unless the user asks. If a chosen field can't be tracked, or the union
-   would exceed the limit, say so plainly; never untrack another field to make room. Report it as done
-   with no write only if the nonempty chosen set is already tracked **and** Incident's object-level tracking
-   is on. If the fields are selected but that flag is off, the change still needs a save.
-5. Show the exact final tracked-field list by field label (disambiguate matching labels) in either case.
-   Before any save, also show that object-level tracking will be enabled and get an explicit yes
-   (`AskUserQuestion`) for that plan; when the user already named the fields, this confirms the selection.
-6. After any save, read Incident's tracked fields back through the SOR. Mark the feature `Done` only when
-   the live read (for the no-write case) or post-save read-back shows Incident's object-level tracking on,
-   the chosen fields tracked, and no field dropped that the user didn't ask to drop — a save response alone
+| # | Feature | Handled by | Reference |
+|---|---------|-----------|-----------|
+| P | Incident Preferences | **Delegate** → `IncidentMgmt` (its preference steps) | `references/incident-preferences.md` |
+| 1 | Incident Persona PSG | **Delegate** → `service-itsm-incident-persona-assign` | `references/incident-persona-psg.md` |
+| 2 | Priority Matrix | **Delegate** → `IncidentPriorityMatrix` | `references/priority-matrix.md` |
+| 3 | SLA & Milestones | **Delegate** → `SLASettings`, then `sla-management-setup` (custom policy) | `references/sla-milestones.md` |
+| 4 | Incident Dashboards | **Delegate** → `itsm-incident-dashboard-enablement` (Manager) and `itsm-incident-fulfiller-dashboard-enablement` (Fulfiller) | `references/incident-dashboards.md` |
+| 5 | Email-to-Incident | **Delegate** → `EmailToIncident` | `references/email-to-incident.md` |
+| 6 | Major Incident Management | **Delegate** → `MIM` | `references/major-incident-management.md` |
+| 7 | Broadcast Communications | **Delegate** → `service-itsm-broadcast-communications-setup` | `references/broadcast-communications.md` |
+| 8 | Manage Incidents with AI | **Delegate** → `service-itsm-manage-incidents-with-ai-configure` | `references/manage-incidents-with-ai.md` |
+| 9 | Service Management Privilege | **Delegate** → `ServiceMgmtPrivilegeSetup` | `references/service-mgmt-privilege.md` |
+| 10 | Audit Tracking | **Delegate** → `FieldHistoryTracking` | `references/audit-tracking.md` |
+
+Every feature runs on SORs; this skill hands no feature off to another skill. A SOR is a recipe, not an
+agent: this skill runs the SOR's steps itself under the **SOR hand-off protocol** below and owns every
+user-facing gate — the questions, the confirmation before each write, and the read-back. The SOR's own steps
+and guidance decide *how*. **Read a feature's reference file before running that feature**: it adds only
+what is specific to this skill. Every operation is fetched at runtime through the `headless-360` MCP server:
+`discover` by intent, `describe` for the current route/schema/labels, then `dispatch_readonly` (reads) /
+`dispatch` (writes).
+**Hardcode nothing — `describe` wins.** If a described path repeats the `/services/data/v{version}` prefix,
+send the prefix once.
+
+### SOR hand-off protocol (every feature)
+
+1. **Find it.** `discover` the SOR by intent and `describe` the id `discover` returns. Judge availability by
+   what the calls return, not by a step's `status` label — a step labelled `proposed` may still be served.
+   A `discover` miss or a `401`/`403`/`404` means the surface isn't available to this user or org: surface
+   it and stop.
+2. **This skill owns both prerequisite gates.** Behavior step 2 already confirmed IT Service Enablement and
+   the master switch on. If a SOR's own check reads either as anything but `ENABLED`, go back to step 2 —
+   never run a SOR's own enable or delegate step for them, and never follow a hand-off a SOR names for
+   either gate or for another feature on this menu.
+3. **Read before write.** Read the current state through the SOR's read steps. If it already matches what
+   the user wants, that read is the verification: mark the feature `Done` with no write.
+4. **Confirm the exact change.** State the current value and the exact change, and get an explicit yes
+   (`AskUserQuestion`) before any write. The user's initial request is not that confirmation; one yes can
+   cover several writes if you listed them all.
+5. **Write, then read back.** Write only through the SOR's write steps, then read back through its verify
+   steps. Mark the feature `Done` only when the read-back shows the chosen state — a write response alone
    is not proof.
 
 ## Behavior
@@ -90,8 +82,8 @@ owns the user-facing gates:
 ### 0. Reuse what the session already knows
 
 Before running any preflight below, check whether the same fact was already established earlier in this
-conversation. Cache-eligible: the **master switch state** (reuse **only when confirmed *enabled***; a
-cached "off" MUST NOT let step 2 skip), **already-completed features** (stay "Done"; don't re-run unless
+conversation. Cache-eligible: the **IT Service Enablement and master switch states** (reuse each **only
+when confirmed *enabled***; a cached "off" MUST NOT let step 2 skip), **already-completed features** (stay "Done"; don't re-run unless
 asked to reconfigure), and the **target org**. **When in doubt, re-check.** Skip only when the earlier fact
 is unambiguously in context AND you have not switched orgs — a wrong skip on a live write is worse than a
 duplicated read.
@@ -101,24 +93,42 @@ duplicated read.
 Scan chat history for which features are already done, any stated preferences/constraints, the target org,
 and business context that informs which features are relevant.
 
-### 2. Ensure the Incident Management master switch is on (prerequisite)
-
-Every feature below depends on the org-level `service-cloud-itsm-incident` master switch being enabled.
-Before showing the menu, `discover` the `IncidentMgmt` SOR by intent and `describe` its master-feature
-steps (`read-itsm-incident-feature-status`, `enable-itsm-incident-feature`,
-`verify-itsm-incident-feature-status`). Follow its current invocation and prefix the stored path as its
-version note says (`v67.0` is the minimum and a safe default). A `404` from a version above the org's
-maximum is a version mismatch: retry once at `v67.0` before treating `404` as unavailable.
-Do not use the Service-Foundation `IncidentManagement` look-alike or its broadcast toggles.
-Read the master status via `dispatch_readonly` and decide on `status` first: `ENABLED` is an idempotent
-no-op even if `enableBlockedReasons` is non-empty; `NOT_AVAILABLE` means halt (do not attempt enable);
-for `NOT_ENABLED`, surface any `enableBlockedReasons` as plain text (their messages are HTML-escaped
-markup) and halt if present. Otherwise show the exact off → on change and ask for explicit confirmation before
-running the SOR's enable step via `dispatch`. Re-read via the SOR's verify step and require
-`ENABLED` before continuing. On a declined confirmation, unexpected status, `401`/`403`/`404`,
-failed write, or read-back mismatch, stop without showing the menu; never infer success from
-the write response. **Skip only when the master switch was already confirmed *enabled* in this
-session** (see step 0). A cached "off"/unknown state MUST fall through to the live read.
+### 2. Verify IT Service Enablement, then ensure the Incident Management master switch is on
+
+Every feature below depends on IT Service Enablement (`service-cloud-itsm-setup`) and uses the recommended
+ITSM Incident Management check (`service-cloud-itsm-incident`). Before showing the menu—or before a direct
+single-feature handoff—`discover` the `IncidentMgmt` SOR by intent and `describe` its steps, then check the
+two gates in this order, using that SOR for every read, enable, and verify
+(`read-/enable-/verify-itsm-setup-feature-status`, `read-/enable-/verify-itsm-incident-feature-status`).
+Follow its current invocation and prefix each stored path as its version note says: use the org's full API
+version with its minor, such as `v68.0`, never a bare major. If a feature read fails, stop and do not retry
+other version strings. Never read or toggle `service-cloud-incident-management`, and do
+not use the Service-Foundation `IncidentManagement` look-alike or its broadcast toggles.
+
+Decide on `status` first: `ENABLED` is an idempotent no-op even if `enableBlockedReasons` is non-empty;
+`NOT_AVAILABLE` means halt (do not attempt enable). Show any `enableBlockedReasons` as plain text (their
+messages are HTML-escaped markup) and halt if present. Never infer success from a write response.
+
+1. **IT Service Enablement** — only exact `ENABLED` continues. Exact `NOT_ENABLED` with no blocked reasons:
+   ask **“IT Service Enablement is off — enable it now?”** with `AskUserQuestion` (single-select, exactly
+   two options: Yes and No) — every time, never as plain text, and do not preview the menu before it is
+   answered. Yes → delegate to the `IncidentMgmt` SOR (read → enable → verify), stating the user already
+   confirmed this exact change so it does not ask again; continue only when verify reads 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 → stop and point to Setup. Missing entry, blocked reasons, error, or any other status → stop and explain
+   plainly; no question.
+2. **Incident Management** — same pattern, second: exact `NOT_ENABLED` with no blocked reasons →
+   `AskUserQuestion` **“Incident Management is off — enable it now?”** (Yes/No); Yes → delegate to the
+   `IncidentMgmt` SOR with the same already-confirmed statement and continue only on verify exact
+   `ENABLED`; No → stop and point to Setup. `NOT_AVAILABLE`, blocked reasons, error, or anything else → stop
+   and explain; no question.
+
+Never offer to bypass either gate.
+
+**Skip only when both gates were already confirmed *enabled* in this session** (see step 0). A cached
+"off" or unknown state MUST fall through to the checks above.
 
 ### 3. Present the feature menu as a multi-select
 
@@ -129,12 +139,10 @@ several enqueue for sequential handling in step 4.
 
 ### 4. Handle each selected feature in order
 
-Handle selected features sequentially in dependency order (or the order given). For each: if it is a
-**delegated** feature, hand off to its child skill — or, for Audit Tracking, run the Field History Tracking
-SOR through the six steps above; if it is an **inline** feature, **read its reference file** and execute it
-there. Whenever this skill itself writes (inline, or a SOR hand-off), always **read live state before
-writing, confirm before every write, and verify every write by read-back**. Honor the per-feature
-invariants below.
+Handle selected features sequentially in dependency order (or the order given). For each, **read its
+reference file**, then run its SORs under the hand-off protocol. This skill does the writing, so always
+**read live state before writing, confirm before every write, and verify every write by read-back**. Honor
+the per-feature invariants below.
 
 ### 5. After each feature completes
 
@@ -148,10 +156,10 @@ template in `examples/output-templates.md`.
 
 ---
 
-## Critical inline-execution invariants (load-bearing — full detail in each reference)
+## Critical invariants (load-bearing — the SORs carry the full detail)
 
-Apply these whenever an inline feature runs; the **Everywhere** rules also apply to the Audit Tracking SOR
-hand-off. They are irreversible or silently-wrong if missed.
+The **Everywhere** rules apply to every feature; the rest apply to the named feature. They are irreversible
+or silently wrong if missed.
 
 - **Resolve the right node (Preferences).** Target the ITSM Incident Management org-preferences node
   (the one with the six per-feature toggles), **not** the Service-Foundation look-alike whose toggles
@@ -161,20 +169,32 @@ hand-off. They are irreversible or silently-wrong if missed.
   them; require an explicit "I understand this can't be undone" confirmation before enabling; never enable
   to test. *Restrict Assigned Group…* also **freezes once the org has any Incident record** — an enable can
   fail outright; do not retry.
-- **License, not assignment (Major Incident Management).** MIM is the approval group + two preferences on
-  top of **base** Incident Management. The Major Incident Manager grant is a **LICENSE**
-  (`PermissionSetLicenseAssign`), never a `PermissionSetAssignment`. **License before group membership;
-  validate group users before designating a group; remove before reassign.** Only two preference names are
-  valid: `AutoCreationOfProblem`, `AutoClosureChildIncidents`.
 - **PSL before PSG (Persona).** Assign the union of a persona PSG's member permission-set **licenses first,
   then the PSG** (keyed on `PermissionSetGroupId`, never a permission-set Id) — otherwise the persona is
   silently half-provisioned. Query the persona PSGs by `DeveloperName` with **no** `NamespacePrefix` filter.
+- **The Priority Matrix save is a full replacement (Priority Matrix).** Any cell left out of the save is
+  deleted — always send the complete matrix, using only active Priority values.
+- **SLA Versioning is permanent; the predefined seed is not idempotent (SLA & Milestones).** Turn on SLA
+  Versioning only after the explicit **Enable** answer, and never offer to turn it off. Detect the
+  predefined *Standard Support for Incidents* policy before seeding and never re-seed it. Never deactivate,
+  reorder, or broaden another SLA policy; halt on the first failed milestone create; never ask for an
+  Account.
+- **One-way features (Email-to-Incident, Broadcast Communications).** Turning on Email-to-Incident or the
+  Broadcast Communications feature can't be undone — say so before asking, and never offer or attempt to
+  turn either off.
+- **License, not assignment (Major Incident Management).** MIM is the approval group + two preferences on
+  top of **base** Incident Management, and MIM itself must already be active — Salesforce provisions it, so
+  never try to turn it on. The Major Incident Manager grant is a **LICENSE**
+  (`PermissionSetLicenseAssign`), never a `PermissionSetAssignment`. **License before group membership;
+  the approval group is a public Group, never a User, and its users must validate true before you designate
+  it; to reassign, validate the new group, then remove, then create.** Only two preference names are
+  valid: `AutoCreationOfProblem`, `AutoClosureChildIncidents`.
 - **Destructive delete + unverifiable assignments (Service Management Privilege).** Deleting a Service
   Management Privilege is irreversible — confirm explicitly, never delete to test. Bulk employee↔privilege
-  assignments have **no read-back** — report them as applied, not verified. The *Enable Privilege Assignment*
-  master toggle is the UI entry gate (reversible; the controller does not re-check it), so enable it first as
-  workflow ordering, not a hard precondition. No public API substitute exists — a `404` / discover-miss means
-  the surface isn't served on this org yet; surface it and stop.
+  assignments have **no read-back** — report them as applied, not verified. Turn on the reversible *Enable
+  Privilege Assignment* toggle before any escalation-level or privilege step, as the SOR orders it; if the
+  user declines, stop. No public API substitute exists — a `404` / discover-miss means the surface isn't
+  served on this org; surface it and stop.
 - **Everywhere:** read before write; treat "already in that state" / a duplicate as idempotent success;
   verify by read-back (a write response alone is not proof); each license consumes a seat; on `401`/`403`/
   `404` surface the raw error and stop; keep record Ids, HTTP codes, route paths, and tooling terms
@@ -185,33 +205,48 @@ hand-off. They are irreversible or silently-wrong if missed.
 ## Feature Dependencies & Recommended Order
 
 ```text
-1. SLA & Milestones            (time-based commitments on incidents)      [delegated]
-2. Priority Matrix             (Impact × Urgency → Incident.Priority)      [delegated]
-3. Incident Preferences        (the six per-feature setup toggles)         [inline]
-4. Major Incident Management   (approval group + two MIM preferences)      [inline]
-5. Incident Persona PSG        (Fulfiller / Manager persona for a user)    [inline]
-6. Service Management Privilege (escalation level + privilege assignments) [inline]
-7. Audit Tracking              (field history on chosen Incident fields)   [delegated]
+P.  Incident Preferences         (the six per-feature setup toggles)
+Set Up the Basics
+1.  Incident Persona PSG         (Fulfiller / Manager persona for a user)
+2.  Priority Matrix              (Impact × Urgency → Incident.Priority)
+3.  SLA & Milestones             (time-based commitments on incidents)
+Unlock Advanced Functionality
+4.  Incident Dashboards          (Manager / Fulfiller dashboards + Home pages)
+5.  Email-to-Incident            (incoming email → Incidents, routing addresses)
+6.  Major Incident Management    (approval group + two MIM preferences)
+7.  Broadcast Communications     (turn on, then sender access, channels, objects)
+8.  Manage Incidents with AI     (AI triage, Einstein assignment, chat/voice drafts)
+9.  Service Management Privilege (escalation level + privilege assignments)
+10. Audit Tracking               (field history on chosen Incident fields)
 ```
 
+Features 1–8 follow Salesforce Go's IT Service Incident Management page; Service Management Privilege and
+Audit Tracking aren't on that page.
+
+A priority-tiered SLA needs the Priority Matrix on: with it off, every Incident gets the default priority,
+so only that tier's milestones fire.
+
 ---
 
 ## Rules
 
 - ALWAYS show "(via service-itsm-agentic-setup-incident-management)" in the setup header
-- ALWAYS run the master-switch prerequisite (Behavior step 2) before showing the menu, unless a live
-  status read already confirmed the switch ENABLED on this org earlier in this session
+- ALWAYS check the IT Service Enablement and master-switch prerequisites (Behavior step 2) through
+  the `IncidentMgmt` SOR before showing the menu or handing off a named feature, unless both were
+  confirmed enabled earlier in this conversation
+- ALWAYS ask each off gate with `AskUserQuestion` (single-select Yes/No), every time, never as plain text,
+  before delegating the enable; No stops and points to Setup
+- ALWAYS require exact `ENABLED` verification for `service-cloud-itsm-setup` before the Incident switch;
+  anything else stops. Never read or toggle `service-cloud-incident-management`
 - ALWAYS present the feature menu before configuring any selected feature (the master-switch prerequisite
   is the only permitted action before the menu) — do not assume which feature the user wants, **except**
   when the user named a specific feature, in which case go straight to it (single-select is fine)
 - ALWAYS pair the rendered feature-menu table with an `AskUserQuestion` (`multiSelect: true`) in the same
   response — the table is the visual view; the tool call is the selection channel
-- For an **inline** feature, ALWAYS read its reference file first and follow the SOR at runtime — never
-  hardcode a route, body, or preference name
-- For **Audit Tracking**, ALWAYS keep every already-tracked Incident field in the save unless the user asked
-  to stop tracking it, confirm the exact final field list before the save, and verify by read-back before
-  marking it `Done` (or verify the already-configured state by live read with no write) — the SOR asks the
-  user nothing itself
+- ALWAYS read a feature's reference file before executing it, follow its rules, and follow the SOR at
+  runtime — never hardcode a route, body, or preference name
+- ALWAYS run a feature's SORs under the hand-off protocol; NEVER hand a feature off to another skill, and
+  never follow a SOR's hand-off for either prerequisite gate or for another feature on this menu
 - NEVER set up a feature the user did not select; for "set up everything", walk each feature sequentially
   in recommended order, confirming between each step
 - Track progress across the conversation — do not re-present completed features as "Not done"
@@ -224,30 +259,39 @@ hand-off. They are irreversible or silently-wrong if missed.
 Before emitting any menu or summary, confirm each; adjust the output before sending if any is unchecked.
 
 - [ ] The header line ends with `(via service-itsm-agentic-setup-incident-management)`
-- [ ] The master switch was confirmed on (via the `IncidentMgmt` SOR status/verify steps) before the menu,
-      unless a live read already confirmed it ENABLED on this org earlier in this session
+- [ ] The `IncidentMgmt` SOR confirmed both prerequisite gates before the menu or direct feature
+      handoff, unless both were already confirmed enabled earlier in this conversation; each off gate was
+      asked with `AskUserQuestion` (Yes/No), not plain text, before the enable was delegated
+- [ ] The exact `service-cloud-itsm-setup` entry verified exact `ENABLED` before the Incident-switch
+      sequence; any other result stopped
 - [ ] The feature menu emitted BOTH the ASCII table AND an `AskUserQuestion` (`multiSelect: true`) in the
       same response (single-select only if the user already named a specific feature)
 - [ ] Each feature row's `Status` reflects the actual tracked state (`Not done`, `In progress`, `Done`)
 - [ ] A feature is being handled only because the user explicitly selected it (or is being walked through
       sequentially with confirmation under an "all" / "everything" request)
-- [ ] For an inline feature: its reference file was read; live state was read before any write; each write
-      was confirmed and verified by read-back; one-way / license-ordering invariants were honored
-- [ ] For a delegated feature: the child skill (or, for Audit Tracking, the Field History Tracking SOR) was
-      used, not configured inline
-- [ ] For Audit Tracking: a live metadata read resolved the fields and complete labeled set; any save kept
-      every already-tracked field the user didn't ask to drop, was confirmed before it ran, and was verified
-      by read-back; a no-write `Done` also had Incident's object-level tracking confirmed on
+- [ ] For each feature: its reference file was read and its checks passed; its SORs ran under the
+      hand-off protocol and no other skill was used; live state was read before any write; each
+      write was confirmed and verified by read-back, and a no-write `Done` came from a live read; one-way /
+      license-ordering invariants were honored
 - [ ] No Salesforce record IDs appear in the output — human-readable names only
 
 ---
 
 ## Reference File Index
 
+Read each `references/` file before executing its feature.
+
 | File | When to read |
 |------|--------------|
 | `examples/output-templates.md` | Behavior steps 3, 5, 6 — feature menu (multi-select), post-feature progress, completion summary |
-| `references/incident-preferences.md` | Before executing the **Incident Preferences** feature — the six preferences, the one-way rules, the SOR delegation map, invariants, and failure taxonomy |
-| `references/major-incident-management.md` | Before executing the **Major Incident Management** feature — the two surfaces (approval group + preferences), licensing preconditions, ordering, invariants |
-| `references/incident-persona-psg.md` | Before executing the **Incident Persona PSG** feature — the two persona PSGs, PSL-before-PSG ordering, resolution rules, invariants |
-| `references/service-mgmt-privilege.md` | Before executing the **Service Management Privilege** feature — the Enable Privilege Assignment toggle, escalation level, privilege CRUD (destructive delete), bulk assignments (no read-back), and the SOR step map |
+| `references/incident-preferences.md` | **Incident Preferences** — where to start in the `IncidentMgmt` SOR, the steps never to run, the one-way confirmations, and the licensed toggles |
+| `references/incident-persona-psg.md` | **Incident Persona PSG** — the not-provisioned stop, the persona menu, one pass per PSG, and the settling status |
+| `references/priority-matrix.md` | **Priority Matrix** — the reads, the full-replacement save, the read-back, and the Salesforce Go step |
+| `references/sla-milestones.md` | **SLA & Milestones** — the one gate question, the lowercase seed, predefined vs custom, the milestone strategy, and milestone actions |
+| `references/incident-dashboards.md` | **Incident Dashboards** — the persona choice, the two preferences each, and the dashboard check |
+| `references/email-to-incident.md` | **Email-to-Incident** — the one-way enable, the full-map settings save, and routing addresses |
+| `references/major-incident-management.md` | **Major Incident Management** — MIM must be active, the questions, reusing the approvers group, and validating before designating |
+| `references/broadcast-communications.md` | **Broadcast Communications** — the one-way enable, then sender access, channels, and objects |
+| `references/manage-incidents-with-ai.md` | **Manage Incidents with AI** — the three switches, which ones a request covers, the licensed ones, transcripts, and the smoke test |
+| `references/service-mgmt-privilege.md` | **Service Management Privilege** — the toggle first, Tag-first, the irreversible delete, and the unverifiable assignments |
+| `references/audit-tracking.md` | **Audit Tracking** — the field choice, the additive save, object-level tracking, and the read-back |

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

@@ -11,26 +11,42 @@ Incident Management Setup (via service-itsm-agentic-setup-incident-management)
 
 Here are the features available for Incident Management. Select one or more to configure:
 
-┌───┬───────────────────────────────┬──────────────────────────────────────────────────┬──────────┐
-│ # │ Feature                       │ Description                                      │ Status   │
-├───┼───────────────────────────────┼──────────────────────────────────────────────────┼──────────┤
-│ 1 │ SLA & Milestones              │ Create a MilestoneType, SLA Policy, and          │ Not done │
-│   │                               │ Entitlement so Incidents inherit SLA milestones  │          │
-│ 2 │ Priority Matrix               │ Enable and shape the Impact × Urgency grid that  │ Not done │
-│   │                               │ derives Priority on Incident records             │          │
-│ 3 │ Incident Preferences          │ The six per-feature setup toggles (validations,  │ Not done │
-│   │                               │ auto-close, triage, Einstein assign, rich text)  │          │
-│ 4 │ Major Incident Management     │ Approval group + the two MIM preferences         │ Not done │
-│   │                               │ (auto-create problem, auto-close child)          │          │
-│ 5 │ Incident Persona PSG          │ Assign the Incident Fulfiller / Incident Manager │ Not done │
-│   │                               │ persona to a user (bundle + backing licenses)    │          │
-│ 6 │ Service Management Privilege  │ Escalation level, privilege records + employee   │ Not done │
-│   │                               │ assignments, behind Enable Privilege Assignment  │          │
-│ 7 │ Audit Tracking                │ Turn on field history tracking for the Incident  │ Not done │
-│   │                               │ fields you choose (who changed what, and when)   │          │
-└───┴───────────────────────────────┴──────────────────────────────────────────────────┴──────────┘
-
-Reply with the numbers of the features you want to set up (one or more, e.g. `1,3`).
+┌────┬───────────────────────────────┬──────────────────────────────────────────────────┬──────────┐
+│ #  │ Feature                       │ Description                                      │ Status   │
+├────┼───────────────────────────────┼──────────────────────────────────────────────────┼──────────┤
+│ P  │ Incident Preferences          │ The six setup toggles (validations, auto-close,  │ Not done │
+│    │                               │ triage, Einstein, group restriction, rich text)  │          │
+├────┴───────────────────────────────┴──────────────────────────────────────────────────┴──────────┤
+│ Set Up the Basics                                                                                │
+├────┬───────────────────────────────┬──────────────────────────────────────────────────┬──────────┤
+│ 1  │ Incident Persona PSG          │ Manage User Access: give a user the Incident     │ Not done │
+│    │                               │ Fulfiller or Manager persona (bundle + licenses) │          │
+│ 2  │ Priority Matrix               │ Configure Rules for Automatic Incident Priority: │ Not done │
+│    │                               │ the Impact × Urgency grid that sets Priority     │          │
+│ 3  │ SLA & Milestones              │ Define SLAs to Prioritize Incidents: turn on SLA │ Not done │
+│    │                               │ Management, then a predefined or custom policy   │          │
+├────┴───────────────────────────────┴──────────────────────────────────────────────────┴──────────┤
+│ Unlock Advanced Functionality                                                                    │
+├────┬───────────────────────────────┬──────────────────────────────────────────────────┬──────────┤
+│ 4  │ Incident Dashboards           │ Deploy the Incident Manager and/or Fulfiller     │ Not done │
+│    │                               │ dashboards, and dashboards on the Home page      │          │
+│ 5  │ Email-to-Incident             │ Report Incidents from Emails: email settings +   │ Not done │
+│    │                               │ routing addresses                                │          │
+│ 6  │ Major Incident Management     │ Review and Manage Major Incident Configuration:  │ Not done │
+│    │                               │ approval group + the two MIM preferences         │          │
+│    │                               │ (auto-create problem, auto-close child)          │          │
+│ 7  │ Broadcast Communications      │ Set Up Broadcast Communication for Major         │ Not done │
+│    │                               │ Incidents: turn on, then sender access, channels │          │
+│    │                               │ (Email/In-app/Slack/Teams), objects              │          │
+│ 8  │ Manage Incidents with AI      │ Auto-triage, Einstein assignment, and AI-drafted │ Not done │
+│    │                               │ incidents from chat or voice transcripts         │          │
+│ 9  │ Service Management Privilege  │ Escalation level, privilege records + employee   │ Not done │
+│    │                               │ assignments, behind Enable Privilege Assignment  │          │
+│ 10 │ Audit Tracking                │ Turn on field history tracking for the Incident  │ Not done │
+│    │                               │ fields you choose (who changed what, and when)   │          │
+└────┴───────────────────────────────┴──────────────────────────────────────────────────┴──────────┘
+
+Reply with the numbers of the features you want to set up (one or more, e.g. `1,3`; `P` for Incident Preferences).
 ```
 
 ## Post-feature progress (Behavior step 5)
@@ -41,19 +57,23 @@ Example after the Incident Preferences feature completes (others still `Not done
 Incident Preferences — configured successfully
 (via service-itsm-agentic-setup-incident-management)
 
-┌───┬───────────────────────────────┬──────────┐
-│ # │ Feature                       │ Status   │
-├───┼───────────────────────────────┼──────────┤
-│ 1 │ SLA & Milestones              │ Not done │
-│ 2 │ Priority Matrix               │ Not done │
-│ 3 │ Incident Preferences          │ Done     │
-│ 4 │ Major Incident Management     │ Not done │
-│ 5 │ Incident Persona PSG          │ Not done │
-│ 6 │ Service Management Privilege  │ Not done │
-│ 7 │ Audit Tracking                │ Not done │
-└───┴───────────────────────────────┴──────────┘
-
-Say a number to configure the next feature, or `done` to finish.
+┌────┬───────────────────────────────┬──────────┐
+│ #  │ Feature                       │ Status   │
+├────┼───────────────────────────────┼──────────┤
+│ P  │ Incident Preferences          │ Done     │
+│ 1  │ Incident Persona PSG          │ Not done │
+│ 2  │ Priority Matrix               │ Not done │
+│ 3  │ SLA & Milestones              │ Not done │
+│ 4  │ Incident Dashboards           │ Not done │
+│ 5  │ Email-to-Incident             │ Not done │
+│ 6  │ Major Incident Management     │ Not done │
+│ 7  │ Broadcast Communications      │ Not done │
+│ 8  │ Manage Incidents with AI      │ Not done │
+│ 9  │ Service Management Privilege  │ Not done │
+│ 10 │ Audit Tracking                │ Not done │
+└────┴───────────────────────────────┴──────────┘
+
+Say a number (or `P`) to configure the next feature, or `done` to finish.
 ```
 
 ## Completion summary (Behavior step 6)
@@ -69,7 +89,7 @@ finished — even if some features are still `Not done`. When rendering:
   - All `Done` → `Your Incident Management features are configured.`
   - Otherwise → `You have finished the features you selected. The remaining features can be resumed later by re-invoking this orchestrator.`
 
-Example — user finished with three features configured, four left:
+Example — user finished after configuring three features:
 
 ```text
 Incident Management Setup — Finished
@@ -78,11 +98,15 @@ Incident Management Setup — Finished
 ┌───────────────────────────────┬──────────┐
 │ Feature                       │ Status   │
 ├───────────────────────────────┼──────────┤
-│ SLA & Milestones              │ Done     │
-│ Priority Matrix               │ Not done │
 │ Incident Preferences          │ Done     │
-│ Major Incident Management     │ Done     │
 │ Incident Persona PSG          │ Not done │
+│ Priority Matrix               │ Not done │
+│ SLA & Milestones              │ Done     │
+│ Incident Dashboards           │ Not done │
+│ Email-to-Incident             │ Not done │
+│ Major Incident Management     │ Done     │
+│ Broadcast Communications      │ Not done │
+│ Manage Incidents with AI      │ Not done │
 │ Service Management Privilege  │ Not done │
 │ Audit Tracking                │ Not done │
 └───────────────────────────────┴──────────┘

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

@@ -0,0 +1,42 @@
+# Feature: Audit Tracking (delegated to the `FieldHistoryTracking` SOR)
+
+How the orchestrator runs the **Audit Tracking** feature — field history on the Incident fields the user
+chooses — over Salesforce's **Field History Tracking SOR**. This file re-derives none of the SOR's steps —
+the SOR's own steps and guidance decide *how*. The orchestrator runs them under its **SOR hand-off
+protocol** and owns the user-facing gates:
+
+1. `discover` the SOR by intent (e.g. "field history tracking") and `describe` the id `discover` returns
+   (`FieldHistoryTracking`). Judge availability by what the calls return, not by a step's `status` label —
+   a step labelled `proposed` may still be served. A `discover` miss or a `401`/`403`/`404` means the
+   surface isn't available to this user or org: surface it and stop.
+2. Use the Incident fields the user already named, or ask which fields to track if the choice is missing
+   or ambiguous, plus anything else `describe` says it needs. If the user chooses no fields, leave the
+   feature `Not done` and stop; do not treat an empty choice as already configured.
+3. Through the SOR, check Setup access, read Incident with `get-single-entity-data-with-metadata`, and get
+   its per-object tracked-field limit. Use the returned tracking flag, field labels, `canBeTracked` values,
+   current tracked set, and `fieldEnumOrId` keys to resolve the user's choices; do not guess field keys.
+4. The save replaces the object's whole tracked-field set, so send the **union** of what's already tracked
+   and the chosen fields using their returned keys, with Incident's object-level tracking flag on — never
+   drop an already-tracked field unless the user asks. If a chosen field can't be tracked, or the union
+   would exceed the limit, say so plainly; never untrack another field to make room. Report it as done
+   with no write only if the nonempty chosen set is already tracked **and** Incident's object-level tracking
+   is on. If the fields are selected but that flag is off, the change still needs a save.
+5. Show the exact final tracked-field list by field label (disambiguate matching labels) in either case.
+   Before any save, also show that object-level tracking will be enabled and get an explicit yes
+   (`AskUserQuestion`) for that plan; when the user already named the fields, this confirms the selection.
+6. After any save, read Incident's tracked fields back through the SOR. Mark the feature `Done` only when
+   the live read (for the no-write case) or post-save read-back shows Incident's object-level tracking on,
+   the chosen fields tracked, and no field dropped that the user didn't ask to drop — a save response alone
+   is not proof.
+
+## Rules
+
+- ALWAYS keep every already-tracked Incident field in the save unless the user asked to stop tracking it,
+  confirm the exact final field list before the save, and verify by read-back before marking it `Done` (or
+  verify the already-configured state by live read with no write) — the SOR asks the user nothing itself
+
+## Before marking it `Done`
+
+- [ ] A live metadata read resolved the fields and complete labeled set; any save kept every
+      already-tracked field the user didn't ask to drop, was confirmed before it ran, and was verified by
+      read-back; a no-write `Done` also had Incident's object-level tracking confirmed on