@salesforce/afv-skills 1.33.0 → 1.35.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@salesforce/afv-skills",
-  "version": "1.33.0",
+  "version": "1.35.0",
   "description": "Salesforce skills for Agentforce Vibes",
   "license": "CC-BY-NC-4.0",
   "files": [

package/skills/agentforce-architecture-analyze/SKILL.md

@@ -3,6 +3,14 @@ name: agentforce-architecture-analyze
 description: "Declared architecture snapshot for one Agentforce agent: planner, topics, actions, flows, Apex, prompt templates, and NGA plugins. Renders a human-readable architecture document and Mermaid invocation graph from design-time metadata (not runtime audit rows). TRIGGER when user asks to describe, diagram, inventory, audit, document, or diff (e.g. v3 vs v5) the architecture / action tree / topic structure / tool inventory of a specific agent by agent API name in a specific org. DO NOT TRIGGER for runtime session traces, conversation transcripts, generation timings, or gateway audit chains — this skill reads design-time metadata only (use agentforce-d360-analyze for session traces)."
 metadata:
   version: "1.0"
+  minApiVersion: "64.0"
+  relatedSkills:
+    - "agentforce-d360-analyze"
+  cliTools:
+    - tool: ["sf"]
+      semver: ">=2.136.8"
+    - tool: ["python3"]
+      semver: ">=3.10.0"
 ---
 
 # agentforce-architecture-analyze — declared architecture snapshot

package/skills/agentforce-bot-upgrade/SKILL.md

@@ -7,8 +7,6 @@ metadata:
   minApiVersion: "63.0"
   relatedSkills:
     - "agentforce-generate"
-    - "agentforce-test"
-    - "agentforce-observe"
   cliTools:
     - tool: ["sf"]
       semver: ">=2.0.0"

package/skills/agentforce-d360-analyze/SKILL.md

@@ -2,7 +2,15 @@
 name: agentforce-d360-analyze
 description: "Data Cloud 360° view of a single Agentforce session. TRIGGER when user asks to trace, inspect, summarize, or describe a specific Agentforce session by session id (Agent Session UUID `019d…` or MessagingSession id `0Mw…`). Also triggers on session discovery — find/list/search sessions by time, agent, channel, outcome, or conversation text — when the user has no session id yet. DO NOT TRIGGER for design-time architecture questions (use agentforce-architecture-analyze instead) or for runtime perf/latency/SLO questions that require platform telemetry beyond Data Cloud."
 metadata:
+  cliTools:
+    - tool: ["python3"]
+      semver: ">=3.10.0"
+    - tool: ["sf"]
+      semver: ">=2.0.0"
+  relatedSkills:
+    - "agentforce-architecture-analyze"
   version: "1.0"
+  minApiVersion: "66.0"
 ---
 
 # agentforce-d360-analyze — Data Cloud 360° session view

package/skills/agentforce-observe/SKILL.md

@@ -3,6 +3,9 @@ name: agentforce-observe
 description: "Analyze production Agentforce agent behavior using session traces and Data Cloud. TRIGGER when: user queries STDM session data or Data Cloud trace records; investigates production agent failures, regressions, or performance issues; asks about session traces, conversation logs, or agent metrics; wants to reproduce a reported production issue in preview; runs findSessions or trace analysis queries. DO NOT TRIGGER when: user creates, modifies, or debugs .agent files during development (use agentforce-generate); writes or runs test specs (use agentforce-test); uses sf agent preview for local development iteration; deploys or publishes agents."
 allowed-tools: Bash Read Write Edit Glob Grep
 metadata:
+  relatedSkills:
+    - "agentforce-generate"
+    - "agentforce-test"
   version: "0.8"
   cliTools:
     - tool: ["git"]

package/skills/agentforce-test/SKILL.md

@@ -3,6 +3,9 @@ name: agentforce-test
 description: "Write, run, and analyze structured test suites for Agentforce agents — functional AND security. TRIGGER when: user writes or modifies test spec YAML (AiEvaluationDefinition); runs sf agent test create, run, run-eval, or results commands; asks about test coverage strategy, metric selection, or custom evaluations; interprets test results or diagnoses test failures; asks about batch testing, regression suites, or CI/CD test integration; requests security testing, OWASP LLM Top 10, red-teaming, penetration testing, prompt-injection tests, a security grade, or a vulnerability assessment of an agent. DO NOT TRIGGER when: user creates, modifies, previews, or debugs .agent files (use agentforce-generate); deploys or publishes agents; writes Agent Script code; uses sf agent preview for development iteration; analyzes production session traces (use agentforce-observe); performs a static safety review of .agent file content (use agentforce-generate Section 15)."
 allowed-tools: Bash Read Write Edit Glob Grep
 metadata:
+  relatedSkills:
+    - "agentforce-generate"
+    - "agentforce-observe"
   version: "0.8"
   cliTools:
     - tool: ["curl"]

package/skills/automation-flow-generate/SKILL.md

@@ -3,6 +3,7 @@ name: automation-flow-generate
 description: "Generate Salesforce Flows using the MCP tool execute_metadata_action. Use when the user asks to create, build, or generate a flow — including Screen, Autolaunched, Record-Triggered (before/after-save), Scheduled. Also trigger for flow-like requests such as \"when a record is created\", \"trigger daily at\", \"send an email when\", \"update the field when\", \"automate\", \"workflow\", or \"flow XML/metadata\". This is the only skill for Salesforce Flow generation."
 metadata:
   version: "1.0"
+  minApiVersion: "60.0"
 ---
 
 ## Goal

package/skills/automation-sandbox-post-copy-config-generate/SKILL.md

@@ -0,0 +1,239 @@
+---
+name: automation-sandbox-post-copy-config-generate
+description: "Generate the JSON config file that the Salesforce sandbox post-copy automation tool consumes, from a customer SOP in any format (PDF, xlsx, csv, JSON, docx, Markdown, plain text, or a screenshot of an endpoint table). Use when the user asks to create, build, generate, produce, or convert a post-copy or post-refresh automation config — turning a sandbox-refresh SOP into a JSON array of OutboundMessages and RemoteSiteSettings entries with ConfigurationName, Label, Fields, IsActive, and ExecutionOrder. Also trigger for phrasings like \"post-copy config\", \"post-refresh automation JSON\", \"update the outbound message (OBM) endpoints after refresh\", \"convert this SOP to config\", \"remote site settings JSON\", \"refresh planner to JSON\", or \"sandbox refresh config\". DO NOT TRIGGER when: user wants to deploy the generated config to an org (use platform-metadata-deploy) or execute/run the post-copy automation tool. This is the only skill for Salesforce sandbox post-copy config generation."
+metadata:
+  version: "1.0"
+---
+
+# Automation: Sandbox Post-Copy Config Generate
+
+Convert a customer's sandbox-refresh / post-copy SOP into a structured JSON
+array that the post-copy automation tool consumes. Each entry is a
+declarative instruction: which Salesforce configuration to update, which
+fields are involved, whether it is active, and what order it runs in.
+
+## STOP — do this before writing any JSON
+
+Do **not** compose the output from memory. Before you write the file, you
+MUST open and read `assets/config_template.json` and copy an entry from it
+for each action. Every output entry is exactly one of these two shapes —
+five top-level keys, no others, no wrapper object:
+
+```json
+[
+  {
+    "ConfigurationName": "OutboundMessages",
+    "Label": "IR_Account_OBM_PROD",
+    "Fields": { "EndpointUrl": "https://uat.example.com/services/account", "Object": "Account" },
+    "IsActive": true,
+    "ExecutionOrder": 1
+  },
+  {
+    "ConfigurationName": "RemoteSiteSettings",
+    "Label": "R12_Remote_Site",
+    "Fields": { "RemoteSiteUrl": "https://uat.example.com" },
+    "IsActive": true,
+    "ExecutionOrder": 2
+  }
+]
+```
+
+- `ConfigurationName`: exactly `OutboundMessages` or `RemoteSiteSettings` — never `Type`, `Name`, or `Operation`.
+- OBM `Fields`: `EndpointUrl` + `Object` (both required). RemoteSite `Fields`: `RemoteSiteUrl` only — never `Url`/`RemoteSiteURL`.
+- Top level is a JSON array. No `steps`/`actions`/`records` wrapper. No `<…>` or `REPLACE_WITH_…` placeholder ever survives into the output.
+
+If you announce "I will now write …" without having read the template and
+catalog, stop and read them first — a from-memory guess produces the wrong
+keys and fails at runtime.
+
+## Scope
+
+- **In scope**: Reading a customer SOP in any of the supported formats
+  (PDF, xlsx, csv, JSON, docx, Markdown, plain text, pasted excerpt, or
+  images containing data tables — e.g., a screenshot of an
+  Outbound Messages list with endpoint URLs), identifying post-copy /
+  post-refresh actions, mapping each action to a supported
+  `ConfigurationName`, emitting the canonical JSON array.
+- **Out of scope**: Generating Salesforce metadata XML (delegate to
+  `generating-*` skills), deploying anything to an org, running the
+  post-copy tool, inferring or fabricating values not present in the SOP —
+  if the SOP does not give a concrete URL/value for an action, skip the
+  action.
+
+**Every emitted entry must have every Field populated with a real value
+from the customer source.** No empty strings, no `null`, no
+`<from-backup>` / `TBD` / `TODO` placeholders. Customers should never
+see an unpopulated field in the output — if a value cannot be located,
+skip the entry and surface it. See the corresponding rule below.
+
+---
+
+## Required Inputs
+
+Gather or infer before generating:
+
+- **SOP source(s)**: One or more paths (or pasted content) in any of:
+  PDF, xlsx, csv, JSON, docx, Markdown, plain text, or images
+  (.png/.jpg/.jpeg/.tiff/.bmp). Multiple files are common — the action
+  list and the endpoint table sometimes live in different files. Read
+  every file the user supplies.
+- **Target output path**: Where the JSON config should be written. Default
+  to `post-copy-config.json` in the current directory unless specified.
+- **Scope filter** (optional): If the SOP covers many environments
+  (e.g., fcQA, fcUAT, multiple sandboxes), confirm which subset the user
+  wants in the output.
+
+If the user provides a clear SOP and target, generate immediately without
+asking unnecessary questions.
+
+---
+
+## Workflow
+
+All steps are sequential. Steps 1–5 (reading the SOP, the catalog, the
+template, and the schema) are **prerequisites to writing** — you may not
+skip to the write step. If you catch yourself about to emit JSON without
+having read `assets/config_template.json` and
+`references/configuration_catalog.md`, go back and read them first.
+
+1. **Locate and read every supplied SOP source** — read
+   `references/source_format_handling.md` for the exact extraction
+   recipe per format (PDF, xlsx, csv, JSON, docx, image). At a glance:
+   - **PDF**: extract text with `pypdf` (text layer) and OCR
+     image-based pages with `pytesseract` if the text layer is empty.
+   - **xlsx**: read every sheet with `openpyxl` (`data_only=True`),
+     scan all columns including ones outside the visible default
+     range, check cell comments and embedded media.
+   - **csv / JSON / Markdown / text**: read directly.
+   - **docx**: extract paragraphs and tables with `python-docx`.
+   - **Images** (.png/.jpg/...): use the `Read` tool to view, then
+     decide if the image carries data (a table of endpoint URLs, a
+     setup screenshot showing values to capture) or is purely
+     illustrative (architecture diagram, flow chart). Extract values
+     only from data-bearing images. See the image-handling rules in
+     `references/source_format_handling.md`.
+   - For very large SOPs (>50 pages / >20 sheets), focus on sections
+     or sheets titled "Post Refresh", "Post-Copy", "Post-Refresh
+     Steps", "Update …", or equivalent.
+
+2. **Identify post-copy actions** — read
+   `references/sop_parsing_patterns.md` for the heuristics that turn prose
+   instructions ("Update Outbound Message endpoint X to URL Y") into
+   structured action records.
+
+3. **Map each action to a `ConfigurationName`** — load
+   `references/configuration_catalog.md`. The catalog currently supports
+   only `OutboundMessages` and `RemoteSiteSettings`. Any action that
+   targets a different configuration type is out of scope: skip it and
+   list it in the response so the user can extend the catalog later.
+
+4. **Read the JSON template** — load `assets/config_template.json`. It
+   shows the exact required shape of one `OutboundMessages` entry and one
+   `RemoteSiteSettings` entry, with `<…>` placeholder slots. Copy an
+   entry, replace every `<…>` slot with the concrete SOP value, and keep
+   the exact top-level keys (`ConfigurationName`, `Label`, `Fields`,
+   `IsActive`, `ExecutionOrder`) — never rename them to `Type`, `Name`,
+   `Operation`, etc. Never emit an entry that still contains a `<…>`
+   placeholder; if you cannot fill a slot, skip the entry (see Rules).
+
+5. **Validate against the schema** — load `assets/json_schema.json`. Every
+   entry must conform: `ConfigurationName` is one of the catalog values,
+   `Fields` is an object, `IsActive` is boolean, `ExecutionOrder` is a
+   positive integer.
+
+6. **Group entries by phase, then assign `ExecutionOrder`** —
+   `ExecutionOrder` is a phase number, not a per-row counter. Entries that
+   can run in parallel (no dependency between them) share the same value.
+   Different `ConfigurationName` types typically get different phases; all
+   entries within one phase share its number. See the ordering heuristic
+   in `references/sop_parsing_patterns.md`.
+
+7. **Compare against the example** — verify the output shape against
+   `examples/sample_sop_to_config.json` before writing.
+
+8. **Write the JSON file** — emit pretty-printed JSON (2-space indent).
+
+---
+
+## Rules / Constraints
+
+| Constraint | Rationale |
+|-----------|-----------|
+| Output is a JSON array at the top level (not an object with a wrapper key) | The post-copy tool consumes an array directly |
+| Every entry has all five required keys: `ConfigurationName`, `Label`, `Fields`, `IsActive`, `ExecutionOrder` | The tool fails fast on missing keys; partial entries are not silently accepted |
+| `ConfigurationName` is one of the catalog values | Unknown values cause the runtime mapper to error out — never invent a new type without updating the catalog |
+| `Fields` keys are the actual API field names on the target metadata | Wrong key names mean the tool can't locate the field at runtime |
+| `Fields` values are the concrete values from the SOP (literal URLs, names, etc.) | The post-copy tool applies the value as-is; placeholders are not resolved at runtime |
+| If the SOP names an action but no concrete value (URL, etc.) is provided, **skip the entry** entirely and list it in the response | Generating an entry without a real value would produce a silent no-op or a deployment error at runtime |
+| Every Field in every emitted entry must be a real value sourced from the customer's SOP or a supplemental sheet they provided. Never emit `""`, `null`, or placeholder markers like `<from-backup>` / `TBD` / `TODO` | Customers consume the JSON directly — empty / placeholder fields surface to them as broken output and would also fail at runtime |
+| Before skipping an OBM / RemoteSite for missing values, **search every tab / sheet of the supplied workbook (and every supplied file)** for an endpoint table keyed by that name | Customer SOPs frequently split the action list and the URL table across different sheets (e.g., the Michelin UAT Refresh Planner lists OBMs in the Integration tab but the URL table lives in the Evolution SFA tab) |
+| Information already captured by another field is **not** repeated in `Fields` (e.g., `RemoteSiteName` lives in `Label`, `IsActive` lives at the top level — neither belongs in `Fields`) | Duplicate keys make the entry ambiguous and waste bytes the tool then has to reconcile |
+| For `OutboundMessages`, `Fields` MUST include both `EndpointUrl` and `Object` (the target SObject — `Account`, `Contact`, `Asset`, `Lead`, etc.) | Same Label can apply to multiple OBMs differing only by entity; `Object` disambiguates them at runtime |
+| For `RemoteSiteSettings`, the URL key MUST be spelled exactly `RemoteSiteUrl` — never `Url`, `RemoteSiteURL`, `SiteUrl`, or `EndpointUrl` | The post-copy tool matches the field by exact API name; any other spelling means it can't locate the field and the entry silently no-ops at runtime |
+| `ExecutionOrder` is a phase number — entries with no dependency on each other share the same value | The post-copy tool runs all entries with the same `ExecutionOrder` in parallel; sequencing is only needed where one action depends on another |
+| `IsActive: false` entries remain in the output (do not delete them) | The customer toggles them on per-environment; deleting loses traceability |
+| Default `IsActive` to `true` when the SOP marks an action as required | Most SOP steps are required; explicit opt-out is the exception |
+
+### Canonical entry shape
+
+See the entry shapes shown in the STOP section above, or copy directly from
+`assets/config_template.json`. Do **not** rename the five top-level keys
+(`ConfigurationName`, `Label`, `Fields`, `IsActive`, `ExecutionOrder`) to
+`Type`, `Name`, `Operation`, `apiName`, etc., and do **not** wrap the array
+in an object with a `steps` / `actions` / `records` key.
+
+---
+
+## Gotchas
+
+| Issue | Resolution |
+|-------|------------|
+| SOP step says "delete all endpoints" rather than "update X to Y" | Emit an entry with `ConfigurationName: "OutboundMessages"`, `Label` describing the deletion target, and a note in `Fields` (`{"Action": "Delete"}`); the catalog documents the Delete pattern |
+| Same Label appears for multiple environments (fcQA + fcUAT) | Emit one entry per environment; suffix the Label or use the environment-specific Label as it appears in the SOP |
+| For OutboundMessages, the same Label can legitimately apply to multiple entries when each targets a different `Object` (e.g., one OBM for Account, one for Contact). | Do not collapse them — emit one entry per Object. The `Object` value (inferred from the OBM name like `IR_Account_OBM_PROD` → `Account`) is what distinguishes them, not the Label. |
+| SOP groups many Custom Labels together in a single table | One entry per row of the table — do not collapse into a single bulk entry |
+| Action targets a setting outside the catalog (CustomLabels, ConnectedApps, NamedCredentials, SSO, CustomSettings, etc.) | Skip the action, do NOT invent a new `ConfigurationName`; list every skipped action in the response so the user knows what to add to the catalog later |
+| SOP includes pre-refresh steps interleaved with post-refresh | Filter out pre-refresh — only post-refresh / post-copy actions belong in the output |
+| SOP names an outbound message / remote site to update but does not include the new URL | Skip the entry. List the skipped item in the response so the user can supply the URL or amend the SOP |
+| SOP includes secrets in URLs (e.g., `https://USER:TOKEN@host/...`) | Embed them verbatim — the tool consumes the value as-is — but flag in the response so the user is aware the JSON now contains a secret and should be stored / shared accordingly |
+| User's SOP is in a non-English language or has heavy formatting (tables, callouts) | Extract the prose first, normalize whitespace, then parse — formatting artifacts do not need to survive into the JSON |
+| The SOP includes screenshots / images. Some are illustrative (architecture diagrams, flow charts, "this is what the setup screen looks like" examples); others are data-bearing (a screenshot of a real Outbound Messages list, a captured Remote Site table). | Treat illustrative images as out-of-scope — do NOT extract values from them. For data-bearing images (the surrounding text refers to "the values shown below" / "as captured in the screenshot above" / a real Endpoint URL is visible), OCR them and use the values. See `references/source_format_handling.md` for the heuristic. |
+| The SOP is supplied as multiple files (e.g., a PDF + a companion xlsx + a screenshot folder), or values are split across tabs / pages | Read every supplied file end-to-end before skipping any entry. The action list and the URL table are frequently in different files — see the rule above about multi-sheet sources. |
+
+---
+
+## Output Expectations
+
+Deliverables:
+- A single JSON file (default `post-copy-config.json`) containing a
+  top-level array of post-copy action entries.
+- A short summary in your response listing: total entries, count per
+  `ConfigurationName`, actions skipped because they did not map to the
+  catalog, and actions skipped because the SOP did not include a concrete
+  value.
+
+The output file structure conforms to `assets/json_schema.json`.
+
+---
+
+## Cross-Skill Integration
+
+| Need | Delegate to |
+|------|-------------|
+| Generate the actual Salesforce metadata XML for a Custom Label / Named Credential / Remote Site / etc. | The matching `generating-*` skill |
+| Deploy generated metadata or run the post-copy tool against an org | `deploying-metadata` skill |
+| Compare an SOP against entities defined in UDD | `udd:research-entities` |
+
+---
+
+## Reference File Index
+
+| File | When to read |
+|------|-------------|
+| `assets/config_template.json` | Step 4 — starting structure for the JSON output |
+| `assets/json_schema.json` | Step 5 — validate every emitted entry |
+| `references/configuration_catalog.md` | Step 3 — to map an SOP action to a `ConfigurationName` and get the canonical Field keys |
+| `references/sop_parsing_patterns.md` | Step 2 and step 6 — heuristics for extracting actions from prose and ordering them |
+| `references/source_format_handling.md` | Step 1 — exact extraction recipe per input format (PDF / xlsx / csv / JSON / docx / image) and the data-bearing-vs-illustrative image heuristic |
+| `examples/sample_sop_to_config.json` | Step 7 — verify output shape matches expected format |
+| `examples/sample_sop_excerpt.md` | Step 7 — see a representative SOP excerpt that produced the sample JSON |

package/skills/automation-sandbox-post-copy-config-generate/assets/config_template.json

@@ -0,0 +1,21 @@
+[
+  {
+    "ConfigurationName": "OutboundMessages",
+    "Label": "<OBM DeveloperName exactly as in the SOP>",
+    "Fields": {
+      "EndpointUrl": "<literal post-refresh URL from the SOP>",
+      "Object": "<target SObject, e.g. Account / Contact / Asset>"
+    },
+    "IsActive": true,
+    "ExecutionOrder": 1
+  },
+  {
+    "ConfigurationName": "RemoteSiteSettings",
+    "Label": "<Remote Site name exactly as in the SOP>",
+    "Fields": {
+      "RemoteSiteUrl": "<literal post-refresh URL from the SOP>"
+    },
+    "IsActive": true,
+    "ExecutionOrder": 2
+  }
+]

package/skills/automation-sandbox-post-copy-config-generate/assets/json_schema.json

@@ -0,0 +1,90 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "title": "Post-Copy Automation Config",
+  "description": "Array of declarative post-copy actions consumed by the Salesforce post-copy automation tool.",
+  "type": "array",
+  "items": {
+    "type": "object",
+    "additionalProperties": false,
+    "required": [
+      "ConfigurationName",
+      "Label",
+      "Fields",
+      "IsActive",
+      "ExecutionOrder"
+    ],
+    "allOf": [
+      {
+        "if": {
+          "properties": { "ConfigurationName": { "const": "RemoteSiteSettings" } }
+        },
+        "then": {
+          "properties": {
+            "Fields": {
+              "type": "object",
+              "additionalProperties": false,
+              "required": ["RemoteSiteUrl"],
+              "properties": {
+                "RemoteSiteUrl": {
+                  "description": "The exact API field name for a Remote Site Setting URL. Must be spelled RemoteSiteUrl — Url, RemoteSiteURL, SiteUrl, and EndpointUrl are all invalid.",
+                  "type": "string",
+                  "minLength": 1
+                }
+              }
+            }
+          }
+        }
+      },
+      {
+        "if": {
+          "properties": { "ConfigurationName": { "const": "OutboundMessages" } }
+        },
+        "then": {
+          "properties": {
+            "Fields": {
+              "type": "object",
+              "required": ["Object"],
+              "anyOf": [
+                { "type": "object", "required": ["EndpointUrl"] },
+                { "type": "object", "required": ["Action"] }
+              ]
+            }
+          }
+        }
+      }
+    ],
+    "properties": {
+      "ConfigurationName": {
+        "description": "Salesforce configuration / metadata type. Must be one of the values listed in references/configuration_catalog.md.",
+        "type": "string",
+        "enum": [
+          "OutboundMessages",
+          "RemoteSiteSettings"
+        ]
+      },
+      "Label": {
+        "description": "The metadata Label or DeveloperName of the specific record being updated, exactly as it appears in the SOP.",
+        "type": "string",
+        "minLength": 1
+      },
+      "Fields": {
+        "description": "Map of API field name -> concrete value taken verbatim from the SOP. Do not include fields that are duplicated by Label (RemoteSiteName) or by the top-level IsActive flag.",
+        "type": "object",
+        "minProperties": 1,
+        "additionalProperties": {
+          "type": ["string", "number", "boolean"]
+        },
+        "$comment": "Per-ConfigurationName key constraints are enforced by the allOf/if-then blocks above."
+      },
+      "IsActive": {
+        "description": "Whether the post-copy tool should execute this action. Default true.",
+        "type": "boolean"
+      },
+      "ExecutionOrder": {
+        "description": "Phase number. Entries with no dependency on each other share the same value and run in parallel; lower numbers run before higher.",
+        "type": "integer",
+        "minimum": 1
+      }
+    }
+  }
+}

