@salesforce/afv-skills 1.41.0 → 1.43.0

package/skills/service-itsm-agentic-setup-itsm-agentforce-permset-assign/references/helper-contracts.md

@@ -4,13 +4,13 @@ All four scripts are deterministic, side-effect-free JSON classifiers (A9). They
 
 ## `scripts/classify-permset-availability.mjs`
 
-Decides Branch A vs Branch B (assign vs hand-off) AND emits per-persona `needsPsl` flags. Fulfiller-only — the four persona names are hard-coded.
+Decides Branch A vs Branch B (assign vs hand-off) AND emits per-persona `needsPsl` flags. Fulfiller-only — the three persona names are hard-coded.
 
 ### Input
 
 One file path (positional):
 
-1. `permsets.json` — `sf data query --json` capture of `PermissionSet` filtered to the four Fulfiller persona `Name` values (see `permset-topology.md`). Unrelated rows are filtered out by the classifier.
+1. `permsets.json` — `sf data query --json` capture of `PermissionSet` filtered to the three Fulfiller persona `Name` values (see `permset-topology.md`). Unrelated rows are filtered out by the classifier.
 
 Must be the raw stdout capture (the `{status, result: {records: [...]}}` envelope). An unparseable / non-envelope body produces `verdict:"CANNOT-CONFIRM"` with the raw error in `reasons[]`.
 
