@salesforce/afv-skills 1.67.0 → 1.68.0

package/skills/platform-datamask-run/references/policy-authoring.md

@@ -91,13 +91,62 @@ Each `DataMaskPolicyField` carries a `MaskingCategory` plus a `MaskValue` — th
 `MaskingRuleType` column** (older docs claiming values like `RandomEmail` / `RandomPhoneNumber`
 were wrong; that column does not exist).
 
-- `MaskingCategory` — `library` (pick a value from the built-in library, the common case) or
-  `replaceRandom` (random replacement).
-- `MaskValue` — a snake_case library token identifying the value set. Verified tokens include:
-  `first_name`, `last_name`, `email`, `phone`, `street`, `city`, `state`, `postal_code`,
-  `country`, `account_name`, `URL`.
-
-## Choosing treatments
+- `MaskingCategory` — `library` (pick a value from the built-in library, the common case),
+  `characters` (random characters), or `replaceRandom` (random replacement).
+- `MaskValue` depends on the category:
+  - `library` — a snake_case library token identifying the value set. Verified tokens include:
+    `first_name`, `last_name`, `email`, `phone`, `street`, `city`, `state`, `postal_code`,
+    `country`, `account_name`, `URL`.
+  - `characters` and `replaceRandom` — the field's Salesforce type (for example `Text`, `Date`).
+    Left empty, the run fails with `UNKNOWN_EXCEPTION` ("Mask Value is required for Replace Random
+    field").
+
+## Choosing the fields from Core's classification
+
+The Data Mask UI's "Automatic PII rules" are driven by a per-field `recommendedPiiType` that Core's
+classifier computes. Use the same source here so the skill and the UI recommend the same fields. Do
+this once per target object, before inserting any `DataMaskPolicyField` row.
+
+1. **Call the classification operation** through the `project-codey` server's `dispatch_readonly`
+   tool. It takes a `path`, not an operationId: `path`
+   `/headless/invoke/platform/datamask/data-mask-policy/get-object-fields-with-masking-info`, `method`
+   `GET`, and `query_params` `{objectApiName: <object>, includePicklistValues: false,
+   includeFilterOnlyFields: false}` (for example `objectApiName: "Contact"`). Omit `policyObjectId` (a
+   new object has no `DataMaskPolicyObject` row yet). If this path 404s, re-resolve it with `find_route`
+   rather than guessing. The `.../data-mask-policy-builder/...` route serves the same operation but does
+   not take the two picklist/filter params.
+2. **Read the response.** The result is `{status_code, body}`, where `body` is an array with one entry
+   per field. Each entry carries `apiName`, `label`, `type`, and `recommendedPiiType` (`null` when Core
+   has no recommendation). Any other shape counts as a failed call (step 4).
+3. **Map each recommendation to a treatment.** Core returns tokens such as `last_name`, `street`,
+   `phone`, `characters`, and `replaceRandom`. Compare `recommendedPiiType` case-insensitively with the
+   verified `MaskValue` tokens in "Field treatment columns" above. `characters` and `text` are the same
+   category.
+   - A verified token → `MaskingCategory=library`, `MaskValue=<that token>`.
+   - `characters`/`text` → `MaskingCategory=characters`. `replaceRandom` → `MaskingCategory=replaceRandom`.
+     Both also require `MaskValue` = the field's Salesforce type as Core reports it in `type` (for example
+     `Text`, `Date`). The UI's "Mask With" menu offers `Random Characters` for `characters`.
+   - Any other recommendation (for example `title`, `full_name`, `full_address`, `credit_card`, `ssn`,
+     `password`, `date`, `numberRange`) has no `MaskingCategory` or verified token here. **Report it as
+     unmapped. Do not guess a `MaskValue`.**
+   - A field with no `recommendedPiiType` is not masked. List it in the report.
+4. **Fall back only when the call fails** (refused, errored, the `project-codey` server is unavailable,
+   or the response shape is unrecognized). Then use the static table below and state in the report that
+   the field list came from the static table, not from Core. When the call succeeds, Core's answer is
+   authoritative. Do not add fields from the static table.
+
+## Fallback treatments (static table)
+
+Use this table **only** when the classification call in "Choosing the fields from Core's classification"
+fails. When the call succeeds, use Core's `recommendedPiiType` and skip this table. The table is narrower than Core:
+
+- It covers only the standard fields listed below. It does not apply Core's label, type, or encryption
+  rules, so it misses fields Core does recommend (for Contact: the Other* address fields, `Fax`,
+  `HomePhone`, `OtherPhone`, `AssistantPhone`).
+- Core's type-based fallback classifies some text fields as `characters` (for Contact, `AssistantName`)
+  and some date fields as `replaceRandom` (for Contact, `Birthdate`). Both map to their `MaskingCategory`
+  value with `MaskValue` set to the field's Salesforce type (`Text` for AssistantName, `Date` for
+  Birthdate), so they are masked, not reported as unmapped.
 
 Match the `MaskValue` to the field's semantics — do **not** apply one blanket replacement:
 

package/skills/platform-datamask-run/references/run-and-abort.md