package/skills/automation-sandbox-post-copy-config-generate/examples/sample_sop_excerpt.md

@@ -0,0 +1,31 @@
+# Sample SOP Excerpt
+
+This is a representative slice of a customer SOP — the type of input the
+skill receives. The matching expected output is in
+`sample_sop_to_config.json`.
+
+---
+
+## Post Refresh Steps – Update Outbound Messages Endpoints
+
+Update the Outbound Messaging Endpoints after the refresh. Navigate to
+Setup > Process Automation > Workflow Actions > Outbound Messages.
+
+| Outbound Message       | Post-refresh endpoint URL                       |
+|------------------------|-------------------------------------------------|
+| `IR_Account_OBM_PROD`  | `https://uat.example.com/services/account`      |
+| `IR_Contact_OBM_PROD`  | `https://uat.example.com/services/contact`      |
+| `IR_Asset_OBM_PROD`    | `https://uat.example.com/services/asset`        |
+
+The OBM names embed the target SObject (`Account`, `Contact`, `Asset`),
+which becomes the mandatory `Object` field on each generated entry.
+
+## Post Refresh Steps – Remote Site Settings
+
+Update the Remote Site Settings under Setup > Security > Remote Site
+Settings. Both should remain Active.
+
+| Remote Site Name   | Post-refresh URL                       |
+|--------------------|----------------------------------------|
+| `R12_Remote_Site`  | `https://uat.example.com`              |
+| `Tavant_API`       | `https://tavant.uat.example.com`       |