@@ -19,7 +19,7 @@ Must be the raw stdout capture (the `{status, result: {records: [...]}}` envelop
 ```json
 {
   "personasFound": ["IncidentFulfiller"],
-  "personasMissing": ["ProblemFulfillerPermSet","ChangeRequestFulfillerPermSet","ReleaseManagerPermSet"],
+  "personasMissing": ["ProblemFulfillerPermSet","ChangeRequestFulfillerPermSet"],
   "candidates": [
     { "Id": "0PS...", "Name": "IncidentFulfiller", "Label": "Incident Fulfiller", "LicenseId": "0PL...", "needsPsl": true }
   ],
@@ -28,16 +28,16 @@ Must be the raw stdout capture (the `{status, result: {records: [...]}}` envelop
 }
 ```
 
-- `candidates[]` lists ONLY rows whose `Name` matches one of the four known Fulfiller personas. Unrelated rows in the query result are dropped.
+- `candidates[]` lists ONLY rows whose `Name` matches one of the three known Fulfiller personas. Unrelated rows in the query result are dropped.
 - `needsPsl` is derived per-row from `LicenseId !== null` — read it from the SELECTED persona in the workflow.
-- `personasFound` preserves the canonical order (Incident, Problem, Change, Release) so the AskUserQuestion menu is stable across runs.
+- `personasFound` preserves the canonical order (Incident, Problem, Change) so the AskUserQuestion menu is stable across runs.
 
 Verdict values:
 
 | verdict | Meaning | Caller action |
 |---|---|---|
 | `ASSIGN` | ≥1 Fulfiller persona present on the org | Continue to Phase 2. AskUserQuestion which persona to assign; read `needsPsl` off that persona to gate PSL SOQL + POST |
-| `HAND-OFF` | None of the four personas present | Skip Phase 2 entirely; go to Phase 3 (delegate to `service-itsm-agentic-setup-agentforce-studio-validate`) |
+| `HAND-OFF` | None of the three personas present | Skip Phase 2 entirely; go to Phase 3 (delegate to `service-itsm-agentic-setup-agentforce-studio-validate`) |
 | `CANNOT-CONFIRM` | The query envelope was unparseable | Surface `reasons[]` verbatim and stop |
 
 **Never auto-select** from `candidates[]` — a Fulfiller commonly needs only one persona (e.g. Incident) even when several are provisioned. Present the list and let the user pick.

package/skills/service-itsm-agentic-setup-itsm-agentforce-permset-assign/references/permset-topology.md

@@ -9,7 +9,7 @@ Core (namespace `force`).
 
 **Employee agent is out of scope for this skill.** The Employee agent's access
 model is separate (org-preferences + a different persona layer) and does not
-map onto these four permsets.
+map onto these three permsets.
 
 ## Fulfiller persona ↔ AddOn ↔ PSL ↔ PermSet
 
@@ -18,7 +18,6 @@ map onto these four permsets.
 | Incident Fulfiller | `IncidentManagementAddOn-1` | `IncidentFulfillerPsl-1` | **`IncidentFulfiller`** | `IncidentFulfillerUser` |
 | Problem Fulfiller | `ProblemManagementAddOn-1` | `ProblemFulfillerPsl-1` | **`ProblemFulfillerPermSet`** | `ProblemFulfillerUser` |
 | Change Fulfiller | `ChangeManagementAddOn-1` | `ChangeRequestFulfillerPsl-1` | **`ChangeRequestFulfillerPermSet`** | `ChangeFulfillerPerm` |
-| Release Manager | `ReleaseManagementAddOn-1` | `ReleaseManagerPsl-1` | **`ReleaseManagerPermSet`** | (org-perm-gated only) |
 
 ### Key facts
 
@@ -26,14 +25,9 @@ map onto these four permsets.
   in the previous version of this skill (`svc_itsm_intelligence`) never
   returns any of these rows.
 - **Naming inconsistency**: `IncidentFulfiller` has NO `PermSet` suffix; the
-  other three DO. The classifier's fixed-name list reflects this exactly —
+  other two DO. The classifier's fixed-name list reflects this exactly —
   do not "normalize" the Incident name to `IncidentFulfillerPermSet`, it does
   not exist on the org.
-- **`ReleaseManagerPermSet`** ships as a permset but its Fulfiller user permission
-  lives on the OrgPreference layer (org-perm-gated). Assigning the permset
-  still works and is the correct write; the runtime effect activates once the
-  org toggle is on. Downstream, `service-itsm-agentic-setup-agentforce-studio-validate`
-  is the skill that toggles the org preference.
 - **CMDB access is a separate concern** — the CMDB read/write permsets are
   handled by `service-itsm-agentic-setup-cmdb-access-assign` and are not
   gated by any `svc_itsm_intelligence__*` prompt-template invocable, so they
@@ -47,8 +41,7 @@ FROM PermissionSet
 WHERE Name IN (
   'IncidentFulfiller',
   'ProblemFulfillerPermSet',
-  'ChangeRequestFulfillerPermSet',
-  'ReleaseManagerPermSet'
+  'ChangeRequestFulfillerPermSet'
 )
 ```
 

package/skills/service-itsm-agentic-setup-itsm-agentforce-permset-assign/scripts/classify-permset-availability.mjs

@@ -2,19 +2,18 @@
 // Deterministic branch classifier for the Fulfiller persona permset-assign flow.
 //
 // Reads ONE input:
-//   - PermissionSet query capture (from `sf data query --json`) for the four
+//   - PermissionSet query capture (from `sf data query --json`) for the three
 //     Core-shipped Fulfiller persona permsets:
 //       * IncidentFulfiller
 //       * ProblemFulfillerPermSet
 //       * ChangeRequestFulfillerPermSet
-//       * ReleaseManagerPermSet
 //     (namespace `force`, not a managed-package namespace)
 //
 // Rules (A9):
-//   - `verdict:"ASSIGN"`      — ≥1 of the four personas is present. Caller
+//   - `verdict:"ASSIGN"`      — ≥1 of the three personas is present. Caller
 //                                asks the user which persona to assign; do NOT
 //                                auto-select.
-//   - `verdict:"HAND-OFF"`    — none of the four present. The ITSM AddOn(s)
+//   - `verdict:"HAND-OFF"`    — none of the three present. The ITSM AddOn(s)
 //                                are not provisioned; permset-assign is a
 //                                no-op. Hand off to the studio validate skill
 //                                so the AddOn(s) can be enabled first.
@@ -29,7 +28,7 @@
 //     candidates: [{ Id, Name, Label, LicenseId, needsPsl }, ...],
 //     verdict: "ASSIGN" | "HAND-OFF" | "CANNOT-CONFIRM",
 //     reasons: [...] }
-// `candidates` includes only rows for the four known persona Names; unrelated
+// `candidates` includes only rows for the three known persona Names; unrelated
 // rows in the query result are filtered out. `needsPsl` is derived per-row
 // from `LicenseId !== null`. Exit is always 0 on parseable bodies; verdict
 // carries the branch decision. Exit 2 on missing argv.
@@ -40,7 +39,6 @@ const KNOWN_PERSONAS = [
   'IncidentFulfiller',
   'ProblemFulfillerPermSet',
   'ChangeRequestFulfillerPermSet',
-  'ReleaseManagerPermSet',
 ];
 
 function readEnvelope(path) {
@@ -78,7 +76,7 @@ if (!ps.ok) {
   process.exit(0);
 }
 
-// Filter to only the five known persona Names — drop any unrelated rows.
+// Filter to only the three known persona Names — drop any unrelated rows.
 const knownRows = ps.records.filter((r) => KNOWN_PERSONAS.includes(r?.Name));
 const foundNames = knownRows.map((r) => r.Name);
 const personasFound = KNOWN_PERSONAS.filter((n) => foundNames.includes(n));
@@ -96,11 +94,11 @@ const reasons = [];
 let verdict;
 if (personasFound.length === 0) {
   verdict = 'HAND-OFF';
-  reasons.push('None of the four Core-shipped Fulfiller persona permsets (IncidentFulfiller, ProblemFulfillerPermSet, ChangeRequestFulfillerPermSet, ReleaseManagerPermSet) is present on this org — the ITSM AddOn(s) are not provisioned.');
+  reasons.push('None of the three Core-shipped Fulfiller persona permsets (IncidentFulfiller, ProblemFulfillerPermSet, ChangeRequestFulfillerPermSet) is present on this org — the ITSM AddOn(s) are not provisioned.');
   reasons.push('Permset-assign cannot fix this; hand off to service-itsm-agentic-setup-agentforce-studio-validate.');
 } else {
   verdict = 'ASSIGN';
-  reasons.push(`Found ${personasFound.length} of 4 Fulfiller persona permset(s) on this org: ${personasFound.join(', ')}.`);
+  reasons.push(`Found ${personasFound.length} of 3 Fulfiller persona permset(s) on this org: ${personasFound.join(', ')}.`);
   if (personasMissing.length > 0) {
     reasons.push(`Not provisioned (AddOn(s) missing for these personas): ${personasMissing.join(', ')}.`);
   }

package/skills/service-itsm-incident-mgmt-configure/SKILL.md

@@ -2,6 +2,8 @@
 name: service-itsm-incident-mgmt-configure
 description: "Reads and toggles the master Incident Management setting on a Salesforce ITSM org — the org-level switch that turns Incident Management on or off. Reads current state before writing, is idempotent, and requires explicit user confirmation before any change. Use when the user wants to enable, disable, toggle, view, or turn on/off Incident Management (Service ITSM) at the org level. DO NOT TRIGGER for Default Field Validations for Incidents, Auto Closure of Child Incidents, Email-to-Incident sub-toggles, Problem Management, Change Management, Case Management, ITSM External Client App setup, or Incident Priority Matrix configuration (use the service-itsm-incident-priority-configure skill)."
 metadata:
+  relatedSkills:
+    - "service-itsm-incident-priority-configure"
   version: "1.1"
   domains: ["Service"]
   minApiVersion: "67.0"

package/skills/service-itsm-incident-priority-configure/SKILL.md

@@ -2,7 +2,9 @@
 name: service-itsm-incident-priority-configure
 description: "Configures the Incident Priority Matrix for Salesforce ITSM through the sf CLI — enabling or disabling the matrix, shaping the Impact x Urgency grid that derives Priority on Incident records, toggling the manual-override preference, and reading or setting the default fallback priority. Reads every value before writing, is idempotent, and requires explicit user confirmation before any mutation. Use when the user wants to view, enable, disable, set up, seed, add to, change, or remove priority matrix configuration for Incident records, change the default incident priority, or asks about incident priority setup, impact/urgency mapping, override, or the ITSM incident priority matrix. DO NOT TRIGGER for Problem or ChangeRequest priority matrices, Case priority fields, standard Priority picklists outside ITSM, SLA or milestone configuration, or enabling Incident Management itself (use the service-itsm-incident-mgmt-configure skill)."
 metadata:
-  version: "1.3"
+  version: "1.4"
+  relatedSkills:
+    - "service-itsm-incident-mgmt-configure"
   domains: ["Service"]
   minApiVersion: "67.0"
   cliTools:
@@ -19,7 +21,7 @@ allowed-tools: |
 
 Configures the **Incident Priority Matrix** for Salesforce ITSM — the grid that derives an Incident's **Priority** from its **Impact** and **Urgency**. Covers viewing the matrix, enabling / disabling it, adding / changing / removing / seeding cells, toggling the manual-override preference, and reading / setting the default (fallback) priority.
 
-Every read and write dispatches through the **`sf` CLI** — no MCP dispatcher, no `/headless/invoke/*` route, no Aura controller. This means the skill works on any org with the Incident Management license enabled, without the `api.agentic.access.enableHeadless360McpServer` gate.
+Every read and write dispatches through the **`sf` CLI**, so this skill works on any org with the Incident Management license enabled.
 
 Writes are **idempotent** (skipped when the current state already matches the target), the skill always **reads before it writes**, and an explicit **confirm-to-write** checkpoint is required before any mutation.
 
@@ -54,7 +56,7 @@ surface the raw error and stop.**
 
 ## Routes at a glance
 
-Every route is called through `sf` — no `curl`, no MCP server. Full method / path / body / response
+Every route is called through the `sf` CLI. Full method / path / body / response
 details, the picklist extraction recipe, and gotchas live in `references/sf-cli-invocation.md`.
 
 | Concern | Transport | HTTP status |
@@ -69,6 +71,7 @@ details, the picklist extraction recipe, and gotchas live in `references/sf-cli-
 | Default fallback priority (read) | `sf api request rest` GET on `/services/data/v67.0/tooling/query/?q=...StandardValueSet...` | 200 |
 | Default fallback priority (write) | `sf project retrieve start` + edit + `sf project deploy start` on `StandardValueSet:IncidentPriority` | deploy Succeeded |
 | Picklist values (Incident) | `sf api request rest` GET on `/services/data/v67.0/sobjects/Incident/describe` | 200 |
+| Salesforce Go step "Done" (write, after a mutation) | `sf api request rest` PUT on `/services/data/v67.0/connect/setup/discovery/feature/service-cloud-itsm-incident/configuration/step/definePriorityMatrix/progress` | 200 |
 
 **Path prefixes are load-bearing — do NOT strip them.** Setup Connect API paths MUST start with
 `/services/data/v67.0/`. Tooling REST paths MUST start with `/services/data/v67.0/tooling/`.
@@ -116,13 +119,10 @@ a user statement (or you cannot identify a specific prior `sf` response), re-rea
   read this session AND no `StandardValueSet:IncidentPriority` deploy has run since,
   skip step 6.
 
-**When in doubt, re-check.** Skip only when the earlier fact is unambiguously in context
-AND the target-org alias has not changed AND no write elsewhere in the session could
-have invalidated it (Phase-4 writes in this skill are the primary invalidators — a
-PATCH on a pref, a POST/PATCH/delete on a `ServiceOpPriorityConfig` row, or a
-`StandardValueSet:IncidentPriority` deploy all bust the cache for the matching read).
-If the user hints at a different org (or a different alias), re-run the read. A wrong
-skip on a live org write is worse than a duplicated read.
+**When in doubt, re-check.** Skip only when the fact is unambiguously in context, the
+`--target-org` alias is unchanged, and no Phase-4 write since (a pref PATCH, a
+`ServiceOpPriorityConfig` POST/PATCH/delete, or a `StandardValueSet:IncidentPriority`
+deploy) could have invalidated it. A wrong skip on a live org is worse than a re-read.
 
 ### Phase 1 — Preflight
 
@@ -164,7 +164,8 @@ Read the current value of the same concern first (Phase 2 covers this), confirm
 ### Phase 5 — Verify and present
 
 7. Re-read the concern that was mutated (matrix rows via Tooling SOQL; default priority via `StandardValueSet` query; prefs are echoed on PATCH response). If the observed state does not match the requested state, treat it as a failed write and report the raw server response verbatim.
-8. Present before/after (Impact × Urgency grid via `examples/render-matrix.md`) plus a one-line summary (e.g. `Incident matrix: High/High → Critical added`). Matrix changes affect only Incidents created **after** the write; disabling the matrix does not clear stored rows or the default priority.
+8. **Mark the Salesforce Go step Done — only if a Phase-4 functional write actually landed.** The "Define Priority Matrix" step is user-override: its checkmark is **not** derived from org state, so configuring the matrix alone never flips it — completion must be written. After step 7 verifies the write, PUT the completion once (`references/sf-cli-invocation.md` route 10; body `{"isComplete": true}`, flag REQUIRED). It rides on the Phase-3 confirmation — no separate `AskUserQuestion`. **Skip entirely on view-only reads and idempotent no-ops.**
+9. Present before/after (Impact × Urgency grid via `examples/render-matrix.md`) plus a one-line summary (e.g. `Incident matrix: High/High → Critical added`). Matrix changes affect only Incidents created **after** the write; disabling the matrix does not clear stored rows or the default priority.
 
 ---
 
@@ -172,7 +173,7 @@ Read the current value of the same concern first (Phase 2 covers this), confirm
 
 | Constraint | Rationale |
 |-----------|-----------|
-| All operations run through `sf` CLI | The user-selected transport for this skill; no MCP dispatcher; no `/headless/invoke/*` route |
+| All operations run through `sf` CLI | Works on any org with Incident Management enabled; requires no additional setup |
 | Always API v67.0 minimum | The Setup Connect API pref routes require v67+ |
 | Read live state before writing | The Phase-2 snapshot is the source of truth for the confirmation prompt, the idempotency check, and the Phase-5 verify |
 | **REQUIRED confirm-to-write checkpoint** before any mutation | Toggling prefs or changing matrix rows mutates org state; user must approve the exact plan |
@@ -182,6 +183,7 @@ Read the current value of the same concern first (Phase 2 covers this), confirm
 | Refuse any `ReferenceObject` other than `Incident` (`Problem`, `ChangeRequest`, anything else) | `ServiceOpPriorityConfig` is shared with the Problem / ChangeRequest matrices at the wire level — the server accepts any `ReferenceObject` string. Scope to `Incident` is skill-enforced only. |
 | On Change / Remove, if the target coordinate resolves to more than one row, do NOT dispatch — require an explicit `Id` or a confirmed consolidation plan | The server allows duplicate `(ReferenceObject, Urgency, Impact)` rows. Picking "the row Id" arbitrarily would mutate one duplicate and leave the other in place, keeping the matrix non-deterministic. |
 | Report exact error text from the CLI response | The CLI surfaces the underlying error message verbatim |
+| After a functional write, PUT the Salesforce Go step-progress completion (route 10); skip on view / no-op | The "Define Priority Matrix" step is user-override — its checkmark isn't derived from org state, so config writes alone leave the Go checklist stuck |
 
 ---
 
@@ -196,6 +198,7 @@ Before reporting completion of any mutation, confirm each of the following. If a
 - [ ] Every `Impact`, `Urgency`, `Priority` in any add / change payload was validated against the Phase-1 picklist values before dispatch. Duplicates on `(ReferenceObject, Urgency, Impact)` were caught client-side against the Phase-2 snapshot — the server does NOT reject duplicates. Every add payload had `ReferenceObject == "Incident"`.
 - [ ] Phase 4 writes used the exact CLI invocations from `references/sf-cli-invocation.md`; on any `4xx` / `5xx` (or non-`Succeeded` deploy), the raw response was surfaced and the run halted.
 - [ ] Phase 5 verify re-read the affected concerns; any diff was reported as `write FAILED — server state differs from request` with the raw response.
+- [ ] If a Phase-4 functional write landed, the Go step-progress completion PUT (route 10) was sent after verify. On view-only reads and idempotent no-ops, no completion PUT was dispatched.
 - [ ] The final report gave a before/after with the Impact × Urgency grid and a one-line summary.
 
 ---

package/skills/service-itsm-incident-priority-configure/examples/matrix-operations.md

@@ -1,6 +1,6 @@
 # Matrix Operations — CLI Invocation Templates
 
-Every mutation is a single `sf` CLI command. Unlike the earlier Aura-dispatcher path (`save-details` replace-whole), the Tooling REST endpoints operate on **one row at a time** — the read-modify-write step is client-side only. Add, change, and remove are three distinct wire calls, not one replace.
+Every mutation is a single `sf` CLI command. The Tooling REST endpoints operate on **one row at a time** — the read-modify-write step is client-side only. Add, change, and remove are three distinct wire calls, not one replace.
 
 Templates below start from this hypothetical current matrix (Tooling SOQL result):
 
@@ -198,3 +198,29 @@ The XML shape after editing (default `High`):
 ```
 
 Validate the target value against the Phase-1 active picklist first.
+
+---
+
+## Mark the Salesforce Go setup step complete (Phase 5, after a mutation)
+
+Once a functional write above has been dispatched **and** the Phase-5 verify confirms it landed,
+flip the "Define Priority Matrix" tile in the Salesforce Go setup checklist to Done. This step is a
+user-override step: configuring the matrix functionally does **not** move its checkmark — the
+completion has to be written explicitly (route 10 in `references/sf-cli-invocation.md`).
+
+```bash
+sf api request rest \
+  "/services/data/v67.0/connect/setup/discovery/feature/service-cloud-itsm-incident/configuration/step/definePriorityMatrix/progress" \
+  --method PUT \
+  --header "Content-Type:application/json" \
+  --body '{"isComplete": true}' \
+  --target-org <alias>
+```
+
+Response: `200` with the updated step progress. Notes:
+
+- **`isComplete` is required** — omitting it returns HTTP 500, not 400.
+- Send it **only when Phase 4 actually wrote something**. On a view-only read or an idempotent
+  no-op (e.g. disabling an already-disabled matrix), dispatch nothing — the PUT is itself a mutation.
+- It rides on the confirmation the user already gave for the functional change; it is not a
+  separately-confirmed write.

package/skills/service-itsm-incident-priority-configure/references/sf-cli-invocation.md

@@ -6,7 +6,7 @@ This skill invokes every read and write through the **`sf` CLI**. Two transports
 - `sf data query --use-tooling-api` / `sf data delete record --use-tooling-api` — Tooling API convenience wrappers with better parsing than raw REST.
 - `sf project retrieve start` + `sf project deploy start` — for the `StandardValueSet` metadata that carries the default fallback priority.
 
-Every invocation below was verified 200 (or `Succeeded` for the metadata deploy) against `orgfarm-afdcaf38b6` on 2026-08-04. Path prefixes are load-bearing; do not strip `/services/data/v67.0/` or `/services/data/v67.0/tooling/`.
+Every invocation below reflects the exact request and response shapes returned by the platform. Path prefixes are load-bearing; do not strip `/services/data/v67.0/` or `/services/data/v67.0/tooling/`.
 
 ## Authentication
 
@@ -88,7 +88,7 @@ sf data query \
   --query "SELECT Id, DeveloperName, ReferenceObject, Urgency, Impact, Priority FROM ServiceOpPriorityConfig WHERE ReferenceObject = 'Incident'"
 ```
 
-Zero to `|Impact| × |Urgency|` rows returned. Row keys are PascalCase (`Id`, `DeveloperName`, `ReferenceObject`, `Urgency`, `Impact`, `Priority`) — these are Tooling SObject field names, not the lowercase JSON keys the Aura controller used. `DeveloperName` is included so the add step can derive a fresh unique suffix from existing rows.
+Zero to `|Impact| × |Urgency|` rows returned. Row keys are PascalCase (`Id`, `DeveloperName`, `ReferenceObject`, `Urgency`, `Impact`, `Priority`) — these are Tooling SObject field names. `DeveloperName` is included so the add step can derive a fresh unique suffix from existing rows.
 
 For programmatic scripts, add `--json` and parse `result.records[]`.
 
@@ -111,9 +111,9 @@ Suffix pattern: pattern-match the existing rows' `DeveloperName` values from the
 
 **Important:** The Tooling REST endpoint does NOT enforce picklist validation on `Urgency`, `Impact`, `Priority`. Garbage values are accepted at the wire level but the runtime matrix evaluator refuses to use them. Validate every value against the Phase-1 picklist values before dispatch.
 
-**Duplicates:** the server does NOT enforce `(ReferenceObject, Urgency, Impact)` uniqueness — a second POST on the same coordinate is accepted as a separate row (verified 2026-08-04 on `itsm-eval-org`: two rows with identical `(Incident, Medium, High)` both persisted with distinct `Id`s). Client-side dedup against the Phase-2 snapshot is the ONLY guard against duplicate matrix cells; if you skip it, the runtime picks one of the duplicates non-deterministically.
+**Duplicates:** the server does NOT enforce `(ReferenceObject, Urgency, Impact)` uniqueness — a second POST on the same coordinate is accepted as a separate row (for example, two rows with identical `(Incident, Medium, High)` coordinates will both persist with distinct `Id`s). Client-side dedup against the Phase-2 snapshot is the ONLY guard against duplicate matrix cells; if you skip it, the runtime picks one of the duplicates non-deterministically.
 
-**ReferenceObject:** the server accepts any string for `ReferenceObject` (verified: a `Problem` row inserted successfully). `ServiceOpPriorityConfig` is the shared SObject for Incident / Problem / ChangeRequest matrices. Scope to `Incident` is skill-enforced only — refuse any other value client-side.
+**ReferenceObject:** the server accepts any string for `ReferenceObject` (for example, a `Problem` row can be inserted successfully). `ServiceOpPriorityConfig` is the shared SObject for Incident / Problem / ChangeRequest matrices. Scope to `Incident` is skill-enforced only — refuse any other value client-side.
 
 ### 6. Matrix rows — change
 
@@ -218,6 +218,36 @@ The XML shape is:
 
 Exactly one `<default>true</default>` should be present at deploy time.
 
+### 10. Salesforce Go setup-step completion — write (after a mutation only)
+
+The "Define Priority Matrix" tile in the Salesforce Go setup checklist (feature
+`service-cloud-itsm-incident`, step `definePriorityMatrix`) is a **user-override** step: its
+"Done" checkmark is a user-supplied `StepProgress` record, **not** derived from org state.
+Writing the matrix config (prefs, rows, default) functionally is invisible to the checklist —
+the completion must be written explicitly, exactly as the guided modal does on save.
+
+```bash
+sf api request rest \
+  "/services/data/v67.0/connect/setup/discovery/feature/service-cloud-itsm-incident/configuration/step/definePriorityMatrix/progress" \
+  --method PUT \
+  --header "Content-Type:application/json" \
+  --body '{"isComplete": true}' \
+  --target-org <alias>
+```
+
+**Expected:** HTTP 200 with the updated progress. The endpoint is idempotent — re-asserting
+`isComplete: true` when already complete is a harmless 200, so no read-before-write is needed.
+
+- **`isComplete` is REQUIRED.** Omitting it returns **HTTP 500** (server-side NPE), not a 400.
+- **Fire only after a functional Phase-4 write has landed** (a pref PATCH, a row POST/PATCH/delete,
+  or a `StandardValueSet` deploy). On a view-only read or an idempotent no-op, dispatch **nothing** —
+  there is no configuration action to mark done, and the completion PUT is itself a mutation.
+- This is the same feature the master-pref preflight reads via `/connect/setup/discovery/features`
+  (filter `apiName == "service-cloud-itsm-incident"`); here the singular `.../feature/service-cloud-itsm-incident/...`
+  subresource carries the per-step progress.
+- Rely on the 200 success signal. Any non-200 surfaces verbatim through the skill's standard error
+  handling — the completion PUT is not special-cased.
+
 ---
 
 ## Idempotency contract
@@ -230,8 +260,9 @@ Exactly one `<default>true</default>` should be present at deploy time.
 | Change a cell | The Phase-2 row's `Priority` already equals the requested value |
 | Remove a cell | No Phase-2 row matches `(ReferenceObject, Urgency, Impact)` |
 | Default fallback priority | The Phase-2 `default: true` entry's `valueName` already equals the requested value |
+| Salesforce Go step completion (route 10) | No functional Phase-4 write was dispatched this run — i.e. the request was view-only, or every targeted concern was itself an idempotent no-op. The PUT is also idempotent server-side, so re-asserting `isComplete: true` after a real write is harmless |
 
-When idempotent, report `ALREADY-<state>` and skip Phase 4 entirely.
+When a functional concern (the first six rows) is idempotent, report `ALREADY-<state>` and skip Phase 4 entirely. Route 10 is a Phase-5 action, not a Phase-4 concern — it has no `ALREADY-<state>` report.
 
 ---
 
@@ -259,6 +290,6 @@ For an uncustomized org the defaults are `High/Medium/Low` on `Impact` and `Urge
 | Duplicate `(ReferenceObject, Urgency, Impact)` rows | Accepted silently at the wire level — the server does NOT enforce uniqueness. Both rows persist and the runtime picks one non-deterministically. Deduplicate against the Phase-2 snapshot before POST; this check is the only guard. |
 | `ReferenceObject` accepts any string | The `ServiceOpPriorityConfig` SObject is shared with `Problem` and `ChangeRequest` matrices; the server accepts any value in `ReferenceObject`. Scope to `Incident` is skill-enforced only — refuse other values client-side. |
 | `sf api request rest ... --method DELETE` on Tooling | Fails with `SfError: No 'mode' found in 'body' entry` (sf CLI 2.143). Use `sf data delete record --use-tooling-api` instead. |
-| `/headless/invoke/service/service-itsm/...` returns 404 through `sf api request rest` | Those routes are Aura-dispatcher only; not addressable via the REST API host. Use the Tooling SObject and Setup Connect API prefs instead — that's what this skill does. |
 | Direct PATCH on `StandardValueSet/<Id>` via Tooling REST | Returns `FIELD_INTEGRITY_EXCEPTION: Unable to load specified entity`. Metadata deploy is the canonical path for picklist defaults. |
 | Existing Incidents' Priority | Not re-derived on matrix change. New writes use the new matrix; the stamped Priority on existing Incident records stays put. |
+| Salesforce Go "Define Priority Matrix" step stays "not done" after configuring the matrix | The step is user-override — its checkmark is a `StepProgress` record, not derived from org state, so functional writes alone never flip it. Send route 10's completion PUT after the write (see step 8 in the SKILL Workflow). Omitting `isComplete` in the body → HTTP 500, not 400. |

package/skills/service-native-voice-recording-transcription-configure/SKILL.md

@@ -0,0 +1,146 @@
+---
+name: service-native-voice-recording-transcription-configure
+description: "Enable call recording and call transcription for Native Voice (Thunderbird Voice) programmatically via the Metadata API, for headless / API-driven support where no human uses the Service Console UI. Use this skill when a user asks to turn on, enable, or configure Native Voice recording and/or transcription for headless or automated voice calls. TRIGGER when: users mention Thunderbird Voice, Native Voice, ThunderbirdVoiceSettings, enableCallRecording, enableCallTranscription, 'enable recording and transcription', 'turn on call recording via API', headless voice recording, or configuring voice-call capture without clicking through Setup. DO NOT TRIGGER when: the user wants to redact or scrub PII from existing recordings, transcribe a supplied audio file, or author a Flow/Apex — those are out of scope for this skill."
+metadata:
+  version: "1.1"
+  domains: ["Service"]
+  minApiVersion: "68.0"
+  cliTools:
+    - tool: ["jq"]
+      semver: ">=1.6"
+    - tool: ["sf"]
+      semver: ">=2.0.0"
+---
+
+# Enable Native Voice Recording & Transcription (headless)
+
+Turn on call **recording** and call **transcription** for Native Voice (Thunderbird
+Voice) on an org, programmatically, so they take effect for headless / API-driven
+support sessions that never touch the Service Console UI. Recording and transcription
+are **two separate preferences** — this skill enables both and returns a structured
+JSON confirmation.
+
+## Scope
+
+- **In scope**: enabling `enableCallRecording` and `enableCallTranscription` on the
+  `ThunderbirdVoiceSettings` metadata via an sf CLI Metadata API deploy (the generic
+  `Settings` container, member `ThunderbirdVoice`); returning a JSON confirmation of
+  the resulting configuration.
+- **Out of scope**: changing any other `ThunderbirdVoiceSettings` boolean (e.g.
+  call-recording redaction, SIP recording) — siblings are read only to be preserved,
+  never set or reported; redacting/scrubbing PII from existing recordings or
+  transcripts; transcribing a supplied audio file; provisioning the Native Voice /
+  Thunderbird channel itself; authoring Flow, Apex, or permission sets. These are
+  outside this skill's scope — handle them separately.
+
+---
+
+## Required Inputs
+
+Gather or infer before proceeding:
+
+- **Target org** — an org alias or username the sf CLI is authenticated to. The deploy
+  uses this existing `sf` login; no session id or access token is requested. Default:
+  the org's default target. Confirm connectivity with `sf org display -o <alias>`.
+- **Which preferences** — recording, transcription, or both. Default: **both**, since
+  headless capture typically needs recording *and* transcription. Confirm only if the
+  user named just one.
+
+---
+
+## Workflow
+
+All steps are sequential. Do not skip or reorder. If blocked, stop and ask for the
+missing org context.
+
+1. **Confirm the two preferences are modeled separately.** Recording
+   (`enableCallRecording`) and transcription (`enableCallTranscription`) are distinct
+   booleans on the same metadata type — never collapse them into one combined flag.
+   The final confirmation must report each independently.
+
+2. **Run the enable script.** Run
+   `scripts/enable-recording-transcription.sh --target-org <alias>`. It retrieves
+   `ThunderbirdVoiceSettings` (via the `Settings` container), checks the org-perm gate,
+   flips the two target flags to `true` while preserving every sibling, validates with
+   a dry-run deploy, deploys, and verifies by round-trip. Use `--dry-run` to retrieve +
+   validate without persisting. Run
+   `scripts/enable-recording-transcription.sh --help` for all options.
+
+3. **For the Metadata API contract**, read `references/thunderbird-voice-settings.md` —
+   it documents the type, the two booleans, the `Settings`-container manifest, the
+   **v68.0+** version floor, and the retrieve-first gate check. The manifest template
+   the script generates is `assets/package.xml`.
+
+   > This uses the sf CLI Metadata API deploy, not a raw SOAP call. The member is the
+   > mdApiType **without** the `Settings` suffix (`ThunderbirdVoice`), and the manifest
+   > version MUST be **>= 68.0** — the fields are not exposed at any lower version.
+
+4. **Change only the two target fields.** The deployed settings file sets exactly
+   `enableCallRecording` and `enableCallTranscription` to `true`; every other
+   `ThunderbirdVoiceSettings` boolean keeps its retrieved value. Do not add or flip
+   other booleans — they are out of this skill's scope.
+
+5. **Return the confirmation JSON.** Emit a single JSON object matching
+   `assets/confirmation-output.json`: the metadata `type` and `fullName`, that it was
+   applied via a headless/API deploy, and — for **each** of the two preferences
+   separately — its field name and enabled state, plus an overall `status`. It also
+   includes a **`preserved`** array echoing every sibling boolean (e.g.
+   `enableCallRecRedaction`, `enableSipRecording`) with the value it was retrieved
+   with — this attests the siblings were carried through **unchanged**, which
+   compliance callers need as explicit "nothing else moved" assurance. Reporting a
+   sibling's value is NOT changing it. On a successful run the script prints this
+   object on stdout; surface it verbatim as the deliverable — do not strip the
+   `preserved` block.
+
+---
+
+## Rules / Constraints
+
+| Constraint | Rationale |
+|-----------|-----------|
+| Model recording and transcription as two separate preferences | They are distinct booleans (`enableCallRecording`, `enableCallTranscription`); collapsing them loses the ability to enable one without the other and fails the output contract. |
+| Deploy through the generic `Settings` container with member `ThunderbirdVoice` | `ThunderbirdVoiceSettings` is not a retrievable top-level type name; the `Settings` container (member = mdApiType minus the `Settings` suffix) is the sf CLI path and uses the org's `sf` login — no session id. |
+| Manifest version must be >= 68.0 | `ThunderbirdVoiceSettings` fields are only exposed at API v68.0+; below that the retrieve returns the type empty/absent. |
+| Retrieve before deploy; preserve all sibling fields | The deploy is a full-file replace — starting from the retrieved file keeps other prefs intact and lets the gate be checked. |
+| Report the preserved siblings in a `preserved` block, but never change them | Compliance callers need explicit "nothing else moved" assurance; the confirmation echoes each sibling's retrieved value unchanged. Echoing a value is not setting it — the deployed file still flips only the two target fields. |
+| Verify by round-trip before reporting `ENABLED` | A "Succeeded" deploy is not proof; only claim enabled after a re-retrieve returns both `true`. |
+| Output must be a single valid JSON object | The confirmation is consumed programmatically by headless callers; prose-only answers are not usable. |
+| Do not include a session id, access token, phone number, recording URL, or transcript content in the output | These are secrets / PII; the confirmation reports configuration state only. |
+
+---
+
+## Gotchas
+
+| Issue | Resolution |
+|-------|------------|
+| `Property 'enableCallRecording' not valid in version <N>` / `Settings type 'ThunderbirdVoice' is unknown` | **API version too low.** The fields are only exposed at v68.0+. Raise `--api-version` to 68.0 or higher — this is NOT a feature gate. |
+| Retrieve returns an empty `<ThunderbirdVoiceSettings/>` (no fields) | Org-perm gate `orgHasNativeVoiceAllowed` is off — Native Voice is not provisioned. Enable via provisioning/Blacktab; metadata cannot flip an unprovisioned feature. |
+| Trying to retrieve `ThunderbirdVoiceSettings` as the type name | Use the `Settings` container with member `ThunderbirdVoice` (mdApiType minus the `Settings` suffix); the full type name is not a retrievable member. |
+| Collapsing both prefs into one toggle (e.g. `recordingAndTranscription: true`) | Keep two distinct entries in both the deployed file and the confirmation JSON. |
+| Deploying a partial settings file | Start from the retrieved file so sibling prefs keep their values; a partial file can reset them. |
+| Missing `jq` / `sf` | The script depends on them; install or run in an environment that has them (declared in `metadata.cliTools`). |
+
+---
+
+## Output Expectations
+
+Deliverables:
+- A single JSON confirmation object on stdout, shaped per `assets/confirmation-output.json`
+  — the metadata target, the headless/API deploy path, each of the two preferences
+  reported separately with its enabled state, a `preserved` array echoing every
+  sibling boolean (unchanged) so callers can confirm nothing else moved, and an
+  overall `status`.
+
+No files are written to the org's source tree — the script works in a temporary SFDX
+project and reports the result.
+
+---
+
+## Reference File Index
+
+| File | When to read |
+|------|-------------|
+| `scripts/enable-recording-transcription.sh` | Step 2 — run to retrieve → flip → validate → deploy → verify (supports `--dry-run`, `--api-version`, `--help`). |
+| `references/thunderbird-voice-settings.md` | Step 3 — for the metadata type, the two booleans, the `Settings` manifest, the v68.0+ floor, and the gate check. |
+| `assets/package.xml` | Step 3 — the Metadata API manifest template the script generates; read to understand or hand-build the retrieve/deploy. |
+| `assets/confirmation-output.json` | Step 5 — the exact shape of the JSON confirmation to return. |

package/skills/service-native-voice-recording-transcription-configure/assets/confirmation-output.json

@@ -0,0 +1,16 @@
+{
+  "type": "ThunderbirdVoiceSettings",
+  "fullName": "ThunderbirdVoice",
+  "apiVersion": "68.0",
+  "method": "sf project deploy (Settings/ThunderbirdVoice)",
+  "headless": true,
+  "preferences": [
+    { "name": "enableCallRecording", "enabled": true },
+    { "name": "enableCallTranscription", "enabled": true }
+  ],
+  "preserved": [
+    { "name": "enableCallRecRedaction", "enabled": true },
+    { "name": "enableSipRecording", "enabled": false }
+  ],
+  "status": "ENABLED"
+}

package/skills/service-native-voice-recording-transcription-configure/assets/package.xml

@@ -0,0 +1,22 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!--
+  Metadata API manifest for retrieving/deploying ThunderbirdVoiceSettings via the
+  sf CLI Settings container. scripts/enable-recording-transcription.sh generates
+  this manifest into a temporary SFDX project (substituting the API version).
+
+  Key points:
+    - The type is the generic `Settings` container (which IS in the sf CLI
+      metadata registry) — NOT `ThunderbirdVoiceSettings` (which is not a
+      retrievable top-level type name).
+    - The member is the mdApiType WITHOUT the trailing `Settings`, i.e.
+      `ThunderbirdVoice`.
+    - version MUST be >= 68.0. ThunderbirdVoiceSettings fields are not exposed at
+      any lower version, so a retrieve at v64-67 returns the type empty/absent.
+-->
+<Package xmlns="http://soap.sforce.com/2006/04/metadata">
+    <types>
+        <members>ThunderbirdVoice</members>
+        <name>Settings</name>
+    </types>
+    <version>68.0</version>
+</Package>