@salesforce/afv-skills 1.37.0 → 1.38.0

package/skills/platform-sharing-rules-generate/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: platform-sharing-rules-generate
-description: "Use this skill when users need to create, edit, delete, or manage Salesforce Sharing Rules metadata. TRIGGER when: users mention sharing rules, record sharing, criteria-based sharing, role-based sharing, guest user sharing, sharingRules, sharingCriteriaRules, sharingGuestRules, sharingOwnerRules, .sharingRules-meta.xml files, or ask to share records with specific roles or groups. Also trigger when users want to modify or remove existing sharing rules, or update sharing rule criteria or access levels. DO NOT TRIGGER when user needs permission sets or profiles (use platform-permission-set-generate), or needs object-level security rather than record-level sharing (use platform-permission-set-generate)."
+description: "Use this skill when users need to get, create, edit, delete, or manage Salesforce Sharing Rules metadata. TRIGGER when: users mention sharing rules, record sharing, criteria-based sharing, role-based sharing, guest user sharing, sharingRules, sharingCriteriaRules, sharingGuestRules, sharingOwnerRules, .sharingRules-meta.xml files, or ask to share records with specific roles or groups. Also trigger when users want to retrieve or view existing sharing rules from an org, modify or remove existing sharing rules, or update sharing rule criteria or access levels. DO NOT TRIGGER when user needs permission sets or profiles (use platform-permission-set-generate), or needs object-level security rather than record-level sharing (use platform-permission-set-generate)."
 metadata:
-  version: "1.2"
+  version: "1.3"
   minApiVersion: "60.0"
   relatedSkills:
     - "platform-custom-object-generate"
@@ -14,11 +14,11 @@ metadata:
 
 # Sharing Rules Generator
 
-Create, edit, and delete Salesforce Sharing Rules metadata to control record-level access beyond org-wide defaults. Supports criteria-based rules, role/group-based owner rules, and guest user rules for Experience Sites.
+Get, create, edit, and delete Salesforce Sharing Rules metadata to control record-level access beyond org-wide defaults. Supports criteria-based rules, role/group-based owner rules, and guest user rules for Experience Sites.
 
 ## Scope
 
-- **In scope**: Creating, editing, and deleting `sharingCriteriaRules`, `sharingOwnerRules`, and `sharingGuestRules` metadata; retrieving existing sharing rules from an org; appending new rules to existing files; modifying rule criteria, access levels, or shared-to targets; removing rules from metadata files; configuring rules for Guest and Portal profiles.
+- **In scope**: Creating, editing, deleting, and retrieving (getting) `sharingCriteriaRules`, `sharingOwnerRules`, and `sharingGuestRules` metadata; retrieving existing sharing rules from an org using the Metadata API Retrieve pattern; appending new rules to existing files; modifying rule criteria or access levels; removing rules from metadata files; configuring rules for Guest and Portal profiles.
 - **Out of scope**: Changing org-wide defaults (OWD/sharing model), creating Experience Sites, configuring permission sets or profiles (use `platform-permission-set-generate`), territory-based sharing rules.
 
 ---
@@ -27,6 +27,10 @@ Create, edit, and delete Salesforce Sharing Rules metadata to control record-lev
 
 Before proceeding, confirm with the user if not already clear:
 
+### For Get operations:
+- Which object's sharing rules should be retrieved? (standard or custom object API name, or all objects)
+- Which target org should the rules be retrieved from? (org alias or default)
+
 ### For Create operations:
 - Which object should the sharing rule apply to? (standard or custom object API name)
 - What type of rule? (criteria-based, role/group-based owner rule, or guest user rule)
@@ -36,7 +40,7 @@ Before proceeding, confirm with the user if not already clear:
 
 ### For Edit operations:
 - Which existing rule should be modified? (rule fullName or label)
-- What should change? (access level, shared-to target, criteria, label)
+- What should change? (access level, criteria, label — note: `sharedTo` and `sharedFrom` cannot be edited in place)
 
 ### For Delete operations:
 - Which rule(s) should be removed? (rule fullName or label)
@@ -64,19 +68,23 @@ Defaults unless specified:
 
 ## Workflow
 
-Steps are sequential within each phase. Phase 3 branches by operation type — execute only the matching branch.
+Steps are sequential within each phase. Phase 3 branches by operation type — execute only the matching branch. Phase 4 applies to create, edit, and delete only (get operations end at Phase 3).
 
 ### Phase 1 — Discover
 
 1. **Resolve the SFDX project path** — find the project's `sfdx-project.json` and identify the package directory for `sharingRules/`.
 