package/skills/automation-sandbox-post-copy-config-generate/examples/sample_sop_to_config.json

@@ -0,0 +1,50 @@
+[
+  {
+    "ConfigurationName": "OutboundMessages",
+    "Label": "IR_Account_OBM_PROD",
+    "Fields": {
+      "EndpointUrl": "https://uat.example.com/services/account",
+      "Object": "Account"
+    },
+    "IsActive": true,
+    "ExecutionOrder": 1
+  },
+  {
+    "ConfigurationName": "OutboundMessages",
+    "Label": "IR_Contact_OBM_PROD",
+    "Fields": {
+      "EndpointUrl": "https://uat.example.com/services/contact",
+      "Object": "Contact"
+    },
+    "IsActive": true,
+    "ExecutionOrder": 1
+  },
+  {
+    "ConfigurationName": "OutboundMessages",
+    "Label": "IR_Asset_OBM_PROD",
+    "Fields": {
+      "EndpointUrl": "https://uat.example.com/services/asset",
+      "Object": "Asset"
+    },
+    "IsActive": true,
+    "ExecutionOrder": 1
+  },
+  {
+    "ConfigurationName": "RemoteSiteSettings",
+    "Label": "R12_Remote_Site",
+    "Fields": {
+      "RemoteSiteUrl": "https://uat.example.com"
+    },
+    "IsActive": true,
+    "ExecutionOrder": 2
+  },
+  {
+    "ConfigurationName": "RemoteSiteSettings",
+    "Label": "Tavant_API",
+    "Fields": {
+      "RemoteSiteUrl": "https://tavant.uat.example.com"
+    },
+    "IsActive": true,
+    "ExecutionOrder": 2
+  }
+]

