@salesforce/afv-skills 1.40.0 → 1.41.0

package/skills/service-digital-engagement-channel-configure/SKILL.md

@@ -10,10 +10,10 @@ metadata:
     - "platform-permission-set-generate"
     - "service-digital-engagement-deployment-configure"
   cliTools:
-    - tool: ["python3"]
-      semver: ">=3.10.0"
     - tool: ["sf"]
       semver: ">=2.0.0"
+    - tool: ["python3"]
+      semver: ">=3.8"
 ---
 
 # Configuring Enhanced Chat Channel
@@ -107,7 +107,20 @@ All steps are sequential. Do not skip or reorder.
    | Omni-Channel Queue | `Queue` | `sessionHandlerQueue` |
    | Omni-Channel Flow | `Flow` | `sessionHandlerFlow` + `sessionHandlerQueue` (fallback) |
    | User | `User` | `sessionHandlerUser` + `sessionHandlerQueue` (fallback) |
-   | Agentforce Service Agent | `AgentforceServiceAgent` | `sessionHandlerAsa` + `sessionHandlerQueue` (fallback) |
+   | Agentforce Service Agent | `AgentforceServiceAgent` | `sessionHandlerQueue` (fallback only — see v67 note below) |
+
+   > **v67 limitation — `sessionHandlerAsa` is not accepted by the Metadata API at v67.** Do NOT include `<sessionHandlerAsa>` in the XML for ASA routing. Instead:
+   > 1. **Verify the bot is Active before channel creation.** The Data API rejects binding with "Only active Agentforce Service Agents are supported." Run `sf agent activate -o <org> --api-name <BotDevName>` and confirm `BotVersion.Status = Active` first.
+   > 2. Deploy the XML with `<sessionHandlerType>AgentforceServiceAgent</sessionHandlerType>` and `<sessionHandlerQueue>` only — no `<sessionHandlerAsa>` element.
+   > 3. After the deploy succeeds, query the channel Id: `sf data query -o <org> -q "SELECT Id FROM MessagingChannel WHERE DeveloperName='<ChannelDevName>'" --json`
+   > 4. Resolve the BotDefinition Id: `sf data query -o <org> -q "SELECT Id FROM BotDefinition WHERE DeveloperName='<BotDevName>'" --json`
+   > 5. PATCH both handler fields via Data API in a single call:
+   >    ```bash
+   >    sf api request rest -o <org> --method PATCH \
+   >      "/services/data/v67.0/sobjects/MessagingChannel/<CHAN_ID>" \
+   >      --body "{\"SessionHandlerId\":\"<BOT_ID>\",\"FallbackQueueId\":\"<QUEUE_ID>\"}"
+   >    ```
+   > 6. Verify: `sf data query -o <org> -q "SELECT SessionHandlerId, FallbackQueueId FROM MessagingChannel WHERE Id='<CHAN_ID>'" --json` — both must be non-null.
 
 8. **Apply user verification** — if enabled, set `embeddedConfig.authMode` to `Auth` and include `<messagingAuthorizations>`. If not enabled, set `embeddedConfig.authMode` to `UnAuth` and omit `<messagingAuthorizations>`.
 
@@ -141,6 +154,27 @@ All steps are sequential. Do not skip or reorder.
     sf project deploy start --source-dir <path-to-messagingChannels-folder> --target-org <org-alias>
     ```
 
+15a. **ASA routing only — bind the bot via Data API PATCH.** Skip this step for Queue, Flow, and User routing types.
+
+    ```bash
+    CHAN_ID=$(sf data query -o <org> --json \
+      -q "SELECT Id FROM MessagingChannel WHERE DeveloperName='<CHANNEL_DEV_NAME>'" \
+      | python3 -c "import sys,json; print(json.load(sys.stdin)['result']['records'][0]['Id'])")
+    BOT_ID=$(sf data query -o <org> --json \
+      -q "SELECT Id FROM BotDefinition WHERE DeveloperName='<ASA_BOT_DEV_NAME>'" \
+      | python3 -c "import sys,json; print(json.load(sys.stdin)['result']['records'][0]['Id'])")
+    QUEUE_ID=$(sf data query -o <org> --json \
+      -q "SELECT Id FROM Group WHERE Type='Queue' AND DeveloperName='<FALLBACK_QUEUE_DEV_NAME>'" \
+      | python3 -c "import sys,json; print(json.load(sys.stdin)['result']['records'][0]['Id'])")
+
+    sf api request rest -o <org> --method PATCH \
+      "/services/data/v67.0/sobjects/MessagingChannel/$CHAN_ID" \
+      --body "{\"SessionHandlerId\":\"$BOT_ID\",\"FallbackQueueId\":\"$QUEUE_ID\"}"
+    # Expected: HTTP 204
+    ```
+
+    Verify: `sf data query -o <org> -q "SELECT SessionHandlerId, FallbackQueueId FROM MessagingChannel WHERE Id='$CHAN_ID'" --json` — both must be non-null.
+
 15. **Activate the channel** — after successful deployment, activate the messaging channel:
     ```bash
     sf data update record --sobject MessagingChannel --where "DeveloperName='<CHANNEL_NAME>'" --values "IsActive=true" --target-org <org-alias>
@@ -163,7 +197,8 @@ All steps are sequential. Do not skip or reorder.
 | `sessionHandlerType` must match the handler fields present | Setting `Queue` but populating `sessionHandlerFlow` causes deployment error |
 | Flow routing requires both `sessionHandlerFlow` and `sessionHandlerQueue` | Queue is the mandatory fallback for human escalation |
 | User routing requires both `sessionHandlerUser` and `sessionHandlerQueue` | Queue is the mandatory fallback when user is unavailable |
-| ASA routing requires both `sessionHandlerAsa` and `sessionHandlerQueue` | Queue is the mandatory fallback for human escalation |
+| ASA routing: include `sessionHandlerQueue` in the XML; bind `SessionHandlerId` via Data API PATCH after deploy | `sessionHandlerAsa` is not accepted by the Metadata API at v67 — bot binding must happen via Data API |
+| Bot must be Active before the Data API PATCH that sets `SessionHandlerId` | API rejects with "Only active Agentforce Service Agents are supported" if the bot is inactive |
 | `masterLabel` max 40 characters | Platform limit on channel labels |
 | File name must match `^[a-zA-Z][a-zA-Z0-9_]*$` | API name format enforced by Metadata API |
 | `allowedFileTypes` is a comma-separated string with no spaces | Not a nested list or array |
@@ -184,6 +219,8 @@ All steps are sequential. Do not skip or reorder.
 | Queue not found on deploy | Ensure the referenced queue exists and has `MessagingSession` as a `queueSobject` type |
 | Omni-Channel Flow not found on deploy | Ensure the referenced flow exists and is active before deploying the channel |
 | ASA bot reference invalid | Bot must be published and active; use exact developer name from BotDefinition metadata |