-2. **Check for existing sharing rules** — look for `<packageDir>/sharingRules/<ObjectName>.sharingRules-meta.xml`. If found, read it to understand existing rules and avoid duplicates.
+2. **Always retrieve the latest sharing rules from the org** using the Metadata API Retrieve pattern:
+   ```bash
+   sf project retrieve start --metadata "SharingRules:<ObjectName>" --target-org <org>
+   ```
+   This ensures the local file reflects the current org state. Never trust a local file that may be stale — edits or deletes against a stale file can recreate rules that were already removed in the org or overwrite changes made by other users.
 
-3. **If no local file exists**, retrieve from the org: `sf project retrieve start --metadata "SharingRules:<ObjectName>" --target-org <org>`
+3. **Read the retrieved file** — parse `<packageDir>/sharingRules/<ObjectName>.sharingRules-meta.xml` to understand existing rules and avoid duplicates.
 
 ### Phase 2 — Determine Operation and Rule Type
 
-4. **Identify the operation** — determine whether the user wants to **create**, **edit**, or **delete** a sharing rule.
+4. **Identify the operation** — determine whether the user wants to **get**, **create**, **edit**, or **delete** a sharing rule.
 
 5. **Select the rule type** based on user intent. Read `references/rule-types.md` for the complete schema of each type and its required elements.
 
@@ -86,6 +94,19 @@ Steps are sequential within each phase. Phase 3 branches by operation type — e
 
 ### Phase 3 — Execute Operation
 
+#### For Get:
+
+8a. **Use the file already retrieved in Phase 1** — the retrieve in step 2 already pulled the latest `<ObjectName>.sharingRules-meta.xml` from the org. No additional retrieve is needed.
+
+8b. **Read and present the retrieved rules** — parse the `.sharingRules-meta.xml` file and present the rules to the user in a readable format showing:
+    - Rule name (`fullName`) and label
+    - Rule type (criteria-based, owner-based, or guest)
+    - Access level
+    - Shared-to target
+    - Criteria (if applicable)
+
+    For get operations, skip Phase 4 (no write needed). The retrieve itself writes the metadata file to the local project.
+
 #### For Create:
 
 8a. **Construct the XML** following the schema in `references/rule-types.md`. Key structure:
@@ -99,36 +120,33 @@ Steps are sequential within each phase. Phase 3 branches by operation type — e
 
 8a. **Locate the target rule** — find the rule by `<fullName>` or `<label>` in the existing `.sharingRules-meta.xml` file.
 
-8b. **Determine modifications** — identify which elements to change (e.g., `<accessLevel>`, `<sharedTo>`, `<criteriaItems>`, `<label>`) and what the new values will be. Do not write yet — all disk writes happen in Phase 5 after user confirmation.
+8b. **Gate unsupported edits** — the platform does NOT support in-place modification of `<sharedTo>` or `<sharedFrom>` elements. If the user requests a change to the sharing target or source, refuse the edit and instruct them to delete the existing rule and create a new one with the desired target. This is the same pattern used for rule-type changes (see TC-16).
+
+8c. **Determine modifications based on rule type**:
+    - **Owner-based rules (`sharingOwnerRules`)**: only `<accessLevel>` can be edited. The platform does not support modifying any other element (`sharedTo`, `sharedFrom`, `label`) on owner rules. If the user requests changes beyond access level, refuse and instruct them to delete + create.
+    - **Criteria-based rules (`sharingCriteriaRules`)**: supported editable elements are `<accessLevel>`, `<criteriaItems>`, `<label>`, and `<booleanFilter>`.
+    - **Guest rules (`sharingGuestRules`)**: supported editable elements are `<accessLevel>`, `<criteriaItems>`, `<label>`, and `<includeHVUOwnedRecords>`.
 
 #### For Delete:
 
 8a. **Locate the target rule** — find the rule by `<fullName>` or `<label>` in the existing `.sharingRules-meta.xml` file.
 
-8b. **Count remaining rules** — run: `grep -c '<sharingCriteriaRules>\|<sharingOwnerRules>\|<sharingGuestRules>' <file>` to get the total rule count. If the count is 1 (only the rule being deleted), the file must be removed entirely in Phase 5. Do not write yet — all disk writes happen in Phase 5 after user confirmation.
-
-### Phase 4 — Confirm with User   CRITICAL
-
-9. **Present a summary of changes** before writing to disk. You MUST stop and wait for user confirmation. Format the summary as:
-
-    > **Operation:** Create / Edit / Delete
-    > **Object:** `<ObjectName>`
-    > **Rule:** `<fullName>` (`<label>`)
-    > **Changes:** (describe what will be created/modified/removed)
-    >
-    > Proceed? (yes / no / edit)
+8b. **Count remaining rules** — run `scripts/count-remaining-rules.sh <file>` to get the total rule count. If the count is 1 (only the rule being deleted), the file must be removed entirely in Phase 4.
 
