kris/afv-library
1
0
Fork 0
mirror of https://github.com/forcedotcom/afv-library.git synced 2026-08-07 08:04:28 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity

feat: add Pre-Work Brief skills (base + customization)

Browse Source 
Adds two complementary skills for setting up and customizing the
Field Service Mobile Pre-Work Brief feature.

skills/setting-up-pre-work-brief/

End-to-end setup of Pre-Work Brief on a Salesforce org with the
Einstein for Field Service add-on. Detects provisioning state, enables
Lightning Data Service, deploys the prompt template, assigns permission
sets, adds the PreWorkBriefPromptTemplate field to the Work Order
layout, and creates a fresh test Work Order + Service Appointment so
the admin can validate on-device immediately. Verified end-to-end
against an Einstein for Field Service trial org, May 2026.

skills/customizing-pre-work-brief/

Generator-pattern skill for vertical-specific Pre-Work Briefs deployable
as code. The admin provides industry, website, and a sentence about
what their technicians do; the skill produces custom objects, an
autolaunched PromptFlow, a sibling prompt template, a permission set,
and a test Work Order. Loads vertical-specific seed templates from
templates/<industry>.md.

Five seeds ship:
  - hvac.md (verified end-to-end on a trial org, May 2026)
  - banking.md, telecom.md, healthcare.md, retail-merchandising.md
    (scaffolds; ready for the next admin in those verticals to verify)

Each seed contributes recommended custom objects, a section structure
for the prompt template, vertical-specific rules, and a cadence example.
For verticals not in the library, --industry other synthesizes a draft
seed at runtime and writes it back to templates/ for next time.

The two skills compose: base setup gets PWB working at all on the
managed flow; customizing builds a parallel customer-specific bundle.
This commit is contained in:
Nitasha Walia 2026-05-20 09:53:01 -07:00
parent 338dd0c7e4
commit cc7c475b01
7 changed files with 2088 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

539
skills/customizing-pre-work-brief/SKILL.md Normal file
View File