package/skills/automation-sandbox-post-copy-config-generate/references/configuration_catalog.md

@@ -0,0 +1,76 @@
+# Configuration Catalog
+
+The fixed catalog of supported `ConfigurationName` values for the post-copy
+automation config. **Never invent a new value** — if an SOP step does not
+fit a row below, raise it to the user.
+
+The catalog currently covers two types only:
+
+1. `OutboundMessages`
+2. `RemoteSiteSettings`
+
+Anything else (Custom Labels, Connected Apps, Named Credentials, SSO, etc.)
+is out of scope for this skill at present — surface them to the user and
+recommend a follow-up to extend the catalog.
+
+## How to use this catalog
+
+For each post-copy action extracted from the SOP:
+
+1. Find the row whose **SOP signal** phrases match the action.
+2. Use the `ConfigurationName` from that row.
+3. Use one of the listed **Field keys** in your entry's `Fields` object.
+4. Put the **concrete value** from the SOP (literal URL, name, etc.) as
+   the value. If the SOP does not state a concrete value, **skip the
+   entry** entirely and list it in the response.
+
+## Catalog
+
+### OutboundMessages
+
+- **SOP signal phrases**: "outbound message", "OBM", "endpoint URL",
+  "Workflow Actions > Outbound Messages".
+- **Field keys** (both required for non-delete entries):
+  - `EndpointUrl` — value is the literal post-refresh URL the SOP gives
+    for that outbound message.
+  - `Object` — the SObject the outbound message targets (e.g., `Account`,
+    `Contact`, `Asset`, `Lead`). This is mandatory because the same
+    `Label` may apply to multiple OBMs that differ only by entity, and
+    the post-copy tool needs the Object to disambiguate. Infer from the
+    OBM name (e.g., `IR_Account_OBM_PROD` → `Account`,
+    `IR_Contact_OBM_PROD` → `Contact`) or from explicit text in the SOP.
+    If the entity is genuinely ambiguous and the SOP gives no signal,
+    skip the entry and surface it.
+- **Skip when**: the SOP only names the outbound message but does not
+  give a new endpoint URL, OR the target Object cannot be determined.
+- **Special action**: deletion. When the SOP says "delete all endpoints",
+  use `Fields: { "Action": "Delete", "Object": "<entity>" }`. (`"Delete"`
+  is a literal instruction the tool understands, not a placeholder.)
+
+### RemoteSiteSettings
+
+- **SOP signal phrases**: "remote site setting", "remote site", "trusted
+  URL", "Setup > Security > Remote Site Settings".
+- **Field keys**:
+  - `RemoteSiteUrl` — value is the literal post-refresh URL. The key must
+    be spelled **exactly** `RemoteSiteUrl`. Do **not** use `Url`,
+    `RemoteSiteURL`, `SiteUrl`, or `EndpointUrl` (that last one is the OBM
+    key, not the remote-site key). The post-copy tool matches the field by
+    exact API name, so any other spelling silently no-ops at runtime.
+- **Do NOT add**:
+  - `RemoteSiteName` — the name lives in the top-level `Label` field.
+  - `IsActive` — the active flag lives at the top level of the entry.
+  Putting either inside `Fields` duplicates information the tool already
+  has and creates ambiguity.
+- **Skip when**: the SOP names the remote site but does not give a new
+  URL.
+
+## Adding a new ConfigurationName
+
+If a customer SOP introduces a configuration type not in the list above,
+**stop and ask the user**. Adding a new value requires:
+
+1. Update the `enum` in `assets/json_schema.json`.
+2. Add a new section to this file.
+3. Update `examples/sample_sop_to_config.json` if relevant.
+4. Update the description in `SKILL.md` to include the new type.