@salesforce/afv-skills 1.49.0 → 1.51.0

package/skills/field-service-data-capture-form-deployer-configure/references/flow-metadata-json.md

@@ -0,0 +1,243 @@
+# Flow Metadata JSON — Data Capture Flow
+
+A Data Capture Flow is a Salesforce Flow with `processType=DataCaptureFlow`. It is created and updated through the **Tooling API `Flow` sObject**, whose `Metadata` field is a JSON object — the same shape you get back from `GET /services/data/vXX.0/tooling/sobjects/Flow/{id}`. There is **no `.flow-meta.xml`, no zip, and no SFDX project** — the agent assembles this JSON inline and POSTs it.
+
+The shape below is the JSON transliteration of the Metadata blob retrieved from real flows in a live Field Service org (`Data_Capture_Asset_Inspection`, `Inventory_Transfer`) and verified against that org's `Flow` describe.
+
+## The deploy call
+
+```http
+POST /services/data/vXX.0/tooling/sobjects/Flow
+{
+  "FullName": "<FlowApiName>",
+  "Metadata": { ...the object below... }
+}
+```
+
+- `FullName` is the Flow API name (matches `^[A-Z][A-Za-z0-9_]*$`). `FullName` is set-on-create only.
+- A 201 with `success: true` returns the new Flow version id.
+- To **activate on create**, set `Metadata.status: "Active"`. Default `"Draft"` so the user reviews in Flow Builder first — activation is via `Flow.Metadata.status`, not a separate `FlowDefinition` write (`FlowDefinition.ActiveVersionId` is not directly writable).
+- To **update** an existing version, `PATCH /services/data/vXX.0/tooling/sobjects/Flow/{id}` with `{"Metadata": {...full metadata...}}` (the editor skill's redeploy path).
+
+## JSON ↔ XML mapping rule
+
+The Metadata JSON is a mechanical transliteration of the Flow XML:
+
+- Each XML element becomes a JSON key. `<label>X</label>` → `"label": "X"`.
+- **Repeated** elements become a JSON **array**: multiple `<screens>` → `"screens": [ {...}, {...} ]`; multiple `<choiceReferences>` → `"choiceReferences": ["A","B"]`.
+- Typed value wrappers keep their wrapper key: `<value><stringValue>X</stringValue></value>` → `"value": {"stringValue": "X"}`; `<booleanValue>true</booleanValue>` → `{"booleanValue": true}`; `<numberValue>1.0</numberValue>` → `{"numberValue": 1.0}`; `<elementReference>Foo</elementReference>` → `{"elementReference": "Foo"}`.
+- Booleans and numbers are real JSON scalars, not strings.
+
+## Minimum-deployable shape
+
+```json
+{
+  "processType": "DataCaptureFlow",
+  "environments": ["Offline"],
+  "areMetricsLoggedToDataCloud": false,
+  "label": "HVAC Compressor Inspection",
+  "interviewLabel": "HVAC Compressor Inspection {!$Flow.CurrentDateTime}",
+  "description": "Generated from spec: HVAC Compressor Inspection",
+  "status": "Draft",
+
+  "processMetadataValues": [
+    { "name": "BuilderType", "value": { "stringValue": "LightningFlowBuilder" } },
+    { "name": "CanvasMode",  "value": { "stringValue": "AUTO_LAYOUT_CANVAS" } }
+  ],
+
+  "choices": [
+    { "name": "Good", "choiceText": "Good", "dataType": "String", "value": { "stringValue": "Good" } }
+  ],
+
+  "start": { "locationX": 0, "locationY": 0, "connector": { "targetReference": "Screen_HeaderInformation" } },
+
+  "screens": [
+    {
+      "name": "Screen_HeaderInformation",
+      "label": "Header Information",
+      "locationX": 0, "locationY": 0,
+      "allowBack": true, "allowFinish": true, "allowPause": true,
+      "showFooter": true, "showHeader": true,
+      "connector": { "targetReference": "Screen_OperatingParameters" },
+      "fields": [
+
+        {
+          "name": "jobName",
+          "extensionName": "runtime_service_fieldservice:dcTextInput",
+          "fieldType": "ComponentInstance",
+          "inputParameters": [
+            { "name": "label",    "value": { "stringValue": "Job Name" } }
+          ],
+          "inputsOnNextNavToAssocScrn": "UseStoredValues",
+          "isRequired": true,
+          "storeOutputAutomatically": true,
+          "styleProperties": {
+            "verticalAlignment": { "stringValue": "top" },
+            "width": { "stringValue": "12" }
+          }
+        },
+
+        {
+          "name": "Quantity",
+          "extensionName": "runtime_service_fieldservice:dcCounter",
+          "fieldType": "ComponentInstance",
+          "inputParameters": [
+            { "name": "label", "value": { "stringValue": "Quantity" } },
+            { "name": "min",   "value": { "numberValue": 1.0 } },
+            { "name": "value", "value": { "numberValue": 1.0 } }
+          ]
+        },
+
+        {
+          "name": "To",
+          "choiceReferences": ["Truck", "Work_Order"],
+          "extensionName": "runtime_service_fieldservice:dcRbGroup",
+          "fieldText": "To",
+          "fieldType": "ComponentChoice"
+        },
+
+        {
+          "name": "issuesIdentified",
+          "choiceReferences": ["Corrosion", "Wear", "Leakage"],
+          "extensionName": "runtime_service_fieldservice:dcCbGroup",
+          "fieldText": "Issues Identified",
+          "fieldType": "ComponentMultiChoice"
+        },
+
+        {
+          "name": "Work_Order_Number",
+          "extensionName": "runtime_service_fieldservice:dcTextInput",
+          "fieldType": "ComponentInstance",
+          "inputParameters": [
+            { "name": "label",    "value": { "stringValue": "Work Order Number" } }
+          ],
+          "isRequired": true,
+          "visibilityRule": {
+            "conditionLogic": "and",
+            "conditions": [
+              { "leftValueReference": "Work_Order", "operator": "EqualTo", "rightValue": { "booleanValue": true } }
+            ]
+          }
+        },
+
+        {
+          "name": "Part",
+          "fieldType": "Repeater",
+          "fields": [
+            { "name": "Quantity",    "extensionName": "runtime_service_fieldservice:dcCounter",   "fieldType": "ComponentInstance" },
+            { "name": "Part_Number", "extensionName": "runtime_service_fieldservice:dcTextInput", "fieldType": "ComponentInstance" }
+          ],
+          "isRequired": false,
+          "styleProperties": { "verticalAlignment": { "stringValue": "top" }, "width": { "stringValue": "12" } }
+        },
+
+        {
+          "name": "safetyInstructions",
+          "fieldText": "<p>All personnel must wear PPE.</p>",
+          "fieldType": "DisplayText"
+        }
+      ]
+    }
+  ],
+
+  "decisions": [
+    {
+      "name": "Transfer_Location_Decision",
+      "label": "Transfer Location Decision",
+      "locationX": 0, "locationY": 0,
+      "defaultConnectorLabel": "Error",
+      "rules": [
+        {
+          "name": "Truck_Decision",
+          "conditionLogic": "and",
+          "conditions": [
+            { "leftValueReference": "To.selectedChoiceValues", "operator": "EqualTo", "rightValue": { "elementReference": "Truck" } }
+          ],
+          "connector": { "targetReference": "Get_Truck" },
+          "label": "Truck"
+        }
+      ]
+    }
+  ],
+
+  "recordLookups": [
+    {
+      "name": "Get_Truck",
+      "label": "Get Truck",
+      "locationX": 0, "locationY": 0,
+      "assignNullValuesIfNoRecordsFound": false,
+      "connector": { "targetReference": "Part_Transfers" },
+      "filterLogic": "and",
+      "filters": [
+        { "field": "Service_Resource__c", "operator": "EqualTo", "value": { "elementReference": "$User.Id" } }
+      ],
+      "object": "Location",
+      "outputAssignments": [
+        { "assignToReference": "Transfer_Destination", "field": "Id" }
+      ]
+    }
+  ],
+
+  "loops": [
+    {
+      "name": "Part_Transfers",
+      "label": "Part Transfers",
+      "locationX": 0, "locationY": 0,
+      "collectionReference": "Part.AddedItems",
+      "iterationOrder": "Asc",
+      "nextValueConnector": { "targetReference": "Transfer_Part" }
+    }
+  ],
+
+  "recordCreates": [
+    {
+      "name": "Transfer_Part",
+      "label": "Transfer Part",
+      "locationX": 0, "locationY": 0,
+      "connector": { "targetReference": "Part_Transfers" },
+      "inputAssignments": [
+        { "field": "Product2Id", "value": { "elementReference": "Part_Transfers.Part_Number.value" } }
+      ],
+      "object": "ProductTransfer",
+      "storeOutputAutomatically": true
+    }
+  ],
+
+  "variables": [
+    { "name": "parentObjectType",   "dataType": "String", "isCollection": false, "isInput": true,  "isOutput": false },
+    { "name": "parentRecordId",     "dataType": "String", "isCollection": false, "isInput": true,  "isOutput": false },
+    { "name": "recordId",           "dataType": "String", "isCollection": false, "isInput": true,  "isOutput": false },
+    { "name": "Transfer_Destination","dataType": "String", "isCollection": false, "isInput": false, "isOutput": false }
+  ]
+}
+```
+
+## Field-rendering strategies
+
+| Strategy | Triggered by | Key JSON differences |
+|----------|--------------|----------------------|
+| `ComponentInstance` | most types: TextInput, Email, Phone, Numeric, Counter, Date, DateTime, Checkbox, Toggle, LongText | `"fieldType": "ComponentInstance"`, label via `inputParameters` |
+| `ComponentChoice` | Picklist, Radio (`dcRbGroup`) | `"fieldType": "ComponentChoice"`, label via `fieldText`, options via `choiceReferences` array |
+| `ComponentMultiChoice` | CheckboxGroup | `"fieldType": "ComponentMultiChoice"`, label via `fieldText`, options via `choiceReferences` array |
+| native `DisplayText` | DisplayText | `"fieldType": "DisplayText"`, body via `fieldText` (HTML), no `extensionName` |
+| native `Repeater` | Repeater | `"fieldType": "Repeater"`, child fields via nested `fields` array, no `extensionName` |
+
+## Requiredness — `isRequired` only, never a `required` inputParameter
+
+Mark a mandatory field with the field-level `"isRequired": true` key **only**. Do **not** add `{ "name": "required", ... }` to `inputParameters` — `dcName`, `dcSignature`, and other Field Service components reject it, and the deploy fails with `We can't find this input attribute: 'required'`. This is the single most common deploy error; the examples above intentionally carry `isRequired` with no `required` inputParameter.
+
+## Connector pattern
+
+- `start.connector` points to screen #1.
+- Each screen — *except* the last — has a `connector` to the next screen.
+- The **last screen** connects to `postScreen` (decision/lookup/loop/create) if present, otherwise omits `connector`.
+- All screens set `"allowFinish": true`.
+
+## Things deliberately not generated
+
+- No formulas, assignments, or text templates.
+- No nested loops or decisions inside loops.
+- No subflows.
+- No `dcLookup` without an `objectApiName` (specs missing `lookupObject` fall back to a labeled TextInput placeholder).
+- No `dcFileView` without a `fileName` (specs missing `fileName` fall back to a labeled TextInput placeholder).
+- No visual polish HTML (banners, progress bars, callouts).

package/skills/field-service-data-capture-form-deployer-configure/references/post-screen-automation.md

@@ -0,0 +1,127 @@
+# Post-screen automation: decision → lookup → loop → createRecord
+
+The Inventory_Transfer flow in the demo org shows the canonical "do something with the captured data" chain. After the last screen, the flow:
+
+1. **Decides** which branch to take based on a Radio answer (Truck vs Work Order).
+2. **Looks up** a record per branch (the truck Location for the user, or the WorkOrder).
+3. **Stores** the resulting Id into a private variable (`Transfer_Destination`).
+4. **Loops** over the Repeater's `AddedItems` collection.
+5. **Creates** one Salesforce record per row, mapping the row's child-field values onto the target object.
+
+This file documents the spec shape that drives that XML.
+
+## Spec extension
+
+Add a top-level `postScreen` block:
+
+```json
+{
+  "formTitle": "Inventory Transfer",
+  "formType": "Inventory",
+  "screens": { ... },
+  "postScreen": {
+    "variables": [
+      { "name": "Transfer_Destination", "type": "String" }
+    ],
+    "decision": {
+      "name": "Transfer_Location_Decision",
+      "label": "Transfer Location Decision",
+      "defaultLabel": "Error",
+      "branches": [
+        {
+          "name": "Truck_Decision",
+          "label": "Truck",
+          "when": { "field": "To", "operator": "EqualTo", "value": "Truck" },
+          "then": "Get_Truck"
+        },
+        {
+          "name": "Work_Order_Decision",
+          "label": "Work Order",
+          "when": { "field": "To", "operator": "EqualTo", "value": "Work Order" },
+          "then": "Get_WO"
+        }
+      ]
+    },
+    "recordLookups": [
+      {
+        "name": "Get_Truck",
+        "label": "Get Truck",
+        "object": "Location",
+        "filters": [
+          { "field": "Service_Resource__c", "operator": "EqualTo", "valueRef": "$User.Id" }
+        ],
+        "outputAssignments": [
+          { "assignTo": "Transfer_Destination", "field": "Id" }
+        ],
+        "next": "Part_Transfers"
+      },
+      {
+        "name": "Get_WO",
+        "label": "Get WO",
+        "object": "WorkOrder",
+        "filters": [
+          { "field": "Id", "operator": "EqualTo", "valueRef": "Work_Order_Number.value" }
+        ],
+        "outputAssignments": [
+          { "assignTo": "Transfer_Destination", "field": "LocationId" }
+        ],
+        "next": "Part_Transfers"
+      }
+    ],
+    "loop": {
+      "name": "Part_Transfers",
+      "label": "Part Transfers",
+      "collection": "Part.AddedItems",
+      "next": "Transfer_Part"
+    },
+    "recordCreates": [
+      {
+        "name": "Transfer_Part",
+        "label": "Transfer Part",
+        "object": "ProductTransfer",
+        "next": "Part_Transfers",
+        "inputAssignments": [
+          { "field": "DestinationLocationId", "valueRef": "Transfer_Destination" },
+          { "field": "IsReceived", "boolean": true },
+          { "field": "OwnerId", "valueRef": "$User.Id" },
+          { "field": "Product2Id", "valueRef": "Part_Transfers.Part_Number.value" },
+          { "field": "QuantityReceived", "valueRef": "Part_Transfers.Quantity.value" },
+          { "field": "QuantitySent", "valueRef": "Part_Transfers.Quantity.value" },
+          { "field": "ReceivedById", "valueRef": "$User.Id" }
+        ]
+      }
+    ]
+  }
+}
+```
+
+## How the converter wires it up
+
+When `postScreen` is present:
+
+- The **last screen's connector** points to the decision's `name` (or, if no decision, the first lookup, or the loop, or the first recordCreate — whichever is first in the chain).
+- The decision emits `<decisions>` with one `<rules>` per branch. Each rule's `connector` targets `then`. The `defaultConnectorLabel` becomes the catch-all branch label (no connector means the flow ends on the default path).
+- Each `recordLookups` emits its filter list, output assignments, and a `connector` to its `next`.
+- The `loop` emits `<loops>` with `collectionReference`, `nextValueConnector` to its `next`. The "no more items" path falls through (no connector).
+- Each `recordCreates` emits its input assignments and a `connector` back to the loop (so iteration continues). The loop's "default" (after items finish) is what naturally terminates the flow.
+- All non-input variables in `postScreen.variables` are emitted alongside the three required `parentObjectType` / `parentRecordId` / `recordId` variables.
+
+## Spec → XML reference card
+
+| Spec key | Emits |
+|---|---|
+| `valueRef` | `<elementReference>...</elementReference>` |
+| `value` (string) | `<stringValue>...</stringValue>` |
+| `boolean` | `<booleanValue>true|false</booleanValue>` |
+| `number` | `<numberValue>...</numberValue>` |
+
+Filter / decision-condition operators that have been seen in real flows: `EqualTo`, `NotEqualTo`, `GreaterThan`, `LessThan`, `IsNull`, `Contains`. The converter passes them through as-is — Salesforce will reject anything invalid.
+
+## Limitations
+
+- Only one decision, one loop, and one chain of lookups+creates per spec. Real flows can have many; that's not in scope here.
+- No `assignments` element (the Inventory_Transfer flow uses `recordLookups` outputAssignments instead, which we replicate).
+- No formula resources or text templates.
+- No nested loops, no decisions inside loops.
+
+If you need any of the above, deploy what the skill produces and finish wiring in Flow Builder.

package/skills/field-service-data-capture-form-designer-configure/SKILL.md

@@ -0,0 +1,110 @@
+---
+name: field-service-data-capture-form-designer-configure
+description: "Design a Field Service Mobile Data Capture Flow from either a natural-language description OR a PDF/image of an existing paper form. Extracts field labels, types, required-state, and section structure into an intermediate JSON spec, confirms the plan with the user, then hands off to fs-data-capture-form-deployer for compile + deploy. Handles both input modes in one skill — prose ('build a Field Service form for asset inspection', 'make a DataCaptureFlow that asks the technician to…', 'create an inventory transfer form') and visual sources ('convert this PDF to a Data Capture Flow', 'make a Field Service form from this image', 'turn this paper form into a DataCaptureFlow'). Detects the input mode automatically from a .pdf/.png/.jpg/.jpeg path, else extracts from the prose. Do NOT use this skill to patch an already-deployed flow — that's fs-data-capture-form-editor."
+user-invocable: false
+metadata:
+  version: "1.0"
+  domains: ["Field Service"]
+---
+
+# Design a Data Capture Form (from prose or from an image / PDF)
+
+This skill produces an intermediate JSON spec from the user's input — a
+natural-language description **or** a PDF/image of an existing form — gets the
+user's approval on the plan, and then invokes `fs-data-capture-form-deployer` to
+compile and deploy.
+
+## When this skill fires
+
+The user asks for a Data Capture Flow / Field Service Mobile form. The input
+arrives in one of two modes:
+
+- **Prose mode** — the user describes the form in plain text with no attached file. Examples:
+  - "Create a data capture form for asset inspection that asks for asset id, condition rating, photos, and remarks."
+  - "Build a Field Service form for inventory transfer with parts repeater, source location, and destination dropdown."
+  - "Generate a DataCaptureFlow that captures three things: site name, contact info, and a notes field."
+- **Image / PDF mode** — the user supplies a path to a `.pdf`, `.png`, `.jpg`, or `.jpeg` file. Examples:
+  - "Convert /tmp/inspection.pdf to a Data Capture Flow"
+  - "Build a Field Service form from this image: ~/Downloads/site-visit.png"
+  - "Turn this paper form into a DataCaptureFlow" (with attached image)
+
+Detect the mode from the input: **if the user supplied a `.pdf` / `.png` / `.jpg` / `.jpeg` path, use image/PDF mode; otherwise use prose mode.** Everything after extraction (steps 2-6) is identical for both.
+
+## Workflow
+
+### 1. Read the source (mode-dependent)
+
+**Prose mode — read the description carefully; don't fabricate fields.**
+Extract only the fields the user actually mentioned. Don't invent extra fields based on what "usually goes on" an inspection form. If the user says "asks for asset id, condition rating, photos, and remarks", emit four fields, not eight.
+
+If the user's description is too vague to produce a usable form ("build a form that captures stuff about a service appointment"), ask one or two targeted questions before extracting — what fields they want, whether there's a parent record, what should happen on submit. Don't guess.
+
+Then apply the prose-evidence rules in [reference/extraction-from-prompt.md](reference/extraction-from-prompt.md).
+
+**Image / PDF mode — read the file.**
+Use the `Read` tool on the path the user gave you. PDFs and images are natively supported. If the PDF is more than 10 pages, ask the user which pages contain the form (the `Read` tool requires a `pages` parameter for large PDFs).
+
+Then apply the control-evidence rules in [reference/extraction-from-image.md](reference/extraction-from-image.md).
+
+### 2. Extract the intermediate JSON
+
+Apply every rule in the mode-appropriate extraction reference (from step 1). The output schema is defined by the **input contract of the build skill**:
+- [field-types.md](../fs-data-capture-form-deployer/reference/field-types.md) — field type → component mapping, required Flow boilerplate, choice/repeater shapes, visibility rules.
+- [post-screen-automation.md](../fs-data-capture-form-deployer/reference/post-screen-automation.md) — schema for the optional `postScreen` block.
+
+Write the JSON to `/tmp/data-capture-spec.json`.
+
+### 3. Determine the desired outcome
+
+A data capture form is a means, not an end. Before asking for approval, decide what should happen in Salesforce when the user submits the form:
+
+- If the user explicitly says what to create/update ("create a ProductTransfer for each part"), OR the source/filename strongly implies an outcome (Inventory Transfer → ProductTransfer; Asset Inspection → WorkOrderLineItem) — emit a `postScreen` block with the named (or best-guess) object and field API names. When it's a best guess, list every `valueRef` / `field` in the confirmation step so the user can correct names.
+- If the outcome is ambiguous AND the user gave no hint — surface the question in the confirmation step ("What should happen when this form is submitted?") with concrete options drawn from the form's domain.
+- A screens-only flow with no `postScreen` is valid, but you must say so explicitly in the confirmation step.
+
+See the mode-appropriate extraction reference for the full outcome-elicitation rules.
+
+### 4. Confirm with the user (mandatory gate)
+
+Show the user what you plan to build before deploying. Use `AskUserQuestion` to gate the handoff to Build.
+
+In the question body or surrounding text, plainly state:
+
+1. **The desired outcome.** What the flow does after the last screen — e.g. "Submitting the form will create a ProductTransfer per row in the Parts repeater" or "This flow only captures data — admin will wire up automation in Flow Builder." If a `postScreen` block was generated, list every Salesforce object name and every `field` API name it references. Object/field API names are the most common source of post-deploy errors.
+2. The `formTitle` and the proposed `<FlowApiName>` (PascalCase, no spaces).
+3. The number of screens and total fields (count repeater children too).
+4. Any visibility rules generated and the choice values they key off of.
+5. **Every field type, especially specialized ones, and the evidence it's based on.** For each `Signature`, `UploadFile`, `UploadImage`, `Images`, `Matrix`, `Address`, `Lookup`, `FileView`, or `Repeater` in the spec, name the field and the evidence — in prose mode the prose evidence ("user said 'parts repeater'", "user described a sign-here pad"); in image mode the visual evidence ("`damagePhoto` → UploadImage because the source has a camera-icon button"). These deploy as **real functional components** (`dcSignature`, `dcUpImage`, etc.) — so emitting them when the user only meant a text field (prose) or when you can only point to the field's *label* (image) is the most common extraction bug. If the matching control vocabulary / visual control isn't present, downgrade to `ShortText`/`LongText`/`Numeric` and call it out.
+6. **Lookup objects and FileView filenames.** For every `Lookup`, list the `lookupObject` (Salesforce object API name) and `lookupSearchFields` you chose. For every `FileView`, list the `fileName`. These names are common sources of post-deploy errors — surface them so the user can correct.
+7. Any fields that fell back to a labeled `dcTextInput` placeholder (only happens for `Lookup` with no `lookupObject` and `FileView` with no `fileName`).
+
+Offer the user clear options:
+- **Approve and deploy** — proceed to step 5.
+- **Edit the spec first** — let them edit `/tmp/data-capture-spec.json` directly, then re-run from step 4.
+- **Cancel** — stop without deploying.
+
+Do not proceed to step 5 without explicit approval.
+
+### 5. Hand off to Build
+
+Once approved, hand the approved spec to `fs-data-capture-form-deployer`. Pick a `<FlowApiName>` matching `^[A-Z][A-Za-z0-9_]*$` (default: PascalCase of `formTitle`), then follow that skill's workflow — it runs entirely over REST through the Codey runtime, with **no `sf` CLI, no scripts, and no `.flow-meta.xml`**:
+
+1. **Verify org auth** — [fs-data-capture-form-deployer/SKILL.md](../fs-data-capture-form-deployer/SKILL.md) §1 (a cheap `SELECT Id FROM Organization LIMIT 1` REST probe; the runtime resolves the connected org — this family does not manage aliases).
+2. **Build the Flow Metadata JSON inline** from the approved spec — deployer §3 + [reference/flow-metadata-json.md](../fs-data-capture-form-deployer/reference/flow-metadata-json.md). The agent assembles the `Metadata` object directly; there is no XML compile step.
+3. **Deploy** with a single `POST /services/data/vXX.0/tooling/sobjects/Flow` carrying `{ "FullName": "<FlowApiName>", "Metadata": { ... } }` — deployer §4.
+
+After deploy, follow the reporting + error-handling steps in [fs-data-capture-form-deployer/SKILL.md](../fs-data-capture-form-deployer/SKILL.md) §5.
+
+### 6. Offer to attach the form to a parent record
+
+After a successful deploy, the flow exists but is invisible from the Forms tab on any Service Appointment / Work Order. Ask the user whether they want it attached to a specific parent (the canonical "pending form" pattern). If yes, follow the attach steps in [fs-data-capture-form-deployer/SKILL.md](../fs-data-capture-form-deployer/SKILL.md) §6 — a single `POST /services/data/vXX.0/sobjects/DynamicDataCapture` (no scripts). For SA-context testing, attach to the SA's parent Work Order, not the SA itself — FSL Mobile reads Forms from the parent Work Order.
+
+## Out of scope
+
+- Patching an already-deployed flow → `fs-data-capture-form-editor`.
+- Hand-authoring patterns the converter doesn't generate (visual polish HTML, real `dcSignature`/`dcUpImage`, master-detail child records, supporting CustomObjects) → `fs-data-capture-reference` library skill.
+
+## Files in this skill
+
+- `reference/extraction-from-prompt.md` — prose-evidence rules for picking field types from user descriptions, screen grouping, visibility rules, outcome-elicitation, validation checklist. Used in **prose mode**.
+- `reference/extraction-from-image.md` — control-evidence rules for picking field types from rendered widgets, repeater extraction rules, screen grouping, visibility rules, outcome-elicitation, validation checklist. Used in **image / PDF mode**.