@@ -48,28 +48,35 @@ Capture `jobRunId`. A `409`/`CONFLICT` means a run is already active for this po
 ## 3. Poll to terminal
 ```bash
 sf data query --target-org <alias> \
-  --query "SELECT Id, Status, Type, TotalRecords FROM DataMaskPolicyJobRun WHERE Id = '<jobRunId>'"
+  --query "SELECT Id, Status, Type FROM DataMaskPolicyJobRun WHERE Id = '<jobRunId>'"
 ```
-Repeat on a bounded interval until `Status` is one of `completed`, `completed_with_errors`,
-`failed`. `scheduled`/`running` are NOT terminal. `scripts/poll-job.sh` automates this with a
-timeout.
+`DataMaskPolicyJobRun` has **no `TotalRecords` field** — there is no record-count column on the
+parent; the masked count lives on the child detail rows (step 4). Repeat the status query on a
+bounded interval until `Status` is one of `completed`, `completed_with_errors`, `failed`.
+`scheduled`/`running` are NOT terminal. `scripts/poll-job.sh` automates this with a timeout.
 
 ## 4. Report from the detail object
-Per-object masked results live on the child, not the parent:
+Per-object masked results live on the child, not the parent. `DataMaskPolicyJobRunDtl` has **no
+`Status` column** — the status lives in `Type`/`Subtype`, with the count itself in `Value` (a
+string):
 ```bash
 sf data query --target-org <alias> \
-  --query "SELECT Id, DataMaskPolicyJobRunId, Status FROM DataMaskPolicyJobRunDtl WHERE DataMaskPolicyJobRunId = '<jobRunId>'"
+  --query "SELECT ObjectReference, Type, Subtype, Value FROM DataMaskPolicyJobRunDtl WHERE DataMaskPolicyJobRunId = '<jobRunId>' ORDER BY Timestamp"
 ```
-Report the concrete masked-record count and per-object success/failure from these rows. Do not
-report a number you did not read from here.
+Expect one `status_update` row per `Subtype` (`loaded`, `completed`, `total_records_masked`) for
+each target object; `total_records_masked`'s `Value` is the masked count. Report the concrete
+masked-record count and per-object success/failure from these rows. Do not report a number you did
+not read from here.
 
 ## 5. Abort the currently-running job — ONLY when the user asked to cancel
 Steps 5–7 are the **abort** flow. Run them **only when the prompt explicitly asks to cancel/abort**
 a run — a "create and run" or "edit and run" task is complete after step 4.
 
 Aborting is an **on-demand action against a job that is already in progress**: take that job's
