@salesforce/afv-skills 1.63.0 → 1.65.0

package/skills/industries-home-health-guided-setup-enable-org-fsl-get/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: industries-home-health-guided-setup-enable-org-fsl-get
+description: "Enable Home Health plus its Field Service (FSL) dependency on a Health Cloud org — the org-preference toggle cascade, Chatter precondition, and FSL settings/ESO follow-on toggles. Triggers on \"enable Home Health\", \"turn on Home Health\", or as a delegation target from `home-health-guided-setup` Phase 0. The master toggle itself and the FSL package install are each delegated further, not re-derived here."
+metadata:
+  version: "1.0"
+---
+
+# Home Health — Enable Org + Field Service Dependency
+
+Child skill extracted from `home-health-guided-setup` Phase 0 (`[metadata — automate the toggles; Field Service package install is a genuine manual hand-off]`). Covers Group 1 (`GroupSalesforceFieldServiceSetup`) steps 1–3 verbatim. Every step below shows both its org link and its resolved help-doc link — full per-step table (all 75 steps, all 16 groups) lives in the parent skill's setup-and-labels reference; the links here are copied from there, not re-derived.
+
+## Session state (scoped to this skill)
+
+- `org_alias` — which org this run targets (confirm explicitly, never assume).
+- `step_status[1..7]` — per-step status for this phase's 7 steps, reported back to the caller as a single `phase_complete` boolean once all are terminal.
+
+**Org-Id independence (NON-NEGOTIABLE):** every Id this skill writes or compares against must be resolved fresh, on the current target org, at runtime — never carried over from a reference doc, a prior run, or a different org. The only exceptions are genuine platform-fixed literals (`DeveloperName`s, FQNs, enum values) that are the same on every org by construction.
+
+## Steps
+
+1. **Discover current state first**: query `IndustriesSettings.IsHomeHealthEnabled` via Tooling API before assuming anything needs to change.
+2. **Chatter precondition**: if off, retrieve the full `ChatterSettings` metadata body, deploy it back with only `enableChatter` flipped (never a bare single-field payload — other Chatter fields can silently reset to defaults on a partial deploy), verify via Tooling read-back.
+3. **Enable Home Health — delegate to the master-toggle SOR, do not re-author it here.** This step **`delegates_to: health-cloud-revan/HomeHealthSettings`** (the standard Setup-page leaf SOR; use `health-cloud-renegade/HomeHealthSettingsLSC` instead when the org drives the toggle through the Lightning Setup Component). That SOR owns the enable itself — it drives the Home Health setup page's toggle action, which cascades the full FSL preference chain (`FieldServiceEnabled → OptimizationServiceAccess → O2EngineEnabled → HomeHealthEnabled → RescheduleAll`) and re-reads to confirm, which is strictly more complete than a bare `IndustriesSettings.enableHomeHealth` metadata flip. Invoke it, don't inline the toggle logic — this skill deliberately reuses that leaf SOR rather than duplicating (and drifting from) its cascade. Fallback only if that SOR is unavailable at runtime: `IndustriesSettings.enableHomeHealth = true` via Metadata deploy, verified via Tooling.
+4. **Install the Field Service managed package.** This step **`delegates_to: health-cloud-revan/home-health-install-fsl-package`** — invoke it rather than re-deriving the detect/primary-install/secondary-recipe/manual-fallback logic inline (it's a reusable, generalized pattern, not specific to this phase). Treat its `installed` return as satisfying this step. On `in-progress` (install accepted, takes ~20-30 min; NOT a failure) return control to the caller with `phase_complete: false` / blocking step 4 so it can start Phase 13 (`home-health-guided-setup-agentforce-setup`) while the install runs; the caller re-checks FSL at safe points and, once `FSL` is confirmed, resumes this phase at **step 5** (then 6, 7). On `awaiting-manual`, surface the Salesforce Go hand-off, keep Phase 13 / non-FSL work going, and keep re-polling the detect query.
+5. **Enable Digital Experience (`CommunitiesSettings.enableNetworksEnabled` + `enableOotbProfExtUserOpsEnable`) — MANDATORY, promoted from an optional downstream toggle.** **Enable only — do NOT create or build a site here** (the Experience Cloud site is built later in Phase 10). Deploy via Metadata API (`settings/Communities.settings` + a `Settings`-type `package.xml` member `Communities`); verify by querying `SELECT COUNT() FROM Network` — `INVALID_TYPE` means it did NOT take, a count (even 0) means it did. **This is now a hard gate, same tier as step 4 (FSL), not a "nice to have ahead of the Patient App phase":** `home-health-guided-setup-get-org-ready` will not run User creation (2a) or license/permission-set assignment (2b) until both this step and step 4 report done — confirmed necessary live: a Customer Community (portal) User cannot be created while `Network` is `INVALID_TYPE`, and some permission sets (e.g. the FSL-gated Scheduler sets) only make sense once FSL is actually installed, so running user/permission-set work ahead of these two toggles produces partial, re-work-requiring state.
+6. **FSL settings cascade**: once FSL is confirmed installed (step 4 returned `installed`), deploy `FieldServiceSettings.fieldServiceOrgPref = true` (a separate Metadata object from `IndustriesSettings` — don't conflate them), verify. Wizard step `ChangeFSLSettings` (`action.type: ButtonNavigate`) — org link: `/lightning/setup/FieldServiceSettings/home`; help doc: https://sfdc.co/HomeHealthFieldServiceSettings. Surface both even though this write is automated, so the admin can review the setting directly if they want.
+7. **Enable Enhanced Scheduling and Optimization** — wizard step `EnableESO` (`action.type: ButtonNavigate`) — org link: `/lightning/setup/FieldServiceSettings/home`; help doc: https://sfdc.co/HomeHealthEnhancedSchedulingOptimization ("Show Me How" style link — more procedural than the "Learn More" links elsewhere).
+8. Optional downstream toggles surfaced by live setup runs (confirm relevance before enabling — not every org needs every one): `IndustriesPricingSettings`, `RevenueManagementSettings.enableCoreCPQ`, `EinsteinGptSettings.enableEinsteinGptPlatform` (only once real Agentforce/Einstein agents are in play), Context Service access (`PUT /connect/contextservice/access/contextServiceEnabled/contextServiceEnabled` — Connect API, not Metadata). **`QuoteSettings.enableQuote` is NOT optional once Phase 11 (Budget) is in scope** — it's a hard prerequisite for the Budget container's Quote tab; enable it here proactively on any full "set up Home Health" run rather than waiting for the Budget phase to discover it's missing.
+   - **Work Order Billing enablement** now lives in Phase 11 step 3 (`3b. EnableBilling`, alongside `EnablePricing`) in `home-health-guided-setup` — not here.
+
+## Return contract (for callers delegating to this skill)
+
+Report back `phase_complete: true` once steps 1-8 are each in a terminal state (done / delegated-done / deferred-manual per the parent skill's terminal-state contract), or `phase_complete: false` with the specific blocking step (most commonly step 4 FSL `in-progress` / awaiting the manual hand-off, or step 5 for Digital Experience) so the caller can decide whether to keep running other non-dependent phases in parallel. **Steps 4 and 5 together are the gate `home-health-guided-setup-get-org-ready` checks before running User creation or license/permission-set assignment** — report their status distinctly, don't fold them into a single boolean.
+
+## Companion references
+
+- `health-cloud-revan/home-health-guided-setup-agentforce-setup` — Phase 13 — Agentforce/Einstein enablement and Home Health agent build.
+- `health-cloud-revan/home-health-guided-setup-get-org-ready` — Phase 2 orchestrator (sub-steps 2a-2f).
+- `health-cloud-revan/home-health-guided-setup` — the root orchestrator (full 16-group Home Health wizard) that delegates to this skill.
+- `health-cloud-revan/home-health-install-fsl-package` — leaf — FSL managed-package install (Tooling API → Setup Discovery recipe → Salesforce Go).
+- `health-cloud-revan/HomeHealthSettings` — leaf SOR — the Home Health master toggle (standard Setup page).
+- `health-cloud-renegade/HomeHealthSettingsLSC` — leaf SOR — the master toggle, Lightning Setup Component variant.
+
+<!-- skill-validate: ignore-start -->
+<!-- codey:operations start -->
+## Operations Reference
+
+Operations this skill uses — routing and dependency reference.
+
+| Operation | Purpose | Status | Call | Depends on |
+|-----------|---------|--------|------|------------|
+| `enable-home-health` | delegate | — | → `health-cloud-revan/HomeHealthSettings` | — |
+| `delegate-install-fsl-package` | delegate | — | → `health-cloud-revan/home-health-install-fsl-package` | — |
+<!-- codey:operations end -->
+<!-- skill-validate: ignore-end -->

package/skills/industries-home-health-guided-setup-get-org-ready-get/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: industries-home-health-guided-setup-get-org-ready-get
+description: "Get a Health Cloud org ready to use Home Health — users/licenses, entity label suggestions, the WorkOrder record type, and the default scheduling + bundling policies. Mid-level orchestrator: delegates each lettered sub-step to its own leaf skill rather than inlining them. Triggers on \"get the org ready for Home Health\", or as a delegation target from `home-health-guided-setup` Phase 2."
+metadata:
+  version: "1.0"
+---
+
+# Home Health — Get Your Org Ready (Phase 2 orchestrator)
+
+Mid-level orchestrator extracted from `home-health-guided-setup` Phase 2 (`[mixed — see per-step tags]`). Covers Group 2 (`GroupGetYourOrgReady`) steps 1–5. Per-step org link + help link (all confirmed literal, from the Home Health setup page's own labels) lives in the parent skill's setup-and-labels reference.
+
+Each lettered sub-step below is independent enough (different mechanism, different data shape) to be its own dispatchable skill — this orchestrator's only job is to sequence the delegated calls and reconcile their returns into one `phase_complete` signal, not to re-derive any of their logic.
+
+## Steps (each a delegation, not inline logic)
+
+1. **2a — User creation.** `delegates_to: health-cloud-revan/home-health-create-users`. Prerequisite, not a native wizard step — several steps below need a real User Id from this one's return. **Gated: requires `home-health-guided-setup-enable-org-fsl` steps 4 (FSL installed) and 5 (Digital Experience enabled) both terminal before this runs** — confirmed live that running user creation ahead of either produces rework (a Customer Community/portal User can't be created while Digital Experience is off, and personas needing FSL-gated permission sets end up getting assigned those sets late in 2b anyway). If either is still pending, defer 2a (and therefore 2b) and keep running the FSL-independent sub-steps (2c, 2d) in the meantime.
+2. **2b — Assign Licenses.** `delegates_to: health-cloud-revan/home-health-assign-licenses`. Run after 2a; pass along any User Ids 2a resolved so this doesn't re-discover them. Same FSL + Digital Experience gate as 2a (it inherits the gate transitively — if 2a was deferred, 2b is too).
+3. **2c — Update Labels.** `delegates_to: health-cloud-revan/home-health-update-entity-labels`. Independent of 2a/2b/2d/2e/2f — optional, cosmetic, can run in any order relative to the others.
+4. **2d — Create Record Type.** `delegates_to: health-cloud-revan/home-health-create-work-order-record-type`. Independent of every other sub-step in this phase — fully automatable, no customer context needed, safe to run first in Sweep 1.
+5. **2e — Create Scheduling Policy.** `delegates_to: health-cloud-revan/home-health-create-scheduling-policy`. Requires FSL installed (`home-health-install-fsl-package`, called from `home-health-guided-setup-enable-org-fsl`) — if that hasn't completed yet, defer this sub-step and keep running the others.
+6. **2f — Create Bundling Policy.** `delegates_to: health-cloud-revan/home-health-create-bundling-policy`. Same FSL prerequisite as 2e; independent of 2e otherwise (different object, no shared fields).
+
+## Sequencing notes
+
+- 2d is the only sub-step with zero dependencies and zero customer input — run it first regardless of what else is pending.
+- **2a and 2b both gate on `home-health-guided-setup-enable-org-fsl` steps 4 (FSL) AND 5 (Digital Experience) being terminal — check both before creating any User or assigning any permission set/license, not just before 2e/2f.** If either is still pending, run 2c/2d now and defer 2a/2b until both land.
+- 2a → 2b have a real order dependency (2b needs 2a's User Ids); the rest don't depend on each other.
+- 2e and 2f gate on FSL being installed (step 4 only — they don't need Digital Experience) — if `home-health-guided-setup-enable-org-fsl` reports `phase_complete: false` (FSL still awaiting manual install), run 2c/2d now and defer 2a/2b/2e/2f, don't block the whole phase on FSL.
+
+## Return contract (for callers delegating to this skill)
+
+Report back a per-sub-step ledger (`2a`..`2f` → done / awaiting-data / deferred-manual / blocked-on-fsl) and a single `phase_complete` boolean (true only once every sub-step is in a terminal state).
+
+## Companion references
+
+- `health-cloud-revan/home-health-assign-licenses` — Phase 2b leaf — license and permission-set assignment.
+- `health-cloud-revan/home-health-create-bundling-policy` — Phase 2f leaf — bundling policy.
+- `health-cloud-revan/home-health-create-scheduling-policy` — Phase 2e leaf — scheduling policy.
+- `health-cloud-revan/home-health-create-users` — Phase 2a leaf — user creation.
+- `health-cloud-revan/home-health-create-work-order-record-type` — Phase 2d leaf — Work Order record type.
+- `health-cloud-revan/home-health-guided-setup-enable-org-fsl` — Phase 0 — enable Home Health, FSL package, Digital Experience, FSL settings/ESO.
+- `health-cloud-revan/home-health-guided-setup` — the root orchestrator (full 16-group Home Health wizard) that delegates to this skill.
+- `health-cloud-revan/home-health-install-fsl-package` — leaf — FSL managed-package install (Tooling API → Setup Discovery recipe → Salesforce Go).
+- `health-cloud-revan/home-health-update-entity-labels` — Phase 2c leaf — entity label updates.
+
+<!-- skill-validate: ignore-start -->
+<!-- codey:operations start -->
+## Operations Reference
+
+Operations this skill uses — routing and dependency reference.
+
+| Operation | Purpose | Status | Call | Depends on |
+|-----------|---------|--------|------|------------|
+| `delegate-create-work-order-record-type` | delegate | — | → `health-cloud-revan/home-health-create-work-order-record-type` | — |
+| `delegate-update-entity-labels` | delegate | — | → `health-cloud-revan/home-health-update-entity-labels` | — |
+| `delegate-create-users` | delegate | — | → `health-cloud-revan/home-health-create-users` | — |
+| `delegate-assign-licenses` | delegate | — | → `health-cloud-revan/home-health-assign-licenses` | — |
+| `delegate-create-scheduling-policy` | delegate | — | → `health-cloud-revan/home-health-create-scheduling-policy` | — |
+| `delegate-create-bundling-policy` | delegate | — | → `health-cloud-revan/home-health-create-bundling-policy` | — |
+<!-- codey:operations end -->
+<!-- skill-validate: ignore-end -->

package/skills/industries-home-health-licenses-assign/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: industries-home-health-licenses-assign
+description: "Assign Home Health permission-set licenses to the right Users. Triggers on \"assign Home Health licenses\", or as a delegation target from `home-health-guided-setup-get-org-ready` (Phase 2b)."
+metadata:
+  version: "1.0"
+---
+
+# Home Health — Assign Licenses
+
+Child skill extracted from `home-health-guided-setup` Phase 2b (`[data — ask which licenses go to which users]`).
+
+Wizard step `AssignLicenses` (`action.type: Manual` — the wizard itself only self-attests, it has no in-app assignment UI of its own). Help doc: https://sfdc.co/HomeHealthLicenses (Starter-edition orgs get a separate article instead: https://help.salesforce.com/s/articleView?id=ind.lsc_home_health.htm — check org edition before choosing which link to hand the admin).
+
+**Prerequisite gate (check before assigning any license/permission set): FSL installed AND Digital Experience enabled.** Same gate as `home-health-create-users` — confirmed live that FSL-gated permission sets (e.g. the Field Service Call Center Rep/Dispatcher/Integration sets) should only be assigned once FSL is actually installed, and some assignments depend on a persona that itself required Digital Experience to exist. Verify both via `home-health-guided-setup-enable-org-fsl` steps 4 and 5 before proceeding.
+
+Discover available `PermissionSetLicense` records and existing Users via query; ask the admin which licenses go to which users — never invent the mapping. If `home-health-create-users` has already run this session, use its returned User Ids rather than re-discovering. Assign via `PermissionSetLicenseAssign` (license) and `PermissionSetAssignment` (permission set) — both standard REST-createable. Org link for manual review: `/lightning/setup/ManageUsers/home` → user detail → Permission Set License Assignments related list.
+
+## Return contract (for callers delegating to this skill)
+
+Report back which User → license/permission-set assignments were created, and any the admin deferred.
+
+## Companion references
+
+- `health-cloud-revan/home-health-create-users` — Phase 2a leaf — user creation.
+- `health-cloud-revan/home-health-guided-setup-enable-org-fsl` — Phase 0 — enable Home Health, FSL package, Digital Experience, FSL settings/ESO.
+- `health-cloud-revan/home-health-guided-setup-get-org-ready` — Phase 2 orchestrator (sub-steps 2a-2f).
+- `health-cloud-revan/home-health-guided-setup` — the root orchestrator (full 16-group Home Health wizard) that delegates to this skill.

package/skills/industries-home-health-operating-hours-create/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: industries-home-health-operating-hours-create
+description: "Discover or create an OperatingHours record for a Home Health coverage calendar, then define its TimeSlot rows. Triggers on \"create Home Health operating hours\", \"set up coverage schedule\", or as a delegation target from `home-health-guided-setup-care-and-skill-setup` (Phase 3 steps 2-3)."
+metadata:
+  version: "1.0"
+---
+
+# Home Health — Create Operating Hours
+
+Child skill extracted from `home-health-guided-setup` Phase 3 steps 2 (`CreateOperatingHours`) and 3 (`UpdateOperatingHours`), kept together because step 3 edits the record step 2 creates — not two independently dispatchable steps. `[data]`.
+
+Org links: `OperatingHours` new-record page (help: https://sfdc.co/HomeHealthOperatingHours), then `/lightning/o/OperatingHours/home` to add time slots (help: https://sfdc.co/HomeHealthAddSlots).
+
+Follow the shared **`sfs-sobject-create` customer-context pattern** — this step **`delegates_to: sfs-setup-experience/sfs-sobject-create`**: discover existing reusable calendars first (a typical org already has generic ones like "Base Calendar"/"Gold Appointments Calendar") before creating a new one. Never invent a timezone or schedule — ask.
+
+**Step 1 — create the calendar.** Proven payload (replay with real values):
+```text
+POST {INST}/services/data/{API}/sobjects/OperatingHours
+{ "Name":"<CALENDAR_NAME>", "TimeZone":"<IANA_TZ>" }
+```
+`TimeZone` must be a real IANA id (e.g. `America/Denver`) — ask the customer their site timezone, never default it.
+
+**Step 2 — add TimeSlot rows (one per day-of-week block), child of the OperatingHours just created or discovered:**
+```text
+POST {INST}/services/data/{API}/sobjects/TimeSlot
+{ "OperatingHoursId":"<LOOKUP:OperatingHours.Id>", "DayOfWeek":"Monday",
+  "StartTime":"09:00:00.000Z", "EndTime":"17:00:00.000Z", "Type":"Normal" }
+```
+**GOTCHA: `StartTime`/`EndTime` are time-of-day in UTC** (`…Z` suffix) — the platform stores the wall-clock slot against the OperatingHours' own `TimeZone`; the `Z` is the accepted serialization, not a UTC conversion of the local time. `Type:"Normal"` is **FIXED**. One row per day (or per sub-block if the customer splits the day) — ask for the real coverage schedule, don't assume Mon-Fri 9-5.
+
+## Return contract (for callers delegating to this skill)
+
+Report back the OperatingHours Id (existing or newly created) and the TimeSlot rows written, keyed by calendar name, so `home-health-create-service-territory` can reference it.
+
+## Companion references
+
+- `health-cloud-revan/home-health-guided-setup-care-and-skill-setup` — combined Phase 3 + Phase 4 orchestrator.
+- `health-cloud-revan/home-health-create-service-territory` — Phase 3 leaf — ServiceTerritory.
+- `health-cloud-revan/home-health-guided-setup` — the root orchestrator (full 16-group Home Health wizard) that delegates to this skill.
+- `sfs-setup-experience/sfs-sobject-create` — the canonical entity-create pattern (describe → query-existing → create).

package/skills/industries-home-health-scheduling-policy-create/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: industries-home-health-scheduling-policy-create
+description: "Create Home Health's default Field Service scheduling policy via the Connect API admin-setup-step-action executor, with its fixed platform defaults presented before writing. Triggers on \"create Home Health scheduling policy\", or as a delegation target from `home-health-guided-setup-get-org-ready` (Phase 2e)."
+metadata:
+  version: "1.0"
+---
+
+# Home Health — Create Scheduling Policy
+
+Child skill extracted from `home-health-guided-setup` Phase 2e (`[metadata — wizard's own action is a fixed-default create; present before writing]`).
+
+Public doc (literal URL, confirmed via Custom Label, not a key needing further lookup): `https://sfdc.co/HomeHealthDefaultSchedulingRules`.
+
+**This is not a standard-object create.** The wizard step (`action.type: LaunchComponent`, `resource: {"name": "healthcloud:createHHSchedulingPolicyModal"}`) dispatches through the Connect API (`POST /connect/industries/executeAdminSetupStepAction`, the admin-setup-step-action resource) to the server-side scheduling-policy creator. That creator:
+
+1. Checks existence first (`execute()` queries for a `{namespace}__Scheduling_Policy__c` — the **FSL-package-namespaced** custom object, e.g. `SVMXC__Scheduling_Policy__c`, NOT the standard `AppointmentSchedulingPolicy` sObject — named via `LC.getLabel("HHDefaultSchedulingPolicy","SchedulingPolicyName")`, a fixed Custom Label value = "Home Health Default Scheduling Policy"). If found, tell the admin it already exists and skip.
+2. If absent, creates it with **fixed, non-negotiable platform defaults** — `Name`="Home Health Default Scheduling Policy", `Description`=fixed Custom Label text, `Fix_Overlaps__c=true`, `Daily_Optimization__c=true`, `Commit_Mode__c="AlwaysCommit"` — then links a fixed, hardcoded set of `Work_Rule__c` records (Active Resources, Match Skills, Match Territory, Required Service Resource, Excluded Resources, Resource Availability, Scheduled End, Scheduled Start, Service Appointment Visiting Hours, Service Crew Resources Availability) and `Service_Goal__c` records (Preferred Service Resource — weighted 10, ASAP/Resource Priority/Skill Level — weighted 1 each) that must already exist in the org (standard FSL package content — requires `home-health-install-fsl-package` to have run first).
+
+None of these values are a business decision — the wizard itself doesn't ask the admin anything, it just creates. Per the show-defaults-then-create pattern (below), present this exact field/value list to the admin before calling the executor, since it's writing real records even though the values are fixed:
+> "Home Health's Create Scheduling Policy step creates a Field Service scheduling policy named 'Home Health Default Scheduling Policy' with these fixed settings: Fix Overlaps = on, Daily Optimization = on, Commit Mode = Always Commit, plus the standard Home Health work-rule and goal set. These are Salesforce's platform defaults, not something that varies by org — I'll create it as-is unless you want something different. Proceed?"
+
+If the admin wants different rules/weights than the platform defaults (a real business choice), don't fight the wizard's fixed-value bean — after the default policy exists, editing `{namespace}__Scheduling_Policy__c` and its junction records directly via standard REST is a separate, valid path; ask what they want changed and treat that as a normal `ask` follow-up, distinct from this step's own automation.
+
+**This step is complete once the named policy record exists — there is NO separate "select the default policy in Field Service Settings" action.** Home Health's flows resolve the policy by its fixed name ("Home Health Default Scheduling Policy") via the `HHDefaultSchedulingPolicy` Custom Label, not by an org-level "default policy" pointer. `FieldServiceSettings` / `FSL__Logic_Settings__c` carry no default-scheduling-policy field to set (confirmed live: no `IsDefault` on the policy object; the FSL settings custom objects are not Data-API-writable for this purpose). Do **not** direct the admin to Field Service Settings to "pick the default" after creating the policy, and do not treat the step as pending on that — creating the record is the entire step. (Bundling is separate — that's `home-health-create-bundling-policy`'s `ApptBundlePolicy`, not this policy.)
+
+Separately: the standard `AppointmentSchedulingPolicy` sObject (keyPrefix `0Vr`) also exists and is independently REST-creatable (`POST /sobjects/AppointmentSchedulingPolicy`) — but it is a **different object** from what this wizard step produces. Don't conflate the two; only use the standard object if the admin is deliberately configuring generic Field Service appointment scheduling policies, not this Home Health wizard step.
+
+## Show-defaults-then-create pattern
+
+Whenever a step has fixed platform default values AND real customer-specific fields in the same create, don't silently pick one path. Discover what the admin has already said this session, present the platform defaults for the rest explicitly, and let the admin confirm or override before the write happens — never create first and explain after. This is stricter than plain `ask` (which has no default to show) and stricter than plain `automate` (which never shows a choice) — it's its own third shape: **present-then-create**. (`home-health-create-bundling-policy` uses the same pattern.)
+
+## Return contract (for callers delegating to this skill)
+
+Report back the policy record's Id (existing or newly created), or `blocked: FSL not installed` if the prerequisite package/work-rule/goal records aren't present yet.
+
+## Companion references
+
+- `health-cloud-revan/home-health-create-bundling-policy` — Phase 2f leaf — bundling policy.
+- `health-cloud-revan/home-health-guided-setup-get-org-ready` — Phase 2 orchestrator (sub-steps 2a-2f).
+- `health-cloud-revan/home-health-guided-setup` — the root orchestrator (full 16-group Home Health wizard) that delegates to this skill.
+- `health-cloud-revan/home-health-install-fsl-package` — leaf — FSL managed-package install (Tooling API → Setup Discovery recipe → Salesforce Go).

package/skills/industries-home-health-service-objective-create/SKILL.md

@@ -0,0 +1,22 @@
+---
+name: industries-home-health-service-objective-create
+description: "Guide creation of a Home Health service/scheduling objective — manual, navigation-only wizard step. Triggers on \"create Home Health service objective\", or as a delegation target from `home-health-guided-setup-care-and-skill-setup` (Phase 4 step 3)."
+metadata:
+  version: "1.0"
+---
+
+# Home Health — Create Service Objective
+
+Child skill extracted from `home-health-guided-setup` Phase 4 step 3 (`CreateServiceObjective`, `[data]`). Wizard step `action.type: ButtonNavigate`; org link: `/lightning/o/FSL__Service_Goal__c/home`; help doc: https://sfdc.co/HomeHealthServiceObjectives.
+
+**No proven direct-create payload is captured for this step** — unlike the other Phase 3/4 steps, the execution playbook doesn't carry a confirmed `FSL__Service_Goal__c` field shape (the wizard button is navigation-only). Hand off with both links; if the admin wants this automated rather than done by hand in the UI, describe `FSL__Service_Goal__c` first (`GET /sobjects/FSL__Service_Goal__c/describe`) and derive required fields the same way `sfs-sobject-create` would, rather than guessing a payload — don't invent field names from the other Phase 4 steps' shapes, this object's required fields haven't been confirmed live.
+
+## Return contract (for callers delegating to this skill)
+
+Report back the objective record's Id if created, or `deferred-manual` with both links if the admin is completing this by hand.
+
+## Companion references
+
+- `health-cloud-revan/home-health-guided-setup-care-and-skill-setup` — combined Phase 3 + Phase 4 orchestrator.
+- `health-cloud-revan/home-health-guided-setup` — the root orchestrator (full 16-group Home Health wizard) that delegates to this skill.
+- `sfs-setup-experience/sfs-sobject-create` — the canonical entity-create pattern (describe → query-existing → create).

package/skills/industries-home-health-skills-create/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: industries-home-health-skills-create
+description: "Discover or create Home Health Skill records (clinical, language, or other) via the Data API. Triggers on \"create Home Health skills\", \"add a skill\", or as a delegation target from `home-health-guided-setup-care-and-skill-setup` (Phase 4 step 4)."
+metadata:
+  version: "1.0"
+---
+
+# Home Health — Create Skills
+
+Child skill extracted from `home-health-guided-setup` Phase 4 step 4 (`CreateSkills`, `[data]`). Org link: `/lightning/setup/SkillPage/home`; help doc: https://sfdc.co/HomeHealthSkills.
+
+**API endpoint gotcha: `Skill` is created via the DATA API** (`POST /sobjects/Skill`) — the opposite endpoint from `SkillType` (`home-health-create-skill-type`, Tooling API). A `Skill` create against Tooling 404s; `Skill` is `INVALID_TYPE` on the Data-API *query* path but is createable there.
+
+```text
+POST {INST}/services/data/{API}/sobjects/Skill
+{ "MasterLabel":"<SKILL_NAME>", "DeveloperName":"<Skill_Api>" }
+```
+
+Ask for real skill names, never invent (e.g. don't assume "Wound Care" or "French Speaking" unless the admin says so) — this applies equally to clinical skills and language/other SkillType-categorized skills. If `home-health-create-skill-type` created a category for this skill, confirm via Describe whether `Skill` carries a lookup to it before assuming one exists — don't invent the field name.
+
+## Return contract (for callers delegating to this skill)
+
+Report back the Skill Id(s) (existing or newly created), keyed by skill name, so `home-health-link-service-resource-skill` and `home-health-create-skill-requirement` can reference them.
+
+## Companion references
+
+- `health-cloud-revan/home-health-guided-setup-care-and-skill-setup` — combined Phase 3 + Phase 4 orchestrator.
+- `health-cloud-revan/home-health-create-skill-requirement` — Phase 4 leaf — SkillRequirement.
+- `health-cloud-revan/home-health-create-skill-type` — Phase 4 leaf — SkillType (optional).
+- `health-cloud-revan/home-health-guided-setup` — the root orchestrator (full 16-group Home Health wizard) that delegates to this skill.
+- `health-cloud-revan/home-health-link-service-resource-skill` — Phase 4 leaf — ServiceResourceSkill link.

package/skills/industries-home-health-users-create/SKILL.md

@@ -0,0 +1,29 @@
+---
+name: industries-home-health-users-create
+description: "Discover or create the Users needed before Home Health license/permission assignment can reference a real User Id. Triggers on \"create Home Health users\", \"set up users for Home Health\", or as a delegation target from `home-health-guided-setup-get-org-ready` (Phase 2a)."
+metadata:
+  version: "1.0"
+---
+
+# Home Health — User Creation (prerequisite)
+
+Child skill extracted from `home-health-guided-setup` Phase 2a. Not a native wizard step — several downstream steps (license assignment, portal-account ownership) need a real User Id.
+
+**Prerequisite gate (check before creating any User): FSL installed AND Digital Experience enabled.** Confirmed live that creating Users ahead of either produces rework — a Customer Community/portal persona can't be created while `Network` is `INVALID_TYPE` (Digital Experience off), and FSL-dependent personas end up needing their permission sets assigned late by `home-health-assign-licenses` anyway. Verify both via `home-health-guided-setup-enable-org-fsl` steps 4 and 5 (or re-check directly: FSL via the `InstalledSubscriberPackage` detect query, Digital Experience via `SELECT COUNT() FROM Network` not throwing `INVALID_TYPE`) before proceeding. If a specific persona being created doesn't need either (e.g. an internal Clinician), it's still worth confirming both org-wide first rather than discovering a gap mid-batch.
+
+`[data — ask]`: discover existing Users first (`GET /sobjects/User` query scoped to relevant profiles); only create new Users if the admin confirms new personas are needed. Never invent names/emails/usernames.
+
+Known gotcha: the target Account's owner must have a `UserRole` assigned, or `User` creation for a portal-account-owner persona fails. Fix in order: create the `UserRole` first, assign it to the Account owner, then create the User.
+
+Org link for manual user creation if the admin prefers the UI: `/lightning/setup/ManageUsers/home`. (Not a native wizard step, so the wizard offers no help link of its own — this link is standard Setup navigation.)
+
+## Return contract (for callers delegating to this skill)
+
+Report back the resolved User Id(s) (existing or newly created) keyed by persona, so `home-health-assign-licenses` can reference them without re-discovering.
+
+## Companion references
+
+- `health-cloud-revan/home-health-assign-licenses` — Phase 2b leaf — license and permission-set assignment.
+- `health-cloud-revan/home-health-guided-setup-enable-org-fsl` — Phase 0 — enable Home Health, FSL package, Digital Experience, FSL settings/ESO.
+- `health-cloud-revan/home-health-guided-setup-get-org-ready` — Phase 2 orchestrator (sub-steps 2a-2f).
+- `health-cloud-revan/home-health-guided-setup` — the root orchestrator (full 16-group Home Health wizard) that delegates to this skill.

package/skills/industries-icm-act3-toggles-configure/SKILL.md

@@ -0,0 +1,198 @@
+---
+name: industries-icm-act3-toggles-configure
+description: "Act 3 of Health Cloud ICM setup — the five ordered ICM core preference toggles (Enhanced Care Plans, Integrated Care Management master, Care Task sharing, Care Gap Detection, MCG reveal), sequencing the operations already verified on the IntegratedCareManagementSettings setup-page node. Standalone reference for the icm-setup skill's third phase."
+metadata:
+  version: "1.0"
+---
+
+# Act 3 of 8 — ICM Core Feature Toggles
+
+Part of the [`icm-setup`](../../SKILL.md) skill — the **third of eight acts**. Runs after
+[Act 1](../act1-prereqs/SKILL.md) and [Act 2](../act2-discovery-framework/SKILL.md), and is
+followed by [Act 4](../act4-record-page/SKILL.md) → [Act 5](../act5-genai-suggested-assessments/SKILL.md)
+→ [Act 6](../act6-mcg-integration/SKILL.md) → Act 7 → Act 8.
+Finishing these toggles is **not** finishing the skill: for an unqualified "set up ICM" request
+you must continue through Acts 4 onward to Act 8. Only run Act 3 in isolation when the admin's ask is
+explicitly narrow (e.g. "ICM's on, I just need Care Gaps").
+
+## ⛔ Entry gate — should you even be starting here?
+
+**STOP before running any toggle and check how you got here.** If you arrived at Act 3 because
+the admin asked to "set up ICM" / "configure ICM" / "enable care management" with **no
+narrowing qualifier**, you are in the wrong place: that request is the full 1→8 journey and
+**must start at Act 1**, not here. Go back to the [router](../../SKILL.md), post the mandatory
+pre-write plan, and begin at Act 1. Do **not** rationalize *"'do ICM setup' just means the
+toggles"* — that exact reasoning caused a prior run to deliver a partial setup; it is the bug
+this gate exists to stop.
+
+You may run Act 3 as the entry point **only** when the admin's ask explicitly narrows to it —
+e.g. "ICM is already on, I just need Care Gaps / Care Task sharing / MCG", or they explicitly
+said Acts 1–2 are already done. If you cannot quote an explicit narrowing phrase from the
+admin's request, do not run this Act in isolation — return to Act 1. Even when narrowing is
+explicit, **read back all five toggle states before writing** and change only what's missing.
+
+## Source of truth for the operations
+
+This Act does **not** define its own step contract. Every operation named below already
+exists, verified, on the **`IntegratedCareManagementSettings`** setup-page node (team
+`health-cloud-han-solo`) — `describe` that node to read the authoritative contract.
+Call those operations by id/controller method exactly as defined there. If you find yourself
+re-deriving a route, param name, or verify pattern for one of the five toggles below, stop —
+read the node instead. Duplicating the contract in two places is how they drift out of sync.
+
+> **⚠️ Transport: use the customer-executable path on a real org.** Each
+> toggle preference has no supported direct customer API of its own; the customer-executable
+> primitive is a
+> minimal `IndustriesSettings` MDAPI deploy + a **`Settings:Industries` Metadata-API retrieve** to
+> read state back. On a real customer org **the underlying endpoint is unavailable and
+> returns 404 — expected, not a failure.** Use the MDAPI-deploy +
+> retrieve transport (the write operations are already on the node for every toggle). This is the
+> parent skill's MDAPI fallback rule applied to the Act-3 toggles; a 404 here never means "the
+> toggle can't be set." **Read the five toggle states with ONE retrieve, not five Tooling
+> `Is*Enabled` queries** (parent *Transport & deploy discipline* rule 4) — the Tooling
+> `SELECT … FROM IndustriesSettings` path server-errors on OrgFarm orgs and can hang to timeout; a
+> single `Settings:Industries` retrieve returns every `enableX` element at once. Never read a Tooling
+> error as "toggle off."
+>
+> **Split-deploy + batching discipline.** Toggle 1 (Enhanced Care Plans) must land and be confirmed
+> **before** toggle 2 (it provisions the ICM Console app #2 depends on), and toggle 2 turns on
+> `HCCareMgmt` — so deploy **#1 alone, confirm, then #2 alone, confirm.** Once #2 is confirmed
+> effective, **toggles 3, 4, 5 (the generic-setter toggles keyed by `orgPref`) gate on the master,
+> not on each other — deploy the three in ONE transaction** and verify all three with one retrieve
+> (fall back to per-toggle deploys only if the combined deploy is rejected). **Full-run note
+> (`full_run = true`):** this is parent *Full-run consolidation* Tier 3 — #1 arrives already batched
+> with Act 2's items 2–7 in Tier 2b, then #2 alone, then #3–#5 together, plus Version-Aware Historical
+> View. On a narrow standalone Act-3 ask, run the chain self-contained here.
+
+## The five toggles, in required order
+
+| # | Toggle (UI label) | Org preference | Write operation | Verify operation |
+|---|---|---|---|---|
+| 1 | Enhanced Care Plans — **FIRST** | `CarePlansPreference` | `enable-care-plans-preference` | `verify-enable-care-plans-preference` |
+| 2 | Integrated Care Management (Automatic Sharing for Goal Assignment Records) | `IntegratedCareManagement` | `enable-integrated-care-management` | `verify-enable-integrated-care-management` |
+| 3 | Automatic Sharing for Care Task Records | `careTaskSharingPreference` | `enable-care-task-sharing` | `verify-enable-care-task-sharing` |
+| 4 | Care Gap Detection | `careGapPreference` | `enable-care-gap-detection` | `verify-enable-care-gap-detection` |
+| 5 | MCG — reveal toggle | `mcgPreference` | `enable-mcg` | `verify-enable-mcg` |
+
+**Why #1 must land before #2:** proven live, not inferred — enabling `CarePlansPreference`
+provisions the **ICM Console app** that the ICM master toggle's effective behavior depends
+on. The node encodes this with a `depends_on` chain where each write depends on the *prior
+toggle's verify step* (not just its write) — preserve that discipline when driving this Act:
+confirm state before advancing, don't fire all five writes back-to-back.
+
+**Toggles 3-5 share one generic setter/getter** keyed by an `orgPref` string, while toggle 2
+has its own dedicated setter/getter. This asymmetry is real, not an authoring
+inconsistency.
+
+**Toggle 5 (MCG) is a reveal toggle** — for an unqualified "set up ICM" it runs like the other
+four (all five toggles run). Enabling it reveals the MCG option in the ICM Settings UI; it does
+**not** set up the working Milliman integration — that is [Act 6](../act6-mcg-integration/SKILL.md).
+See `../../references/mcg-integration-runbook.md` before an
+admin assumes "MCG toggle on" means "MCG is set up." Only skip toggle 5 when the admin's ask is
+explicitly narrow and excludes MCG.
+
+## After the five toggles — enable Version-Aware Historical View (deferred out of Act 2)
+
+**Version-Aware Historical View for Internal Assessments** — mdApiName
+`enableViewInternalAssmtSetting`, `minMdApiVersion` 262 —
+is a **Discovery Framework → General Settings** toggle (it lives on the Act 2 page), but its gate
+is `(HealthCloud.orgHasHealthCloud && OrgPermissions.HCCareMgmt) || PublicSector.orgHasLPIFeature`.
+On a Health Cloud org that means it needs **Care Management (`HCCareMgmt`) effective first** —
+which is exactly what Act 3's toggle #2 (`IntegratedCareManagement`) turns on. Act 2 therefore
+**defers it to here** rather than silently dropping it (a pre-`HCCareMgmt` deploy reports
+"Changed" but never takes effect).
+
+Enable it **after toggle #2 is confirmed effective** (its verify step has passed):
+
+- Transport: minimal `IndustriesSettings` MDAPI deploy of `enableViewInternalAssmtSetting`, at
+  the org's own API version (≥262), then a `Settings:Industries` retrieve to confirm it actually
+  stuck (bundle it into the toggle-3–5 retrieve in a full run) — same discipline as the five toggles
+  above. It is a pure on/off toggle once the gate is met (no extra config, no license beyond Care
+  Management).
+- What it does: lets users open completed Discovery-Framework internal assessments regardless of
+  the current question version — the Lightning component renders historical responses in their
+  original context.
+
+If Act 3 is being run in isolation ("ICM's already on, I just need Care Gaps") and the admin did
+not ask for this, treat it as optional — offer it, don't force it. For an unqualified full "set up
+ICM" run, enable it here so it does not fall through the cracks between Act 2 and later acts.
+
+## Why not the AdminSetup wizard-graph discovery contract?
+
+The `IntegratedCareManagementSettings` setup-page node also documents the Industries
+AdminSetup framework — a discovery call to find access-filtered `configurations[].steps[]`,
+and a step-execution call to dispatch a discovered action.
+
+**This skill does not use it.** That step-execution surface has no
+supported customer-executable transport — external REST callers receive HTTP 404, and
+its variants are not customer-reachable either. The
+direct MDAPI-deploy + Tooling-read toggle path above is the customer transport and is what you
+run. The AdminSetup surface remains documented on that node (status `proposed`) for internal
+automation only; do not route customer setup through it.
+
+## Preconditions (from the node)
+
+- Health Cloud provisioned with Care Management capability.
+- Running user has Industries Care Management setup access (View Setup / AccessSetup).
+- Enhanced Care Plans enabled before the ICM master toggle (the ordering above).
+
+## Act 3 end state — verify by diffing ONE retrieve; do not proceed on a partial
+
+**Before marking Act 3 done, run the single `Settings:Industries` retrieve and assert EVERY row
+below reads its expected state in that one response.** This adds **no** org round-trips — it is the
+same retrieve you already made to verify the toggle batches; the only new work is comparing the
+values you already hold. A "deploy reported Changed" is *not* evidence a toggle stuck (the
+silent-drop pattern) — the read-back is. **Any row that reads OFF/absent on a full run → redeploy
+just that pref at the org's own API version, re-retrieve, and only then continue.** This
+completeness diff is what catches a skipped item or a silently-dropped deploy before it becomes a
+re-test cycle.
+
+| # | Toggle | Verify via | Expected (full run) |
+|---|---|---|---|
+| 1 | Enhanced Care Plans (`CarePlansPreference`) | `verify-enable-care-plans-preference` | ON |
+| 2 | Integrated Care Management master (`IntegratedCareManagement`) | `verify-enable-integrated-care-management` | ON — turns on `HCCareMgmt` |
+| 3 | Care Task sharing (`careTaskSharingPreference`) | `verify-enable-care-task-sharing` | ON |
+| 4 | Care Gap Detection (`careGapPreference`) | `verify-enable-care-gap-detection` | ON |
+| 5 | MCG reveal (`mcgPreference`) | `verify-enable-mcg` | ON — skip **only** on a narrow ask that excludes MCG |
+| 6 | Version-Aware Historical View (`enableViewInternalAssmtSetting`) | its `Is*Enabled` element in the same retrieve | ON — **owned by this Act, not optional on a full run**; the row most often left OFF |
+
+Row 6 is the one the deferred-from-Act-2 handoff most often drops (it reads OFF unless someone
+runs the "After the five toggles" step above) — the diff makes that omission self-evident instead
+of silent. **Narrow standalone Act-3 ask** ("ICM's already on, just Care Gaps"): rows the admin
+explicitly excluded — and Version-Aware, if unrequested — may read OFF; that is expected, note it,
+do **not** redeploy uninvited. On an unqualified full "set up ICM" run, **all six must read ON.**
+
+**➡️ Next: continue to [Act 4](../act4-record-page/SKILL.md).** Unless the admin's ask was
+explicitly narrow (just toggles / "ICM's already on"), the ICM setup is **not complete** until
+Act 4's end state is reached. Do not report "ICM setup done" here.
+
+## What Act 3 does not cover — these are expectation-setting notes, NOT stop signals
+
+The items below are deferred *sub-features*. Mention them so the admin has accurate
+expectations, then **keep going** — first any remaining Act 3 work, then Act 4. **Do not use
+any of these as a reason to end the run after the toggles.**
+
+- Care Gap Detection being ON does not mean care gaps will surface — Clinical Measures must be
+  configured separately per clinical protocol (P1, out of scope for this skill). This is a
+  note to relay, **not** a reason to stop; Act 4 still runs.
+- MCG toggle 5 being ON does not mean MCG is integrated — see the MCG runbook reference before
+  setting that expectation with an admin.
+
+If you must stop early for a genuine blocker, say explicitly: "Acts 1–3 done; Act 4 not run
+because <blocker>" — never imply the whole setup is complete when Act 4 has not run.
+
+<!-- skill-validate: ignore-start -->
+<!-- codey:operations start -->
+## Operations Reference
+
+Operations this skill uses — routing and dependency reference.
+
+| Operation | Purpose | Status | Call | Depends on |
+|-----------|---------|--------|------|------------|
+| `hchan-icms-verify-enable-care-plans-preference` | verify | — | `IndustriesSettings.query` | — |
+| `hchan-icms-verify-enable-integrated-care-management` | verify | — | `IndustriesSettings.query` | — |
+| `hchan-icms-verify-enable-care-task-sharing` | verify | — | `IndustriesSettings.query` | — |
+| `hchan-icms-verify-enable-care-gap-detection` | verify | — | `IndustriesSettings.query` | — |
+| `hchan-icms-verify-enable-mcg` | verify | — | `IndustriesSettings.query` | — |
+<!-- codey:operations end -->
+<!-- skill-validate: ignore-end -->