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

service helpagent coordinate: Service Cloud Help Agent, guided setup Use this skill to stand up a Service Cloud Help Agent (an Agentforce Service Agent) on a Salesforce org from Claude Code, following the same guided flow as the Help Agent Quick Setup wizard. This is a coordinate skill: it orchestrates existing skills against a canonical spec — it does not author a new agent primitive. Why this skill exists Salesforce's official Help Agent template creation API is not yet shipped. Without it, Claude has no built in concept of "Help Agent" and would otherwise generate a generic agent. assets/help agent spec.md substitutes for the missing API: its agent script is the canonical template the eventual Quick Start UI will produce. Treat the spec as source of truth for the agent's lineage (topics, actions, instructions). Scope In scope: Guided, four checkpoint Help Agent setup (identity → grounding → channel → go live) Knowledge grounding via Agentforce Data Library (ADL) Web Chat / Help Portal channel setup and Experience Cloud site embed Readiness checks (licenses, Einstein Agent User, Data Cloud permission sets) Out of scope — delegate elsewhere: OAuth / External Client App setup → [integration connectivity connected app configure](../integration connectivity connected app configure/SKILL.md) Raw agent authoring with no Help Agent lineage → agentforce generate Metadata deploy/retrieve → platform metadata deploy Prerequisites Claude Code + Salesforce CLI installed and an authenticated org (see repo README.md ) MCP servers registered: salesforce api context , metadata experts , sobject reads Salesforce Skills installed into .agents/skills/ (or .claude/skills/ ) A Salesforce org with the required features enabled (or enable able via metadata): Agentforce, Einstein Generative AI, Knowledge, Experience Cloud, and Data Cloud. Any org shape that meets this bar works — production, sandbox, scratch, or Developer Edition. The readiness check in assets/help agent spec.md §4.0 detects each feature and enables what can be enabled; it stops with a clear message if a required capability is missing and cannot be turned on. Skills this coordinates The spec feeds these existing skills — do not author a new Help Agent skill: Skill Role 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 + 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 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: 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. 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 PSL seat availability, then create a dedicated Einstein Agent User for this agent. First confirm the three required PSLs have available seats: 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 . AgentforceKnowledgeUser (Permission Set, force namespace) — 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: 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. The PSG assigned in step 1 covers this once Data Cloud is on. Recognizing where the user is entering 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 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

service-helpagent-coordinate