-`jobRunId` (and note its `DataMaskPolicyId` — you need it to start a replacement run if the window is
-missed), wait for `DataMaskPolicyJobRun.Status = running`, and go straight to the abort (step 6).
+`jobRunId` (and note its policy Id — you need it to start a replacement run if the window is
+missed; `DataMaskPolicyJobRun` has no direct policy lookup field, so resolve it from the job's
+`PolicyName` via `SELECT Id FROM DataMaskPolicy WHERE MasterLabel = '<PolicyName>'` against the
+Tooling API), wait for `DataMaskPolicyJobRun.Status = running`, and go straight to the abort (step 6).
 You can only abort a running job. Do **not** use the terminal poll from step 3 here — it waits until
 the job is *done*. Use the poller's `running` mode, which returns the instant the job is abortable:
 ```bash

package/skills/platform-datamask-run/scripts/poll-job.sh

@@ -17,10 +17,10 @@
 # so the default cap is 600s (10 min) with a 20s interval to keep the query volume low. Do NOT poll
 # on a tight (sub-10s) interval — it just burns tool calls against a job that cannot finish sooner.
 #
-# TERMINAL MODE: The parent DataMaskPolicyJobRun.Status can LAG the real job state (it may read
-# `pending`/`running` for a while after masking finished). So this poller ALSO checks
-# DataMaskPolicyJobRunDtl: once a `total_records_masked` detail row exists, the job is effectively
-# done and we stop, even if the parent status hasn't caught up. Ground truth is the detail rows.
+# TERMINAL MODE: exits only on a terminal PARENT status. A `total_records_masked` detail row is NOT a
+# completion signal: it can already exist, reading `0`, while the parent is still `running`, so
+# stopping on the first row reports a count for a job that has not finished. Read the detail rows
+# only AFTER this script exits.
 #
 # RUNNING MODE (for abort): exits the instant the parent status reads `running` — the only state in
 # which the abort endpoint accepts the request (a `pending`/`scheduled` job 409s). Because the pool
@@ -30,7 +30,7 @@
 # start a fresh run rather than abort a job that already finished.
 #
 # Exit codes:
-#   terminal mode: 0 = terminal status OR masked-count detail row observed (signal on stdout);
+#   terminal mode: 0 = terminal parent status observed (printed on stdout);
 #                  1 = timed out; 2 = bad args.
 #   running mode:  0 = `running` observed (prints `running`); 1 = timed out; 2 = bad args;
 #                  3 = job reached a terminal state before `running` was seen (prints that status).
@@ -63,12 +63,15 @@ is_terminal() {
 
 elapsed=0
 while (( elapsed < MAX_SECONDS )); do
-  status="$(
-    sf data query --target-org "$ORG" \
-      --query "SELECT Status FROM DataMaskPolicyJobRun WHERE Id = '${JOB_ID}'" \
-      --json 2>/dev/null \
-    | python3 -c "import json,sys; r=json.load(sys.stdin).get('result',{}).get('records',[]); print(r[0]['Status'] if r else 'UNKNOWN')"
-  )"
+  # CSV is a header line then one value per row, so bash can read it with no pipe and no
+  # post-processor. stderr is left attached so an auth or alias failure is visible; a failed
+  # query only skips this tick, it does not end the poll.
+  csv="$(sf data query --target-org "$ORG" \
+    --query "SELECT Status FROM DataMaskPolicyJobRun WHERE Id = '${JOB_ID}'" \
+    --result-format csv)" || csv=""
+  status=""
+  { IFS= read -r _; IFS= read -r status; } <<< "$csv" || true
+  status="${status:-UNKNOWN}"
   echo "[poll-job] ${JOB_ID} status=${status} (${elapsed}s/${MAX_SECONDS}s) mode=${POLL_MODE}"
 
   if [[ "$POLL_MODE" == "running" ]]; then
@@ -88,19 +91,6 @@ while (( elapsed < MAX_SECONDS )); do
       echo "$status"
       exit 0
     fi
-
-    # Ground-truth check: a masked-count detail row means the job finished even if the parent lags.
-    masked="$(
-      sf data query --target-org "$ORG" \
-        --query "SELECT Value FROM DataMaskPolicyJobRunDtl WHERE DataMaskPolicyJobRunId = '${JOB_ID}' AND Subtype = 'total_records_masked'" \
-        --json 2>/dev/null \
-      | python3 -c "import json,sys; r=json.load(sys.stdin).get('result',{}).get('records',[]); print(r[0]['Value'] if r else '')"
-    )"
-    if [[ -n "$masked" ]]; then
-      echo "[poll-job] detail row total_records_masked=${masked} — job effectively complete (parent status=${status})"
-      echo "completed"
-      exit 0
-    fi
   fi
 
   sleep "$INTERVAL"
@@ -110,6 +100,6 @@ done
 if [[ "$POLL_MODE" == "running" ]]; then
   echo "[poll-job] TIMEOUT after ${MAX_SECONDS}s — job never reached 'running'" >&2
 else
-  echo "[poll-job] TIMEOUT after ${MAX_SECONDS}s — neither terminal status nor masked-count detail row observed" >&2
+  echo "[poll-job] TIMEOUT after ${MAX_SECONDS}s — job never reached a terminal status" >&2
 fi
 exit 1

package/skills/platform-dataspace-access-configure/SKILL.md

@@ -1,9 +1,10 @@
 ---
 name: platform-dataspace-access-configure
-description: "Use this skill to configure or inspect Salesforce Data Cloud DataSpace access for permission sets. Grants dataspace-level access via MDAPI PermissionSet XML with dataspaceScopes elements, optionally grants object-level access to DMO, DLO, or CIO objects via the Object Access Grants Connect API, and inspects existing scopes via read-only PermissionSet metadata retrieval. TRIGGER when: user needs to create or update a permission set with DataSpace access, grant access to a specific dataspace, list permission sets with access to a DataSpace, configure dataAccessLevel/objectAccessLevel, add RBAC object access grants, or list/remove object access grants for a permission set + DataSpace pair. DO NOT TRIGGER when: the task is a generic permission set without dataspace access (use platform-permission-set-generate), the request is about data ingestion/streams, or the work involves creating dataspaces themselves rather than granting access to them."
+description: "THE skill for granting Data Cloud data-space access and the PERMISSION-SET / RBAC way of granting object access. Grants data-space-level access via MDAPI PermissionSet XML with dataspaceScopes, grants object-level access to DMO/DLO/CIO objects via the Object Access Grants Connect API (RBAC object grants), and inspects existing scopes read-only. TRIGGER when the user needs to grant access to a data space / dataspace, create/update a permission set with DataSpace access, list/configure scopes, or add/list/remove RBAC object access grants — 'grant access to a data space' routes here. DO NOT TRIGGER for a generic permission set (use platform-permission-set-generate), data ingestion/streams, creating dataspaces themselves, or an access POLICY / policy rule / tag/classification-based access (use platform-policy-rule-generate). For a vague object-access ask, surface both skills and ASK the permission-set way vs the policy way; if unsure the object is Data Cloud, ask which first."
 metadata:
   relatedSkills:
     - "platform-permission-set-generate"
+    - "platform-policy-rule-generate"
   version: "1.0"
   domains: ["Platform", "Data 360"]
   minApiVersion: "67.0"
@@ -27,6 +28,23 @@ The MDAPI layer is required to establish the PermissionSet → DataSpace linkage
 
 ---
 
+## When to use this skill (routing)
+
+This is the **permission-set / RBAC** path to Data Cloud access:
+
+- **"Grant access to a data space" / dataspace access** → this skill (Layer 1, `dataspaceScopes` on a permission set).
+- **Grant object access via a permission set / RBAC object grant** → this skill (Layer 2, Object Access Grants Connect API).
+
+Object access has a second, separate path — a **data-governance access policy** (a tag/OLS `PolicyRuleDefinition`), owned by **`platform-policy-rule-generate`**. Infer the mechanism from context; ask only when the request is vague:
+
+- The user is **driving from a permission set** (mentions a permission set, RBAC, or an object grant on a permset) → object access grant → **this skill**, no need to ask.
+- The user **frames it as a policy** (create a policy / access policy / policy rule, OLS/FLS/RLS, tag/classification-based) → route to **`platform-policy-rule-generate`**.
+- The request is **genuinely vague** — "grant object access to X" with no mechanism and no clue → **ASK**: the **permission-set way** (this skill) or the **policy way** (`platform-policy-rule-generate`)? If it is also unclear whether the object is a Data Cloud object, ask which object first.
+
+"Access to a **data space**" is always this skill (the permission-set / `dataspaceScopes` path) — no disambiguation needed.
+
+---
+
 ## Decide the Case First
 
 Pick exactly one case from the table below before writing any files. Each case has a different output shape.

package/skills/platform-metadata-discovery-get/SKILL.md

@@ -0,0 +1,185 @@
+---
+name: platform-metadata-discovery-get
+description: "Use before creating, changing, or writing code against Salesforce metadata, to find out what already exists in the org with the right tool. Routes each question to metadata grounding, scoped SOQL with sf data query, sf sobject list or describe, sf org list metadata, source retrieval, or local files, and covers orgs and setups where grounding is not available. Use to check whether an object, field, picklist, permission set, page, app, or flow already exists before creating one, confirm field names, types, and picklist values before writing Apex, LWC, SOQL, or Flow logic, list every field on an object or every member of a metadata type, find automation that runs on an object, or explain how something in the org is configured and who can access it. DO NOT TRIGGER for whole-org overviews, org comparison, or drift (use dx-org-analyze), metadata file structure or XML shape (platform-metadata-api-context-get), or Data Cloud DLO and DMO schema (data360-code-extension-generate)."
+metadata:
+  relatedSkills:
+  - data360-code-extension-generate
+  - dx-org-analyze
+  - platform-metadata-api-context-get
+  - platform-metadata-grounding-get
+  - platform-metadata-retrieve
+  version: "1.3"
+  domains:
+  - "Platform"
+  cliTools:
+  - tool:
+    - "sf"
+    semver: ">=2.0.0"
+  mcpTools:
+    metadata-grounding:
+      tools:
+      - "search_metadata"
+      - "query_metadata"
+      - "describe_metadata"
+      semver: ">=1.0.0"
+    headless-360:
+      tools:
+      - "describe"
+      - "dispatch"
+      - "dispatch_readonly"
+      semver: ">=1.0.0"
+id: "platform-metadata-discovery-get"
+---
+
+# Salesforce Metadata Discovery
+
+Before you create metadata, change it, or write code that references it, know what already exists in the org. This skill picks the tool for each question. Metadata grounding finds metadata by meaning when you do not know its name. It needs Salesforce Catalog and a connected grounding server, and many orgs and setups have neither. Every other route works with the `sf` CLI alone.
+
+Skip discovery when the request only changes local files and adds no new references to org metadata.
+
+## Check What You Have
+
+Do this once per session, before the first lookup.
+
+1. **The CLI and its org.** Run `sf org display --json` to see the default org and its id. If no org is authenticated, ask the user to run `sf org login web` and wait. If you cannot run commands at all, read `references/h360-routes.md`.
+2. **Grounding servers.** Note whether the Metadata Grounding MCP (tools `search_metadata`, `query_metadata`, `describe_metadata`) or the Salesforce MCP is connected. The Salesforce MCP is shown in Setup today as the Headless360 (H360) MCP Server. Its tools are `describe`, `dispatch`, and `dispatch_readonly`, which are different from the Metadata Grounding MCP tools.
+3. **One org.** Grounding identifiers start with the 18-character org id. If it differs from the id in `sf org display`, tell the user and ask which org to use before you combine results.
+
+## Route by Intent
+
+| Intent | Use | If that is not available |
+|---|---|---|
+| Find metadata by meaning, check a name you are guessing, or check for something to reuse | Metadata grounding search. Load `platform-metadata-grounding-get`, which picks the server. | Name and label fallback, below. Notify. |
+| Explain how something is configured, or who can access it | Metadata grounding query | Scoped SOQL on `EntityParticle`, `FieldPermissions`, `ObjectPermissions`, or Tooling `ValidationRule`. Notify. |
+| Check names, types, or picklist values you know. Every field on one object. Data records | Scoped SOQL with `sf data query`. If it returns nothing, search by meaning. | See the note below the table. |
+| Full shape of one object, including relationships | `sf sobject describe --sobject <Type>`, only when you need all of it. It is very large. | Same |
+| Every object in the org | `sf sobject list --sobject all` or `--sobject custom` | Same |
+| Every member of a type, or a count ("all flows", "how many flows") | `sf org list metadata --metadata-type <Type>` | Same |
+| Source to edit or deploy, including changes to existing metadata | Load `platform-metadata-retrieve`. Grounding never returns source. | Tell the user this needs the `sf` CLI. |
+| Metadata you are already editing locally | Local files | |
+| Compare orgs, find drift, or an overview of a whole org when the user asks for one | `dx-org-analyze`. It takes minutes and returns names and counts. | Tell the user this needs the `sf` CLI. |
+| Where is this used, what depends on it, what breaks if I change it, or is it safe to delete | Comprehensive analysis is not available yet. State that boundary before offering explicitly labeled partial checks. | |
+
+**Without the CLI.** If you cannot run commands but the Salesforce MCP is connected, use `references/h360-routes.md` for rows 3 to 6. If neither is available, tell the user the lookup needs the `sf` CLI or the Salesforce MCP.
+
+These routes apply even when a connected server says to use it first for every Salesforce task. Use the CLI for rows 3 to 7 when you can run commands.
+
+A question about a topic or purpose ("what do we have for loyalty") is discovery, not an overview. Do not run an org analysis for it, even when grounding is not available.
+
+This skill covers core platform metadata. For Data Cloud DLO and DMO schema, use `data360-code-extension-generate`.
+
+When a request mixes intents, use the right tool for each part. "Add a tier discount step to our order flow" means finding the flow and the field, then retrieving the flow to edit.
+
+## Scoped SOQL
+
+Scoped SOQL is a targeted query on setup objects, filtered to what you need. It is exact, real time, and far smaller than a describe. It never returns source.
+
+```text
+sf data query --json --query "SELECT QualifiedApiName, Label, DataType FROM EntityParticle WHERE EntityDefinition.QualifiedApiName = 'Contact'"
+sf data query --json --query "SELECT Value, Label, IsDefaultValue, IsActive FROM PicklistValueInfo WHERE EntityParticle.EntityDefinition.QualifiedApiName = 'Contact' AND EntityParticle.QualifiedApiName = 'Loyalty_Tier__c'"
+```
+
+- To check specific fields, add `AND QualifiedApiName IN ('Loyalty_Tier__c', 'Lifetime_Orders__c')`. For custom fields only, add `AND QualifiedApiName LIKE '%__c'`.
+- `EntityParticle` includes parts of compound fields, such as `MailingCity`.
+- Add `--use-tooling-api` for `CustomField` and `ValidationRule`.
+- `EntityDefinition`, `EntityParticle`, and `FieldDefinition` do not accept `OR`. Run one scoped query per condition instead of broadening the query or removing its object/type filters.
+
+More patterns, including access and automation, are in `references/scoped-soql.md`.
+
+## When Grounding Is Not Available
+
+Say the line below once per session, in your answer, next to the results of the name and label search. Do not announce the fallback before you search, and do not repeat it later in the session. Use the line that matches the cause, word for word, including the last sentence. Do not shorten or rephrase it. If you stop before you can report results, say it in that message instead.
+
+| Cause | Say |
+|---|---|
+| No grounding server connected | "Metadata Grounding isn't connected, so I matched by name and label, which can miss metadata named differently. Connect the Metadata Grounding MCP to search by meaning." |
+| Catalog not enabled | "Salesforce Catalog isn't turned on in this org, so I matched by name and label, which can miss metadata named differently. An admin can turn on Salesforce Catalog through Feature Manager in Data Cloud Setup." |
+| Permission missing | "Catalog search needs the Customize Application permission, so I matched by name and label, which can miss metadata named differently." |
+
+Then search names and labels. Try two or three likely words, one `LIKE` per query.
+
+```text
+sf data query --json --query "SELECT QualifiedApiName, Label FROM EntityDefinition WHERE Label LIKE '%loyalty%'"
+sf data query --json --query "SELECT QualifiedApiName, Label, DataType FROM EntityParticle WHERE EntityDefinition.QualifiedApiName = 'Contact' AND Label LIKE '%tier%'"
+sf data query --json --use-tooling-api --query "SELECT DeveloperName, EntityDefinition.QualifiedApiName FROM CustomField WHERE DeveloperName LIKE '%tier%' AND NamespacePrefix = null"
+sf data query --json --query "SELECT ApiName, Label, ProcessType, IsActive FROM FlowDefinitionView WHERE Label LIKE '%order%'"
+```
+
+- The `CustomField` query searches custom fields on every object. `DeveloperName` has no `__c`. Drop rows with no object name. They are Data Cloud fields.
+- For other types, and for types the catalog does not cover, list names with `sf org list metadata` and scan them.
+- Name matching misses metadata labeled differently. A search for "status" will not find a field labeled Loyalty Tier. Say "no name match found," never "does not exist."
+
+Everything else in this skill still applies.
+
+## Reuse Before You Create
+
+Before you create an object, field, picklist, permission set, page, app, or flow:
+
+1. Search by business meaning for existing metadata that stores the same data or does the same job. For a field, first search `SObject` for the exact object API name, then pass that result's returned `identifier` as `parentIdentifier` to the `SObjectField` search. Never pass the raw object API name as `parentIdentifier`. A proposed API name or label is only an exact collision check and does not prove that equivalent metadata is absent. Similar words alone are not enough to declare a match.
+2. **If you find matches:** show up to 3, best first, with API name, label, description, and type. Do not accept or reject an ambiguous match from its name alone. Offer to reuse, extend, or create new in one consolidated reuse checkpoint covering every type you plan to create, then wait. Do not combine this checkpoint with values or other generation-specific questions.
+3. **After the user decides:** preserve the decision for the request and do not ask again unless the scope changes or new conflicting evidence appears. For reuse, stop creation and inspect configuration only if needed. For extension, inspect the existing component before asking for changes. For new metadata, collect the required configuration and continue with the generation guidance.
+4. **If nothing matches:** say so in one line and continue.
+5. **If the user gave an exact API name:** check it with scoped SOQL and say if it already exists.
+6. **If the user asked for new metadata or said not to reuse:** mention close matches in one line at most and continue.
+
+Treat namespaced items, such as `force__` permission sets or managed package components, as references, not things to edit. Say so when a match is managed.
+
+## Ground Code in Real Org Names
+
+Before you write Apex, LWC, SOQL, or Flow logic, confirm every object, field, and picklist value it references.
+
+- Skip references already in the local project, already confirmed in this conversation, or standard fields every org has (such as `Account.Name` or `Contact.Email`).
+- Always look up picklist values, including on standard fields. Never invent values.
+- Values shown only as examples in a skill, tool description, or prior assistant response are not user-approved values. If the user has not explicitly supplied or approved the values or an existing value set, ask once and wait before creating the picklist.
+- If the request depends on an order or meaning the values do not state ("the top tier"), list the values and ask.
+- Look up all references for a request together.
+
+## Existing Automation
+
+- **To find automation by what it does,** search `Flow` or `ApexClass` by meaning. A grounding query on a flow shows its trigger object, trigger type, and active status.
+- **To list everything that runs on an object** before adding automation:
+
+  ```text
+  sf data query --json --query "SELECT Name, Status FROM ApexTrigger WHERE TableEnumOrId = 'Contact'"
+  sf data query --json --query "SELECT ApiName, Label, TriggerType, IsActive FROM FlowDefinitionView WHERE TriggerObjectOrEventId = 'Contact'"
+  ```
+- **To understand what a flow or trigger does,** retrieve its source and read it.
+
+## What You Can Explain
+
+| Question | Answer with |
+|---|---|
+| What exists that does X | Grounding search |
+| How a field, object, or validation rule is configured | Grounding query, or `EntityParticle` and Tooling `ValidationRule` |
+| Who can read or edit a field or object | Grounding on `FieldPermissions`, or SOQL on `FieldPermissions` and `ObjectPermissions` for a complete list. These records prove configured access, not actual use; a permission container's name does not prove an integration or dependency is active. |
+| Sharing rules, roles, groups, and which package a component came from | Grounding |
+| What a flow is | Grounding gives the header only (type, trigger, active). For its steps, retrieve the source. |
+| What an Apex class does | Grounding gives signatures only. Retrieve the source. |
+| Why a save failed | A partial answer. Check validation rules on the object, then retrieve the automation that runs on it. |
+| Page layouts, reports, custom metadata types, custom settings | Not in the catalog. Use `sf org list metadata` and retrieve. |
+| Where something is used, what depends on it, what breaks if it changes, or whether it is safe to delete | Comprehensive analysis is not available yet. Say so before any checks. You may offer narrow checks, but label each one as partial and never present their union as complete or conclude that the change is safe. |
+
+## Working With Skills
+
+- This skill decides what already exists. Build skills decide how to create it. Run discovery before any skill writes files.
+- If a loaded skill has its own equivalent semantic reuse check, use it instead of the matching step here. Do not run both. An exact-name or exact-label collision check is not equivalent and does not replace semantic reuse discovery.
+- Two exceptions, even when a skill says otherwise: always look up picklist values, and check names, types, or picklist values you know with scoped SOQL instead of a full object describe.
+- If a skill's discovery step fails or its tool is not available, use the routes in this skill and tell the user once.
+
+## Freshness and Local Files
+
+- Reuse discovery results for the rest of the conversation unless that item has changed.
+- The catalog can take several minutes to reflect deploys and other org changes. For anything changed in this session, trust the local source and deploy results, and confirm with SOQL, which is real time. If the user reports a change SOQL does not show, ask them to confirm the name and org before you write code that uses it.
+- When the metadata you need is not in the local project, retrieve it before editing, and tell the user you did.
+- If you learn the org version differs from local in ways you did not make, for example from a retrieve or a deploy conflict, show the difference and ask before you overwrite either one.
+- When scanning local source for references, read the package directories from `sfdx-project.json` and search those directories. Exclude response exports, logs, generated output, caches, and agent configuration unless the user explicitly asks to inspect them.
+- Searching local files finds exact text only. Do not use it to find org metadata by meaning.
+
+## Never
+
+- Write or deploy files built from grounding query output. It returns properties, not source.
+- Treat grounding results as a complete list. They are ranked and capped.
+- Say metadata does not exist because a search or a name match found nothing.
+- Combine results from two different orgs.
+- Present partial dependency or reference checks as a complete impact analysis, or conclude from them that metadata is safe to change or delete.
+- Treat illustrative values from examples, skills, or tool descriptions as user-approved metadata.

package/skills/platform-metadata-discovery-get/references/api-map.md

@@ -0,0 +1,25 @@
+# What Each Route Calls
+
+For engineers and reviewers. The skill names tools, not APIs, because the agent picks tools. Read from sf CLI 2.150.6 and jsforce source, and checked live on 2026-10-07.
+
+| Route | API call |
+|---|---|
+| `sf sobject list` | REST `describeGlobal` (`GET /services/data/vXX.0/sobjects`), filtered to custom or all on the client |
+| `sf sobject describe` | REST describe SObject (`GET /services/data/vXX.0/sobjects/<Type>/describe`). Tooling describe with `--use-tooling-api` |
+| `sf org list metadata` | Metadata API `listMetadata` (SOAP) |
+| `sf data query` | REST query resource (`GET /services/data/vXX.0/query`). Tooling query resource with `--use-tooling-api` |
+| `sf project retrieve start` | Metadata API `retrieve` (SOAP) |
+| Metadata grounding search | `GET /services/data/vXX.0/metadata-grounding/search` |
+| Metadata grounding describe | `POST /services/data/vXX.0/metadata-grounding/schema` |
+| Metadata grounding query | `POST /services/data/vXX.0/metadata-grounding/query` |
+
+## Which Surface Reaches Which Call
+
+| Call | `sf` CLI | Metadata Grounding MCP | Salesforce MCP |
+|---|---|---|---|
+| REST and Tooling query | Yes | No | Yes, `dispatch_readonly` |
+| REST describe and object list | Yes | No | Yes, `dispatch_readonly` |
+| Metadata API `listMetadata` and `retrieve` | Yes | No | No |
+| Metadata grounding | No. The grounding paths are reachable only through an MCP server, so a direct REST call returns not found | Yes | Yes, after `describe` on the operation id |
+
+The skills do not use the Enterprise API, the SOAP API with the org-specific WSDL. None of these tools call it.

package/skills/platform-metadata-discovery-get/references/h360-routes.md

@@ -0,0 +1,30 @@
+# Routes Through the Salesforce MCP
+
+Use this file when you reach the org through the Salesforce MCP. If you are in a terminal or IDE and can run the `sf` CLI, the CLI routes work as well.
+
+Grounding itself is covered in `platform-metadata-grounding-get`. This file covers the routes the skill body sends to the CLI.
+
+## How to Call
+
+Use `dispatch_readonly` with `method: GET`. Pass the path as `url` and the SOQL as the `q` query parameter, not appended to the URL.
+
+| Route | `url` | Query parameters |
+|---|---|---|
+| Standard SOQL | `/services/data/v66.0/query` | `q`: the SOQL |
+| Tooling SOQL | `/services/data/v66.0/tooling/query` | `q`: the SOQL |
+| Describe one object | `/services/data/v66.0/sobjects/<Type>/describe` | None |
+
+The rows are in `body.records`. For a `COUNT()` query the number is in `body.totalSize` and `records` is empty. Every pattern in `scoped-soql.md` works through these paths.
+
+## Route by Intent
+
+| Intent | Through this server |
+|---|---|
+| Check names, types, or picklist values you know. Every field on one object. Data records | Standard SOQL. Use Tooling SOQL for `CustomField` and `ValidationRule`. |
+| Full shape of one object, only when you need all of it | Describe one object. It is very large. |
+| Every object in the org | Standard SOQL on `EntityDefinition`, for example `SELECT QualifiedApiName, Label FROM EntityDefinition WHERE QualifiedApiName LIKE '%__c'` for custom objects. Never call `/sobjects` for the full object list. It returned about 1.8 million characters in one test org. |
+| Every member of a type, or a count | Tooling SOQL for Tooling types, for example `SELECT COUNT() FROM FlowDefinition`, or `ApexClass` and `ValidationRule`. To list flows with labels, use Standard SOQL on `FlowDefinitionView`. Other types cannot be listed through this server. Tell the user it needs the `sf` CLI in a terminal or IDE. |
+| Source to edit or deploy | Not available through this server. Load `platform-metadata-retrieve` if it is available. Otherwise tell the user it needs the `sf` CLI in a terminal or IDE. |
+| Compare orgs, find drift, or a whole-org overview | Not available through this server. Tell the user it needs the `sf` CLI. |
+
+If a call fails with an authentication or session error, tell the user to reconnect the Salesforce MCP. If it fails as not found or not allowed, say so, and tell the user the lookup may need the `sf` CLI in a terminal or IDE.

package/skills/platform-metadata-discovery-get/references/scoped-soql.md

@@ -0,0 +1,52 @@
+# Scoped SOQL Patterns
+
+Run each query through the Salesforce MCP with `dispatch_readonly`, as Standard or Tooling SOQL per the table. The paths are in `ref:platform-metadata-discovery-get/references/h360-routes`. In a terminal or IDE, `sf data query --json --query "<SOQL>"` works too. Add `--use-tooling-api` where the table says Tooling, and `--target-org <alias>` when the user named an org other than the default.
+
+## Objects and Fields
+
+| Need | Query | API |
+|---|---|---|
+| Does this object exist | `SELECT QualifiedApiName, Label FROM EntityDefinition WHERE QualifiedApiName = 'Loyalty_Transaction__c'` | Standard |
+| Several objects at once | `SELECT QualifiedApiName, Label FROM EntityDefinition WHERE QualifiedApiName IN ('Menu__c', 'Promotion__c')` | Standard |
+| Every field on one object | `SELECT QualifiedApiName, Label, DataType FROM EntityParticle WHERE EntityDefinition.QualifiedApiName = 'Contact'` | Standard |
+| Custom fields only | Add `AND QualifiedApiName LIKE '%__c'` to the query above | Standard |
+| Check specific fields | Add `AND QualifiedApiName IN ('Loyalty_Tier__c', 'Email')` | Standard |
+| Picklist values | `SELECT Value, Label, IsDefaultValue, IsActive FROM PicklistValueInfo WHERE EntityParticle.EntityDefinition.QualifiedApiName = 'Contact' AND EntityParticle.QualifiedApiName = 'Loyalty_Tier__c'` | Standard |
+| Record types on an object | `SELECT Name, DeveloperName, IsActive FROM RecordType WHERE SobjectType = 'Contact'` | Standard |
+
+`EntityParticle` includes parts of compound fields, such as `MailingCity`. A full field list for Contact is about a tenth the size of a describe.
+
+## Name and Label Fallback
+
+Use these only when grounding is not available. Try two or three likely words.
+
+| Need | Query | API |
+|---|---|---|
+| Objects by label | `SELECT QualifiedApiName, Label FROM EntityDefinition WHERE Label LIKE '%loyalty%'` | Standard |
+| Fields on one object by label | `SELECT QualifiedApiName, Label, DataType FROM EntityParticle WHERE EntityDefinition.QualifiedApiName = 'Contact' AND Label LIKE '%tier%'` | Standard |
+| Custom fields on every object by name | `SELECT DeveloperName, EntityDefinition.QualifiedApiName FROM CustomField WHERE DeveloperName LIKE '%tier%' AND NamespacePrefix = null` | Tooling |
+| Flows by label | `SELECT ApiName, Label, ProcessType, IsActive FROM FlowDefinitionView WHERE Label LIKE '%order%'` | Standard |
+| Permission sets by label | `SELECT Name, Label FROM PermissionSet WHERE IsOwnedByProfile = false AND Label LIKE '%loyalty%'` | Standard |
+
+- `EntityDefinition`, `EntityParticle`, and `FieldDefinition` do not accept `OR`. The query fails with "Disjunctions not supported." Run one query per word.
+- `CustomField` accepts `OR`. `DeveloperName` has no `__c`. Drop rows with no object name. They are Data Cloud fields.
+
+## Access
+
+| Need | Query | API |
+|---|---|---|
+| Who can read or edit a field | `SELECT Parent.Label, Parent.IsOwnedByProfile, Parent.Profile.Name, PermissionsRead, PermissionsEdit FROM FieldPermissions WHERE SobjectType = 'Contact' AND Field = 'Contact.Loyalty_Tier__c'` | Standard |
+| Who can use an object | `SELECT Parent.Label, Parent.IsOwnedByProfile, Parent.Profile.Name, PermissionsRead, PermissionsCreate, PermissionsEdit, PermissionsDelete FROM ObjectPermissions WHERE SobjectType = 'Loyalty_Transaction__c'` | Standard |
+
+When `Parent.IsOwnedByProfile` is true, the row belongs to a profile. Read the name from `Parent.Profile.Name`, because `Parent.Label` is an id for those rows. A field or object with no row for a profile or permission set has no access through it.
+
+## Automation and Rules
+
+| Need | Query | API |
+|---|---|---|
+| Triggers on an object | `SELECT Name, Status FROM ApexTrigger WHERE TableEnumOrId = 'Contact'` | Standard |
+| Flows that run on an object | `SELECT ApiName, Label, TriggerType, IsActive FROM FlowDefinitionView WHERE TriggerObjectOrEventId = 'Contact'` | Standard |
+| Validation rules on an object | `SELECT ValidationName, Active, ErrorMessage FROM ValidationRule WHERE EntityDefinition.QualifiedApiName = 'Contact'` | Tooling |
+| Count of flows | `SELECT COUNT() FROM FlowDefinition` | Tooling |
+
+These return names and status, not logic. To read what a flow, trigger, or rule does, retrieve its source.