-    **Do NOT write any file changes until the user explicitly confirms.** If the user says "no", abort. If the user says "edit", incorporate their feedback and re-present.
+8c. **Delegate destructive deployment to `platform-destructive-deploy`** — a normal `sf project deploy start` is additive and will NOT remove a rule from the org. Delegate to the `platform-destructive-deploy` skill with the following context:
+    - Metadata type: `SharingCriteriaRule`, `SharingOwnerRule`, or `SharingGuestRule` (depending on the rule type)
+    - Member: `<ObjectName>.<RuleFullName>`
+    - Target org: the user's specified org
 
-### Phase 5 — Write and Verify
+### Phase 4 — Write and Verify
 
-10. **Apply the change** only after user confirmation:
+9. **Apply the change**:
     - **Create**: Write the file to `<packageDir>/sharingRules/<ObjectName>.sharingRules-meta.xml`.
     - **Edit**: Update only the elements identified in step 8b; preserve all other elements exactly as they were.
     - **Delete (rules remain)**: Write the updated file with the target rule removed.
     - **Delete (last rule)**: Remove the file `<packageDir>/sharingRules/<ObjectName>.sharingRules-meta.xml` entirely.
 
-11. **Run the verification checklist** below and consult the examples files (`examples/create-cases.md`, `examples/edit-cases.md`, `examples/delete-cases.md`) for scenario-specific expected behaviors before presenting output.
+10. **Run the verification checklist** below and consult the examples files (`examples/create-cases.md`, `examples/edit-cases.md`, `examples/delete-cases.md`) for scenario-specific expected behaviors before presenting output.
 
 ---
 
@@ -156,16 +174,21 @@ Steps are sequential within each phase. Phase 3 branches by operation type — e
 - [ ] Do both use valid `<role>`, `<roleAndSubordinates>`, or `<group>` targets?
 
 ### Edit Operation Checks
+- [ ] Was the edit against a freshly retrieved file (not a stale local copy)?
+- [ ] Is the edit limited to supported fields for the rule type?
+  - Owner rules: only `accessLevel`
+  - Criteria rules: `accessLevel`, `criteriaItems`, `label`, `booleanFilter`
+  - Guest rules: `accessLevel`, `criteriaItems`, `label`, `includeHVUOwnedRecords`
+- [ ] Was `sharedTo`/`sharedFrom` left unchanged? (if user requested that change, refuse and advise delete + create)
 - [ ] Was only the intended element modified?
 - [ ] Are all required elements still present after the edit?
 - [ ] Does the modified rule still pass the universal checks above?
-- [ ] Was user confirmation received before writing?
 
 ### Delete Operation Checks
 - [ ] Was the correct rule removed (matched by `<fullName>`)?
 - [ ] Is the remaining XML well-formed with proper `<SharingRules>` root?
 - [ ] If no rules remain, was the file removed entirely?
-- [ ] Was user confirmation received before writing?
+- [ ] Was `platform-destructive-deploy` delegated to with the correct metadata type (`SharingCriteriaRule`, `SharingOwnerRule`, or `SharingGuestRule`)?
 
 ### Account-Specific Checks   CRITICAL
 - [ ] If object is Account, is `<accountSettings>` present with all three sub-elements?
@@ -185,7 +208,10 @@ Steps are sequential within each phase. Phase 3 branches by operation type — e
 | Criteria field values must exist as picklist values on the org | Invalid values cause: "Picklist value does not exist" |
 | Never hardcode file paths — resolve from `sfdx-project.json` | Customer projects use custom package directories |
 | For managed package custom objects, use the full API name including namespace prefix (e.g., `ns__Object__c`) | Namespace-prefixed objects store sharing rules under the prefixed name |