@ -0,0 +1,539 @@
---
name: customizing-pre-work-brief
description: "Generate a vertical-specific Pre-Work Brief on Field Service Mobile, deployable as code. The admin provides industry, website, and a sentence describing what their technicians do; this skill produces custom objects, an autolaunched flow, a prompt template, a permission set, and a test record. TRIGGER when: user wants Pre-Work Brief tailored to their company or industry; user wants the brief to reference custom objects or fields specific to their business; user mentions website-grounded or vertical-specific briefs; user wants a second 'customized' brief alongside the default; user asks to clone or extend the managed Field Service flow; user references a specific vertical (HVAC, banking, telecom, healthcare, retail merchandising). DO NOT TRIGGER when: org has not yet completed base setup (use setting-up-pre-work-brief first); user wants Voice to Form; user wants Post-Work Summary; user wants a brand-new prompt template type from scratch (use Prompt Builder docs)."
allowed-tools: Bash Read Write Edit Glob Grep WebFetch
license: Apache-2.0
metadata:
version: "0.2.0"
last_updated: "2026-05-20"
argument-hint: "<org-alias> --company <name> --industry <hvac|banking|telecom|healthcare|retail-merchandising|other> --website <url> [--description <text>] [--service-resource <id>]"
compatibility: claude-code
---
# Customizing Pre-Work Brief
Generate a vertical-specific Pre-Work Brief that grounds on the customer's business and the data model their technicians actually work with. The skill produces a deployable bundle — custom objects, autolaunched flow, prompt template, permission set, plus a test Work Order — so an admin goes from "the default brief works but feels generic" to "the brief reads like someone who knows our business wrote it" in one run.
This skill is the second half of a two-step adoption journey. Step one — `setting-up-pre-work-brief` — gets PWB working at all on the managed flow. Step two — this skill — replaces the managed flow with a customer-specific bundle deployable entirely from metadata. No Save-As click in Flow Builder is required; the only manual step is one click to activate the prompt template, consistent with the base setup pattern.
The skill is **vertical-agnostic by design.** It ships with seed templates for common Field Service archetypes (HVAC, banking, telecom, healthcare, retail merchandising) at `templates/<industry>.md`. The seed contributes a section structure, recommended custom objects, and grounding patterns. For verticals not in the library, the skill synthesizes from the website + admin description and adds the result back into `templates/` for next time.
---
## Prerequisites
The base setup must be complete. Run `setting-up-pre-work-brief` against the same org first if any of the checks below fail:
```bash
ORG_ALIAS="${1:-}"
[ -z "$ORG_ALIAS" ] && { echo "Usage: customizing-pre-work-brief <org-alias> --company <name> --industry <vertical> --website <url>"; exit 1; }
echo "Checking base setup is in place..."
sf org list metadata --metadata-type GenAiPromptTemplate --target-org "$ORG_ALIAS" --json | \
jq -r '[.result[]? | select(.fullName == "Pre_Work_Brief")] | length as $n |
if $n > 0 then "✓ Default Pre_Work_Brief template deployed" else "✗ Default template missing — run setting-up-pre-work-brief first" end'
sf data query --target-org "$ORG_ALIAS" \
--query "SELECT DeveloperName FROM PermissionSetLicense WHERE DeveloperName = 'EinsteinFieldServicePsl' AND TotalLicenses > 0" --json | \
jq -r '.result.totalSize as $n | if $n > 0 then "✓ Einstein for Field Service PSL present" else "✗ PSL missing — run setting-up-pre-work-brief first" end'
sf sobject describe --sobject WorkOrder --target-org "$ORG_ALIAS" --json | \
jq -r '[.result.fields[]? | select(.name == "PreWorkBriefPromptTemplate")] | length as $n |
if $n > 0 then "✓ PreWorkBriefPromptTemplate field present" else "✗ Field missing — run setting-up-pre-work-brief first" end'
```
All three must report `✓` before continuing.
---
## Args
| Arg | Required | Default | Purpose |
|---|---|---|---|
| `<org-alias>` | yes | — | Target org. |
| `--company <name>` | yes | — | Company name. Used in the prompt template label and in business context generation. |
| `--industry <vertical>` | yes | — | One of: `hvac`, `banking`, `telecom`, `healthcare`, `retail-merchandising`, or `other`. Picks the seed template at `templates/<industry>.md`. If `other`, the skill synthesizes a template at runtime. |
| `--website <url>` | yes | — | Public website URL. The skill fetches the homepage to derive technician context. |
| `--description <text>` | no | (admin prompted) | 1-2 sentence description of what the company's technicians actually do on-site. If omitted, the skill asks. |
| `--service-resource <id>` | no | (admin prompted) | ServiceResource Id to assign the test Service Appointment to. |
| `--customized-template-name <name>` | no | `PreWorkBrief_<Industry>_<Company>` | Developer name of the new prompt template. Increment if running multiple times for the same org. |
Parse args:
```bash
COMPANY=""
INDUSTRY=""
WEBSITE=""
DESCRIPTION=""
SERVICE_RESOURCE_ID=""
TEMPLATE_NAME=""
while [ $# -gt 0 ]; do
case "$1" in
--company) COMPANY="$2"; shift 2 ;;
--industry) INDUSTRY="$2"; shift 2 ;;
--website) WEBSITE="$2"; shift 2 ;;
--description) DESCRIPTION="$2"; shift 2 ;;
--service-resource) SERVICE_RESOURCE_ID="$2"; shift 2 ;;
--customized-template-name) TEMPLATE_NAME="$2"; shift 2 ;;
*) shift ;;
esac
done
[ -z "$COMPANY" ] && { echo "--company is required"; exit 1; }
[ -z "$INDUSTRY" ] && { echo "--industry is required (hvac|banking|telecom|healthcare|retail-merchandising|other)"; exit 1; }
[ -z "$WEBSITE" ] && { echo "--website is required"; exit 1; }
# Default template name
if [ -z "$TEMPLATE_NAME" ]; then
CLEAN_COMPANY=$(echo "$COMPANY" | tr -cd '[:alnum:]_')
CLEAN_INDUSTRY=$(echo "$INDUSTRY" | tr '[:lower:]' '[:upper:]' | head -c 1)$(echo "$INDUSTRY" | tail -c +2)
TEMPLATE_NAME="PreWorkBrief_${CLEAN_INDUSTRY}_${CLEAN_COMPANY}"
fi
```
---
## Step 1: Build the business context
Combine the company website with the admin's description into a short technician-facing brief.
**1a. Fetch the website.**
Use Claude's `WebFetch` tool against `$WEBSITE` with the prompt:
> Read this company's homepage and any obvious sub-pages. Return a 5-bullet summary of (1) what the company does, (2) the products or services they sell, (3) who their typical customer is, (4) what kind of work a field technician would perform on-site for them, (5) any specialized equipment, certifications, or terminology a technician would need to know. Keep it factual and pulled directly from the page. Do not invent details.
Capture the response as `$WEBSITE_SUMMARY`.
**1b. Get the admin's description.**
If `--description` was passed, use it directly. Otherwise ask:
> "In 1-2 sentences, what do your technicians actually do on-site for this business?"
Capture as `$ADMIN_DESCRIPTION`.
**1c. Synthesize.**
Combine `$WEBSITE_SUMMARY` and `$ADMIN_DESCRIPTION` into a single 3-5 sentence paragraph saved as `$BUSINESS_CONTEXT`. Show the result to the admin and ask for sign-off before continuing.
---
## Step 2: Load the vertical seed template
```bash
SEED_PATH="templates/${INDUSTRY}.md"
if [ -f "$SEED_PATH" ]; then
echo "✓ Found seed template at $SEED_PATH"
SEED=$(cat "$SEED_PATH")
else
echo "No seed for industry '$INDUSTRY'. Synthesizing one from business context."
INDUSTRY="other"
SEED=""
fi
```
The seed contributes:
- **Section structure** for the prompt template (e.g., HVAC = Mission and contact / Customer and SLA / Site access and certifications / Equipment and refrigerant context).
- **Recommended custom objects** with the fields each typically carries.
- **Standard objects + fields** to query in the flow.
- **Cadence example** to anchor the model's tone.
If the seed doesn't exist, the skill writes one at the end of the run so the next admin in the same vertical gets it.
---
## Step 3: Audit the org's existing schema
Some of what the seed proposes may already exist in the org. Audit before creating duplicates.
```bash
GROUNDING_OBJECTS="Account Asset Contact Case WorkOrder WorkOrderLineItem ServiceAppointment WorkPlan WorkStep"
EXCLUDE_NAMESPACES="FSL__,FSSK__,SDO__,FSLDemoTools__"
for obj in $GROUNDING_OBJECTS; do
echo ""
echo "Custom fields on $obj:"
sf sobject describe --sobject "$obj" --target-org "$ORG_ALIAS" --json 2>/dev/null | \
jq -r --arg obj "$obj" --arg exclude "$EXCLUDE_NAMESPACES" '
($exclude | split(",")) as $ns_list |
.result.fields[]?
| select(.name | endswith("__c"))
| . as $f
| select(any($ns_list[]; . as $ns | $f.name | startswith($ns)) | not)
| " \($obj).\(.name) | type=\(.type) | label=\(.label)"
'
done > /tmp/pwb-existing-customs.txt
# Check whether the seed's recommended custom objects already exist
sf sobject list --target-org "$ORG_ALIAS" --sobject-type custom --json | \
jq -r '.result[]?' > /tmp/pwb-existing-objects.txt
cat /tmp/pwb-existing-customs.txt
echo ""
echo "Existing custom objects: $(wc -l < /tmp/pwb-existing-objects.txt)"
```
Cross-reference against the seed's recommended objects. For each recommended object:
- Already exists → skip object creation, audit its fields.
- Doesn't exist → propose to admin for creation.
Show the diff to the admin and ask for confirmation before deploying anything.
---
## Step 4: Generate and deploy custom objects
For each approved custom object, write metadata files. The general shape (using HVAC's `Refrigerant_Log__c` as an illustration; the actual fields come from the seed):
```xml
<?xml version="1.0" encoding="UTF-8"?>
<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">
<deploymentStatus>Deployed</deploymentStatus>
<description>{seed-supplied description}</description>
<enableActivities>true</enableActivities>
<enableHistory>true</enableHistory>
<enableReports>true</enableReports>
<enableSearch>true</enableSearch>
<label>{seed-supplied label}</label>
<nameField>
<label>{Object} Number</label>
<type>AutoNumber</type>
<displayFormat>{prefix}-{0000}</displayFormat>
<startingNumber>1</startingNumber>
</nameField>
<pluralLabel>{seed-supplied plural label}</pluralLabel>
<sharingModel>ReadWrite</sharingModel>
</CustomObject>
```
Lookup field rules to avoid the "must specify either cascade delete or restrict delete" deploy error:
```xml
<?xml version="1.0" encoding="UTF-8"?>
<CustomField xmlns="http://soap.sforce.com/2006/04/metadata">
<fullName>Asset__c</fullName>
<deleteConstraint>SetNull</deleteConstraint>
<label>Asset</label>
<referenceTo>Asset</referenceTo>
<relationshipLabel>Refrigerant Logs</relationshipLabel>
<relationshipName>Refrigerant_Logs</relationshipName>
<type>Lookup</type>
</CustomField>
```
Note: do not set `<required>true</required>` on lookups — pair it with `<deleteConstraint>` or the deploy fails. For the customs the brief queries, optional lookups are fine.
If any new lookup goes onto WorkOrder (e.g., `WorkOrder.Maintenance_Contract__c`), write that field too — the flow will reference it via `$Input.WorkOrder.<New_Field>__c`.
Deploy:
```bash
mkdir -p /tmp/pwb-custom-build/force-app/main/default
cat > /tmp/pwb-custom-build/sfdx-project.json <<'EOF'
{"packageDirectories":[{"path":"force-app","default":true}],"namespace":"","sourceApiVersion":"65.0"}
EOF
# (Write all object + field XMLs into /tmp/pwb-custom-build/force-app/main/default/objects/...)
cd /tmp/pwb-custom-build
sf project deploy start --target-org "$ORG_ALIAS" --source-dir force-app --wait 30 --api-version 65.0
```
---
## Step 5: Generate the from-scratch flow
Write a `PromptFlow` flow that grounds on the relevant standard objects + the new customs. The pattern (verified working against the `afvuser` trial org, 2026-05-20):
- `<processType>PromptFlow</processType>`
- `<apiVersion>65.0</apiVersion>` (the managed flow's `getCustomerSignalsInsights` action requires v65+; from-scratch flows that don't use it can stay lower, but 65 is the safe default)
- `<start>` block has `<triggerType>Capability</triggerType>` and a `<capabilityTypes>` element declaring `PromptTemplateType://einstein_gpt__fieldServicePreWorkBrief` with a `WorkOrder` SObject input
- A chain of `<recordLookups>` elements with `getFirstRecordOnly=true` (single-record references resolve cleanly; collections require Loops which complicate the demo)
- An `<assignments>` element with `<elementSubtype>AddPromptInstructions</elementSubtype>` that builds `$Output.Prompt` from grounded references
Skeleton:
```xml
<?xml version="1.0" encoding="UTF-8"?>
<Flow xmlns="http://soap.sforce.com/2006/04/metadata">
<apiVersion>65.0</apiVersion>
<description>{Industry}-specific Pre-Work Brief grounding flow for {Company}.</description>
<interviewLabel>Pre-Work Brief {Industry} {!$Flow.CurrentDateTime}</interviewLabel>
<label>Pre-Work Brief {Industry} Custom</label>
<processType>PromptFlow</processType>
<status>Active</status>
<start>
<locationX>0</locationX>
<locationY>0</locationY>
<capabilityTypes>
<name>PromptTemplateType://einstein_gpt__fieldServicePreWorkBrief</name>
<capabilityName>PromptTemplateType://einstein_gpt__fieldServicePreWorkBrief</capabilityName>
<inputs>
<name>WorkOrder</name>
<capabilityInputName>WorkOrder</capabilityInputName>
<dataType>SOBJECT://WorkOrder</dataType>
<isCollection>false</isCollection>
</inputs>
</capabilityTypes>
<connector>
<targetReference>{first lookup}</targetReference>
</connector>
<triggerType>Capability</triggerType>
</start>
<!-- recordLookups, then a single assignments that builds $Output.Prompt -->
</Flow>
```
The seed at `templates/<industry>.md` enumerates which lookups to chain, what each queries, and how `$Output.Prompt` is structured.
Deploy:
```bash
cd /tmp/pwb-custom-build
sf project deploy start --target-org "$ORG_ALIAS" --source-dir force-app/main/default/flows --wait 30 --api-version 65.0
```
Activate the flow (deploying with `<status>Active</status>` is necessary but not sufficient — Salesforce treats it as draft until explicitly activated):
```bash
FD_ID=$(sf data query --target-org "$ORG_ALIAS" --use-tooling-api \
--query "SELECT Id FROM FlowDefinition WHERE DeveloperName = '${TEMPLATE_NAME}_Flow'" --json | \
jq -r '.result.records[0].Id')
LATEST_VERSION=$(sf data query --target-org "$ORG_ALIAS" --use-tooling-api \
--query "SELECT VersionNumber FROM Flow WHERE Definition.DeveloperName = '${TEMPLATE_NAME}_Flow' ORDER BY VersionNumber DESC LIMIT 1" --json | \
jq -r '.result.records[0].VersionNumber')
cat > /tmp/activate-flow.json <<EOF
{"Metadata": {"activeVersionNumber": $LATEST_VERSION}}
EOF
sf api request rest --target-org "$ORG_ALIAS" --method PATCH \
"/services/data/v65.0/tooling/sobjects/FlowDefinition/$FD_ID" \
--body @/tmp/activate-flow.json
```
---
## Step 6: Generate the prompt template
Build a `GenAiPromptTemplate` with three sections from the seed: business-context paragraph, flow reference, instruction block (sections + rules + cadence example). The flow reference is the single line:
```
{!$Flow:<flow-developer-name>.Prompt}
```
Skeleton:
```xml
<?xml version="1.0" encoding="UTF-8"?>
<GenAiPromptTemplate xmlns="http://soap.sforce.com/2006/04/metadata">
<developerName>{TEMPLATE_NAME}</developerName>
<masterLabel>Pre-Work Brief — {Company} ({Industry})</masterLabel>
<templateVersions>
<content>You are briefing a {Industry} field technician on the job they are about to perform on-site. Address the technician directly, in the second person.
Business context (do not contradict):
{BUSINESS_CONTEXT}
Specific job grounding:
{!$Flow:{flow-developer-name}.Prompt}
{INSTRUCTION_BLOCK from seed — sections + rules + cadence example}
</content>
<inputs>
<apiName>WorkOrder</apiName>
<definition>SOBJECT://WorkOrder</definition>
<referenceName>Input:WorkOrder</referenceName>
<required>true</required>
</inputs>
<primaryModel>sfdc_ai__DefaultOpenAIGPT4OmniMini</primaryModel>
<status>Published</status>
<templateDataProviders>
<definition>flow://{flow-developer-name}</definition>
<parameters>
<definition>SOBJECT://WorkOrder</definition>
<isRequired>true</isRequired>
<parameterName>WorkOrder</parameterName>
<valueExpression>{!$Input:WorkOrder}</valueExpression>
</parameters>
<referenceName>Flow:{flow-developer-name}</referenceName>
</templateDataProviders>
</templateVersions>
<type>einstein_gpt__fieldServicePreWorkBrief</type>
<visibility>Global</visibility>
</GenAiPromptTemplate>
```
Deploy and surface the activation deeplink:
```bash
cd /tmp/pwb-custom-build
sf project deploy start --target-org "$ORG_ALIAS" --source-dir force-app/main/default/genAiPromptTemplates --wait 30 --api-version 65.0
# Resolve the template Id
TEMPLATE_ID=$(sf api request rest "/services/data/v62.0/einstein/prompt-templates?pageSize=200" --target-org "$ORG_ALIAS" 2>/dev/null | \
python3 -c "
import sys, json, os
d = json.loads(sys.stdin.read())
name = os.environ.get('TEMPLATE_NAME')
for t in d.get('promptRecords', []):
if t.get('fields', {}).get('DeveloperName', {}).get('value') == name:
print(t.get('fields', {}).get('Id', {}).get('value'))
break")
# Fall back to deploy report if runtime catalog hasn't picked it up yet
if [ -z "$TEMPLATE_ID" ]; then
for did in $(sf data query --target-org "$ORG_ALIAS" --use-tooling-api \
--query "SELECT Id FROM DeployRequest WHERE NumberComponentsDeployed > 0 ORDER BY CompletedDate DESC LIMIT 10" --json | \
jq -r '.result.records[]?.Id'); do
cand=$(sf project deploy report --target-org "$ORG_ALIAS" --job-id "$did" --json 2>/dev/null | \
jq -r ".result.details.componentSuccesses[]? | select(.componentType == \"GenAiPromptTemplate\" and .fullName == \"$TEMPLATE_NAME\") | .id" | head -1)
[ -n "$cand" ] && TEMPLATE_ID="$cand" && break
done
fi
echo ""
echo " ⚠ Action required: click Activate in Prompt Builder."
echo " The template is deployed and Published, but until activated, it"
echo " won't appear in the runtime catalog. The mobile app will fail with"
echo " 'We hit a snag' until activation is complete."
echo ""
echo " Generating sign-in link to the template (valid ~15 minutes):"
sf org open --target-org "$ORG_ALIAS" \
--path "/lightning/setup/EinsteinPromptStudio/$TEMPLATE_ID/edit" \
--url-only 2>&1 | grep -oE 'https://[^[:cntrl:][:space:]]+frontdoor[^[:cntrl:][:space:]]+' | head -1 | sed 's/\x1b\[[0-9;]*m//g'
```
Pause until the admin confirms activation. Verify:
```bash
sf api request rest "/services/data/v62.0/einstein/prompt-templates?pageSize=200" --target-org "$ORG_ALIAS" 2>/dev/null | \
python3 -c "
import sys, json, os
d = json.loads(sys.stdin.read())
name = os.environ.get('TEMPLATE_NAME')
hit = [t for t in d.get('promptRecords', []) if t.get('fields', {}).get('DeveloperName', {}).get('value') == name]
print('✓ Active in runtime catalog' if hit else '✗ Not yet active — click Activate in Prompt Builder')"
```
> **Why a click is still required.** Salesforce does not currently expose a programmatic activation path for `GenAiPromptTemplate`. We tried Tooling REST PATCH on `IsActive`, Connect API `/activate` endpoints across v62-v66, Apex `ConnectApi.EinsteinLLM` methods, and metadata `activeVersionNumber` — none work for `GenAiPromptTemplate` (the `activeVersionNumber` PATCH does work for Flow, which is why Step 5 can activate the flow programmatically). The skill follows the same one-click activation pattern the base `setting-up-pre-work-brief` skill uses for consistency.
---
## Step 7: Generate the permission set
Bundle CRUD on the new objects, FLS on the new fields (including any new WorkOrder lookups), and assign to admin + technician:
```xml
<?xml version="1.0" encoding="UTF-8"?>
<PermissionSet xmlns="http://soap.sforce.com/2006/04/metadata">
<description>Read/Edit on {Industry} custom objects + new fields used by the {Industry} Pre-Work Brief flow for {Company}.</description>
<hasActivationRequired>false</hasActivationRequired>
<label>Pre-Work Brief {Industry} Access ({Company})</label>
<objectPermissions>
<allowCreate>true</allowCreate>
<allowDelete>true</allowDelete>
<allowEdit>true</allowEdit>
<allowRead>true</allowRead>
<modifyAllRecords>false</modifyAllRecords>
<object>{Custom_Object__c}</object>
<viewAllRecords>true</viewAllRecords>
</objectPermissions>
<!-- Repeat objectPermissions for each new custom object -->
<fieldPermissions><editable>true</editable><field>{Object}.{Field__c}</field><readable>true</readable></fieldPermissions>
<!-- Repeat fieldPermissions for each new field -->
</PermissionSet>
```
Deploy + assign:
```bash
cd /tmp/pwb-custom-build
sf project deploy start --target-org "$ORG_ALIAS" --source-dir force-app/main/default/permissionsets --wait 30 --api-version 65.0
PERMSET_NAME="PreWorkBrief_${INDUSTRY}_Access"
sf org assign permset --name "$PERMSET_NAME" --target-org "$ORG_ALIAS"
sf org assign permset --name "$PERMSET_NAME" --on-behalf-of "$TECH_USERNAME" --target-org "$ORG_ALIAS"
```
> **Asset.ProductDescription gotcha.** Verified during the HVAC dry-run on `afvuser` (2026-05-19): even with full Asset CRUD granted, `ProductDescription` is read-only for non-admin profiles in some org configurations. If the seed proposes populating it, fall back to writing the same content into `Asset.Description` instead.
---
## Step 8: Create a fresh test Work Order with seed data
Mirrors the `setting-up-pre-work-brief` Step 8-fresh pattern. Resolve Service Resource + Service Territory dynamically; create Account → Asset → custom-object records → Contact → WO → SA → AssignedResource as a chain so the brief has real data to ground on.
The seed contributes example values for the test record (e.g., HVAC seed populates a 10-ton rooftop unit, Platinum SLA contract, R-410A refrigerant log at 14.2 lbs).
After creation, hand off to the admin:
> The {Industry} Pre-Work Brief is wired up. Open the Field Service mobile app, sign in as **`$TECH_USERNAME`**, navigate to today's schedule. The new Work Order **`$WO_NUMBER`** should appear. Open it; the Pre-Work Brief should render in the Overview tab and reference {Company}'s business context plus the custom-object data this skill just created.
---
## Adding a new vertical seed
If you ran with `--industry other` and want to contribute the synthesized template back, the skill writes a draft to `templates/<your-industry>.md` at the end of the run. Review the draft, edit as needed, and commit. The next admin in your industry skips the synthesis step.
A seed should contain:
| Section | What it specifies |
|---|---|
| **Business archetype** | One-sentence description of the vertical's typical customer + technician work |
| **Recommended custom objects** | 2-4 objects with field lists. Include why each matters (compliance, SLA, asset history). |
| **Standard objects + fields to query** | Which standard fields the flow's Get-record elements should pull (e.g., `ServiceAppointment.ArrivalWindowStartTime`, `Contact.Email`) |
| **Prompt template section structure** | The 3-5 sections the brief should contain (e.g., HVAC = Mission and contact / Customer and SLA / Site access and certifications / Equipment and refrigerant context) |
| **Rules** | Vertical-specific rules (e.g., HVAC = "if last refrigerant service was >12 months ago, call it out") |
| **Cadence example** | Tone-anchoring example paragraph using the section structure |
| **Test data sample** | Realistic values for the test WO + seed records the skill creates in Step 8 |
See `templates/hvac.md` as the canonical example.
---
## Idempotency
Re-running this skill against the same org with the same `--customized-template-name`:
- Re-fetches the website and re-prompts for description (cheap; admins re-confirm).
- Re-audits org schema; new customs may have appeared since last run.
- Skips object creation if Step 4 finds the customs already exist.
- Re-deploys the flow as a new version (Salesforce treats identical metadata as no-op).
- Re-deploys the prompt template (same; identical metadata is a no-op).
- Creates a **new** test WO + SA every run.
For a second vertical in the same org, pass a different `--industry` and `--customized-template-name`. The skill produces a parallel pipeline (objects + flow + permset + template + test WO) without touching the first.
---
## Related afv-library Skills
- `setting-up-pre-work-brief` — required prerequisite. Runs the base setup that this skill builds on.
- `generating-flow` — useful when the from-scratch flow needs deeper edits than this skill performs (e.g., complex Loops over collections, Decision elements). Open the deployed flow in Flow Builder for visual review.
- `generating-permission-set` — for orgs that already have a permission set pattern to extend rather than create anew.
---
## References
- Pre-Work Brief setup: `https://help.salesforce.com/s/articleView?id=service.mfs_einstein_pre_work_brief.htm`
- Pre-Work Brief data model: `https://help.salesforce.com/s/articleView?id=service.mfs_einstein_pre_work_brief_data.htm`
- Prompt Builder: `https://help.salesforce.com/s/articleView?id=ai.prompt_builder_about.htm`
- Flow Reference (PromptFlow processType): `https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_visual_workflow.htm`
---
## Known Limitations
- Programmatic activation of `GenAiPromptTemplate` is not exposed in the API today. Step 6's deeplink is the supported path until Salesforce ships an Activate REST endpoint. The skill follows the same one-click pattern as `setting-up-pre-work-brief` for consistency.
- Flows with multi-record record lookups (`getFirstRecordOnly=false`) require a Loop element to reference individual records in the Output.Prompt assignment; the from-scratch pattern in Step 5 uses `getFirstRecordOnly=true` to keep the demo simple. For verticals where a Work Order has multiple Refrigerant Logs / Compliance Checks / etc., the seed should specify a Loop pattern.
- `WebFetch` results depend on the company's homepage being public and not paywalled or JS-only. Pages rendered entirely by client-side JS may return little usable content; in that case fall back to admin description only.
- `AssignedResource` create may fail in orgs that require a Service Territory on the Service Appointment. Step 8 resolves Service Territory from the chosen Service Resource's `ServiceTerritoryMember` and includes it on create. If the resource has no territory membership, ask the admin to pick a different resource or assign a territory in Setup.
- `Asset.ProductDescription` is read-only for non-admin profiles in some org configurations (verified on `afvuser` 2026-05-19). Seeds should write descriptive text to `Asset.Description` instead.

103
skills/customizing-pre-work-brief/templates/banking.md Normal file
View File

@ -0,0 +1,103 @@
# Banking / ATM Service Seed Template
Scaffold. Not yet verified end-to-end against a live org. Adapted from the Unisys customization work (2026-05-19) and standard banking field service patterns.
## Business archetype
This customer services banking and financial-services hardware — ATMs, bank branch teller stations, drive-thru tubes, vault systems — at retail bank locations and remote ATM sites. Technicians perform cash replenishment, hardware repair, software updates, and compliance audits. Cassette levels and last-audit timestamps are critical to every visit. Many sites have escort requirements, time-of-day windows, and dual-control protocols (two technicians required for vault access).
## Recommended custom objects
### `ATM_Cassette__c`
Why: Cash levels and denomination mix drive whether the visit is a routine replenishment vs. emergency.
| Field | Type | Notes |
|---|---|---|
| `Asset__c` | Lookup → Asset | `<deleteConstraint>SetNull</deleteConstraint>` |
| `Cassette_Position__c` | Picklist (restricted) | Top, Middle Upper, Middle Lower, Bottom |
| `Denomination__c` | Picklist (restricted) | $1, $5, $10, $20, $50, $100 |
| `Current_Notes_Count__c` | Number(6,0) | Notes remaining at last reading |
| `Capacity__c` | Number(6,0) | Max notes the cassette holds |
| `Last_Replenishment__c` | Date | Used as sort key |
Name field: AutoNumber `CS-{0000}`.
### `Compliance_Check__c`
Why: Banking equipment requires periodic audits (PCI-DSS for card readers, ADA for screen-reader and audio, internal policy for camera coverage). Last-audit-date drives whether this visit needs to include a compliance pass.
| Field | Type | Notes |
|---|---|---|
| `Asset__c` | Lookup → Asset | `<deleteConstraint>SetNull</deleteConstraint>` |
| `Audit_Type__c` | Picklist (restricted) | PCI-DSS, ADA, Camera Coverage, Lighting, Internal Policy |
| `Last_Audit_Date__c` | Date | When was this audit type last completed |
| `Next_Audit_Due__c` | Date | When the next audit is due |
| `Status__c` | Picklist (restricted) | Compliant, Action Required, Failed |
| `Notes__c` | LongTextArea (500) | Findings from last audit |
Name field: AutoNumber `CC-{0000}`. Enable history tracking (audit trail).
## WorkOrder field additions
| Field | Type | Notes |
|---|---|---|
| `Site_Access_Protocol__c` | Picklist (restricted) | Single Tech, Dual Control Required, Escort Required, After-Hours Only |
| `Cash_Handling_Required__c` | Checkbox | If true, the technician must hold a cash-handling certification |
## Standard objects + fields to query
| Object | Fields |
|---|---|
| Account | Name, Industry, Phone, Description |
| Asset | Name, SerialNumber, InstallDate, Description, Status |
| Contact | Name, Title, Phone, Email |
| ServiceAppointment | AppointmentNumber, SchedStartTime, SchedEndTime, ArrivalWindowStartTime, ArrivalWindowEndTime, Description, Status, Subject |
## Flow structure
Connector chain: `start → GetAccount → GetAsset → GetCassettes → GetComplianceChecks → GetServiceAppointment → GetContact → BuildPrompt`.
`GetCassettes` filters by `Asset__c = $Input.WorkOrder.AssetId`, sorts by `Last_Replenishment__c ASC` (oldest first surfaces what needs attention).
`GetComplianceChecks` filters by `Asset__c = $Input.WorkOrder.AssetId`, sorts by `Next_Audit_Due__c ASC` (most-urgent due-date first).
Both use `getFirstRecordOnly=true` for the demo. For real deployments where one ATM has 4-6 cassettes, switch to a Loop pattern (see Known Limitations in main SKILL.md).
## Prompt template section structure
1. **Mission and contact** — work to perform, on-site contact, end with site security reminder.
2. **Site access protocol** — single tech vs. dual control, time window, escort requirements. If `Cash_Handling_Required__c = true`, instruct the technician to verify their cash-handling cert.
3. **Cash status** — current cassette levels by denomination, time since last replenishment.
4. **Compliance status** — most recently due audit type, last completion date, any action items from the prior audit.
## Rules
- Address the technician directly throughout.
- For dual-control sites, explicitly state "you are the second technician" or "you are the lead; confirm your partner is on-site before opening the vault."
- Never disclose actual cash amounts in the brief — use ranges ("low", "below 25%", "near capacity") to reduce risk if the device is screenshot or shoulder-surfed.
- For any field not grounded, write `[not provided]`.
## Cadence example
> "Perform cash replenishment and a routine PCI-DSS compliance check on ATM-12 at the customer's downtown branch. Your on-site contact is the branch operations manager, reachable at the provided phone number and email. Do not leave the site until both tasks are completed and you have confirmed the device is back in service.
>
> This site requires dual-control access — confirm your partner is on-site before opening the vault. Service window is 6 AM to 8 AM only, before the branch opens to customers.
>
> Cassette status as of last reading: $20 cassette is below 25% capacity, $50 cassette is near capacity, $100 cassette is mid-range. Replenishment was last performed 11 days ago.
>
> The PCI-DSS audit is due within 30 days. The last audit on 2025-12-04 found one finding: receipt printer paper feed was misaligned. Verify the finding has been addressed."
## Test data sample
Account: "First Coastal Bank — Downtown Branch" (Banking), with description noting branch hours and ATM count.
Asset: "ATM-12 — Lobby", Serial `NCR-ATM-554821`, NCR SelfServ 84.
ATM_Cassette records: 4 entries (one per denomination), with current note counts and replenishment dates.
Compliance_Check records: 3 entries (PCI-DSS, ADA, Camera Coverage), with audit dates spanning the last 18 months.
Contact: branch operations manager.
Work Order: "Cash replenishment + PCI-DSS spot check — ATM-12", Medium priority.

108
skills/customizing-pre-work-brief/templates/healthcare.md Normal file
View File

@ -0,0 +1,108 @@
# Healthcare Medical Devices Seed Template
Scaffold. Not yet verified end-to-end against a live org. High-stakes vertical — patient safety and FDA compliance shape every visit.
## Business archetype
This customer manufactures or services medical devices — infusion pumps, imaging equipment, dialysis machines, ventilators, surgical robots — at hospitals, clinics, and ambulatory surgery centers. Technicians perform calibration, software updates, recall remediation, and break/fix. Patient safety protocols (lockout-tagout during service, escorted access in surgical areas), FDA recall status, and last-calibration dates are critical grounding data. Many sites require the technician to coordinate with biomed engineering.
## Recommended custom objects
### `Device_Calibration__c`
Why: Medical devices require periodic calibration with documented results. Walking into a service call without knowing the last-calibration date risks patient safety and regulatory exposure.
| Field | Type | Notes |
|---|---|---|
| `Asset__c` | Lookup → Asset | `<deleteConstraint>SetNull</deleteConstraint>` |
| `Calibration_Type__c` | Picklist (restricted) | Routine, Annual, Post-Repair, Pre-Use Check |
| `Last_Calibration_Date__c` | Date | When the last calibration was performed |
| `Next_Calibration_Due__c` | Date | When the next calibration is due |
| `Result__c` | Picklist (restricted) | Pass, Pass with notes, Fail, Out of tolerance |
| `Calibrated_By__c` | Lookup → User | Who performed the calibration |
| `Notes__c` | LongTextArea (500) | Calibration findings, drift, adjustments made |
Name field: AutoNumber `CAL-{0000}`. Enable history tracking.
### `FDA_Compliance_Log__c`
Why: FDA recalls, field safety notices, and corrective-action communications are mandatory grounding for any service visit on a regulated device.
| Field | Type | Notes |
|---|---|---|
| `Asset__c` | Lookup → Asset | `<deleteConstraint>SetNull</deleteConstraint>` |
| `Notice_Type__c` | Picklist (restricted) | Recall (Class I/II/III), Field Safety Notice, Corrective Action, Voluntary Update |
| `Notice_Date__c` | Date | When the notice was issued |
| `Action_Required__c` | LongTextArea (1000) | What the technician must do |
| `Status__c` | Picklist (restricted) | Pending, In Progress, Completed, N/A |
| `FDA_Reference__c` | Text(50) | FDA recall number or notice ID |
Name field: AutoNumber `FDA-{0000}`. Enable history tracking.
## WorkOrder field additions
| Field | Type | Notes |
|---|---|---|
| `Patient_Safety_Risk__c` | Picklist (restricted) | None, Low, Medium, High |
| `Biomed_Coordination_Required__c` | Checkbox | If true, the brief must instruct the technician to coordinate with hospital biomed before starting |
| `Lockout_Tagout_Required__c` | Checkbox | If true, the technician must confirm LOTO procedures before starting |
## Standard objects + fields to query
| Object | Fields |
|---|---|
| Account | Name, Industry, Phone, Description |
| Asset | Name, SerialNumber, InstallDate, Description, Status |
| Contact | Name, Title, Phone, Email |
| ServiceAppointment | AppointmentNumber, SchedStartTime, SchedEndTime, ArrivalWindowStartTime, ArrivalWindowEndTime, Description, Status, Subject |
## Flow structure
Connector chain: `start → GetAccount → GetAsset → GetMostRecentCalibration → GetActiveFDANotices → GetServiceAppointment → GetContact → BuildPrompt`.
`GetMostRecentCalibration` sorts by `Last_Calibration_Date__c DESC LIMIT 1`.
`GetActiveFDANotices` filters by `Asset__c = $Input.WorkOrder.AssetId AND Status__c IN ('Pending', 'In Progress')`. For a real deployment with multiple active notices, use a Loop pattern.
## Prompt template section structure
1. **Mission and contact** — work to perform, biomed contact + phone + email. End with patient-safety reminder.
2. **Patient safety protocol** — risk level, lockout-tagout requirement, biomed coordination requirement. If risk is Medium or High, list the specific safety steps.
3. **Active FDA notices** — any pending or in-progress notices for this asset, with the FDA reference and required action. If none, state "no active FDA notices."
4. **Calibration status** — last calibration date, result, days until next due. Call out overdue calibrations explicitly.
5. **Equipment context** — asset model, serial, install date, current status.
## Rules
- Address the technician directly throughout.
- If `Biomed_Coordination_Required__c = true`, the brief must explicitly instruct: "Confirm with hospital biomed before starting service. Do not power-cycle the device without their sign-off."
- If `Lockout_Tagout_Required__c = true`, the brief must list the LOTO steps from the asset's documented procedure.
- If an FDA recall has `Status__c = Pending`, this visit must include the recall remediation. Lead with that, not the customer's stated complaint.
- If the next calibration is overdue, the brief must state how many days overdue.
- For any field not grounded, write `[not provided]`.
## Cadence example
> "Perform a Class II FDA recall remediation on the customer's infusion pump (Serial INF-CN-220194). Your biomed contact is Dr. Patel, reachable at the provided phone and email. Do not leave the site until the recall remediation is complete and the device is signed off by biomed.
>
> This is a Medium patient-safety-risk visit. Lockout-tagout procedures are required: power off the device at the wall, apply your personal lock, verify the device is de-energized, and complete the LOTO log entry before opening the chassis.
>
> Active FDA notice: Class II Recall, FDA reference Z-2845-2026, issued 2026-04-12. Action required: install firmware version 7.4.1, verify pressure-sensor recalibration completes successfully, document the firmware checksum on the calibration log.
>
> Most recent calibration: 2026-02-10, result Pass with notes ("minor drift on flow sensor 2"). Next calibration is due in 6 days; if you have time after the recall remediation, perform an early calibration and update the log.
>
> The device is a 2023 model, currently in service. The customer's stated complaint (intermittent flow alarm) is likely related to the recall — the firmware update should resolve it."
## Test data sample
Account: "Mercy General Hospital — ICU Wing" (Healthcare).
Asset: "Infusion Pump INF-CN-220194", installed 2023-04-22.
Device_Calibration: most recent 2026-02-10, Pass with notes.
FDA_Compliance_Log: 1 active Class II recall, 1 completed Field Safety Notice from 2025.
Contact: Dr. Patel, biomed engineering lead.
Work Order: "Recall remediation Z-2845-2026 — Infusion Pump INF-CN-220194", High priority, biomed coordination required, LOTO required, Medium patient safety risk.

107
skills/customizing-pre-work-brief/templates/hvac.md Normal file
View File

@ -0,0 +1,107 @@
# HVAC Commercial Maintenance Seed Template
Canonical seed. Verified end-to-end against `afvuser` trial org, 2026-05-20: deployed 2 custom objects, 11 fields, a from-scratch flow, prompt template, permission set, and a test WO + SA. Brief renders on Field Service Mobile.
## Business archetype
This customer operates commercial HVAC systems — rooftop units, chillers, heat pumps, and associated controls — at retail, healthcare, education, grocery, and office locations. Technicians perform planned maintenance, emergency break/fix, and refrigerant handling. Refrigerant logs are EPA-required and must be referenced for any work involving the refrigerant circuit. Site access constraints (escort requirements, hours, tenant coordination) and SLA tier (response-time commitment) shape every visit.
## Recommended custom objects
### `Maintenance_Contract__c`
Why: SLA tier and coverage scope are the most-referenced grounding context in commercial HVAC briefs. A Platinum-tier customer with a 4-hour response commitment needs the technician to know that before they leave.
| Field | Type | Notes |
|---|---|---|
| `Account__c` | Lookup → Account | `<deleteConstraint>SetNull</deleteConstraint>`, not required |
| `SLA_Tier__c` | Picklist (restricted) | Platinum (4hr), Gold (8hr), Silver (24hr), Bronze (48hr) |
| `Coverage_Scope__c` | LongTextArea (1000) | Free-text scope of services covered |
| `Site_Access_Notes__c` | LongTextArea (500) | Gate codes, escort requirements, hours, tenant coordination |
| `Required_Certifications__c` | Text (255) | EPA Section 608 Universal, OSHA 10, etc. |
Name field: AutoNumber `MC-{0000}`.
### `Refrigerant_Log__c`
Why: EPA-required documentation. Last-service-date and prior charge level inform whether the current visit is a leak diagnostic vs. routine top-up.
| Field | Type | Notes |
|---|---|---|
| `Asset__c` | Lookup → Asset | `<deleteConstraint>SetNull</deleteConstraint>` |
| `Refrigerant_Type__c` | Picklist (unrestricted) | R-410A, R-454B, R-32, R-22 (legacy) |
| `Charge_Level_Lbs__c` | Number(6,2) | Pounds of refrigerant in system |
| `Last_Service_Date__c` | Date | Used as sort key (most recent first) |
| `Notes__c` | LongTextArea (500) | Leak detection results, top-off amounts |
Name field: AutoNumber `RL-{0000}`. Enable history tracking (compliance audit trail).
## WorkOrder field additions
| Field | Type | Notes |
|---|---|---|
| `Maintenance_Contract__c` | Lookup → Maintenance_Contract__c | Not required; flow uses `$Input.WorkOrder.Maintenance_Contract__c` to fetch SLA + coverage |
## Standard objects + fields to query
| Object | Fields beyond the default flow's set |
|---|---|
| Account | Name, Industry, Phone, Description |
| Asset | Name, SerialNumber, InstallDate, Description, Status |
| Contact | Name, Title, Phone, Email |
| ServiceAppointment | AppointmentNumber, SchedStartTime, SchedEndTime, ArrivalWindowStartTime, ArrivalWindowEndTime, EarliestStartTime, DueDate, Description, Status, Subject |
Avoid `Asset.ProductDescription` — it's read-only for non-admin profiles in some org configurations. Use `Asset.Description` for narrative text instead.
## Flow structure
Connector chain: `start → GetAccount → GetAsset → GetMaintenanceContract → GetRefrigerantLog → GetServiceAppointment → GetContact → BuildPrompt`.
All record lookups use `getFirstRecordOnly=true`. The `BuildPrompt` assignment writes a structured `$Output.Prompt` with sections: Work Order, Customer, On-site Contact, Asset, Maintenance Contract, Most Recent Refrigerant Log, Service Appointment.
`GetRefrigerantLog` sorts by `Last_Service_Date__c DESC` to surface the latest entry.
## Prompt template section structure
Four sections, in order:
1. **Mission and contact** — opens with active-voice imperative ("Perform a refrigerant top-up..."), names contact + phone + email, ends with "do not leave the site until the issue is resolved."
2. **Customer and SLA** — customer name, SLA tier, coverage scope. Call out Platinum/Gold tiers as high-priority.
3. **Site access and certifications** — site access notes, required certifications. Instruct technician to verify they hold the certs before arrival.
4. **Equipment and refrigerant context** — asset (model, serial, install date, status), most recent refrigerant log (type, prior charge, last service date). Call out anomalies: service >12 months ago, charge below normal range.
## Rules
- Address the technician directly throughout (second person).
- Opening sentence must use an active-voice verb appropriate to the work.
- For any field not grounded, write `[not provided]`.
- All times in technician's local time zone.
- Brief under 300 words.
- Prose paragraphs, not bullet lists.
- If most recent refrigerant service >12 months ago OR charge level below typical spec for the unit, explicitly note this as a likely contributor to the current issue.
## Cadence example
> "Perform a refrigerant top-up and leak inspection on the building's rooftop unit RTU-3. The customer reports inadequate cooling during peak hours; you will verify charge level and locate any leaks before adjusting refrigerant. Your on-site contact is Maria Reyes, Facilities Manager, reachable at 415-555-0118 and m.reyes@example.com. Do not leave the site until the issue is resolved.
>
> This is a Platinum SLA customer (4-hour response commitment). Coverage scope includes preventive maintenance and emergency break/fix on all rooftop units in the building.
>
> Site access requires escort by building security; check in at the loading dock between 7 AM and 6 PM. Confirm before arrival that you hold an active EPA Section 608 Universal certification, which is required for any refrigerant handling on this site.
>
> The asset is a 10-ton rooftop unit installed 2018, currently in service. The most recent refrigerant log shows R-410A charge of 14.2 lbs, last serviced 2025-09-12. Charge level is below the typical 16 lb spec for this unit, which is consistent with the cooling complaint."
## Test data sample
Account: "Greenfield Grocery — Mission District" (Retail), with description noting refrigeration criticality.
Asset: "Rooftop Unit RTU-3 — Produce Section", Serial `CR-RTU-388291`, Carrier 48HC 10-ton, installed 2018-06-12.
Maintenance_Contract: Platinum (4hr), full coverage scope text, site access notes, required certs `EPA Section 608 Universal, OSHA 10`.
Refrigerant_Log: R-410A, 14.2 lbs (below 16 lb spec), last service 2025-09-12.
Contact: Maria Reyes, Store Facilities Manager.
Work Order: "Refrigerant top-up and leak inspection — RTU-3", High priority, with description detailing the cooling complaint and required diagnostic steps.
Service Appointment: today, 2-hour window, assigned to the chosen Service Resource.

98
skills/customizing-pre-work-brief/templates/retail-merchandising.md Normal file
View File

@ -0,0 +1,98 @@
# Retail Merchandising Field Service Seed Template
Scaffold. Not yet verified end-to-end against a live org.
## Business archetype
This customer provides field merchandising service to retail brands — restocking shelves, setting up promotional displays, capturing planogram-compliance photos, taking competitor pricing surveys — at grocery, drug, mass-merchant, and convenience-store locations. Technicians (often called "merchandisers" or "field reps") visit multiple stores per day with a list of pre-defined tasks per store. Planogram compliance, recent promotional activity, and store-specific access notes are the most useful grounding data.
## Recommended custom objects
### `Store_Visit_Plan__c`
Why: Each store visit has a structured task list: shelf reset, promo build, photo capture, etc. The plan determines whether the visit is 30 minutes or 3 hours.
| Field | Type | Notes |
|---|---|---|
| `Account__c` | Lookup → Account | `<deleteConstraint>SetNull</deleteConstraint>` |
| `Visit_Type__c` | Picklist (restricted) | Routine Maintenance, New Item Cut-In, Promo Build, Compliance Audit |
| `Estimated_Minutes__c` | Number(4,0) | Time budget for the visit |
| `Tasks__c` | LongTextArea (1000) | Bullet list of tasks to complete |
| `Photos_Required__c` | Number(2,0) | How many photos the rep must capture |
| `Submission_Deadline__c` | DateTime | When the visit report must be uploaded |
Name field: AutoNumber `SVP-{0000}`.
### `Planogram_Compliance__c`
Why: A photo from the last visit showing what compliance looked like is the single most useful piece of grounding data — it tells the rep what the shelf should look like and what to fix.
| Field | Type | Notes |
|---|---|---|
| `Account__c` | Lookup → Account | `<deleteConstraint>SetNull</deleteConstraint>` |
| `Visit_Date__c` | Date | When this compliance check was performed |
| `Compliance_Score__c` | Percent(5,2) | 0-100% compliance with the planogram |
| `Issues_Found__c` | LongTextArea (1000) | Free-text list of issues |
| `Photo_Url__c` | URL(255) | Link to the most recent shelf photo |
| `Resolved_By_Visit__c` | Lookup → WorkOrder | Which visit fixed the issues |
Name field: AutoNumber `PG-{0000}`. Enable history tracking.
## WorkOrder field additions
| Field | Type | Notes |
|---|---|---|
| `Store_Visit_Plan__c` | Lookup → Store_Visit_Plan__c | The plan driving this visit |
| `Store_Access_Window__c` | Text(100) | "6 AM - 10 AM only", "Backroom only after 8 PM", etc. |
## Standard objects + fields to query
| Object | Fields |
|---|---|
| Account | Name, Industry, Phone, BillingAddress, Description |
| Contact | Name, Title, Phone, Email |
| ServiceAppointment | AppointmentNumber, SchedStartTime, SchedEndTime, Address, Description, Status, Subject |
Note: this vertical typically does not use `Asset` (no specific equipment is being serviced). The "asset" is the shelf or display itself, which doesn't usually live as an Asset record.
## Flow structure
Connector chain: `start → GetAccount → GetVisitPlan → GetMostRecentCompliance → GetServiceAppointment → GetContact → BuildPrompt`.
`GetMostRecentCompliance` sorts by `Visit_Date__c DESC LIMIT 1`.
## Prompt template section structure
1. **Mission and time budget** — visit type, estimated time, store name + location. End with submission deadline.
2. **Task list** — the tasks from the visit plan, formatted as a numbered list. Photos required count.
3. **Last visit context** — most recent compliance score, key issues found, link to the prior photo if available.
4. **Store access** — access window (6 AM-10 AM, etc.), store contact name + phone, any backroom or stockroom notes.
## Rules
- Address the rep directly throughout. (Note: "rep" or "merchandiser" not "technician" for this vertical.)
- Lead with the time budget so the rep knows whether they're tight or have slack.
- If the last visit's compliance score was below 70%, lead the task list with the issues that need fixing first.
- For any field not grounded, write `[not provided]`.
## Cadence example
> "Perform a routine maintenance visit at Stop & Shop store #4218 in Quincy, MA. Estimated time: 45 minutes. Submission deadline is end of day today.
>
> Today's tasks: (1) restock the snack endcap to planogram, (2) verify the new chip flavor is on the secondary display in aisle 7, (3) capture 3 photos of the snack endcap and the chip secondary, (4) submit before 6 PM.
>
> Last visit was 14 days ago. Compliance score was 82%. Issues at that time: the salty-snack endcap was out of stock on two SKUs, and the secondary display had old promotional signage. The store manager committed to backroom restock; verify those two SKUs are now on the shelf.
>
> Store access: front entrance only between 6 AM and 10 AM. Your store contact is Dana Liu, store manager, reachable at the phone and email on file."
## Test data sample
Account: "Stop & Shop #4218 — Quincy MA" (Retail).
Store_Visit_Plan: routine maintenance, 45 minutes, 4 tasks, 3 photos required, end-of-day deadline.
Planogram_Compliance: most recent 14 days ago, score 82%, two SKU OOS issues.
Contact: Dana Liu, store manager.
Work Order: "Snack endcap restock + secondary display photo — Stop & Shop #4218", routine priority.

100
skills/customizing-pre-work-brief/templates/telecom.md Normal file
View File

@ -0,0 +1,100 @@
# Telecom / Fiber Install Seed Template
Scaffold. Not yet verified end-to-end against a live org.
## Business archetype
This customer provides residential and small-business telecommunications service — fiber-to-the-home, broadband internet, voice — and dispatches technicians for new-customer installs, service drops, outage repair, and equipment swaps. Signal strength readings, ONT (optical network terminal) serial numbers, and recent outage history at the address are the most useful grounding data for a pre-work brief.
## Recommended custom objects
### `Service_Drop__c`
Why: Each install or repair visit interacts with a specific service drop (the physical line from the street to the customer). Signal-strength history at the drop predicts whether the visit will be a quick swap or a longer troubleshoot.
| Field | Type | Notes |
|---|---|---|
| `Account__c` | Lookup → Account | `<deleteConstraint>SetNull</deleteConstraint>` |
| `Asset__c` | Lookup → Asset | The ONT or modem at this drop |
| `Signal_Strength_Db__c` | Number(5,2) | Last measured signal strength in dBm |
| `Last_Reading_Date__c` | DateTime | When the signal was last measured |
| `ONT_Serial__c` | Text(50) | Optical network terminal serial number |
| `Connection_Type__c` | Picklist (restricted) | Fiber, Copper, Coax, Hybrid |
Name field: AutoNumber `SD-{0000}`.
### `Outage_History__c`
Why: A pattern of outages at the address (vs. a one-off) suggests the technician is walking into a recurring problem, not an isolated incident.
| Field | Type | Notes |
|---|---|---|
| `Account__c` | Lookup → Account | `<deleteConstraint>SetNull</deleteConstraint>` |
| `Outage_Start__c` | DateTime | When the outage began |
| `Duration_Minutes__c` | Number(6,0) | How long it lasted |
| `Resolution_Type__c` | Picklist (restricted) | Self-healed, Tech-resolved, CenOps-resolved, Carrier escalation |
| `Ticket_Reference__c` | Text(50) | Internal incident ticket number |
| `Notes__c` | LongTextArea (500) | What was found and fixed |
Name field: AutoNumber `OH-{0000}`. Enable history tracking.
## WorkOrder field additions
| Field | Type | Notes |
|---|---|---|
| `Service_Drop__c` | Lookup → Service_Drop__c | Which drop this WO services |
| `Install_Type__c` | Picklist (restricted) | New Install, Upgrade, Repair, Disconnect |
## Standard objects + fields to query
| Object | Fields |
|---|---|
| Account | Name, Phone, BillingAddress, Description |
| Asset | Name, SerialNumber, InstallDate, Description, Status |
| Contact | Name, Phone, Email, MobilePhone |
| ServiceAppointment | AppointmentNumber, SchedStartTime, SchedEndTime, ArrivalWindowStartTime, ArrivalWindowEndTime, Address, Description, Status, Subject |
## Flow structure
Connector chain: `start → GetAccount → GetServiceDrop → GetAsset → GetOutageHistory → GetServiceAppointment → GetContact → BuildPrompt`.
`GetOutageHistory` sorts by `Outage_Start__c DESC LIMIT 5` for the 5 most-recent incidents at the address.
`GetServiceDrop` filters by `Id = $Input.WorkOrder.Service_Drop__c`.
## Prompt template section structure
1. **Mission and contact** — work to perform, customer name + phone + email.
2. **Service drop snapshot** — connection type, ONT serial, last signal reading + date. Call out signal degradation (>5 dBm drop from a typical -20 dBm baseline) as a likely root cause.
3. **Recent outage history** — count + dates of outages in the last 90 days. If 3+ outages in 30 days, flag as recurring problem.
4. **Appointment timing** — local arrival window, scheduled start/end.
## Rules
- Address the technician directly throughout.
- For "Repair" install types where outage history shows a recurring problem, recommend the technician check upstream (street-side) infrastructure before swapping customer equipment.
- For any field not grounded, write `[not provided]`.
## Cadence example
> "Perform a service-drop repair at the customer's residence. The customer reports intermittent outages over the last 10 days. Your contact is the account holder, reachable at the phone and email on file. Do not leave the site until you have confirmed sustained signal and tested speed at the ONT.
>
> The drop is a fiber connection terminating at ONT serial NS-FOH-882910. Last signal reading was -29.4 dBm on 2026-05-12, which is 9 dBm below the typical -20 dBm baseline for this neighborhood and is consistent with the customer's outage complaints.
>
> Outage history at this address: 4 incidents in the last 30 days, all resolved by the customer's modem auto-recovering after 2-15 minutes. This is a recurring pattern, not a one-off — check the street-side splitter and the OLT port assignment before swapping the ONT.
>
> Your appointment window is 1:00 PM to 5:00 PM today, with a scheduled start of 2:30 PM."
## Test data sample
Account: "Reyes Residence — 22 Chestnut St", with phone + billing address.
Asset: "ONT NS-FOH-882910", installed 2023-08-15.
Service_Drop: signal -29.4 dBm last reading, fiber connection.
Outage_History: 4 entries in last 30 days, all self-healed.
Contact: account holder.
Work Order: "Recurring outage investigation at 22 Chestnut St", Medium priority, install type Repair.

1033
skills/setting-up-pre-work-brief/SKILL.md Normal file
View File

File diff suppressed because it is too large Load Diff