/life-sciences-fieldsalesrep-coordinate

name: life-sciences-fieldsalesrep-coordinate
description: "Use this skill to run the full end-to-end Life Sciences Cloud setup workflow for field sales rep in sequence. Trigger when the user says 'set up Life Sciences Cloud end to end', 'run the full LSC setup', 'orchestrate Life Sciences Cloud configuration', 'complete LSC setup', 'Life Sciences Cloud full install', 'set up Life Sciences Cloud end to end for field sales rep', 'run the full LSC setup for field sales rep', 'orchestrate Life Sciences Cloud configuration for field sales rep', 'complete LSC setup for field sales rep', or 'Life Sciences Cloud full install for field sales rep'. Executes five stages in order: prerequisites validation, starter config deployment, territory configuration, user provisioning, and sample visit creation — gating each stage on the success of the previous one. DO NOT TRIGGER when: user wants to run only one specific stage (prerequisites, config deploy, territory setup, user provisioning, or visit creation individually)."
metadata:
  version: "1.0"
  minApiVersion: "65.0"
  domains: ["Life Sciences"]
  relatedSkills:
    - life-sciences-prerequisites-validate
    - life-sciences-territory-configure
  cliTools:
    - tool: ["git"]
      semver: ">=2.25.0"
    - tool: ["jq"]
      semver: ">=1.6"
    - tool: ["sf"]
      semver: ">=2.0.0"

Life Sciences Cloud End-to-End Orchestrator

Runs the complete Life Sciences Cloud setup workflow as five **stages** in strict sequence, gating each on the success of the previous stage. Each stage delegates to a child skill or a reference workflow, organized internally into **phases** and **steps** (defined under Execution Order below).

Scope Guard (evaluate FIRST)

Serve **only** requests for the full end-to-end LSC setup. A single stage/phase/step is **never** invokable here — never silently expand a partial ask into the whole flow. Before any work:

• **Unrelated** to LSC setup (at start or mid-run) → do not attempt it. Tell the user you did not understand the request and show what you can help with (full end-to-end LSC setup, or standalone `life-sciences-prerequisites-validate` / `life-sciences-territory-configure`); stop.
• Stage with its **own standalone skill** — prerequisites (Stage 1) or territory config (Stage 3) → redirect to `life-sciences-prerequisites-validate` / `life-sciences-territory-configure`; stop.
• Stage with **no standalone skill** — config deploy (2), user provisioning (4), visit creation (5) → explain these run only as part of the full flow, not on their own; stop. Do **not** launch the full flow unless the user then asks for it.

Continue only for the complete end-to-end setup: orchestrating the full flow (prerequisites → config deploy → territory → user provisioning → visit creation) in order with gates. Each stage's actual work is delegated to child skills / reference files.

---

Required Inputs

Gather before proceeding:

• **Target org**: The org to deploy to — selected by the user from the list of connected orgs, or a freshly authenticated org (see Phase 0). Never assume a default org silently; always have the user confirm or select the target org before any stage runs.

---

Execution Order (MANDATORY)

> **Terminology:** **Stage** = one of the 5 units of work (1–5), each delegated to a child skill or a reference workflow; **Phase** = a named group of work inside a stage; **Step** = an atomic action inside a phase. So "Stage 2 › Phase 1 › Step 3" reads top-to-bottom.

Run in this order, each gated on the previous (see the full dependency diagram in `references/orchestration-flow.md`):

| # | Stage | Runs | Gate (must pass to advance) | Output | |---|-------|------|------------------------------|--------| | — | **Setup**: download `.lsc-starter-config/LSStarterConfig` | — | Folder present (MANDATORY — hard stop) | Shared source folder in CWD | | 1 | Prerequisites Validation | `life-sciences-prerequisites-validate` skill | All prerequisites PASS | Org confirmed ready | | 2 | Starter Config Deploy | `references/stage-2-starter-config-overview.md` | All 13 deploy steps succeed | LSC Custom Profile exists | | 3 | Territory Configuration | `life-sciences-territory-configure` skill | Territory model Active + L3 territory | Level-3 territory ID + name | | 4 | User Provisioning | `references/stage-4-user-provisioning-overview.md` | User created, permsets + territory assigned | Rep username | | 5 | Sample Visit Creation | `references/stage-5-visit-creation-overview.md` | Visit + supporting records created; metadata cache generated | — |

---

Workflow

Phase 0 — Org Selection (MANDATORY, runs first)

Before presenting the workflow, establish which org to use. Do this **every time** the user asks to set up Life Sciences Cloud — do not silently reuse the current default org.

1. **List connected orgs**:

   sf org list --json

Parse the result and present the authenticated orgs (non-expired) to the user as a numbered list — include alias, username, org type (Dev Hub / Sandbox / Scratch / Production), and the default marker if any:

   Connected Orgs — select the target for Life Sciences Cloud setup
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
     1. ls-dev        alice@example.com          (Dev Hub)   [default]
     2. ls-sandbox    alice@example.com.sandbox  (Sandbox)
     3. partial-scr   test-xyz@example.com       (Scratch)

     N. Log in to a fresh org (opens a browser to authenticate a new org)

2. **Ask the user to choose**: "Which org would you like to use? Enter a number, or choose **N** to log in to a fresh org."

3. **Handle the selection**:

• **Existing org chosen** → capture its username/alias as the target org for all subsequent steps.
• **Fresh org chosen (option N)** → authenticate a new org interactively: ask for the login URL (My Domain / instance URL, e.g. `https://mydomain.my.salesforce.com`; `https://login.salesforce.com` for produ