-| Always confirm before writing changes | Prevents accidental creation, modification, or deletion of sharing rules |
+| `sharedTo` and `sharedFrom` cannot be edited in place | Platform does not support modifying sharing targets — deploy will fail. Delete the rule and create a new one instead |
+| Owner-based rules only support editing `accessLevel` | No other field (`label`, `sharedTo`, `sharedFrom`) can be modified on owner rules — delete and recreate instead |
+| Always retrieve from the org before edit or delete | Local files may be stale; editing a stale file can recreate deleted rules or overwrite concurrent changes |
+| Deleting a rule requires a destructive deployment | A normal deploy is additive — it will not remove rules from the org. Delegate to `platform-destructive-deploy` |
 | Edit must preserve unmodified elements | Changing only `accessLevel` must not alter `criteriaItems` or other fields |
 | Delete must remove the entire rule block | Partial deletion leaves invalid XML and causes deployment failures |
 | Delete last rule removes the file | An empty `<SharingRules>` root with no children is invalid metadata |
@@ -202,9 +228,12 @@ Steps are sequential within each phase. Phase 3 branches by operation type — e
 | Picklist value mismatch | Query the org for valid values before generating criteria |
 | Appending duplicates existing rule name | Check existing `<fullName>` values before writing |
 | Guest user nickname not found | Query: `SELECT CommunityNickname FROM User WHERE UserType='Guest' AND IsActive=true` |
-| Editing a rule that doesn't exist locally | Retrieve from org first before attempting edit |
-| Deleting a rule referenced by other automation | Warn the user about potential downstream impact before confirming |
+| User requests edit to `sharedTo` or `sharedFrom` | Not supported — refuse the edit and instruct user to delete + create a new rule |
+| User requests edit to owner rule beyond `accessLevel` | Not supported — owner rules only allow `accessLevel` edits. Refuse and instruct user to delete + create |
 | Editing changes rule type (e.g., criteria → owner) | Not supported — delete the old rule and create a new one instead |
+| Local file is stale (rule deleted/changed in org) | Always retrieve fresh from org before edit or delete to avoid recreating removed rules |
+| Delete deployed with normal deploy (no destructive manifest) | Rule remains in the org — delegate to `platform-destructive-deploy` for proper removal |
+| Deleting a rule referenced by other automation | Warn the user about potential downstream impact |
 | Delete leaves malformed XML | Ensure proper XML structure after removal; validate the file is well-formed |
 
 ---
@@ -212,7 +241,8 @@ Steps are sequential within each phase. Phase 3 branches by operation type — e
 ## Output Expectations
 
 Deliverables:
-- `<packageDir>/sharingRules/<ObjectName>.sharingRules-meta.xml` — complete sharing rules file for the target object
+- **For get operations**: `<packageDir>/sharingRules/<ObjectName>.sharingRules-meta.xml` — retrieved sharing rules file from the org, plus a formatted summary of all rules found
+- **For create/edit/delete operations**: `<packageDir>/sharingRules/<ObjectName>.sharingRules-meta.xml` — complete sharing rules file for the target object
 
 ---
 