+| ASA channel deployed but `SessionHandlerId` is null after deploy | `sessionHandlerAsa` is silently rejected by the Metadata API at v67 — run the Data API PATCH step (Phase 3, step 15a) to bind it |
+| "Only active Agentforce Service Agents are supported" on Data API PATCH | Bot is inactive — run `sf agent activate` before the PATCH |
 | Flow or ASA routing fails without fallback queue | `sessionHandlerQueue` is mandatory when `sessionHandlerType` is `Flow` or `AgentforceServiceAgent` |
 | JWT verification not working | Connected app and certificate must be configured for the org |
 | Custom parameters not collected | `name` must be unique per channel; `parameterDataType` defaults to `Text` |
@@ -202,8 +239,11 @@ All steps are sequential. Do not skip or reorder.
 
 ### Routing Checks
 - [ ] Is exactly one `sessionHandlerType` value set (`Queue`, `Flow`, `User`, or `AgentforceServiceAgent`)?
-- [ ] Is the corresponding handler field populated (`sessionHandlerQueue`, `sessionHandlerFlow`, `sessionHandlerUser`, or `sessionHandlerAsa`)?
-- [ ] For Flow, User, or ASA routing, is `sessionHandlerQueue` also populated (fallback)?
+- [ ] For Queue routing: is `sessionHandlerQueue` in the XML?
+- [ ] For Flow routing: is `sessionHandlerFlow` in the XML, plus `sessionHandlerQueue` as fallback?
+- [ ] For User routing: is `sessionHandlerUser` in the XML, plus `sessionHandlerQueue` as fallback?
+- [ ] For ASA routing: is `sessionHandlerQueue` in the XML (no `sessionHandlerAsa` — that goes via Data API)?
+- [ ] For ASA routing: was step 15a run? Are `SessionHandlerId` and `FallbackQueueId` non-null after the PATCH?
 - [ ] Does the routing target reference an existing entity in the org?
 
 ### User Verification Checks

package/skills/service-digital-engagement-channel-configure/assets/messaging_channel_template.xml

@@ -96,7 +96,8 @@
     <!-- <sessionHandlerType>Flow</sessionHandlerType> -->
 
     <!-- Routing: Agentforce Service Agent (requires a fallback queue) -->
-    <!-- <sessionHandlerAsa>{ASA_BOT_NAME}</sessionHandlerAsa> -->
+    <!-- NOTE: sessionHandlerAsa is NOT included here — it is rejected by the Metadata API at v67. -->
+    <!-- After deploy, bind the bot via Data API PATCH: SessionHandlerId + FallbackQueueId (see SKILL.md step 15a) -->
     <!-- <sessionHandlerQueue>{FALLBACK_QUEUE_NAME}</sessionHandlerQueue> -->
     <!-- <sessionHandlerType>AgentforceServiceAgent</sessionHandlerType> -->
 </MessagingChannel>

package/skills/service-digital-engagement-channel-configure/examples/asa_agent_channel.xml

@@ -47,7 +47,10 @@
         <keywordType>Help</keywordType>
         <language>en_US</language>
     </messagingKeywords>
-    <sessionHandlerAsa>Support_Service_Agent</sessionHandlerAsa>
+    <!-- sessionHandlerAsa is NOT in the XML — rejected by Metadata API at v67.
+         After deploy, run step 15a in SKILL.md to bind via Data API PATCH:
+           SessionHandlerId = <BotDefinition.Id for Support_Service_Agent>
+           FallbackQueueId  = <Group.Id for Support_Escalation_Queue>     -->
     <sessionHandlerQueue>Support_Escalation_Queue</sessionHandlerQueue>
     <sessionHandlerType>AgentforceServiceAgent</sessionHandlerType>
 </MessagingChannel>

package/skills/service-helpagent-coordinate/README.md

@@ -15,8 +15,10 @@ skills against a canonical spec — it does **not** author a new agent primitive
 | `assets/help-agent-spec.md` | The canonical Help Agent spec — the guided flow (source of truth), kept small |
 | `references/agent-script.md` | The canonical agent script + placeholders; loaded only at agent-creation time |
 | `references/channel-web-chat.md` | Web Chat channel provisioning detail; loaded only when Web Chat is chosen |
-| `references/channel-help-portal.md` | Help Portal channel (coming soon) — hard-stop guidance |
-| `references/channel-voice.md` | Voice channel (coming soon) — hard-stop guidance |
+| `references/channel-voice.md` | Voice channel wiring detail (existing `PstnVoice` numbers only); loaded only when Voice is chosen |
+| `references/output-report-format.md` | The two report shapes, templates, and scored-failure list; loaded when writing the final `report.md` |
+
+Help Portal is delegated end-to-end to the sibling skill `service-concierge-portal-generate` — no per-channel reference file lives here for that branch.
 
 The spec is split for **progressive disclosure**: the large agent script and the per-channel
 branches live in `references/` and are read only when the flow reaches them, keeping the
@@ -121,3 +123,7 @@ Verify: `! ls .agents/skills/` and `! cat skills-lock.json`.
 ## Related
 
 - ECA / OAuth setup skill: `integration-connectivity-connected-app-configure`
+- Channel setup vs. final agent wiring: `service-digital-engagement-channel-configure` deploys and
+  activates the MessagingChannel with initial Queue routing; `service-agentforce-channel-configure`
+  then replaces that routing with the agent binding (fallback queue + `sessionHandlerAsa`). This
+  skill coordinates both at Checkpoint 3.

package/skills/service-helpagent-coordinate/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: service-helpagent-coordinate
-description: "Use to set up, configure, ground, or go live with a Salesforce Help Agent (an Agentforce Service Agent in Service Cloud) via a guided four-checkpoint flow. Use whenever a user says any of: set up / create / build / add a help agent, service agent, or support chat agent; add or embed a chat widget on a website or Experience Cloud / LWR site; put a help agent on a channel (web chat, voice, phone, help portal), even while rejecting web chat; ground a help agent on Salesforce Knowledge; or wants an AI to answer customer questions, manage support cases, and escalate to a human. The right skill even when the request names only one part, names a coming-soon channel this skill hard-stops on, or references help-agent-spec.md or the Agentforce Quick Setup wizard. DO NOT TRIGGER when authoring a brand-new agent with no Help Agent lineage (use agentforce-generate), configuring OAuth/ECAs (use integration-connectivity-connected-app-configure), or only deploying metadata (use platform-metadata-deploy)."
+description: "Use to set up, configure, ground, or go live with a Salesforce Help Agent (an Agentforce Service Agent in Service Cloud) via a guided four-checkpoint flow. Use whenever a user says any of: set up / create / build / add a help agent, service agent, or support chat agent; add or embed a chat widget on a website or Experience Cloud / LWR site; put a help agent on a channel (web chat, voice, phone, help portal); ground a help agent on Salesforce Knowledge; or wants an AI to answer customer questions, manage support cases, and escalate to a human. The right skill even when the request names only one part or references help-agent-spec.md or the Agentforce Quick Setup wizard. DO NOT TRIGGER when authoring a brand-new agent with no Help Agent lineage (use agentforce-generate), configuring OAuth/ECAs (use integration-connectivity-connected-app-configure), or only deploying metadata (use platform-metadata-deploy)."
 allowed-tools: Bash Read Write Edit Glob Grep WebFetch AskUserQuestion TodoWrite
 metadata:
   version: "0.9"