@@ -222,6 +252,7 @@ Deliverables:
 |------|-------------|
 | Permission set configuration | `platform-permission-set-generate` skill |
 | Custom object creation (if target object doesn't exist) | `platform-custom-object-generate` skill |
+| Destructive deployment (rule deletion from org) | `platform-destructive-deploy` skill |
 
 ---
 
@@ -230,6 +261,7 @@ Deliverables:
 | File | When to read |
 |------|-------------|
 | `references/rule-types.md` | Phase 2 — before generating any rule, to get the complete XML schema for each rule type |
-| `examples/create-cases.md` | Phase 5, step 11 — expected behavior for create and append scenarios |
-| `examples/edit-cases.md` | Phase 5, step 11 — expected behavior for edit scenarios |
-| `examples/delete-cases.md` | Phase 5, step 11 — expected behavior for delete and confirmation flow scenarios |
+| `scripts/count-remaining-rules.sh` | Phase 3, step 8b (Delete) — count sharing rule elements to determine if file should be removed |
+| `examples/create-cases.md` | Phase 4, step 10 — expected behavior for create and append scenarios |
+| `examples/edit-cases.md` | Phase 4, step 10 — expected behavior for edit scenarios |
+| `examples/delete-cases.md` | Phase 4, step 10 — expected behavior for delete scenarios |

package/skills/platform-sharing-rules-generate/examples/create-cases.md

@@ -14,9 +14,9 @@ Structured test scenarios for create operations. Each test case defines an input
 - Criteria: `Status__c` equals `Active`
 
 **Expected behavior:**
-1. Discovers SFDX project path and checks for existing `Property__c.sharingRules-meta.xml`
-2. Presents confirmation summary to user and waits for approval
-3. After confirmation, writes the file
+1. Retrieves the latest sharing rules from the org
+2. Checks for existing `Property__c.sharingRules-meta.xml` — no duplicates found
+3. Writes the file
 
 **Expected output:**
 ```xml
@@ -51,10 +51,9 @@ Structured test scenarios for create operations. Each test case defines an input
 - Criteria: `Published__c` equals `true`
 
 **Expected behavior:**
-1. Discovers project path and checks for existing file
+1. Retrieves the latest sharing rules from the org
 2. Queries org for guest user nickname if not provided
-3. Presents confirmation summary and waits for approval
-4. After confirmation, writes file using `<guestUser>` (not `<role>` or `<group>`)
+3. Writes file using `<guestUser>` (not `<role>` or `<group>`)
 
 **Expected output:**
 ```xml
@@ -89,10 +88,10 @@ Structured test scenarios for create operations. Each test case defines an input
 - Access level: Edit
 
 **Expected behavior:**
-1. Discovers project path, checks for existing Account sharing rules
-2. Includes `<accountSettings>` with all three sub-elements defaulted to `None`
-3. Presents confirmation summary and waits for approval
-4. After confirmation, writes the file
+1. Retrieves the latest sharing rules from the org
+2. Checks for existing Account sharing rules
+3. Includes `<accountSettings>` with all three sub-elements defaulted to `None`
+4. Writes the file
 
 **Expected output:**
 ```xml
@@ -122,17 +121,17 @@ Structured test scenarios for create operations. Each test case defines an input
 ## TC-04: Append a rule to an existing file
 
 **Input:**
-- Object: `Property__c` (file already exists with TC-01's rule)
+- Object: `Property__c` (org already contains TC-01's rule)
 - Rule type: criteria-based
 - Share with: group `AllAgents`
 - Access level: Edit
 - Criteria: `Price__c` greaterThan `1000000`
 
 **Expected behavior:**
-1. Reads existing file and finds TC-01's rule already present
-2. Does not duplicate existing rule
-3. Presents confirmation showing the new rule will be appended
-4. After confirmation, appends new rule inside existing `<SharingRules>` root
+1. Retrieves the latest sharing rules from the org
+2. Reads existing file and finds TC-01's rule already present
+3. Does not duplicate existing rule
+4. Appends new rule inside existing `<SharingRules>` root
 
 **Expected output:** File contains both TC-01's rule AND the new rule within the same `<SharingRules>` element.
 
@@ -141,11 +140,11 @@ Structured test scenarios for create operations. Each test case defines an input
 ## TC-17: Create rule with duplicate fullName
 
 **Input:**
-- Object: `Property__c` (file already contains rule `ShareActivePropertiesWithRegionalManager`)
+- Object: `Property__c` (org already contains rule `ShareActivePropertiesWithRegionalManager`)
 - Create a new rule also named `ShareActivePropertiesWithRegionalManager`
 
 **Expected behavior:**
-1. Reads existing file, finds duplicate `<fullName>`
+1. Retrieves from org, reads file, finds duplicate `<fullName>`
 2. Informs user of the conflict
 3. Suggests an alternative name or asks user to choose
 

package/skills/platform-sharing-rules-generate/examples/delete-cases.md

@@ -1,6 +1,8 @@
 # Sharing Rules — Delete Test Cases
 
-Structured test scenarios for delete operations and confirmation flow. Each test case defines an input, the expected behavior, and the expected output.
+Structured test scenarios for delete operations. Each test case defines an input, the expected behavior, and the expected output.
+
+> **Important:** A normal `sf project deploy start` is additive and will NOT remove a sharing rule from the org. Deleting a rule from the org requires a destructive deployment using `destructiveChanges.xml` with the `--post-destructive-changes` flag.
 
 ---
 
@@ -11,19 +13,20 @@ Structured test scenarios for delete operations and confirmation flow. Each test
 - Delete rule: `ShareActivePropertiesWithRegionalManager`
 
 **Expected behavior:**
-1. Locates the rule in the file
-2. Presents confirmation:
-   > **Operation:** Delete
-   > **Object:** `Property__c`
-   > **Rule:** `ShareActivePropertiesWithRegionalManager` (Share Active Properties With Regional Manager)
-   > **Changes:** Remove this criteria-based sharing rule entirely. 1 other rule(s) will remain in the file.
-   >
-   > Proceed? (yes / no / edit)
-3. Waits for confirmation
-4. Removes the entire `<sharingCriteriaRules>` block for that rule
-5. Other rules in the file remain intact
-
-**Expected output:** File retains `<SharingRules>` root and all other rules, with the deleted rule's block completely removed.
+1. Retrieves the latest sharing rules from the org
+2. Locates the rule in the retrieved file
+3. Removes the entire `<sharingCriteriaRules>` block for that rule from the local file
+4. Other rules in the file remain intact
+5. Creates `destructiveChanges.xml` with:
+   ```xml
+   <types>
+       <members>Property__c.ShareActivePropertiesWithRegionalManager</members>
+       <name>SharingCriteriaRule</name>
+   </types>
+   ```
+6. Deploys with: `sf project deploy start --manifest package.xml --post-destructive-changes destructiveChanges.xml --target-org <org>`
+
+**Expected output:** Local file retains `<SharingRules>` root and all other rules, with the deleted rule's block completely removed. Org has the rule removed via destructive deployment.
 
 ---
 
@@ -34,35 +37,19 @@ Structured test scenarios for delete operations and confirmation flow. Each test
 - Delete rule: `SharePublishedListingsWithSiteGuest`
 
 **Expected behavior:**
-1. Locates the rule — confirms it is the only rule in the file
-2. Presents confirmation warning that the entire file will be removed:
-   > **Operation:** Delete
-   > **Object:** `Listing__c`
-   > **Rule:** `SharePublishedListingsWithSiteGuest` (Share Published Listings With Site Guest)
-   > **Changes:** Remove this guest sharing rule. This is the last rule — the entire file `Listing__c.sharingRules-meta.xml` will be deleted.
-   >
-   > Proceed? (yes / no / edit)
-3. Waits for confirmation
-4. Deletes the entire file
-
-**Expected output:** File `Listing__c.sharingRules-meta.xml` no longer exists.
-
----
-
-## TC-11: Delete with user declining confirmation
-
-**Input:**
-- Object: `Account`
-- Delete rule: `ShareDirectorAccountsWithSalesTeam`
-- User response to confirmation: "no"
-
-**Expected behavior:**
-1. Locates the rule
-2. Presents confirmation
-3. User says "no"
-4. Aborts — no changes written
-
-**Expected output:** No file changes. Acknowledgment that the operation was cancelled.
+1. Retrieves the latest sharing rules from the org
+2. Locates the rule — confirms it is the only rule in the file
+3. Removes the local file entirely
+4. Creates `destructiveChanges.xml` with:
+   ```xml
+   <types>
+       <members>Listing__c.SharePublishedListingsWithSiteGuest</members>
+       <name>SharingGuestRule</name>
+   </types>
+   ```
+5. Deploys with: `sf project deploy start --manifest package.xml --post-destructive-changes destructiveChanges.xml --target-org <org>`
+
+**Expected output:** File `Listing__c.sharingRules-meta.xml` no longer exists locally. Org has the rule removed via destructive deployment.
 
 ---
 
@@ -73,41 +60,9 @@ Structured test scenarios for delete operations and confirmation flow. Each test
 - Delete rule: `RuleThatDoesNotExist`
 
 **Expected behavior:**
-1. Searches for the rule by `<fullName>` in the file
-2. Rule not found — reports error
-3. Lists available rules and asks user to clarify
+1. Retrieves the latest sharing rules from the org
+2. Searches for the rule by `<fullName>` in the retrieved file
+3. Rule not found — reports error
+4. Lists available rules and asks user to clarify
 
 **Expected output:** No file changes. Error message listing available rule names.
-
----
-
-## Confirmation Flow Tests
-
-### TC-13: User confirms with "yes"
-
-**Input:** Any create/edit/delete operation where user responds "yes" to confirmation.
-
-**Expected behavior:** Changes are written to disk as presented in the summary.
-
----
-
-### TC-14: User responds with "edit" and provides feedback
-
-**Input:**
-- Create operation for a criteria rule
-- User responds "edit" to confirmation with: "Change the access level to Edit instead of Read"
-
-**Expected behavior:**
-1. Original summary presented
-2. User says "edit" with feedback
-3. Incorporates feedback (changes `accessLevel` to `Edit`)
-4. Re-presents updated summary
-5. Waits for new confirmation before writing
-
----
-
-### TC-15: User declines with "no"
-
-**Input:** Any create/edit/delete operation where user responds "no" to confirmation.
-
-**Expected behavior:** No file changes. Operation aborted with acknowledgment.

package/skills/platform-sharing-rules-generate/examples/edit-cases.md

@@ -12,16 +12,9 @@ Structured test scenarios for edit operations. Each test case defines an input,
 - Change: access level from `Read` to `Edit`
 
 **Expected behavior:**
-1. Locates the rule by `<fullName>` in the existing file
-2. Presents confirmation showing current vs. proposed change:
-   > **Operation:** Edit
-   > **Object:** `Property__c`
-   > **Rule:** `ShareActivePropertiesWithRegionalManager` (Share Active Properties With Regional Manager)
-   > **Changes:** accessLevel: Read → Edit
-   >
-   > Proceed? (yes / no / edit)
-3. Waits for user confirmation
-4. After confirmation, modifies only `<accessLevel>` — all other elements unchanged
+1. Retrieves the latest sharing rules from the org
+2. Locates the rule by `<fullName>` in the retrieved file
+3. Modifies only `<accessLevel>` — all other elements unchanged
 
 **Expected output (changed portion):**
 ```xml
@@ -31,7 +24,7 @@ All other elements (`fullName`, `label`, `sharedTo`, `criteriaItems`, `includeRe
 
 ---
 
-## TC-06: Edit shared-to target of an existing rule
+## TC-06: Edit shared-to target of an existing rule (UNSUPPORTED)
 
 **Input:**
 - Object: `Property__c`
@@ -39,18 +32,13 @@ All other elements (`fullName`, `label`, `sharedTo`, `criteriaItems`, `includeRe
 - Change: shared-to from role `RegionalManager` to group `PropertyViewers`
 
 **Expected behavior:**
-1. Locates the rule in the file
-2. Presents confirmation showing:
-   > **Changes:** sharedTo: role `RegionalManager` → group `PropertyViewers`
-3. Waits for confirmation
-4. Replaces `<sharedTo>` content only
+1. Detects that the requested change targets `<sharedTo>`, which cannot be edited in place
+2. Refuses the edit and informs the user that the platform does not support modifying `sharedTo` or `sharedFrom` on an existing rule
+3. Suggests: delete the existing rule and create a new one with the desired sharing target
 
-**Expected output (changed portion):**
-```xml
-<sharedTo>
-    <group>PropertyViewers</group>
-</sharedTo>
-```
+**Expected output:** No file changes. Guidance to user about delete + create workflow.
+
+> **Note:** The same restriction applies to `<sharedFrom>` on owner-based rules. Any change to the sharing source or target requires delete + create.
 
 ---
 
@@ -62,10 +50,9 @@ All other elements (`fullName`, `label`, `sharedTo`, `criteriaItems`, `includeRe
 - Change: update criteria from `Status__c equals Active` to `Status__c equals Active` AND `Region__c equals West`
 
 **Expected behavior:**
-1. Locates the rule in the file
-2. Presents confirmation showing current criteria vs. proposed criteria
-3. Waits for confirmation
-4. Replaces `<criteriaItems>` elements
+1. Retrieves the latest sharing rules from the org
+2. Locates the rule in the retrieved file
+3. Replaces `<criteriaItems>` elements
 
 **Expected output (changed portion):**
 ```xml

package/skills/platform-sharing-rules-generate/scripts/count-remaining-rules.sh

@@ -0,0 +1,33 @@
+#!/bin/bash
+# Counts remaining sharing rule elements in a .sharingRules-meta.xml file.
+# Usage: count-remaining-rules.sh <file>
+# Output: integer count of rule elements found
+# Exit behavior: exits 0 with count; exits 1 if file not found, xmllint missing, or XML parse fails
+
+FILE="$1"
+if [ ! -f "$FILE" ]; then
+  echo "Error: File not found: $FILE" >&2
+  exit 1
+fi
+
+if ! command -v xmllint &>/dev/null; then
+  echo "Error: xmllint is not installed or not in PATH" >&2
+  exit 1
+fi
+
+XMLLINT_ERR=$(mktemp)
+COUNT=$(xmllint --xpath 'count(//*[local-name()="sharingCriteriaRules" or local-name()="sharingOwnerRules" or local-name()="sharingGuestRules"])' "$FILE" 2>"$XMLLINT_ERR")
+STATUS=$?
+if [ $STATUS -ne 0 ]; then
+  echo "Error: xmllint failed to parse $FILE (exit $STATUS): $(cat "$XMLLINT_ERR")" >&2
+  rm -f "$XMLLINT_ERR"
+  exit 1
+fi
+rm -f "$XMLLINT_ERR"
+
+if ! [[ "$COUNT" =~ ^[0-9]+\.?[0-9]*$ ]]; then
+  echo "Error: xmllint returned non-numeric output for $FILE: $COUNT" >&2
+  exit 1
+fi
+
+echo "${COUNT%%.*}"

package/skills/platform-widget-generate/SKILL.md

@@ -2,7 +2,7 @@
 name: platform-widget-generate
 description: "Use this skill to author a complete HXL WidgetBundle (UEM body + schema.json + -meta.xml). TRIGGER when: user asks for a widget, mosaic, fragment, card, or rich UI surface for any subject, domain, feature, or entity noun; the prompt names only an entity or data shape without invoking Lightning Types, CLTs, or Apex-backed types. DO NOT TRIGGER when: the prompt explicitly says 'Lightning Type', 'CLT', 'Custom Lightning Type', 'Apex-backed type', or references '@apexClassType/...' (use platform-lightning-type-widget-coordinate); authoring a custom-LWC renderer for a Custom Lightning Type (use platform-custom-lightning-type-generate); or editing only an LWC component."
 metadata:
-  version: "1.1"
+  version: "1.2"
   minApiVersion: "68.0"
   relatedSkills:
     - "platform-apex-generate"
@@ -62,7 +62,7 @@ interface Block {
 }
 ```
 
-The first child of `tile/widget.children` SHOULD be a single `tile/column` (or a single `tile/card`). All widget content typically goes inside that first child for predictable vertical structure across surfaces.
+The first child of `tile/widget.children` SHOULD be a single `tile/column`. All widget content typically goes inside that first child for predictable vertical structure across surfaces.
 
 ---
 
@@ -103,10 +103,8 @@ These conventions cover widget *structure* — how blocks are grouped and stacke
 |---|---|---|
 | `tile/column` | Vertical stack of children | Root wrapper, and any group of blocks that should stack |
 | `tile/row` | Horizontal stack of children | Two or more blocks that belong on the same line |
-| `tile/card` | Visually-boxed group | A bounded section that should read as one unit |
 | `tile/spacer` | Whitespace between blocks | When extra space is needed between content groups |
 
-- **Sectioning:** Separate major content groups with a fresh `tile/card`-bounded section. Do not nest cards inside cards.
 - **Nesting:** Prefer flat layouts. Only nest a `tile/column` inside a `tile/row` (or vice versa) when the visual orientation actually changes for that subgroup.
 - **Authoritative palette:** the table above lists *typical* layout primitives. Always confirm a block exists by inspecting `discoverUiComponents` output — do not assume a block name from this table without seeing it in the discovery response.
 
@@ -198,7 +196,7 @@ Widgets express *intent*, not pixels. Each surface provides a default look and f
 9. **Self-validate.** Before reporting, confirm each check below and report each result individually (`pass` or `fail (<reason>)`). Do **not** summarize as a single "all passed" line — list every check so a reviewer can spot a silent skip.
     - **`schema-parses`** — `<pkgDir>/uiWidgets/<widgetName>/schema.json` parses as JSON.
     - **`schema-root-keys`** — root has `title` (string), `type: "object"`, and `properties.attributes` (object) — where `properties.attributes` carries `lightning:type: "lightning__objectType"` and a nested `properties` map. No `unevaluatedProperties: false`.
-    - **`schema-leaf-types`** — every leaf under `properties.attributes.properties` carries a `lightning:type`. Singular nested inner-class fields appear as `lightning__objectType`; the nested shape is not redeclared.
+    - **`schema-leaf-types`** — every leaf under `properties.attributes.properties` carries a `lightning:type`. Singular nested inner-class fields carry `lightning:type` set to the inner Apex class reference (`@apexClassType/<namespace>__<OuterClass>$<InnerClass>`); the nested shape is not redeclared. `List<InnerClass>` fields carry `lightning:type: "lightning__listType"` with `items.lightning:type` set to the inner Apex class reference (`@apexClassType/<namespace>__<OuterClass>$<InnerClass>`), not a redeclared field map. See `references/schema-from-lightning-type.md`.
     - **`bindings-resolve`** — every `{!$attrs.X}` (or `{!$attrs.<outerField>.<innerField>}` for nested objects) in `<widgetName>.json` resolves to a property under `schema.json` `properties.attributes.properties`, and every `{!$item.X}` resolves to a `forItem` loop variable defined upstream.
     - **`body-envelope`** — `<widgetName>.json` root has `type: "lightning__agentforceWidget"` and a `contentBody` object whose `widgetBody` carries the UEM tree rooted at `tile/widget`. No node in the tree — root or non-root — carries a `type` key.
     - **`metaxml-wellformed`** — `<widgetName>.uiwidget-meta.xml` parses as well-formed XML.