@@ -12,6 +12,8 @@ metadata:
     - "experience-lwr-site-generate"
     - "integration-connectivity-connected-app-configure"
     - "platform-metadata-deploy"
+    - "service-agentforce-channel-configure"
+    - "service-concierge-portal-generate"
     - "service-digital-engagement-channel-configure"
     - "service-digital-engagement-deployment-configure"
     - "service-digital-engagement-messaging-site-integrate"
@@ -20,6 +22,8 @@ metadata:
       semver: ">=7.0.0"
     - tool: ["sf"]
       semver: ">=2.139.6"
+    - tool: ["python3"]
+      semver: ">=3.8"
 ---
 
 # service-helpagent-coordinate: Service Cloud Help Agent, guided setup
@@ -58,192 +62,183 @@ The spec feeds these existing skills — do **not** author a new Help Agent skil
 |---|---|
 | `agentforce-generate` | Agent authoring + ADL provisioning/grounding (see its `references/data-library-reference.md`, `references/org-setup-for-adl.md`) |
 | `dx-org-permission-set-assign` | Data Cloud permission-set assignment |
-| `service-digital-engagement-channel-configure` | Messaging channel setup (uses `sessionHandlerAsa` for AgentforceServiceAgent routing — see `references/channel-web-chat.md`) |
-| `service-digital-engagement-deployment-configure` | Embedded Service Deployment (targets `SiteType = 'ChatterNetworkPicasso'` sites — Aura won't work) |
+| `service-digital-engagement-channel-configure` + `service-agentforce-channel-configure` | Deploy channel (Queue routing), then PATCH `SessionHandlerId` to bind agent (see `references/channel-web-chat.md`) |
+| `service-digital-engagement-deployment-configure` | Embedded Service Deployment — supports both LWR (`ChatterNetworkPicasso`) and Aura (`ChatterNetwork`) sites |
 | `experience-lwr-site-generate` | Experience Cloud (LWR) site — used when the org has no Live LWR site yet |
 | `service-digital-engagement-messaging-site-integrate` | Widget placement + embed (Checkpoint 3.5 / 4) |
 
+## Skills inventory pre-flight (advisory — never a hard stop)
+
+This skill delegates to several sibling skills. Depending on the runtime, those dependencies resolve one of two ways: as directories under `.claude/skills/`, **or** through a runtime skill catalog that the harness resolves on demand (no local directory). An absent `.claude/skills/<name>` directory therefore does **not** prove a dependency is unavailable — it is normal when the catalog resolves skills at invocation time.
+
+Run this check **once, silently, for your own awareness** — never as the run's first user-facing output:
+
+```bash
+for skill in agentforce-generate dx-org-permission-set-assign service-digital-engagement-channel-configure service-digital-engagement-deployment-configure experience-lwr-site-generate service-digital-engagement-messaging-site-integrate service-concierge-portal-generate service-agentforce-channel-configure; do
+  [ -d ".claude/skills/$skill" ] && echo "OK: $skill" || echo "resolve-at-runtime: $skill"
+done
+```
+
+**Do not stop, and do not open the run with a missing-dependency roll call.** Proceed with the checkpoints; delegate to each sibling skill only when the flow actually reaches it. If — and only if — a delegation step is actually reached and that specific skill cannot be resolved at that moment, surface *that one skill* by name at that point. Never front-load the full eight-skill inventory as the deliverable; it is not a decision the user owns and it is not the report.
+
+---
+
 ## Workflow
 
 Read `assets/help-agent-spec.md` first — it is the authoritative flow and is intentionally kept small. **Do not pre-load the rest.** The heavy or conditional material is split into `references/` and read only when the flow reaches it (progressive disclosure — this is deliberate, to keep token usage low):
 
 - **`references/agent-script.md`** — the ~500-line canonical agent script + placeholder list. Load it **only when you are ready to create the agent, after Checkpoint 2** — not during Checkpoints 1, 3, or 4.
 - **`references/channel-web-chat.md`** — Web Chat provisioning detail. Load **only if the user picks Web Chat** at Checkpoint 3.
-- **`references/channel-help-portal.md`** / **`references/channel-voice.md`** — coming-soon channel hard-stops. Load only if the user picks that channel.
+- **`service-concierge-portal-generate`** — Help Portal / Agentforce Concierge portal deploy. **Delegate to this skill** if the user picks Help Portal at Checkpoint 3 — do not inline the portal runbook steps here. Pass `$ORG`, `$BOT_ID`, and `$BOT_DEV_NAME` as context so the skill skips its own entry-point questions.
+- **`references/channel-voice.md`** — Voice channel wiring detail (existing numbers only). Load only if the user picks Voice.
 
 Read the one channel file that matches the user's selection — never all three. Then run the interactive setup **without one-shotting**: walk the user through four checkpoints in order, waiting for a reply at each.
 
 ### Readiness check (silent, MANDATORY, do not reorder)
 Order is load-bearing — running step 3 before step 2 fails with `PermissionSet not found: GenieUserEnhancedSecurity` because the Data Cloud permission sets do not exist in the org until Data Cloud itself is turned on:
-1. Verify licenses + Einstein Agent User.
+1. **Verify PSL seat availability, then create a dedicated Einstein Agent User for this agent.** First confirm the three required PSLs have available seats:
+   ```bash
+   sf data query --target-org $ORG --json \
+     --query "SELECT MasterLabel, TotalLicenses, UsedLicenses FROM PermissionSetLicense WHERE DeveloperName IN ('AgentforceServiceAgentUserPsl', 'GenieDataPlatformStarterPsl', 'EinsteinGPTPromptTemplatesPsl')"
+   ```
+   For each, `UsedLicenses < TotalLicenses` must be true. If any PSL is at capacity, stop and surface which one is exhausted — the PSG assignment will fail and there is nothing the skill can do until a seat is freed or provisioned.
+
+   If all three have capacity, create the user. Do not reuse any existing Einstein Agent User — each Help Agent gets its own. Username: `{agentDevName}_user@{orgId}.ext` (15-char org Id from `sf org display`). Email: `noreply@salesforce.com`. Profile: `Einstein Agent User` (query `SELECT Id FROM Profile WHERE Name = 'Einstein Agent User'` to get the ProfileId, then `sf data create record --sobject User`). If a user with exactly that username already exists, reuse it (idempotent). Then assign all four of the following **before publishing the agent**:
+   - `AgentforceServiceAgentUserPsg` (Permission Set Group) — assigns three PSLs in one call: `Agentforce Service Agent User`, `Data Cloud`, and `Einstein Prompt Templates`. Use `sf org assign permsetgroup`.
+   - `AgentforceServiceAgentSecureBase` (Permission Set) — required for all service agents. Use `sf org assign permset`.
+   - `AgentforceKnowledgeObjectAccess` (Permission Set) — required because the Help Agent uses the `knowledge:` block. Use `sf org assign permset`.
+   - `{AgentName}_Access` (custom Permission Set) — created by `agentforce-generate` for agent-specific Apex/object access.
+
+   Verify PSL assignments landed: `SELECT PermissionSetLicense.DeveloperName FROM PermissionSetLicenseAssign WHERE Assignee.Username = '{agentDevName}_user@{orgId}.ext'` — expect `AgentforceServiceAgentUser`, `DataCloud`, `EinsteinPromptTemplates`.
+
+   **Capture the username** (`{agentDevName}_user@{orgId}.ext`) — it is the value for `<default_agent_user_placeholder>` in the agent script. The agent runs as this user at runtime.
+
+   **Pre-publish gate — verify before every `sf agent publish authoring-bundle` call.** Skipping this causes a masked 401→404: SFAP returns HTTP 401 "User doesn't have access to agent" when the Einstein Agent User is missing `AgentforceServiceAgentUserPsg`, and jsforce's session-refresh retry silently converts that 401 to `ERROR_HTTP_404`. Verify all four assignments are present before invoking the CLI:
+
+   ```bash
+   AGENT_USER_ID=$(sf data query --target-org $ORG --json \
+     --query "SELECT Id FROM User WHERE Username='{agentDevName}_user@{orgId}.ext'" \
+     | python3 -c "import sys,json; print(json.load(sys.stdin)['result']['records'][0]['Id'])")
+
+   # Must return exactly 1 row — if 0, assign before continuing
+   sf data query --target-org $ORG --json \
+     --query "SELECT PermissionSetGroup.DeveloperName FROM PermissionSetAssignment \
+              WHERE AssigneeId='${AGENT_USER_ID}' \
+              AND PermissionSetGroup.DeveloperName='AgentforceServiceAgentUserPsg'"
+
+   # Must return 2 rows — if any are missing, assign before continuing
+   sf data query --target-org $ORG --json \
+     --query "SELECT PermissionSet.Name FROM PermissionSetAssignment \
+              WHERE AssigneeId='${AGENT_USER_ID}' \
+              AND PermissionSet.Name IN ('AgentforceServiceAgentSecureBase','AgentforceKnowledgeObjectAccess')"
+   ```
+
+   Do not call `sf agent publish authoring-bundle` until all four assignments return non-empty results.
+
 2. **Enable Data Cloud** — must complete before step 3 (permission sets don't exist until Data Cloud is on). If Data Cloud is not yet provisioned, offer the user the choice up front — enable and come back later, or wait through it now.
-3. **CRITICAL — Assign the Data Cloud permission sets immediately after enablement.** Non-negotiable — skipping it ships an agent whose grounding returns empty `knowledgeSummary` at runtime even though ADL indexing reports SUCCESS.
+3. **CRITICAL — Assign the Data Cloud permission sets immediately after enablement.** Non-negotiable — skipping it ships an agent whose grounding returns empty `knowledgeSummary` at runtime even though ADL indexing reports SUCCESS. The PSG assigned in step 1 covers this once Data Cloud is on.
 
-Also verify the `SvcCopilotTmpl` and `EmployeeCopilot` namespaces are present. These are Salesforce out-of-the-box platform artifacts surfaced by `enableEinsteinGptPlatform: true` — not AppExchange managed packages — and will not appear in `sf package installed list`. Probe the namespace directly (e.g. `SELECT DeveloperName FROM Flow WHERE NamespacePrefix = 'SvcCopilotTmpl' LIMIT 1`).
 
 ### Recognizing where the user is entering
-Do not assume every run starts at Checkpoint 1. Read the opening prompt and enter at the right checkpoint: if identity is already decided, start at Checkpoint 2 (grounding); if grounding is already in place, start at Checkpoint 3 (channel). Never restart at Checkpoint 1 or re-ask decisions the user already stated. If the opening prompt names **Voice / phone / telephony / IVR / Amazon Connect**, asks to "reach" or "contact" the agent "by phone" / "by call", or asks for it "as a Voice channel" (even phrased as a rejection of web chat), or **Help Portal** as the channel, take the coming-soon hard stop immediately: respond verbatim *"This feature is coming soon, please select Web Chat."* and re-present the channel options — do not run the checkpoints or write any Voice/Help-Portal plan.
+
+**Checkpoint 1 (agent identity) and Checkpoint 3 (channel) must always be confirmed with the user in the current conversation — never inferred from a previous session, a compacted summary, or skill arguments.** These are decisions the user owns; acting on stale context from a prior run will configure the wrong agent or the wrong channel.
+
+If the user's opening message *in the current conversation turn* explicitly names the agent and/or channel (e.g. "set up Master Yoda on Web Chat"), accept those as the inputs and confirm them before proceeding. If not stated in the current turn, ask.
+
+For the org alias: if the user has been working against a specific org in the current session, use that. Otherwise ask.
+
+**Do not assume every run starts at Checkpoint 1.** Read the opening prompt and enter at the right checkpoint: identity decided → Checkpoint 2 (grounding); grounding done → Checkpoint 3 (channel). When the prompt explicitly names or implies a later checkpoint (e.g. "set up the grounding", "wire up the web chat channel") — and states or clearly implies prior checkpoints are already done — accept those prior checkpoints as established, enter scoped at the named checkpoint, and produce a settled-facts report for it. Do NOT force a full guided-identity re-confirmation, do NOT restart at Checkpoint 1, and do NOT demand in-conversation re-confirmation of prior decisions. Values the prompt supplies for the entered checkpoint (audience → `authMode`, named site, categories) are decided, not questions to re-ask.
+
+If the opening prompt names **Voice / phone / telephony / IVR**, read `references/channel-voice.md` and follow it from the top of Checkpoint 3 as the Voice branch.
 
 ### Checkpoint 1 — Meet Your Agent
-Agent name, language, greeting, tone. Offer defaults.
+Ask for four things (offer these exact defaults so the guided-decision report can enumerate them without loading `assets/help-agent-spec.md`):
+1. **Agent Name** — default `Help Agent` (DeveloperName `Help_Agent`).
+2. **Language** — default `en_US`.
+3. **Welcome Greeting** — default `"Hi, I'm {Agent Name}. How can I help you today?"`.
+4. **Tone** — default `"calm, patient, friendly service agent — warm but professional, short sentences, never robotic."`
+
+When the opener names Q&A / case management / human escalation, note explicitly that these map to the canonical four-subagent shape (Agent Router → General FAQ, Service Customer Verification, Case Management, Escalation) — do not invent a different design.
 
 ### Checkpoint 2 — Give Your Agent Context (grounding)
 Ask which knowledge source (Salesforce Knowledge / files / website sync). Grounding is **provisioning an Agentforce Data Library**, not designing a search — the agent's `knowledge:` block does the retrieval at runtime. This checkpoint MUST produce all five of:
 1. **Delegate provisioning to `agentforce-generate`** — it owns ADL create/index/publish. Do not hand-roll data-library metadata.
 2. **A dedicated, named library** — create `Help_Agent_Knowledge`. **Never wire the stock `All_Records_and_Fields_Default`** (it sits in `NOT_SCHEDULED` on trial or preloaded sample-data orgs and returns empty `knowledgeSummary` with no error).
-3. **Category selection** — for Salesforce Knowledge, query the org's Data Category Groups and ask which categories to ground on. Do not assume "all."
+3. **Category selection** — for Salesforce Knowledge, query the org's Data Category Groups. Ask which categories to ground on **only in an interactive run**; for a non-interactive/scoped run, decide the sensible default (**the org's default Data Category Group**, or all groups if none is designated) and note the default explicitly in the settled-facts report's Blocking Issues line (e.g. "Knowledge data category not specified — chose the org's default group"). Do not stall the report asking.
 4. **Wait-for-indexing gate** — poll and only proceed once `indexingStatus.status ∈ {COMPLETED, READY, SUCCESS}`. `NOT_SCHEDULED` is not success.
 5. **Capture the `rag_feature_config_id`** (format `ARFPC_<libraryId>`) and wire it into the agent script's `knowledge:` block — never hardcode.
 
 **Anti-rule:** never respond to a grounding request by designing a SOQL/SOSL/GraphQL/Apex search over Knowledge articles. Grounding is ADL provisioning; retrieval is the agent's job at runtime.
 
 ### Checkpoint 3 — Add to Channels
-Web Chat / Help Portal / Voice. Create messaging channel + Embedded Service Deployment; locate the target site via a **query-first pattern**:
+Web Chat / Help Portal / Voice. Deploy the channel with Queue routing (`service-digital-engagement-channel-configure`), then delegate agent wiring to `service-agentforce-channel-configure` (PATCH `SessionHandlerId`; `sessionHandlerAsa` not accepted at v67). Delegate to the appropriate channel reference file:
 
-```sql
-SELECT Id, Name, UrlPathPrefix, SiteType, Status
-FROM Site
-WHERE SiteType = 'ChatterNetworkPicasso' AND Status = 'Live'
-```
+- **Web Chat** → read `references/channel-web-chat.md`. Create messaging channel + Embedded Service Deployment; locate the target site via a **query-first pattern**:
 
-Only ever present or target `ChatterNetworkPicasso` (LWR) sites — never Aura (`ChatterNetwork`). Resolve the site **in the same turn**, do not defer:
-- **Zero Live LWR sites** → create one via `experience-lwr-site-generate` (recommend the Help Center template).
-- **Exactly one** → confirm it with the user before using (an existing site may serve a different audience); do not silently adopt it.
-- **Multiple** → in the SAME turn, show the executed SOQL, enumerate the results as a table (`Name | UrlPathPrefix | Id`), state plainly "no site is created or modified until you choose," then ask which one to target (include a "create a new site instead" option). Do not answer "I'll query and get back to you" — run the query and present results now.
+  ```sql
+  SELECT Id, Name, UrlPathPrefix, SiteType, Status
+  FROM Site
+  WHERE SiteType IN ('ChatterNetworkPicasso', 'ChatterNetwork') AND Status = 'Active'
+  ```
 
-Do not filter by hardcoded name or URL path prefix — the correct site depends on the customer's org.
+  Both LWR (`ChatterNetworkPicasso`) and Aura (`ChatterNetwork`) sites support the `experience_messaging:embeddedMessaging` widget. Filter out `ESW_`-prefixed sites in post-processing — those are internal ESD endpoint scaffolding, not real Experience Cloud sites. Resolve the site **in the same turn**, do not defer:
+  - **Zero real sites** → create one via `experience-lwr-site-generate` (recommend the Help Center template), or offer "Deploy on my own website (get snippet)".
+  - **Exactly one** → confirm it with the user before using (an existing site may serve a different audience); do not silently adopt it.
+  - **Multiple** → in the SAME turn, show the executed SOQL, enumerate the results as a table (`Name | Type | UrlPathPrefix`), state plainly "no site is created or modified until you choose," then ask which one to target (include "Create a new LWR site" and "Deploy on my own website" as options). Do not answer "I'll query and get back to you" — run the query and present results now.
 
-**Coming-soon channels are hard stops.** If the user selects **Help Portal** or **Voice**, respond verbatim *"This feature is coming soon, please select Web Chat."*, re-present the channel options, and wait. Never write a provisioning plan, phone number, portal site, or "planning-only" scaffold for these channels — even adjacent objects produce broken half-configurations. See `references/channel-voice.md` / `references/channel-help-portal.md`.
+  Do not filter by hardcoded name or URL path prefix — the correct site depends on the customer's org.
+
+- **Help Portal** → delegate to `service-concierge-portal-generate`. Pass the resolved `$ORG`, `$BOT_ID`, and `$BOT_DEV_NAME` so it can skip its entry-point questions. Help Portal deploys an Agentforce Concierge experience on an LWR Experience Cloud site and is fully supported.
+
+- **Voice** → read `references/channel-voice.md` and follow it fully. Voice wires an existing `PstnVoice` MessagingChannel to the agent via `service-agentforce-channel-configure` Branch B — it does not provision a new phone number.
+
+**After each channel branch completes, loop — ask if the user wants to add another channel.** Once a Web Chat, Help Portal, or Voice branch finishes (success or failure), present via `AskUserQuestion`:
+
+- **Add another [same type] channel** — e.g. if Web Chat was just deployed, offer remaining unwired Web Chat channels first. Re-run the branch for that type; skip channels already wired in this session.
+- **Add a different channel type** — return to the top of Checkpoint 3 (re-query `MessagingChannel`, rebuild the type list, omit already-wired channels from the options).
+- **Done — proceed to go-live** — exit the loop and advance to Checkpoint 3.5.
+
+Track which channels have been wired in this session so they are not re-offered. The loop continues until the user selects "Done" or all available channels have been wired.
+
+**When the opening prompt names two or more channels up front** (e.g. "add web chat first, then also make it reachable by phone as Voice — add both"), the prompt itself authorizes every named channel — treat them all as committed work, not one channel plus a maybe. You do **not** need a fresh user reply to move from the first named channel to the next: the up-front request *is* that authorization. Skip the between-branch `AskUserQuestion` for channels the prompt already named, wire each in the stated order, and only fall back to the loop's `AskUserQuestion` for channels the prompt did *not* name. The report must show every named channel was wired — do **not** report only the first and leave the rest as an intention. In the settled-facts report's Checkpoint 3 row (or a short trace right below the tables), make all of the following explicit, in order:
+1. **First-channel completion** as a settled fact (channel type, `authMode` for Web Chat, resolved site/number, ESD state) — not "will then add".
+2. **The authorization to continue**: state that the prompt named the next channel up front, so the flow advanced to it without a between-branch prompt — report *that* (the prompt-level authorization), never a user reply that did not occur. Do not claim the user "continued after an AskUserQuestion" for a channel the prompt already listed; that fabricates an interaction and breaks the settled-facts contract.
+3. **Second- (and later-) channel entry**: state that the flow re-entered Checkpoint 3 for the next named channel and carry that branch to its own settled outcome. If a between-branch prompt genuinely ran (only for a channel the prompt did *not* name), report its options and the actual selection.
+4. Only after every channel the prompt named is wired (or explicitly blocked with a one-line reason) does the flow reach go-live.
+
+A report that stops after the first named channel — or that frames the second as "next step" / "to be added" — is scored as an incomplete loop even when the first channel is perfect.
 
 ### Checkpoint 3.5 — Silent pre-flight (INTERNAL — never announce)
 Run silently; surface output only on failure. Every check must pass before Checkpoint 4:
 1. Data Cloud access in place for running user **and** Einstein Agent User (defer to `agentforce-generate`).
 2. ADL is Activated **and** grounded — run a canary retrieval with the captured `rag_feature_config_id`; if empty despite SUCCESS, surface the **Known manual step** (Data Space scope on the permission set) verbatim, wait for confirmation, re-run.
-3. Messaging channel is **Active** (assert status; activation is `service-digital-engagement-channel-configure`'s job, not the site-integrate skill's), **and** the widget is actually placed — independently re-read the deployed guest-layout JSON for the `experience_messaging:embeddedMessaging` node rather than trusting the site-integrate skill's 200-only signal; inject if missing.
+3. Messaging channel remains **Active** after the Agentforce routing deploy (assert; initial activation is the channel-configure skill's job, not the site-integrate skill's), **and** the widget is actually placed — independently re-read the deployed guest-layout JSON for the `experience_messaging:embeddedMessaging` node rather than trusting the site-integrate skill's 200-only signal; inject if missing.
 
 ### Checkpoint 4 — Review & Go Live
 Embed (LWR + Aura), then complete four explicit go-live steps: (a) wire the **Escalation Flow** to the agent (reuse `Help_Agent_Escalation_Flow` if it already exists — do not create a duplicate); (b) confirm the **Messaging Channel is Active** in Setup → Messaging Settings; (c) **Publish the Embedded Service Deployment** in Setup → Embedded Service Deployments; (d) offer to test together. An unpublished deployment or an inactive channel silently ships a dead widget.
 
 ## Rules / Constraints
 
+## Long-list presentation rules
+
+`AskUserQuestion` is capped at 4 options. For discovered item lists (sites, channels, queues, ADLs): **1–6 items** — paginate 3 per page, "Show more (N remaining)" as option 4, fixed options (Create new, etc.) on the final page only. **7+ items** — list names in plain text, ask the user to type their choice, validate case-insensitively, confirm before proceeding.
+
 | Rule | Rationale |
 |---|---|
 | Never one-shot the setup | It is a guided conversation; wait for user input at each checkpoint |
 | Never skip or reorder the readiness steps | Permission sets don't exist before Data Cloud enablement — you'll see `PermissionSet not found: GenieUserEnhancedSecurity` |
 | Never advance past 3.5 with empty ADL retrieval | Ships a silently-broken agent |
 | Never hardcode a site name or URL path prefix | The correct target LWR site depends on the customer's org — query first, then decide |
-| Never assume `SvcCopilotTmpl` / `EmployeeCopilot` are packages | They are OOB namespaces surfaced by `enableEinsteinGptPlatform`; probe the namespace directly |
-| Never wire an Embedded Service Deployment to an Aura (`ChatterNetwork`) site | It must target `ChatterNetworkPicasso` (LWR) or the widget will fail silently |
+| Never present ESW-prefixed sites as widget deployment targets | `ESW_*` sites are internal ESD endpoint scaffolding — filter them out in post-processing before presenting site options to the user |
 | Create the Embedded Service Deployment as V2 via the Connect API, never bare Metadata deploy — and embed the V2 ESD via the `experience_messaging:embeddedMessaging` LWR component | Metadata API defaults to legacy V1 (`WebV1`, *"Web (v1)"* in Setup) which breaks Enhanced Web Chat; create via Connect API on v67.0+ with `clientVersion: WebV2`. The customer widget mounts via the LWR component keyed on `deploymentName` (not a bootstrap `<script>`). Full six-attribute shape, the Tooling-API patch path, and guest-browser verification are in `references/channel-web-chat.md` — do NOT verify with <!-- skill-validate: ignore-start -->`curl \| grep`<!-- skill-validate: ignore-end --> |
 | Always create a dedicated ADL for the Help Agent — never wire the stock `All_Records_and_Fields_Default` library | On trial or preloaded sample-data orgs the stock library is stuck in `NOT_SCHEDULED` and never indexes; wiring the agent to it produces empty `knowledgeSummary` at runtime with no visible error. Create `Help_Agent_Knowledge` at Checkpoint 2 and wait for `indexingStatus ∈ {COMPLETED, READY, SUCCESS}` before wiring |
 | Never leave Checkpoint 4 without publishing the Embedded Service Deployment and activating the channel | Both are required for the widget to actually serve on the site. If the ESD was created via the Connect API `deployment/setup` call, it is already published — verify *"Published on:"* is stamped (not empty) and the title has no `(v1)` suffix |
-| Web Chat is the only buildable channel; Voice and Help Portal are hard stops | Coming-soon channels have no supporting skill — respond verbatim *"This feature is coming soon, please select Web Chat."* and re-present options; never scaffold. For Web Chat, always run the post-deploy assertion (re-fetch the MessagingChannel, assert `embeddedConfig.authMode`; default `UnAuth`) — a wrong choice silently ships a widget that won't render for guests. The report names `authMode` as a bare value (`authMode: UnAuth`); do not narrate the rationale or the assertion in the report. Never emit a legacy `esw.min.js` / Live Agent V1 snippet |
+| All three channel types are supported — Web Chat, Help Portal, and Voice | For Web Chat, always run the post-deploy assertion (re-fetch the MessagingChannel, assert `embeddedConfig.authMode`; default `UnAuth`) — a wrong choice silently ships a widget that won't render for guests. The report names `authMode` as a bare value (`authMode: UnAuth`); do not narrate the rationale or the assertion in the report. Never emit a legacy `esw.min.js` / Live Agent V1 snippet |
 
 ## Output Expectations
 
-The one deliverable is a single `report.md`: a **status report of what was decided and done**, not a design doc, plan, or architecture write-up. Two rules govern quality:
-
-1. **Report concrete outcomes, never intentions.** Write what *is* — the decided value, the created resource, the resolved ID — not what you *would* or *plan to* do. If a step could not run to completion because this is a non-interactive run, **decide the sensible default, state it as the decision, and report it as such** — do not stall on "awaiting confirmation," "to be resolved," "pending user input," or "please provide…". Hedging language ("will create", "to be executed", "once confirmed") reads as an unfinished plan and is scored as incomplete. Name the agent, the locale, the grounding source, `authMode`, the ADL name, the `rag_feature_config_id`, the site `UrlPathPrefix`, the ESD publish state — as settled facts.
-2. **No padding, no scaffolding prose.** No preamble, no design-doc sections, no restating the prompt. Dense, declarative lines only.
-
-**Before writing, choose the report shape by what the run actually did. There are three:**
-- **A coming-soon stop** — the run hard-stopped on a coming-soon channel (Voice / Help Portal).
-- **A settled-facts report** — the flow *executed a step*: the user directed a concrete action ("set up the grounding", "put it on <named site>") and every input was supplied or has a sensible skill-owned default. Report what was decided and done.
-- **A guided-decision report** — the flow is at a *decision the user owns*: an opening request with no agent details yet ("set up a help agent", "add a chat widget"), **or** a checkpoint surfacing multiple real alternatives the skill must not invent (e.g. several Live LWR sites). Presenting the checkpoint's questions/options *is* the deliverable; stay draft-first.
-
-Use the settled-facts report, not the guided-decision one, when the missing value is a mechanical default the skill can just pick (data category → org default) — decide it and report it done. Use the guided-decision report only when the choice genuinely belongs to the user (identity at an opener; which of several existing sites). The guided-decision report is **not** an escape hatch for hedging on an execute request.
-
-**Coming-soon stop — the flow hard-stopped on a coming-soon channel (Voice / Help Portal).** Short and fixed — the four H2 sections below, nothing more. Do NOT describe how Voice/Portal would be built, do NOT list architecture options, telephony, IVR, Amazon Connect, or "planning-only" steps — that content is an automatic fail. Write exactly:
-
-```markdown
-# Help Agent Setup Report
-
-## Blocking Issue
-<Channel> is a coming-soon channel with no supported setup path. Response given verbatim: "This feature is coming soon, please select Web Chat."
-
-## Channel Options
-- Web Chat — supported; the only buildable channel.
-- Voice / phone — coming soon, not available.
-- Help Portal — coming soon, not available.
-
-## No Provisioning Performed
-No Voice/telephony channel, phone number, messaging channel, or Embedded Service Deployment was created or configured. No supported channel was selected, so the flow did not proceed past the channel gate.
-
-## Next Action
-Re-run and select Web Chat as the channel.
-```
-
-**Settled-facts report — the flow ran (completed, or blocked on something other than a coming-soon channel).** Start with the exact H1 `# Help Agent Setup Report`, then the two tables and two short sections below, in order. Every cell is a **concrete, decided value** — a bare value, not a sentence. Keep prose out.
-
-**Report DECISIONS as settled facts, never placeholders or intentions.** This is a non-interactive run: you do not get to defer. Do NOT emit "to be captured", "not yet reached", "flow is paused", "awaiting", "once confirmed", or "will create". For a value the flow **decides** (agent name, locale, tone, ADL name, `authMode`, data category), state the concrete decision as done — a cell with nothing decided gets `None`. For an **opaque ID the run generates** (the `rag_feature_config_id`, a Salesforce record Id, a site's URL path prefix), report the **actual value produced this run** — never invent a plausible-looking one and never copy an ID from this template; if the run genuinely did not produce it, name that in Blocking Issues rather than fabricating. Hedging is scored as incomplete; fabricated IDs are scored as inaccurate. Include every value below and nothing else.
-
-**Scope the report to the checkpoint(s) the request targeted — do not narrate checkpoints the run never entered.** When the user directs a single checkpoint ("set up the grounding", "ground it on Knowledge" → Checkpoint 2 only), the report centers on that checkpoint. Fill its row with settled facts; give each checkpoint the run did **not** reach a bare `Not started` in its Decision cell — no plan, no "pending", no "not yet reached", no downstream detail. Do **not** manufacture a `Blocking Issues` entry or a `Next Action` about a later checkpoint you were never asked to run: if the targeted checkpoint completed, `Blocking Issues` is `None` and `Next Action` is the single next checkpoint by name (e.g. "Checkpoint 3 (channel) when you're ready"). A report that sprawls into unrequested checkpoints and hedges there is scored as incomplete even when the targeted checkpoint is perfect.
-
-**When the request centers on one decision, carry that decision's reasoning — not a bare value.** Some requests are about a single load-bearing choice: *why the readiness steps run in a specific order*, or *which `authMode` to pick and why*. For these, the targeted cell (or a short `## <Topic>` section right after the tables) must state the **decision, its rationale, and the concrete failure it avoids** — because that reasoning is the deliverable, not scaffolding:
-- **Readiness ordering** — give the ordered sequence (licenses / Einstein Agent User → **enable Data Cloud** → **assign Data Cloud permission sets**), say *why* the order is load-bearing (the permission sets do not exist until Data Cloud is enabled — assigning first fails with `PermissionSet not found: GenieUserEnhancedSecurity`), and warn that skipping the assignment yields empty runtime grounding even when ADL indexing reports SUCCESS. Do not compress this to "perm sets assigned". If Data Cloud is not yet enabled on this org, the Readiness row must say so — never assert "Data Cloud enabled; perm sets assigned" while `Blocking Issues` says it isn't; that contradiction is scored as inaccurate.
-- **`authMode` choice** — name the value (`UnAuth` for an anonymous-or-mixed audience), state the rationale (`UnAuth` allows **both** guests and authenticated upgrades via `identityToken`; `Auth` is authenticated-only and silently breaks the guest widget and the Setup "Test Enhanced Web Chat" page), confirm the audience it was chosen for, and state the assertion as a settled part of the flow — "the deployed MessagingChannel is re-fetched and `embeddedConfig.authMode = UnAuth` is asserted" — **present tense, not "will be re-fetched"**. Do not compress this to "authMode UnAuth". The `authMode` decision is complete once chosen: do **not** frame it as pending ("to be confirmed"), and do **not** manufacture a `Blocking Issues` entry or `Next Action` about the *adjacent* site-resolution step — a scoped `authMode` request is not blocked on the LWR site. If nothing stopped the scoped decision, `Blocking Issues` is `None`.
-
-The `‹…›` slots below mark where **this run's** real values go — replace each slot, never emit the slot text itself:
-
-```markdown
-# Help Agent Setup Report
-
-## Setup Summary
-| Field | Value |
-|---|---|
-| Readiness | Data Cloud enabled; perm sets assigned (GenieUserEnhancedSecurity, GenieAnalytics, DataSpacePermSet); Einstein Agent User assigned |
-| Failure mode guarded | Stock NOT_SCHEDULED ADL → empty knowledgeSummary; guarded via dedicated ADL, indexing gated to COMPLETED |
-| Delegation | agentforce-generate → agent + ADL; dx-org-permission-set-assign → Data Cloud perms; service-digital-engagement-* → channel + ESD |
-
-## Checkpoint Outcomes
-| # | Checkpoint | Decision |
-|---|---|---|
-| 1 | Identity | ‹agent name› (‹DeveloperName›), ‹locale›, ‹tone› |
-| 2 | Grounding | Salesforce Knowledge via agentforce-generate; dedicated ADL ‹library name› (stock All_Records_and_Fields_Default not wired); indexing gated to COMPLETED before wiring; rag_feature_config_id ‹ARFPC_ id from this run's adl publish› captured |
-| 3 | Channel | Web Chat; authMode ‹UnAuth or Auth›; site ‹target site UrlPathPrefix›; ESD HelpChat WebV2 — *or* `Not started` if the run never entered this checkpoint |
-| 4 | Go-live | ESD Published; channel Active; escalation flow wired — *or* `Not started` |
-
-## Blocking Issues
-‹the one thing that actually stopped the flow — one line — or `None`›
-
-## Next Action
-One line — the single next step for the user.
-```
-
-Non-slot values above (Data Cloud, perm-set names, `HelpChat WebV2`, delegation targets) are the skill's canonical defaults — reproduce them as-is. Fill the `‹…›` slots from this run (including `authMode`, which is decided per run from the Step B choice — do not default it in the report). **Any checkpoint the run did not reach gets a bare `Not started` — not a plan, forecast, or "pending" note.** For a request scoped to one checkpoint (e.g. Checkpoint 2 grounding), only that row carries settled facts; rows 3 and 4 read `Not started`, `Blocking Issues` is `None`, and `Next Action` names the next checkpoint (e.g. "Checkpoint 3 (channel) when you're ready").
-
-**Blocked run?** `Blocking Issues` is the one sanctioned place to state a real blocker — one honest line there (e.g. "multiple Live LWR sites — asked user to choose"; "Knowledge data category not specified — chose the org's default group") is **required and is not hedging**. It records what stopped a checkpoint the run *actually entered* — never a checkpoint the request never targeted (a scoped Checkpoint-2 run is not "blocked" on Checkpoint 3). Keep the checkpoint cells decisive for what *was* settled; put the single unresolved thing here. What is scored as incomplete is hedging *inside the decision cells* ("to be captured", "not yet", "pending") — not a clear one-line blocker in this section.
-
-**Guided-decision report — a decision the user owns.** Here the deliverable is *the decision point itself*, presented cleanly. This is not hedging: at an opener or a genuine fork, asking with sensible defaults is the correct, complete response. Do **not** provision, deploy, or fabricate the value the user still owns. Orient, present the current checkpoint's choices with defaults, sketch what the remaining checkpoints will cover, and confirm nothing is live yet. Use exactly these sections:
-
-```markdown
-# Help Agent Setup Report
-
-## Guided Setup
-Help Agent setup runs as four checkpoints: identity → grounding → channel → go-live. Nothing is created, deployed, or published until you confirm at each step.
-
-## Current Checkpoint
-Checkpoint ‹n — name›. This agent will ‹map the user's stated needs to the design in one line: knowledge-grounded Q&A from Salesforce Knowledge, support-case create/update, and escalation to a live human when needed›, delivered as ‹the channel the user named, e.g. a Web Chat widget on their site›.
-
-## Decisions Needed
-- ‹Question 1 — offered default› (e.g. Agent name — `Help Agent`, API name `Help_Agent`)
-- ‹Question 2 — offered default› (e.g. Language — `en_US`)
-- ‹Question 3 — offered default› (e.g. Greeting, Tone)
-- ‹…the real choices for THIS checkpoint only; for a multi-option fork, list the actual alternatives found (e.g. each Live LWR site by Name + UrlPathPrefix) and never pick for the user›
-
-## Checkpoint Roadmap
-- Readiness (silent, before provisioning): confirm licenses / Einstein Agent User → enable Data Cloud → assign the Data Cloud permission sets, in that order.
-- 2 Grounding: connect Salesforce Knowledge via a dedicated Agentforce Data Library, indexing gated to COMPLETED.
-- 3 Channel: deploy the chosen channel + Embedded Service Deployment; confirm `authMode` from who will be chatting.
-- 4 Go-live: embed, publish, and verify with a live round-trip — only after you confirm.
-
-## Next Action
-Reply with your choices (or accept the defaults) and I'll proceed to the next checkpoint. Nothing is created, grounded, embedded, or published until you confirm at each step.
-```
-
-Fill every `‹…›` from this run's context. Keep to these five sections — the Roadmap names what later checkpoints will do (it is not a settled-fact table and must not claim any of it is done); no provisioning tables, no settled-fact cells for steps not yet reached.
+The one deliverable is a single `report.md`: a **status report of what was decided and done**, not a design doc. Two shapes exist — a **settled-facts report** when the flow executed a step (concrete decided values in tables), and a **guided-decision report** when the flow is at a decision the user owns (present the choices, do not fabricate). Never hedge inside decision cells ("to be captured", "pending", "will create"); never fabricate opaque IDs; never manufacture blockers on checkpoints the request did not target. Full templates, per-shape rules, one-decision reasoning callouts (readiness ordering, `authMode`), and the "never include" scored-failure list live in **`references/output-report-format.md`** — read it before writing the report.
 
-**Never include** (each is a scored failure): a preamble restating the prompt or the request; "End of report." trailers; decorative `---` / `===` rules; `Scope`, `Assumptions`, `Out-of-Scope`, `Architecture`, `Options Considered`, `Next Steps`, `Steps:`, or `Outcome Gate:` sections; the checkpoints re-listed as questions; the agent script or reference-file contents pasted inline; emoji; marketing adjectives ("seamless", "robust", "powerful", "comprehensive").
 
 ## Reference File Index
 
@@ -252,5 +247,6 @@ Fill every `‹…›` from this run's context. Keep to these five sections —
 | `assets/help-agent-spec.md` | Always (first) — the canonical flow; small by design. Points to the files below |
 | `references/agent-script.md` | At agent creation only (after Checkpoint 2) — the canonical agent script + placeholders |
 | `references/channel-web-chat.md` | Only if the user selects Web Chat at Checkpoint 3 |
-| `references/channel-help-portal.md` | Only if the user selects Help Portal (coming-soon hard stop) |
-| `references/channel-voice.md` | Only if the user selects Voice (coming-soon hard stop) |
+| `service-concierge-portal-generate` (external skill) | Only if the user selects Help Portal at Checkpoint 3 — delegate, do not inline |
+| `references/channel-voice.md` | Only if the user selects Voice (wires an existing `PstnVoice` channel; no number provisioning) |
+| `references/output-report-format.md` | Right before writing the final `report.md` — the two report shapes, templates, and scored-failure list |