CHANGELOG.md

@@ -1,140 +1,3 @@
-# [1.32.0](https://github.com/forcedotcom/sf-skills/compare/1.31.0...1.32.0) (2026-07-24)
-
-
-### Features
-
-* Release 8 new + 7 updated skills (2026-07-24) @W-23528521@ ([f988850](https://github.com/forcedotcom/sf-skills/commit/f9888508cdcbf5fc09d00f9d099cb8acdfcc63e0))
-
-
-
-# [1.31.0](https://github.com/forcedotcom/sf-skills/compare/1.30.0...1.31.0) (2026-07-17)
-
-
-### Features
-
-* Release 4 new skills + 6 skill updates (weekly batch 2026-07-16) @W-23461225@ ([ae560c9](https://github.com/forcedotcom/sf-skills/commit/ae560c9719cd051d58b72b82b7965fd899df241b))
-
-
-
-# [1.30.0](https://github.com/forcedotcom/sf-skills/compare/1.29.0...1.30.0) (2026-07-10)
-
-
-### Features
-
-* Release 2 new skills: platform-models-api-configure, platform-policy-rule-generate @W-23396600@ ([ae79223](https://github.com/forcedotcom/sf-skills/commit/ae792239f2e798654c77348e0ee4593d3d3110e8))
-
-
-
-# [1.29.0](https://github.com/forcedotcom/sf-skills/compare/1.28.0...1.29.0) (2026-07-03)
-
-
-### Features
-
-* Release 2 new skills: platform-value-set-generate, dx-code-analyzer-custom-rule-create @W-23286064@ ([e07b6b3](https://github.com/forcedotcom/sf-skills/commit/e07b6b37b399107249f056213cf73f7e6d469653))
-
-
-
-# [1.28.0](https://github.com/forcedotcom/sf-skills/compare/1.27.0...1.28.0) (2026-07-03)
-
-
-### Features
-
-* Release: Standardize skill folder structure scripts/, references/, assets/ @W-23262449@ ([3a358c3](https://github.com/forcedotcom/sf-skills/commit/3a358c3b1cce0e0df8c6ba09cc7cd48bb0295341))
-
-
-
-# [1.27.0](https://github.com/forcedotcom/sf-skills/compare/1.26.0...1.27.0) (2026-06-29)
-
-
-### Bug Fixes
-
-* @W-22259678@ update stale skill name references ([#301](https://github.com/forcedotcom/sf-skills/issues/301)) ([48ef93f](https://github.com/forcedotcom/sf-skills/commit/48ef93f39d25792029ea3a4287c845d842706f6f))
-
-
-### Features
-
-* Update stale cross-references to renamed skills @W-23223262@ ([fae028f](https://github.com/forcedotcom/sf-skills/commit/fae028fd99a366de12a41d5e256020aee82ffe29))
-
-
-
-# [1.26.0](https://github.com/forcedotcom/sf-skills/compare/1.25.0...1.26.0) (2026-06-26)
-
-
-### Features
-
-* release 4 new dx-devops skills @W-23195013@ ([77e5e14](https://github.com/forcedotcom/sf-skills/commit/77e5e1476c696c8c33910f21d43d3c555f755c9e))
-
-
-
-# [1.25.0](https://github.com/forcedotcom/sf-skills/compare/1.24.0...1.25.0) (2026-06-26)
-
-
-### Features
-
-* Release 8 new skills: commerce-b2b-open-code-components-replace, dx-org-manage, dx-org-permission-set-assign, platform-agentsetup-categories-fetch, platform-metadata-retrieve, platform-sharing-rules-generate, platform-tracing-agentforce-configure, platform-tracing-configure @W-23195013@ ([9fc0710](https://github.com/forcedotcom/sf-skills/commit/9fc07100ef294649b504890128a2d53a0662f248))
-
-
-
-# [1.24.0](https://github.com/forcedotcom/sf-skills/compare/1.23.0...1.24.0) (2026-06-26)
-
-
-### Features
-
-* Rename datacloud skills to domain-first convention @W-23195294@ ([64a9fcb](https://github.com/forcedotcom/sf-skills/commit/64a9fcb6ee12e64e242a88155d149906a43fc5c3))
-
-
-
-# [1.23.0](https://github.com/forcedotcom/sf-skills/compare/1.22.0...1.23.0) (2026-06-26)
-
-
-### Features
-
-* Release Skills Renaming by domain first convention @W-23187998@ ([deaa3d0](https://github.com/forcedotcom/sf-skills/commit/deaa3d0fedc08c0ade00bba45d5a96384b4bcc20))
-
-
-
-# [1.22.0](https://github.com/forcedotcom/sf-skills/compare/1.21.0...1.22.0) (2026-06-26)
-
-
-### Bug Fixes
-
-* allow nested YAML lists in metadata sub-keys (sync with internal) @W-23173617@ ([#298](https://github.com/forcedotcom/sf-skills/issues/298)) ([a95d0d3](https://github.com/forcedotcom/sf-skills/commit/a95d0d3f828b92eb332fdd5b8e4305b00e170937))
-
-
-### Features
-
-* Release 1 new skill: getting-metadata-api-context @W-23151783 ([19ee934](https://github.com/forcedotcom/sf-skills/commit/19ee934c6722273c99ff8c93fc157443192f0b1c))
-* Release Skills Renaming by domain first convention @W-23187998@ ([b40d286](https://github.com/forcedotcom/sf-skills/commit/b40d286458452f10dec2b86d22d2448ad3060102))
-
-
-
-# [1.21.0](https://github.com/forcedotcom/sf-skills/compare/1.20.0...1.21.0) (2026-06-24)
-
-
-### Features
-
-* release 1 skill : dx-app-analytics-use @W-23151783 ([68c511b](https://github.com/forcedotcom/sf-skills/commit/68c511b7262c89ff1411b98e10c92d5821a1516c))
-
-
-
-# [1.20.0](https://github.com/forcedotcom/sf-skills/compare/1.19.0...1.20.0) (2026-06-23)
-
-
-### Features
-
-* release new skill: platform-agentexchange-partner-offers-enable (PRs [#490](https://github.com/forcedotcom/sf-skills/issues/490), [#579](https://github.com/forcedotcom/sf-skills/issues/579)) @W-23143960@ ([afd1a2d](https://github.com/forcedotcom/sf-skills/commit/afd1a2d8aa35db692269f3efaa2c1c50b16e0a7d))
-
-
-
-# [1.19.0](https://github.com/forcedotcom/sf-skills/compare/1.18.0...1.19.0) (2026-06-23)
-
-
-### Features
-
-* release 10 new devops-testing skills: analyzing-test-failures, checking-devops-prerequisites, configuring-quality-gate, configuring-test-provider, creating-fix-work-item, managing-suite-assignments, polling-test-results, recommending-devops-tests, running-devops-test-suite, syncing-test-providers @W-23143960@ ([a35d50a](https://github.com/forcedotcom/sf-skills/commit/a35d50a3dd2b84b459571d4d5577b092810a5a17))
-
-
-
 # [1.18.0](https://github.com/forcedotcom/sf-skills/compare/1.17.0...1.18.0) (2026-06-19)
 
 

CODEOWNERS

@@ -1,3 +1,3 @@
 # Comment line immediately above ownership line is reserved for related other information. Please be careful while editing.
 #ECCN:Open Source
-#GUSINFO:
+#GUSINFO:Open Source,Open Source Workflow,Docs Only

DOCS_ONLY.md

@@ -0,0 +1,4 @@
+## Docs Only
+
+This repo contains docs only; No code is allowed and the content is not
+licensed under any Open Source license.

LICENSE.txt

@@ -1,207 +1,330 @@
-Apache License Version 2.0
+Creative Commons Attribution-NonCommercial 4.0 International Public
+License
 
-Copyright (c) 2026 Salesforce, Inc.
-All rights reserved.
+By exercising the Licensed Rights (defined below), You accept and agree
+to be bound by the terms and conditions of this Creative Commons
+Attribution-NonCommercial 4.0 International Public License ("Public
+License"). To the extent this Public License may be interpreted as a
+contract, You are granted the Licensed Rights in consideration of Your
+acceptance of these terms and conditions, and the Licensor grants You
+such rights in consideration of benefits the Licensor receives from
+making the Licensed Material available under these terms and
+conditions.
 
-                                 Apache License
-                           Version 2.0, January 2004
-                        http://www.apache.org/licenses/
 
-   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+Section 1 -- Definitions.
 
-   1. Definitions.
+  a. Adapted Material means material subject to Copyright and Similar
+     Rights that is derived from or based upon the Licensed Material
+     and in which the Licensed Material is translated, altered,
+     arranged, transformed, or otherwise modified in a manner requiring
+     permission under the Copyright and Similar Rights held by the
+     Licensor. For purposes of this Public License, where the Licensed
+     Material is a musical work, performance, or sound recording,
+     Adapted Material is always produced where the Licensed Material is
+     synched in timed relation with a moving image.
 
-      "License" shall mean the terms and conditions for use, reproduction,
-      and distribution as defined by Sections 1 through 9 of this document.
+  b. Adapter's License means the license You apply to Your Copyright
+     and Similar Rights in Your contributions to Adapted Material in
+     accordance with the terms and conditions of this Public License.
 
-      "Licensor" shall mean the copyright owner or entity authorized by
-      the copyright owner that is granting the License.
+  c. Copyright and Similar Rights means copyright and/or similar rights
+     closely related to copyright including, without limitation,
+     performance, broadcast, sound recording, and Sui Generis Database
+     Rights, without regard to how the rights are labeled or
+     categorized. For purposes of this Public License, the rights
+     specified in Section 2(b)(1)-(2) are not Copyright and Similar
+     Rights.
+  d. Effective Technological Measures means those measures that, in the
+     absence of proper authority, may not be circumvented under laws
+     fulfilling obligations under Article 11 of the WIPO Copyright
+     Treaty adopted on December 20, 1996, and/or similar international
+     agreements.
 
-      "Legal Entity" shall mean the union of the acting entity and all
-      other entities that control, are controlled by, or are under common
-      control with that entity. For the purposes of this definition,
-      "control" means (i) the power, direct or indirect, to cause the
-      direction or management of such entity, whether by contract or
-      otherwise, or (ii) ownership of fifty percent (50%) or more of the
-      outstanding shares, or (iii) beneficial ownership of such entity.
+  e. Exceptions and Limitations means fair use, fair dealing, and/or
+     any other exception or limitation to Copyright and Similar Rights
+     that applies to Your use of the Licensed Material.
 
-      "You" (or "Your") shall mean an individual or Legal Entity
-      exercising permissions granted by this License.
+  f. Licensed Material means the artistic or literary work, database,
+     or other material to which the Licensor applied this Public
+     License.
 
-      "Source" form shall mean the preferred form for making modifications,
-      including but not limited to software source code, documentation
-      source, and configuration files.
+  g. Licensed Rights means the rights granted to You subject to the
+     terms and conditions of this Public License, which are limited to
+     all Copyright and Similar Rights that apply to Your use of the
+     Licensed Material and that the Licensor has authority to license.
 
-      "Object" form shall mean any form resulting from mechanical
-      transformation or translation of a Source form, including but
-      not limited to compiled object code, generated documentation,
-      and conversions to other media types.
+  h. Licensor means the individual(s) or entity(ies) granting rights
+     under this Public License.
 
-      "Work" shall mean the work of authorship, whether in Source or
-      Object form, made available under the License, as indicated by a
-      copyright notice that is included in or attached to the work
-      (an example is provided in the Appendix below).
+  i. NonCommercial means not primarily intended for or directed towards
+     commercial advantage or monetary compensation. For purposes of
+     this Public License, the exchange of the Licensed Material for
+     other material subject to Copyright and Similar Rights by digital
+     file-sharing or similar means is NonCommercial provided there is
+     no payment of monetary compensation in connection with the
+     exchange.
 
-      "Derivative Works" shall mean any work, whether in Source or Object
-      form, that is based on (or derived from) the Work and for which the
-      editorial revisions, annotations, elaborations, or other modifications
-      represent, as a whole, an original work of authorship. For the purposes
-      of this License, Derivative Works shall not include works that remain
-      separable from, or merely link (or bind by name) to the interfaces of,
-      the Work and Derivative Works thereof.
+  j. Share means to provide material to the public by any means or
+     process that requires permission under the Licensed Rights, such
+     as reproduction, public display, public performance, distribution,
+     dissemination, communication, or importation, and to make material
+     available to the public including in ways that members of the
+     public may access the material from a place and at a time
+     individually chosen by them.
 
-      "Contribution" shall mean any work of authorship, including
-      the original version of the Work and any modifications or additions
-      to that Work or Derivative Works thereof, that is intentionally
-      submitted to Licensor for inclusion in the Work by the copyright owner
-      or by an individual or Legal Entity authorized to submit on behalf of
-      the copyright owner. For the purposes of this definition, "submitted"
-      means any form of electronic, verbal, or written communication sent
-      to the Licensor or its representatives, including but not limited to
-      communication on electronic mailing lists, source code control systems,
-      and issue tracking systems that are managed by, or on behalf of, the
-      Licensor for the purpose of discussing and improving the Work, but
-      excluding communication that is conspicuously marked or otherwise
-      designated in writing by the copyright owner as "Not a Contribution."
+  k. Sui Generis Database Rights means rights other than copyright
+     resulting from Directive 96/9/EC of the European Parliament and of
+     the Council of 11 March 1996 on the legal protection of databases,
+     as amended and/or succeeded, as well as other essentially
+     equivalent rights anywhere in the world.
 
-      "Contributor" shall mean Licensor and any individual or Legal Entity
-      on behalf of whom a Contribution has been received by Licensor and
-      subsequently incorporated within the Work.
+  l. You means the individual or entity exercising the Licensed Rights
+     under this Public License. Your has a corresponding meaning.
 
-   2. Grant of Copyright License. Subject to the terms and conditions of
-      this License, each Contributor hereby grants to You a perpetual,
-      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
-      copyright license to reproduce, prepare Derivative Works of,
-      publicly display, publicly perform, sublicense, and distribute the
-      Work and such Derivative Works in Source or Object form.
 
-   3. Grant of Patent License. Subject to the terms and conditions of
-      this License, each Contributor hereby grants to You a perpetual,
-      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
-      (except as stated in this section) patent license to make, have made,
-      use, offer to sell, sell, import, and otherwise transfer the Work,
-      where such license applies only to those patent claims licensable
-      by such Contributor that are necessarily infringed by their
-      Contribution(s) alone or by combination of their Contribution(s)
-      with the Work to which such Contribution(s) was submitted. If You
-      institute patent litigation against any entity (including a
-      cross-claim or counterclaim in a lawsuit) alleging that the Work
-      or a Contribution incorporated within the Work constitutes direct
-      or contributory patent infringement, then any patent licenses
-      granted to You under this License for that Work shall terminate
-      as of the date such litigation is filed.
+Section 2 -- Scope.
 
-   4. Redistribution. You may reproduce and distribute copies of the
-      Work or Derivative Works thereof in any medium, with or without
-      modifications, and in Source or Object form, provided that You
-      meet the following conditions:
+  a. License grant.
 
-      (a) You must give any other recipients of the Work or
-          Derivative Works a copy of this License; and
+       1. Subject to the terms and conditions of this Public License,
+          the Licensor hereby grants You a worldwide, royalty-free,
+          non-sublicensable, non-exclusive, irrevocable license to
+          exercise the Licensed Rights in the Licensed Material to:
 
-      (b) You must cause any modified files to carry prominent notices
-          stating that You changed the files; and
+            a. reproduce and Share the Licensed Material, in whole or
+               in part, for NonCommercial purposes only; and
 
-      (c) You must retain, in the Source form of any Derivative Works
-          that You distribute, all copyright, patent, trademark, and
-          attribution notices from the Source form of the Work,
-          excluding those notices that do not pertain to any part of
-          the Derivative Works; and
+            b. produce, reproduce, and Share Adapted Material for
+               NonCommercial purposes only.
 
-      (d) If the Work includes a "NOTICE" text file as part of its
-          distribution, then any Derivative Works that You distribute must
-          include a readable copy of the attribution notices contained
-          within such NOTICE file, excluding those notices that do not
-          pertain to any part of the Derivative Works, in at least one
-          of the following places: within a NOTICE text file distributed
-          as part of the Derivative Works; within the Source form or
-          documentation, if provided along with the Derivative Works; or,
-          within a display generated by the Derivative Works, if and
-          wherever such third-party notices normally appear. The contents
-          of the NOTICE file are for informational purposes only and
-          do not modify the License. You may add Your own attribution
-          notices within Derivative Works that You distribute, alongside
-          or as an addendum to the NOTICE text from the Work, provided
-          that such additional attribution notices cannot be construed
-          as modifying the License.
+       2. Exceptions and Limitations. For the avoidance of doubt, where
+          Exceptions and Limitations apply to Your use, this Public
+          License does not apply, and You do not need to comply with
+          its terms and conditions.
 
-      You may add Your own copyright statement to Your modifications and
-      may provide additional or different license terms and conditions
-      for use, reproduction, or distribution of Your modifications, or
-      for any such Derivative Works as a whole, provided Your use,
-      reproduction, and distribution of the Work otherwise complies with
-      the conditions stated in this License.
+       3. Term. The term of this Public License is specified in Section
+          6(a).
 
-   5. Submission of Contributions. Unless You explicitly state otherwise,
-      any Contribution intentionally submitted for inclusion in the Work
-      by You to the Licensor shall be under the terms and conditions of
-      this License, without any additional terms or conditions.
-      Notwithstanding the above, nothing herein shall supersede or modify
-      the terms of any separate license agreement you may have executed
-      with Licensor regarding such Contributions.
+       4. Media and formats; technical modifications allowed. The
+          Licensor authorizes You to exercise the Licensed Rights in
+          all media and formats whether now known or hereafter created,
+          and to make technical modifications necessary to do so. The
+          Licensor waives and/or agrees not to assert any right or
+          authority to forbid You from making technical modifications
+          necessary to exercise the Licensed Rights, including
+          technical modifications necessary to circumvent Effective
+          Technological Measures. For purposes of this Public License,
+          simply making modifications authorized by this Section 2(a)
+          (4) never produces Adapted Material.
 
-   6. Trademarks. This License does not grant permission to use the trade
-      names, trademarks, service marks, or product names of the Licensor,
-      except as required for reasonable and customary use in describing the
-      origin of the Work and reproducing the content of the NOTICE file.
+       5. Downstream recipients.
 
-   7. Disclaimer of Warranty. Unless required by applicable law or
-      agreed to in writing, Licensor provides the Work (and each
-      Contributor provides its Contributions) on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
-      implied, including, without limitation, any warranties or conditions
-      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
-      PARTICULAR PURPOSE. You are solely responsible for determining the
-      appropriateness of using or redistributing the Work and assume any
-      risks associated with Your exercise of permissions under this License.
+            a. Offer from the Licensor -- Licensed Material. Every
+               recipient of the Licensed Material automatically
+               receives an offer from the Licensor to exercise the
+               Licensed Rights under the terms and conditions of this
+               Public License.
 
-   8. Limitation of Liability. In no event and under no legal theory,
-      whether in tort (including negligence), contract, or otherwise,
-      unless required by applicable law (such as deliberate and grossly
-      negligent acts) or agreed to in writing, shall any Contributor be
-      liable to You for damages, including any direct, indirect, special,
-      incidental, or consequential damages of any character arising as a
-      result of this License or out of the use or inability to use the
-      Work (including but not limited to damages for loss of goodwill,
-      work stoppage, computer failure or malfunction, or any and all
-      other commercial damages or losses), even if such Contributor
-      has been advised of the possibility of such damages.
+            b. No downstream restrictions. You may not offer or impose
+               any additional or different terms or conditions on, or
+               apply any Effective Technological Measures to, the
+               Licensed Material if doing so restricts exercise of the
+               Licensed Rights by any recipient of the Licensed
+               Material.
 
-   9. Accepting Warranty or Additional Liability. While redistributing
-      the Work or Derivative Works thereof, You may choose to offer,
-      and charge a fee for, acceptance of support, warranty, indemnity,
-      or other liability obligations and/or rights consistent with this
-      License. However, in accepting such obligations, You may act only
-      on Your own behalf and on Your sole responsibility, not on behalf
-      of any other Contributor, and only if You agree to indemnify,
-      defend, and hold each Contributor harmless for any liability
-      incurred by, or claims asserted against, such Contributor by reason
-      of your accepting any such warranty or additional liability.
+       6. No endorsement. Nothing in this Public License constitutes or
+          may be construed as permission to assert or imply that You
+          are, or that Your use of the Licensed Material is, connected
+          with, or sponsored, endorsed, or granted official status by,
+          the Licensor or others designated to receive attribution as
+          provided in Section 3(a)(1)(A)(i).
 
-   END OF TERMS AND CONDITIONS
+  b. Other rights.
 
-   APPENDIX: How to apply the Apache License to your work.
+       1. Moral rights, such as the right of integrity, are not
+          licensed under this Public License, nor are publicity,
+          privacy, and/or other similar personality rights; however, to
+          the extent possible, the Licensor waives and/or agrees not to
+          assert any such rights held by the Licensor to the limited
+          extent necessary to allow You to exercise the Licensed
+          Rights, but not otherwise.
 
-      To apply the Apache License to your work, attach the following
-      boilerplate notice, with the fields enclosed by brackets "{}"
-      replaced with your own identifying information. (Don't include
-      the brackets!)  The text should be enclosed in the appropriate
-      comment syntax for the file format. We also recommend that a
-      file or class name and description of purpose be included on the
-      same "printed page" as the copyright notice for easier
-      identification within third-party archives.
+       2. Patent and trademark rights are not licensed under this
+          Public License.
 
-   Copyright {yyyy} {name of copyright owner}
+       3. To the extent possible, the Licensor waives any right to
+          collect royalties from You for the exercise of the Licensed
+          Rights, whether directly or through a collecting society
+          under any voluntary or waivable statutory or compulsory
+          licensing scheme. In all other cases the Licensor expressly
+          reserves any right to collect such royalties, including when
+          the Licensed Material is used other than for NonCommercial
+          purposes.
 
-   Licensed under the Apache License, Version 2.0 (the "License");
-   you may not use this file except in compliance with the License.
-   You may obtain a copy of the License at
 
-       http://www.apache.org/licenses/LICENSE-2.0
+Section 3 -- License Conditions.
 
-   Unless required by applicable law or agreed to in writing, software
-   distributed under the License is distributed on an "AS IS" BASIS,
-   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-   See the License for the specific language governing permissions and
-   limitations under the License.
+Your exercise of the Licensed Rights is expressly made subject to the
+following conditions.
 
+  a. Attribution.
+
+       1. If You Share the Licensed Material (including in modified
+          form), You must:
+
+            a. retain the following if it is supplied by the Licensor
+               with the Licensed Material:
+
+                 i. identification of the creator(s) of the Licensed
+                    Material and any others designated to receive
+                    attribution, in any reasonable manner requested by
+                    the Licensor (including by pseudonym if
+                    designated);
+
+                ii. a copyright notice;
+
+               iii. a notice that refers to this Public License;
+
+                iv. a notice that refers to the disclaimer of
+                    warranties;
+
+                 v. a URI or hyperlink to the Licensed Material to the
+                    extent reasonably practicable;
+
+            b. indicate if You modified the Licensed Material and
+               retain an indication of any previous modifications; and
+
+            c. indicate the Licensed Material is licensed under this
+               Public License, and include the text of, or the URI or
+               hyperlink to, this Public License.
+
+       2. You may satisfy the conditions in Section 3(a)(1) in any
+          reasonable manner based on the medium, means, and context in
+          which You Share the Licensed Material. For example, it may be
+          reasonable to satisfy the conditions by providing a URI or
+          hyperlink to a resource that includes the required
+          information.
+
+       3. If requested by the Licensor, You must remove any of the
+          information required by Section 3(a)(1)(A) to the extent
+          reasonably practicable.
+
+       4. If You Share Adapted Material You produce, the Adapter's
+          License You apply must not prevent recipients of the Adapted
+          Material from complying with this Public License.
+
+
+Section 4 -- Sui Generis Database Rights.
+
+Where the Licensed Rights include Sui Generis Database Rights that
+apply to Your use of the Licensed Material:
+
+  a. for the avoidance of doubt, Section 2(a)(1) grants You the right
+     to extract, reuse, reproduce, and Share all or a substantial
+     portion of the contents of the database for NonCommercial purposes
+     only;
+
+  b. if You include all or a substantial portion of the database
+     contents in a database in which You have Sui Generis Database
+     Rights, then the database in which You have Sui Generis Database
+     Rights (but not its individual contents) is Adapted Material; and
+
+  c. You must comply with the conditions in Section 3(a) if You Share
+     all or a substantial portion of the contents of the database.
+
+For the avoidance of doubt, this Section 4 supplements and does not
+replace Your obligations under this Public License where the Licensed
+Rights include other Copyright and Similar Rights.
+
+
+Section 5 -- Disclaimer of Warranties and Limitation of Liability.
+
+  a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE
+     EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS
+     AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF
+     ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS,
+     IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION,
+     WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR
+     PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS,
+     ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT
+     KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT
+     ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU.
+
+  b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE
+     TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION,
+     NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT,
+     INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES,
+     COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR
+     USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN
+     ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR
+     DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR
+     IN PART, THIS LIMITATION MAY NOT APPLY TO YOU.
+
+  c. The disclaimer of warranties and limitation of liability provided
+     above shall be interpreted in a manner that, to the extent
+     possible, most closely approximates an absolute disclaimer and
+     waiver of all liability.
+
+
+Section 6 -- Term and Termination.
+
+  a. This Public License applies for the term of the Copyright and
+     Similar Rights licensed here. However, if You fail to comply with
+     this Public License, then Your rights under this Public License
+     terminate automatically.
+
+  b. Where Your right to use the Licensed Material has terminated under
+     Section 6(a), it reinstates:
+
+       1. automatically as of the date the violation is cured, provided
+          it is cured within 30 days of Your discovery of the
+          violation; or
+
+       2. upon express reinstatement by the Licensor.
+
+     For the avoidance of doubt, this Section 6(b) does not affect any
+     right the Licensor may have to seek remedies for Your violations
+     of this Public License.
+
+  c. For the avoidance of doubt, the Licensor may also offer the
+     Licensed Material under separate terms or conditions or stop
+     distributing the Licensed Material at any time; however, doing so
+     will not terminate this Public License.
+
+  d. Sections 1, 5, 6, 7, and 8 survive termination of this Public
+     License.
+
+
+Section 7 -- Other Terms and Conditions.
+
+  a. The Licensor shall not be bound by any additional or different
+     terms or conditions communicated by You unless expressly agreed.
+
+  b. Any arrangements, understandings, or agreements regarding the
+     Licensed Material not stated herein are separate from and
+     independent of the terms and conditions of this Public License.
+
+
+Section 8 -- Interpretation.
+
+  a. For the avoidance of doubt, this Public License does not, and
+     shall not be interpreted to, reduce, limit, restrict, or impose
+     conditions on any use of the Licensed Material that could lawfully
+     be made without permission under this Public License.
+
+  b. To the extent possible, if any provision of this Public License is
+     deemed unenforceable, it shall be automatically reformed to the
+     minimum extent necessary to make it enforceable. If the provision
+     cannot be reformed, it shall be severed from this Public License
+     without affecting the enforceability of the remaining terms and
+     conditions.
+
+  c. No term or condition of this Public License will be waived and no
+     failure to comply consented to unless expressly agreed to by the
+     Licensor.
+
+  d. Nothing in this Public License constitutes or may be interpreted
+     as a limitation upon, or waiver of, any privileges and immunities
+     that apply to the Licensor or You, including from the legal
+     processes of any jurisdiction or authority.

README.md

@@ -4,16 +4,14 @@ This repository provides a curated collection of Salesforce agent skills for bui
 
 The skills are contributed by Salesforce and the broader community. It’s optimized for Agentforce Vibes and can be used with any AI tool that supports skills.
 
-> ⚠️ **Expect frequent changes.** The Salesforce skills library is evolving rapidly as we refine patterns and incorporate feedback. Skills may be renamed, restructured, or removed between releases — they do not follow the same stability guarantees as GA platform APIs. If you’ve forked or synced the repository, be prepared for upstream changes that may conflict with local modifications. This repository is always the source of truth.
-
 ## 🗂️ Structure
 
 ```
 sf-skills/
 ├── skills/               # Directory-based executable workflows
-│   ├── platform-apex-generate/
-│   ├── platform-custom-object-generate/
-│   ├── automation-flow-generate/
+│   ├── generating-apex/
+│   ├── generating-custom-object/
+│   ├── generating-flow/
 │   └── ...
 ├── samples/              # Synced sample apps (e.g. from npm)
 │   └── ui-bundle-template-app-react-sample-b2e/

manifest.json

@@ -0,0 +1,421 @@
+{
+  "version": 1,
+  "generatedAt": "2026-02-17T21:01:05.349Z",
+  "branch": "main",
+  "prompts": [
+    {
+      "name": "PricingService Invocable Scaffold",
+      "path": "prompts/apex-development/scaffold-invocable-apex.md",
+      "description": "Create a PricingService Apex class with an invocable getPricing method and typed inputs/outputs for Flow.",
+      "category": "apex-development",
+      "tags": [
+        "apex",
+        "invocable",
+        "flow",
+        "scaffold"
+      ]
+    },
+    {
+      "name": "Travel Plan Object Scaffold",
+      "path": "prompts/apex-development/scaffold-object.md",
+      "description": "Provision a Travel Plan custom object with fields, layout, tab, and permission set ready for deployment.",
+      "category": "apex-development",
+      "tags": [
+        "salesforce",
+        "custom-object",
+        "scaffold",
+        "deployment"
+      ]
+    },
+    {
+      "name": "Trigger Refactor Helper",
+      "path": "prompts/apex-development/trigger-refactoring.md",
+      "description": "Refactor the Opportunity trigger into a handler pattern with tests",
+      "category": "apex-development",
+      "tags": [
+        "apex",
+        "refactor",
+        "testing"
+      ]
+    },
+    {
+      "name": "Account Test Data Generator",
+      "path": "prompts/data-operations/create-fake-data.md",
+      "description": "Create an Apex script that generates 10 realistic Account records with complete business data including name, account number, type, industry, annual revenue, ticker symbol, and number of employees. Includes documentation on how to execute the script anonymously.",
+      "category": "data-operations",
+      "tags": [
+        "salesforce",
+        "apex",
+        "data-generation",
+        "test-data",
+        "developer",
+        "admin"
+      ]
+    },
+    {
+      "name": "Account Layout Field Enhancement",
+      "path": "prompts/getting-started/add-fields-pagelayout.md",
+      "description": "Add Type and Industry fields to the Account page layout for better data organization and reporting.",
+      "category": "getting-started",
+      "tags": [
+        "salesforce",
+        "account",
+        "page-layout",
+        "admin",
+        "data-management"
+      ]
+    },
+    {
+      "name": "Lead Source Picklist Enhancement",
+      "path": "prompts/getting-started/add-picklist-value.md",
+      "description": "Add a new 'Referral' value to the Lead Source picklist on the Lead object for better lead tracking.",
+      "category": "getting-started",
+      "tags": [
+        "salesforce",
+        "lead",
+        "picklist",
+        "data-management",
+        "admin"
+      ]
+    },
+    {
+      "name": "High Priority Case Assignment Rule",
+      "path": "prompts/getting-started/create-assignment-rules.md",
+      "description": "Create an assignment rule that automatically routes high priority Cases to a specific queue or user for immediate attention.",
+      "category": "getting-started",
+      "tags": [
+        "salesforce",
+        "case-management",
+        "assignment-rules",
+        "automation",
+        "admin"
+      ]
+    },
+    {
+      "name": "Project Object Quickstart",
+      "path": "prompts/getting-started/create-basic-custom-object.md",
+      "description": "Scaffold a Project__c custom object with core fields and deployable metadata.",
+      "category": "getting-started",
+      "tags": [
+        "salesforce",
+        "custom-object",
+        "beginner"
+      ]
+    },
+    {
+      "name": "Opportunity Days Open Formula",
+      "path": "prompts/getting-started/create-opp-formula.md",
+      "description": "Create a formula field on Opportunity that calculates the number of days since the record was created.",
+      "category": "getting-started",
+      "tags": [
+        "salesforce",
+        "opportunity",
+        "formula-field",
+        "automation",
+        "admin"
+      ]
+    },
+    {
+      "name": "Account Editor Permission Set",
+      "path": "prompts/getting-started/create-permission-set.md",
+      "description": "Create a permission set that grants edit access to Account records and assign it to the current user.",
+      "category": "getting-started",
+      "tags": [
+        "salesforce",
+        "permission-set",
+        "security",
+        "admin",
+        "user-management"
+      ]
+    },
+    {
+      "name": "Account Opportunity Count Roll-Up",
+      "path": "prompts/getting-started/create-rollup-summary.md",
+      "description": "Create a roll-up summary field on Account that counts related Opportunities for better relationship tracking.",
+      "category": "getting-started",
+      "tags": [
+        "salesforce",
+        "account",
+        "opportunity",
+        "rollup-summary",
+        "automation",
+        "admin"
+      ]
+    },
+    {
+      "name": "Hello World LWC Starter",
+      "path": "prompts/getting-started/first-lightning-web-component.md",
+      "description": "Generate a greeting Lightning Web Component and explain its HTML, JS, and metadata files.",
+      "category": "getting-started",
+      "tags": [
+        "lwc",
+        "ui",
+        "beginner"
+      ]
+    },
+    {
+      "name": "Opportunity Days Till Close Formula",
+      "path": "prompts/getting-started/formula-field-days-till-close.md",
+      "description": "Build an Opportunity formula that calculates days between CreatedDate and CloseDate.",
+      "category": "getting-started",
+      "tags": [
+        "formula",
+        "opportunity",
+        "admin"
+      ]
+    },
+    {
+      "name": "Opportunity Close Date Validation",
+      "path": "prompts/getting-started/opp-validation-rule.md",
+      "description": "Create a validation rule on Opportunity that prevents saving when the Close Date is in the past.",
+      "category": "getting-started",
+      "tags": [
+        "salesforce",
+        "opportunity",
+        "validation-rule",
+        "data-quality",
+        "admin"
+      ]
+    },
+    {
+      "name": "StringUtils Utility Scaffold",
+      "path": "prompts/getting-started/reusable-apex-string-utility-class.md",
+      "description": "Create a foundational StringUtils Apex helper with core string methods and unit tests.",
+      "category": "getting-started",
+      "tags": [
+        "apex",
+        "utility",
+        "testing"
+      ]
+    },
+    {
+      "name": "DateUtils Utility Primer",
+      "path": "prompts/getting-started/simple-apex-utility-class.md",
+      "description": "Generate a documented DateUtils Apex class with daysBetween and addDays helpers.",
+      "category": "getting-started",
+      "tags": [
+        "apex",
+        "utility",
+        "beginner"
+      ]
+    },
+    {
+      "name": "Opportunity Stage Score Formula",
+      "path": "prompts/getting-started/stage-based-opportunity-scoring-formula.md",
+      "description": "Craft a readable Opportunity formula that assigns numeric scores per stage.",
+      "category": "getting-started",
+      "tags": [
+        "formula",
+        "opportunity",
+        "admin"
+      ]
+    },
+    {
+      "name": "Test Data Factory Kickoff",
+      "path": "prompts/getting-started/test-data-factory-basics.md",
+      "description": "Build an Apex factory for Accounts, Contacts, and Opportunities with usage examples.",
+      "category": "getting-started",
+      "tags": [
+        "apex",
+        "testing",
+        "test-data"
+      ]
+    },
+    {
+      "name": "Account Trigger Starter",
+      "path": "prompts/getting-started/trigger-and-handler-example.md",
+      "description": "Create a simple Account trigger and handler that sets default values before insert.",
+      "category": "getting-started",
+      "tags": [
+        "apex",
+        "trigger",
+        "beginner"
+      ]
+    },
+    {
+      "name": "Account Employee Validation Rule",
+      "path": "prompts/getting-started/validation-rule-on-account.md",
+      "description": "Draft a rule that blocks Account save when NumberOfEmployees is blank.",
+      "category": "getting-started",
+      "tags": [
+        "validation-rule",
+        "account",
+        "admin"
+      ]
+    },
+    {
+      "name": "Opportunity Approval Investigation",
+      "path": "prompts/investigation-triage/fix-complex-approval-logic.md",
+      "description": "Diagnose inconsistent approval checkbox behavior on Opportunities and propose a remediation plan.",
+      "category": "investigation-triage",
+      "tags": [
+        "investigation",
+        "triage",
+        "opportunity",
+        "approval-process"
+      ]
+    },
+    {
+      "name": "Asset Tracker Spec Build",
+      "path": "prompts/spec-driven-dev/asset-tracker.md",
+      "description": "Gather requirements and deliver a full Asset tracker app via a spec-driven workflow.",
+      "category": "spec-driven-dev",
+      "tags": [
+        "spec-driven",
+        "lwc",
+        "custom-object",
+        "app"
+      ]
+    },
+    {
+      "name": "Apex Unit Test Generator",
+      "path": "prompts/testing-automation/create-unit-test.md",
+      "description": "Create a comprehensive test class for any Apex class with test data setup and result verification.",
+      "category": "testing-automation",
+      "tags": [
+        "salesforce",
+        "apex",
+        "testing",
+        "unit-test",
+        "automation",
+        "developer"
+      ]
+    },
+    {
+      "name": "Run All Apex Tests",
+      "path": "prompts/testing-automation/run-all-test.md",
+      "description": "Execute all Apex tests in the org and display a comprehensive summary including total tests run, number passed, and overall code coverage percentage.",
+      "category": "testing-automation",
+      "tags": [
+        "salesforce",
+        "apex",
+        "testing",
+        "automation",
+        "test-coverage"
+      ]
+    },
+    {
+      "name": "Compliment Mixer App",
+      "path": "prompts/vibe-coding/compliment-mixer.md",
+      "description": "Build a playful compliment generator with custom UI, persistence, and recent history.",
+      "category": "vibe-coding",
+      "tags": [
+        "vibe-coding",
+        "lwc",
+        "app",
+        "fun"
+      ]
+    }
+  ],
+  "rules": [
+    {
+      "name": "Apex Development Guardrails",
+      "path": "rules/apex-development/apex-requirements.md",
+      "description": "Enforce best practices for Apex architecture, performance, security, and testing.",
+      "category": "apex-development",
+      "tags": [
+        "apex",
+        "rules",
+        "guardrails",
+        "testing",
+        "security"
+      ]
+    },
+    {
+      "name": "LWC Development Guardrails",
+      "path": "rules/lwc-development/lwc-requirements.md",
+      "description": "Standardize Lightning Web Component architecture, UX, and tooling practices.",
+      "category": "lwc-development",
+      "tags": [
+        "lwc",
+        "rules",
+        "ux",
+        "architecture"
+      ]
+    },
+    {
+      "name": "Spec-Driven App Development Standards",
+      "path": "rules/spec-driven-dev/app-dev.md",
+      "description": "Apply architecture, integration, and governance requirements for specification-led Salesforce builds.",
+      "category": "spec-driven-dev",
+      "tags": [
+        "spec-driven",
+        "architecture",
+        "governance",
+        "rules"
+      ]
+    }
+  ],
+  "skills": [
+    {
+      "name": "apex-class",
+      "path": "skills/apex-development/apex-class/SKILL.md",
+      "folderPath": "skills/apex-development/apex-class",
+      "category": "apex-development",
+      "files": [
+        "SKILL.md",
+        "examples/AccountDeduplicationBatch.cls",
+        "examples/AccountSelector.cls",
+        "examples/AccountService.cls",
+        "templates/abstract.cls",
+        "templates/batch.cls",
+        "templates/domain.cls",
+        "templates/dto.cls",
+        "templates/exception.cls",
+        "templates/interface.cls",
+        "templates/queueable.cls",
+        "templates/schedulable.cls",
+        "templates/selector.cls",
+        "templates/service.cls",
+        "templates/utility.cls"
+      ],
+      "description": "Generate production-ready Apex classes for Salesforce following enterprise best practices. Covers service classes, selectors, domain classes, batch/queueable/schedulable, DTOs, utilities, interfaces, abstract classes, and custom exceptions. Not for triggers or unit tests."
+    },
+    {
+      "name": "trigger-refactor-pipeline",
+      "path": "skills/apex-development/trigger-refactor-pipeline/SKILL.md",
+      "folderPath": "skills/apex-development/trigger-refactor-pipeline",
+      "category": "apex-development",
+      "files": [
+        "SKILL.md",
+        "assets/test_template.apex",
+        "references/handler_patterns.md",
+        "scripts/analyze_trigger.py"
+      ],
+      "description": "Refactor Salesforce triggers into handler patterns with automated test generation and deployment. Use when modernizing legacy triggers with DML/SOQL in loops or inconsistent patterns.",
+      "license": "Apache-2.0",
+      "compatibility": "Requires Salesforce CLI, Python 3.9+",
+      "allowedTools": "Bash Read Write"
+    },
+    {
+      "name": "deployment-readiness-check",
+      "path": "skills/metadata-deployments/deployment-readiness-check/SKILL.md",
+      "folderPath": "skills/metadata-deployments/deployment-readiness-check",
+      "category": "metadata-deployments",
+      "files": [
+        "SKILL.md",
+        "assets/deployment_checklist.md",
+        "references/rollback_procedures.md",
+        "scripts/check_metadata.sh"
+      ],
+      "description": "Comprehensive pre-deployment validation checklist for Salesforce releases. Use before deploying to production to catch metadata issues, test coverage gaps, and configuration errors.",
+      "license": "Apache-2.0",
+      "compatibility": "Requires Salesforce CLI, jq, bash",
+      "allowedTools": "Bash Read"
+    },
+    {
+      "name": "apex-test-class",
+      "path": "skills/testing-automation/apex-test-class/SKILL.md",
+      "folderPath": "skills/testing-automation/apex-test-class",
+      "category": "testing-automation",
+      "files": [
+        "SKILL.md",
+        "references/assertion-patterns.md",
+        "references/async-testing.md",
+        "references/mocking-patterns.md",
+        "references/test-data-factory.md"
+      ],
+      "description": "Apex test class generation with TestDataFactory patterns, bulk testing (200+ records), mocking strategies for callouts and async operations, and assertion best practices. Use when creating new Apex test classes, improving test coverage, refactoring existing tests, or implementing proper testing patterns for triggers, services, controllers, batch jobs, queueables, and integrations."
+    }
+  ]
+}

package.json

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

samples/ui-bundle-template-app-react-sample-b2e/AGENT.md

@@ -146,7 +146,7 @@ Do not consider a task complete until all three steps have been run successfully
 
 ### Data access (Salesforce)
 
-**Before writing any code that connects to Salesforce, you MUST invoke the `experience-ui-bundle-salesforce-data-access` skill. Do not write any data access code without consulting it first.**
+**Before writing any code that connects to Salesforce, you MUST invoke the `using-ui-bundle-salesforce-data` skill. Do not write any data access code without consulting it first.**
 
 This applies to: GraphQL queries/mutations, REST calls, SDK initialization, custom hooks that fetch data, or any code that imports from `@salesforce/platform-sdk`.
 

samples/ui-bundle-template-app-react-sample-b2x/AGENT.md

@@ -146,7 +146,7 @@ Do not consider a task complete until all three steps have been run successfully
 
 ### Data access (Salesforce)
 
-**Before writing any code that connects to Salesforce, you MUST invoke the `experience-ui-bundle-salesforce-data-access` skill. Do not write any data access code without consulting it first.**
+**Before writing any code that connects to Salesforce, you MUST invoke the `using-ui-bundle-salesforce-data` skill. Do not write any data access code without consulting it first.**
 
 This applies to: GraphQL queries/mutations, REST calls, SDK initialization, custom hooks that fetch data, or any code that imports from `@salesforce/platform-sdk`.
 

scripts/validate-skills.ts

@@ -420,8 +420,7 @@ Wrap values that contain \`: \` (colon + space), such as long descriptions with
 /**
  * Extracts nested key-value pairs from the `metadata:` block in raw frontmatter.
  * Returns `null` if no metadata block, `"scalar"` if metadata has an inline value,
- * `"list"` if direct children are YAML list items, or a `Record` of sub-keys.
- * Nested lists under sub-keys (e.g. cliTools: [{tool:"sf"}]) are allowed.
+ * `"list"` if it contains YAML list items, or a `Record` of sub-keys.
  */
 function parseMetadataBlock(rawFrontmatter: string): Record<string, string> | "scalar" | "list" | null {
   const lines = rawFrontmatter.split(/\r?\n/)
@@ -432,16 +431,12 @@ function parseMetadataBlock(rawFrontmatter: string): Record<string, string> | "s
   const inlineValue = metaLine.slice(metaLine.indexOf(":") + 1).trim()
   if (inlineValue && !inlineValue.startsWith("#")) return "scalar"
 
-  let directIndent: number | null = null
   const result: Record<string, string> = {}
   for (let i = metaIdx + 1; i < lines.length; i++) {
     const line = lines[i]
     if (!line.startsWith(" ") && !line.startsWith("\t")) break
-    const indent = line.length - line.trimStart().length
-    if (directIndent === null) directIndent = indent
     const trimmed = line.trim()
-    if (indent === directIndent && trimmed.startsWith("- ")) return "list"
-    if (indent !== directIndent) continue
+    if (trimmed.startsWith("- ")) return "list"
     const colonIdx = trimmed.indexOf(":")
     if (colonIdx === -1) continue
     const key = trimmed.slice(0, colonIdx).trim()

skills/activating-datacloud/CREDITS.md

@@ -0,0 +1,5 @@
+# Credits & Acknowledgments
+
+This skill is part of the `*-datacloud` family. Shared attribution, upstream source mapping, and maintenance notes live in:
+- [../orchestrating-datacloud/CREDITS.md](../orchestrating-datacloud/CREDITS.md)
+- [../orchestrating-datacloud/UPSTREAM.md](../orchestrating-datacloud/UPSTREAM.md)

skills/activating-datacloud/README.md

@@ -0,0 +1,39 @@
+# activating-datacloud
+
+Activation and downstream delivery workflows for Salesforce Data Cloud.
+
+## Use this skill for
+
+- activations
+- activation targets
+- data actions
+- data action targets
+- downstream platform inspection before push
+
+## Example requests
+
+```text
+"Activate this segment to the downstream platform"
+"Show me what activation targets already exist"
+"Create a data action target for this integration"
+"Help me inspect why this activation is not ready"
+```
+
+## Common commands
+
+```bash
+sf data360 activation platforms -o myorg 2>/dev/null
+sf data360 activation-target list -o myorg 2>/dev/null
+sf data360 activation list -o myorg 2>/dev/null
+sf data360 data-action-target list -o myorg 2>/dev/null
+```
+
+## References
+
+- [SKILL.md](SKILL.md)
+- [../orchestrating-datacloud/assets/definitions/activation-target.template.json](../orchestrating-datacloud/assets/definitions/activation-target.template.json)
+- [../orchestrating-datacloud/assets/definitions/activation.template.json](../orchestrating-datacloud/assets/definitions/activation.template.json)
+- [../orchestrating-datacloud/assets/definitions/data-action-target.template.json](../orchestrating-datacloud/assets/definitions/data-action-target.template.json)
+- [../orchestrating-datacloud/assets/definitions/data-action.template.json](../orchestrating-datacloud/assets/definitions/data-action.template.json)
+- [../orchestrating-datacloud/references/plugin-setup.md](../orchestrating-datacloud/references/plugin-setup.md)
+- [CREDITS.md](CREDITS.md)

skills/activating-datacloud/SKILL.md

@@ -1,18 +1,18 @@
 ---
-name: data360-activate
-description: "Salesforce Data Cloud Act phase. Use this skill when the user manages activations, activation targets, data actions, or downstream delivery of Data Cloud audiences and data. TRIGGER when: user manages activations, activation targets, data actions, or downstream delivery of Data Cloud audiences and data. DO NOT TRIGGER when: the task is segment creation (use data360-segment), data retrieval/search work (use data360-query), or STDM/session tracing (use agentforce-observe)."
+name: activating-datacloud
+description: "Salesforce Data Cloud Act phase. Use this skill when the user manages activations, activation targets, data actions, or downstream delivery of Data Cloud audiences and data. TRIGGER when: user manages activations, activation targets, data actions, or downstream delivery of Data Cloud audiences and data. DO NOT TRIGGER when: the task is segment creation (use segmenting-datacloud), data retrieval/search work (use retrieving-datacloud), or STDM/session tracing (use observing-agentforce)."
 compatibility: "Requires an external community sf data360 CLI plugin and a Data Cloud-enabled org"
 metadata:
   version: "1.0"
 ---
 
-# data360-activate: Data Cloud Act Phase
+# activating-datacloud: Data Cloud Act Phase
 
 Use this skill when the user needs **downstream delivery work**: activations, activation targets, data actions, or pushing Data Cloud outputs into other systems.
 
 ## When This Skill Owns the Task
 
-Use `data360-activate` when the work involves:
+Use `activating-datacloud` when the work involves:
 - `sf data360 activation *`
 - `sf data360 activation-target *`
 - `sf data360 data-action *`
@@ -20,9 +20,9 @@ Use `data360-activate` when the work involves:
 - verifying downstream delivery setup
 
 Delegate elsewhere when the user is:
-- still building the audience or insight → [data360-segment](../data360-segment/SKILL.md)
-- exploring query/search or search indexes → [data360-query](../data360-query/SKILL.md)
-- setting up base connections or ingestion → [data360-connect](../data360-connect/SKILL.md), [data360-prepare](../data360-prepare/SKILL.md)
+- still building the audience or insight → [segmenting-datacloud](../segmenting-datacloud/SKILL.md)
+- exploring query/search or search indexes → [retrieving-datacloud](../retrieving-datacloud/SKILL.md)
+- setting up base connections or ingestion → [connecting-datacloud](../connecting-datacloud/SKILL.md), [preparing-datacloud](../preparing-datacloud/SKILL.md)
 
 ---
 
@@ -40,7 +40,7 @@ Ask for or infer:
 ## Core Operating Rules
 
 - Verify the upstream segment or insight is healthy before creating downstream delivery assets.
-- Run the shared readiness classifier before mutating activation assets: `node ../data360-orchestrate/scripts/diagnose-org.mjs -o <org> --phase act --json`.
+- Run the shared readiness classifier before mutating activation assets: `node ../orchestrating-datacloud/scripts/diagnose-org.mjs -o <org> --phase act --json`.
 - Inspect available platforms and targets before mutating activation setup.
 - Keep destination definitions deterministic and reusable where possible.
 - Treat downstream credential and platform constraints as separate validation concerns.
@@ -52,7 +52,7 @@ Ask for or infer:
 
 ### 1. Classify readiness for act work
 ```bash
-node ../data360-orchestrate/scripts/diagnose-org.mjs -o <org> --phase act --json
+node ../orchestrating-datacloud/scripts/diagnose-org.mjs -o <org> --phase act --json
 ```
 
 ### 2. Inspect destinations first
@@ -107,9 +107,11 @@ Next step: <destination validation or downstream testing>
 
 ## References
 
-- [../data360-orchestrate/assets/definitions/activation-target.template.json](../data360-orchestrate/assets/definitions/activation-target.template.json)
-- [../data360-orchestrate/assets/definitions/activation.template.json](../data360-orchestrate/assets/definitions/activation.template.json)
-- [../data360-orchestrate/assets/definitions/data-action-target.template.json](../data360-orchestrate/assets/definitions/data-action-target.template.json)
-- [../data360-orchestrate/assets/definitions/data-action.template.json](../data360-orchestrate/assets/definitions/data-action.template.json)
-- [../data360-orchestrate/references/plugin-setup.md](../data360-orchestrate/references/plugin-setup.md)
-- [../data360-orchestrate/references/feature-readiness.md](../data360-orchestrate/references/feature-readiness.md)
+- [README.md](README.md)
+- [../orchestrating-datacloud/assets/definitions/activation-target.template.json](../orchestrating-datacloud/assets/definitions/activation-target.template.json)
+- [../orchestrating-datacloud/assets/definitions/activation.template.json](../orchestrating-datacloud/assets/definitions/activation.template.json)
+- [../orchestrating-datacloud/assets/definitions/data-action-target.template.json](../orchestrating-datacloud/assets/definitions/data-action-target.template.json)
+- [../orchestrating-datacloud/assets/definitions/data-action.template.json](../orchestrating-datacloud/assets/definitions/data-action.template.json)
+- [../orchestrating-datacloud/UPSTREAM.md](../orchestrating-datacloud/UPSTREAM.md)
+- [../orchestrating-datacloud/references/plugin-setup.md](../orchestrating-datacloud/references/plugin-setup.md)
+- [../orchestrating-datacloud/references/feature-readiness.md](../orchestrating-datacloud/references/feature-readiness.md)

skills/agentforce-bot-upgrade/SKILL.md

@@ -1,217 +0,0 @@
----
-name: agentforce-bot-upgrade
-description: "Use this skill to Upgrade Einstein Bots into Agentforce agents end-to-end in a single pass, orchestrating per-bot Agent Spec generation, planner reconciliation across bots, agentforce-generate authoring, and post-conversion .agent enhancements. TRIGGER when: user asks to migrate, upgrade, or convert one or more Einstein Bots to Agentforce; runs a multi-bot bot-to-agent upgrade; needs Einstein Bot metadata turned into Agent Spec handoffs and generated .agent agents; convert bots to agents; upgrade my service bots; move bots to Agentforce. DO NOT TRIGGER when: user already has an approved Agent Spec and only wants direct .agent authoring, deploy, test, or observe flows; the request is unrelated to Einstein Bot migration."
-argument-hint: "[--mode <online|offline>] [--org-alias <org-alias> --bots <bot1:v1,bot2:v2,...> | --offline-dir <offline-dir> [--bots <bot1,bot2,...>]] [--interactive <true|false>]"
-metadata:
-  version: "1.0"
-  minApiVersion: "63.0"
-  relatedSkills:
-    - "agentforce-generate"
-    - "agentforce-test"
-    - "agentforce-observe"
-  cliTools:
-    - tool: ["sf"]
-      semver: ">=2.0.0"
----
-
-# Einstein Bot Upgrade Orchestrator
-
-## Purpose
-
-Run a multi-bot upgrade-and-handoff cycle:
-
-1. Parse and validate bot/version pairs from `--bots`
-2. Follow [Generate Agent Spec Reference](references/generate-agent-spec.md) per bot-version pair (parallelizable)
-3. Aggregation step that requires all generated Agent Specs
-4. `/agentforce-generate` per Agent Spec (parallelizable)
-5. Post-conversion enhancement pass per generated Agent Script (parallelizable)
-
-## Inputs
-
-Inputs:
-- `--mode <online|offline>` is optional; default is `online` when omitted.
-- If `mode=online`, required:
-  - `--org-alias <org-alias>`
-  - `--bots <bot1:v1,bot2:v2,...>`
-- If `mode=offline`, required:
-  - `--offline-dir <offline-dir>`
-- `--interactive <true|false>` is optional; default is `true` when omitted.
-
-If required inputs are missing, handle per the Missing Input Handling and Interactive Mode rules below.
-
-## Interactive Mode
-
-`--interactive` controls whether the skill pauses for user input during execution:
-
-- `--interactive true` (default): resolve ambiguities, open questions, and approval gates by asking the user, as described in this skill and its references.
-- `--interactive false`: run autonomously. Do NOT prompt the user at any decision point. For every open question, ambiguity, or approval gate, apply the documented recommended default/solution and record the auto-applied decision in the run artifacts (Agent Spec, open questions, extraction summary). The only hard stops permitted without prompting are inputs that are missing or contradictory with no safe recommended default — a missing mandatory launch input (`--org-alias`/`--bots` for online, `--offline-dir` for offline), no bots discovered, or the same bot given multiple versions. In those cases, report the issue and halt without prompting.
-
-Propagate the effective `--interactive` value to the per-bot Generate Agent Spec workflow (Step 2), the planner workflow (Step 3), and the post-conversion enhancement pass (Step 5).
-
-## Missing Input Handling
-
-Resolve missing required launch inputs before Step 1:
-
-1. **Online mode — `--org-alias` not provided.** Resolve this before attempting to list bots (listing requires a target org).
-   - Interactive: list the available aliases of logged-in orgs and ask the user to select the target org. Use the SF CLI patterns in [SF CLI Bot Reference](references/sf-cli-bot-reference.md).
-   - Non-interactive: halt with an explicit error naming the missing `--org-alias` input (do not prompt or list).
-2. **Online mode — bot name and version (`--bots`) not available.**
-   - Interactive: using `--org-alias` as the target org, list every bot and its versions in the org, then ask the user to select the bot/version entries they want to convert to agents. Use the `BotDefinition` and `BotVersion` query patterns in [SF CLI Bot Reference](references/sf-cli-bot-reference.md) — omit the name/version filters to enumerate all bots and versions — present the results, and build the `--bots` workload from the user's selection.
-   - Non-interactive: halt with an explicit error naming the missing `--bots` input (do not prompt or list).
-3. **Offline mode — `--offline-dir` not available.**
-   - Interactive: ask the user to provide the `--offline-dir` path, then continue.
-   - Non-interactive: fail with an explicit error naming the missing `--offline-dir` input (do not prompt).
-
-## References
-
-Use these reference files during execution:
-
-1. [SF CLI Bot Reference](references/sf-cli-bot-reference.md)
-2. [Generate Agent Spec Reference](references/generate-agent-spec.md)
-3. [Planner Workflow Reference](references/planner-workflow-reference.md)
-4. [Post-Conversion Enhancements Reference](references/post-conversion-enhancements-reference.md)
-5. [Extraction Blueprint](references/extraction-blueprint.md)
-6. [Input Contract](references/input-contract.md)
-7. [Mapping Rules](references/mapping-rules.md)
-8. [Handoff Output Format](references/handoff-output-format.md)
-9. [Quality Checklist](references/quality-checklist.md)
-
-## Execution Contract
-
-### Step 1: Parse and Validate `--bots`
-
-Execute Step 1 in this order:
-
-1. Resolve mode:
-   - If `--mode` omitted, use `online`.
-2. Start fresh for this invocation:
-   - do not discover, inspect, or reuse outputs from previously existing runs
-   - treat this invocation as a clean execution context
-   - only use artifacts produced during the current invocation flow
-3. Build initial workload list:
-   - `mode=online`: read `--bots` and split by comma.
-   - `mode=offline`: scan `<offline-dir>` and collect immediate sub-directories as bot workload roots.
-4. Validate input shape:
-   - `mode=online`: each `--bots` token must match `<bot-name>:<version>`.
-   - `mode=offline`: ensure at least one bot sub-directory exists; otherwise STOP (in interactive mode ask the user to clarify; in non-interactive mode halt with an explicit error per the Interactive Mode rule).
-5. Normalize workload entries:
-   - `mode=online`: build `{bot_name, bot_version}` entries.
-   - `mode=offline`: build `{offline_bot_dir}` entries (Annotate inferred bot name and version when derivable from the sub-directory structure; if not derivable, leave the entry unnamed and continue).
-6. Enforce one-version-per-bot rule (online mode):
-   - If the same `bot_name` appears with multiple versions, STOP (in interactive mode ask the user to clarify; in non-interactive mode halt with an explicit error per the Interactive Mode rule).
-7. Apply offline bot filter:
-   - If `mode=offline` and `--bots` is provided, use `--bots` only as a filter over discovered sub-directories; do not treat it as required offline input.
-8. Persist Step 1 output:
-   - Save and carry forward a validated workload list for Step 2 parallel execution.
-
-### Step 2: Run Einstein Bot Upgrade (Per Bot-Version)
-
-Execute the agent spec generation workflow from [Generate Agent Spec Reference](references/generate-agent-spec.md) per bot-version combination:
-- `--mode <online|offline>` (default `online` if omitted)
-- mode-specific required inputs:
-  - online -> `--org-alias`, `--bot`, `--bot-version`
-  - offline -> `--offline-dir`
-- `--interactive <true|false>` (pass through the effective orchestrator value; default `true`)
-
-Parallelization rule:
-- In `mode=online`, execute invocations in parallel because each bot-version pair is independent.
-- In `mode=offline`, execute the [Generate Agent Spec Reference](references/generate-agent-spec.md) workflow in parallel over every bot sub-directory discovered in Step 1.
-  - Pass `--mode offline` and `--offline-dir <bot-subdirectory-path>` per invocation.
-Ensure each invocation (online/offline) uses isolated working directories to avoid cross-run file collisions.
-
-Hard rules:
-- Do not skip this step.
-
-### Step 3: Aggregation + Planner Step (Conditional)
-
-After all upgrade invocations complete:
-
-1. Always build a consolidated list of `{bot_name, bot_version, run_project_dir, agent_spec_path}`.
-2. Always build list of failed/incomplete upgrade runs (if any).
-3. Always build an initial ready-for-authoring list containing only valid Agent Spec entries.
-   - Each entry must include: `{bot_name, bot_version, run_project_dir, agent_spec_path, handoff_json_path, open_questions_path}`.
-4. If total bot workload count is greater than 1:
-   - Execute planner workflow from [Planner Workflow Reference](references/planner-workflow-reference.md) using:
-     - all ready-for-authoring `agent_spec_path` values as `spec_paths`
-     - orchestrator working directory as `working_dir`
-     - the associated per-spec artifacts from each ready-for-authoring entry: `handoff_json_path` (handoff JSON) and `open_questions_path` (open questions)
-   - Require output file at `<orchestrator working directory>/bot-upgrade-planner-output.json`.
-   - Read `bot-upgrade-planner-output.json` and apply:
-     - if `specs_changed=true`: replace ready-for-authoring entries using planner fields (`updated_spec_path`, `run_project_dir`, `handoff_json_path`, `open_questions_path`)
-     - if `specs_changed=false`: keep original ready-for-authoring list unchanged
-5. If total bot workload count is 1:
-   - Skip planner workflow entirely.
-   - Keep original ready-for-authoring list unchanged.
-
-Planner output expectations:
-1. boolean `specs_changed`
-2. `updated_specs` array with entries:
-   - `original_spec_path`
-   - `updated_spec_path`
-   - `run_project_dir`
-   - `handoff_json_path`
-   - `open_questions_path`
-3. `updated_specs` must be empty when `specs_changed=false`
-
-### Step 4: Invoke Agentforce-Generate (Per Agent Spec)
-
-For each entry in final ready-for-authoring list (post Step 3 planner reconciliation):
-
-0. Add this recommendation to the generated invocation context before calling `/agentforce-generate`:
-   - Do **not activate** Agent Script versions in this orchestrated run.
-   - Draft iteration is required: generating `.agent`, validating, deploying, and preview testing are allowed.
-   - Activate should be deferred unless the user explicitly asks for release.
-1. Resolve effective `run_project_dir` from the final ready-for-authoring entry.
-2. Read `<run_project_dir>/agentforce-generate-invocation-prompt.md` fully.
-3. If Step 3 produced planner-updated spec paths/artifacts, apply path substitutions in the invocation context so spec/handoff/open-questions references point to updated files.
-   - If planner also changed `run_project_dir`, use that updated `run_project_dir` for resolving prompt/output-contract paths.
-4. Keep all non-path instructions unchanged from the original generated prompt.
-5. Invoke `/agentforce-generate` with this resolved invocation context.
-6. Read `<run_project_dir>/agentforce-generate-output-contract.md` and capture outputs exactly as specified.
-
-Parallelization rule:
-- Invoke `/agentforce-generate` in parallel across Agent Specs because each run is independent.
-
-Output-contract capture rules:
-
-1. Treat the output contract as authoritative for required fields/artifacts.
-2. If any contract field is missing, mark status as partial and list missing fields explicitly.
-3. Return captured outputs with deterministic keys matching the contract names.
-4. Preserve output file paths and status of each required artifact.
-5. If expected prompt/contract files are missing for an entry, mark that entry `partial`, record missing paths, and continue processing other entries.
-
-### Step 5: Post-Conversion Agent Script Enhancements (Per Generated Agent Script)
-
-After Step 4 completes, for each generated `.agent` artifact:
-
-1. Resolve the generated `.agent` file path from captured `/agentforce-generate` outputs.
-2. Execute post-conversion enhancement workflow from [Post-Conversion Enhancements Reference](references/post-conversion-enhancements-reference.md) with:
-   - `agentscript_file=<generated-agent-file-path>`
-   - `mode=<online|offline>` (the effective orchestrator run mode resolved in Step 1)
-   - online mode only: `org_alias=<org-alias>` (required so the enhanced Agent Script can be redeployed)
-3. Require in-place enhancement:
-   - optimized/enhanced output must be written to the same `.agent` file location.
-4. Capture per-file enhancement status and any partial failures.
-
-Parallelization rule:
-- Execute post-conversion enhancement workflow in parallel across generated `.agent` files because each file enhancement is independent.
-
-### Step 6: Consolidate Run Report and Conclude
-
-After Step 5 completes for every bot in the workload:
-
-1. Write a single consolidated, human-readable run report as a non-empty Markdown file in the orchestrator working directory. Per bot, the report must state: the effective run mode, whether the planner ran (`executed` or `skipped`), the generated Agent Spec path and generated `.agent` path, the action inventory (including any `NEEDS_STUB` items), and — when `--interactive=false` — the auto-applied decisions.
-2. Treat the run report as the FINAL artifact: write it only after all other artifacts (Agent Spec(s), handoff JSON, open questions, any planner output, and generated `.agent` file(s)) are already written.
-
-## Deliverable
-
-Return:
-1. parsed bot/version list
-2. per-bot upgrade execution status
-3. aggregation output (full Agent Spec list + final ready-for-authoring subset)
-4. planner workflow status (`executed` or `skipped`) and `bot-upgrade-planner-output.json` path when executed
-5. per-spec `/agentforce-generate` execution status
-6. generated handoff artifact paths per bot/spec (including planner-updated artifacts when applicable)
-7. captured `/agentforce-generate` outputs per output contract
-8. per-agent post-conversion enhancement status (including enhanced `.agent` file paths)
-9. path to the consolidated run report written in Step 6

skills/agentforce-bot-upgrade/references/extraction-blueprint.md

@@ -1,242 +0,0 @@
-# Extraction Blueprint
-
-## Goal
-
-Extract only migration-relevant behavior from Einstein Bot and discard transport noise.
-
-## Required Extractions
-
-### 1) Dialog Graph
-
-**Input files:**
-
-Paths below are shown relative to the bots root directory. For org-backed retrieval this root is the SFDX default metadata directory `force-app/main/default/` (so the full path is `force-app/main/default/bots/<BotName>/…`, as retrieved in [SF CLI Bot Reference](sf-cli-bot-reference.md) section 3). For offline input this root is the provided `--offline-dir` (e.g. `bots/`).
-
-- `bots/<BotName>/<BotName>.bot-meta.xml` (bot-level metadata)
-- `bots/<BotName>/<version>.botVersion-meta.xml` (dialog + step graph source of truth)
-
-**Build the graph with this process:**
-
-1. Parse every `<botDialogs>` block in `<version>.botVersion-meta.xml` as one node.
-2. For each node, capture:
-   - `developerName` (node id)
-   - `label`
-   - `mlIntent` (if present)
-   - `dialogGroup` / grouping metadata if present
-3. Treat each `<botSteps>` entry inside a dialog as a step in execution order.
-4. While scanning each step, also detect action invocations and variable mappings from bot steps:
-   - invocation/action step types (for example `Invocation`)
-   - action identifier/name and invocation type (`apex`, `flow`, `standardInvocableAction`, etc.)
-   - variables read by the action (bot variables passed as invocation inputs)
-   - variables updated by the action (bot variables set from invocation outputs)
-   - escalation actions from system messages:
-     - if a dialog contains `conversationSystemMessage` of type `Transfer`, add an action entry with `action_type: "escalate"`
-     - determine escalation target type (`queue`, `flow`, `bot`, or `skill`) by reading `systemMessageMappings` under that `conversationSystemMessage` and resolving referenced variables against declarations in `<conversationVariables>`
-     - store both the resolved `target_type` and mapped target identifier/value on the action record
-   - persist this as `invoked_actions` on the dialog node and as action-level records in `action_inventory`
-5. While scanning each step, detect transition-producing step types:
-   - `Navigation` with `<botNavigationLinks>`
-   - `Group` containing nested `Navigation`
-   - `Wait` type steps, which define intent-driven routing points (intent redirect behavior)
-6. For every discovered transition, add one directed edge:
-   - `source_dialog` -> `targetBotDialog`
-   - `type` (`redirect`, `call`, `intent_redirect`)
-7. Capture conditions from enclosing step/group when present:
-   - `leftOperandName`
-   - `operatorType`
-   - `rightOperandValue`
-   - store as a normalized condition expression on the edge
-8. Mark graph role hints:
-   - probable entry dialogs (for example `Welcome`, `Main_Menu`, or system entry mapping)
-   - terminal dialogs (for example paths ending in `SystemMessage` + `EndChat`, with no outbound navigation)
-
-**Required output for dialog graph extraction:**
-
-```json
-{
-  "nodes": [
-    {
-      "dialog": "Main_Menu",
-      "label": "Main Menu",
-      "intent": "Main_Menu",
-      "invoked_actions": [
-        {
-          "action_name": "Airline_Get_User_Details",
-          "action_type": "flow",
-          "variables_read": ["user_email"],
-          "variables_written": ["airline_user", "is_success"]
-        }
-      ]
-    }
-  ],
-  "edges": [
-    {
-      "source": "Main_Menu",
-      "target": "Bookings_Menu",
-      "type": "redirect",
-      "condition": null
-    }
-  ]
-}
-```
-
-**Quality checks:**
-
-- Every `targetBotDialog` in edges must resolve to an existing dialog node.
-- Keep `Call` and `Redirect` distinct (do not merge semantics).
-- Preserve multiple outgoing edges from the same step when configured.
-
-### 2) Intent Layer
-
-- Intent name/developer name
-- Intent description
-- Linked dialogs
-- Intent examples/utterances (if available)
-
-**Intent summarization workflow:**
-
-1. For each dialog node in the dialog graph, read its `mlIntent` value (if present).
-2. Treat that `mlIntent` as the lookup key for intent metadata in `MlDomain` with the same name.
-3. From the matched intent metadata, extract:
-   - `developerName`
-   - `label` / `description` (if present)
-   - `mlIntentUtterances` (training utterances)
-4. Generate a concise intent summary (2-3 sentences) per unique intent:
-   - sentence 1: user goal the intent represents
-   - sentence 2: typical phrasing style inferred from `mlIntentUtterances`
-   - sentence 3 (optional): routing nuance or disambiguation hint if overlapping with other intents
-5. If an `mlIntent` is referenced by a dialog but no matching `MlDomain` intent is found:
-   - flag the intent as unresolved
-   - add it to `open_questions`
-   - still generate a provisional summary from dialog label/description with `confidence: low`
-
-### 3) Variable and Entity Layer
-
-**Input files:**
-
-- `bots/<BotName>/<BotName>.bot-meta.xml` (context variables, slot/entity metadata)
-- `bots/<BotName>/<version>.botVersion-meta.xml` (conversation variable usage through steps)
-
-**Variable extraction and typing rules:**
-
-1. Extract context variables from `bot-meta.xml` (`<contextVariables>` entries).
-2. Mark every context variable as:
-   - `variable_type: linked`
-   - `data_type`: map from bot metadata `dataType`
-   - `source`: derive from context mappings (`SObjectType` + `fieldName`) when present
-3. Extract conversation variables directly from `botVersion-meta.xml` `<conversationVariables>` entries (authoritative source for declared conversation variables).
-4. Mark every conversation variable as:
-   - `variable_type: mutable`
-   - `data_type`: read directly from the variable's declared data type in `<conversationVariables>`
-
-**Required output shape (variables):**
-
-```json
-{
-  "variables": [
-    {
-      "name": "ContactId",
-      "data_type": "Id",
-      "variable_type": "linked",
-      "source": "MessagingEndUser.ContactId"
-    },
-    {
-      "name": "Complaint_Id",
-      "data_type": "Text",
-      "variable_type": "mutable"
-    }
-  ]
-}
-```
-
-### 4) Action/Invocation Layer
-
-- Action name and invocation type (`apex`, `flow`, etc.)
-- Inputs, outputs, and variable mappings
-- Also extract knowledge-backed action signals from `botVersion-meta.xml`:
-  1. If `knowledgeActionEnabled` is `true`:
-     - add an action entry with `action_type: "knowledge"`
-     - include `knowledgeActionEnabled: true`
-  2. If `knowledgeFallbackEnabled` is `true`:
-     - add an action entry with `action_type: "knowledge"`
-     - include `knowledgeFallbackEnabled: true`
-- When both fields are `true`, capture both flags (either on one combined knowledge action record or two explicit knowledge action records), but ensure both booleans are present in extracted output.
-
-**Offline mode signature generation (required):**
-
-When input mode is offline (`.bot-meta.xml` + `.botVersion-meta.xml` provided, no org fetch):
-
-1. Generate action signatures from bot metadata mappings only (do not block on missing Apex/Flow source code).
-2. For each invocation mapping:
-   - extract action parameter names from invocation input/output mapping keys
-   - resolve mapped bot variable names from mapping values
-   - infer parameter types from mapped variable declarations in `<conversationVariables>` / `<contextVariables>` when available
-3. If type cannot be inferred, use a conservative placeholder type (`Text` or `Object`) and flag in notes/open questions.
-4. Keep unresolved/partial signatures as non-blocking and continue extraction.
-
-**Signature construction rules:**
-
-1. Do not copy bot variable names as action parameter names unless metadata explicitly uses the same name.
-2. Preserve both layers in output:
-   - contract layer: `input_name` / `output_name`, `type`
-   - mapping layer: `mapped_variable`, `variable_type` (`mutable` or `linked`)
-3. For each signature entry, capture direction explicitly:
-   - `direction: input` for values read by the action
-   - `direction: output` for values written by the action
-4. If one action is invoked multiple times with different mappings, keep one action signature and record per-call mapping context separately (for example `call_context`).
-
-### 5) Dialog Clusters and Categorization
-
-After extracting actions and dialog/action mappings, categorize bot functionality into dialog clusters.
-
-1. Classify actions into groups using these priority criteria (highest priority first):
-   - actions working on the same underlying entity SHOULD be grouped together
-   - actions writing/updating the same variable SHOULD be grouped together
-   - actions reading the same input variable CAN be grouped together
-   - actions invoked by dialogs in the same dialog group CAN be grouped together
-   - actions with similar intent CAN be grouped together
-2. Keep group size between:
-   - minimum: 1 action
-   - maximum: 4 actions
-   If a group exceeds 4 actions, split it while preserving higher-priority criteria.
-3. An action may belong to multiple groups when criteria requires an overlap.
-4. Assign dialogs to groups based on associated actions:
-   - for each grouped action, trace back dialogs that invoke it
-   - include those dialogs in the corresponding dialog cluster
-   - maintain an `action_dialog_mapping` for each group (`action -> [dialogs]`)
-5. Generate a short functional description (2-3 sentences) per group using grouped actions and associated dialogs.
-
-## Extraction Output Shape
-
-Build an intermediate extraction summary used by mapping:
-
-```json
-{
-  "run_identity": {},
-  "dialog_graph": {
-    "nodes": [],
-    "edges": []
-  },
-  "intent_catalog": {},
-  "variables": {},
-  "action_inventory": {},
-  "dialog_clusters": {},
-  "unmapped_items": {}
-}
-```
-
-## Persist Extraction Output
-
-Write the extraction summary to a JSON file before starting mapping.
-
-- Output filename: `extraction-summary.json`
-- Output location: same working/output directory used for the current bot/version handoff artifacts
-- The file content must preserve the extraction output shape defined above
-- If extraction is rerun, overwrite this file with the latest extraction snapshot
-
-`action_inventory` should include any extracted knowledge action entries with explicit `knowledgeActionEnabled` and/or `knowledgeFallbackEnabled` boolean flags when present in bot version metadata.
-
-## Extraction Principles
-
-- Favor explicit configured behavior over assumptions.
-- Preserve branch conditions where available.

skills/agentforce-bot-upgrade/references/generate-agent-spec.md

@@ -1,128 +0,0 @@
-# Generate Agent Spec
-
-## What This Skill Is For
-
-This skill implements **only Phase 1 of migration**:
-
-- **In scope**: Einstein Bot -> normalized migration model -> Agent Spec handoff package
-- **Out of scope**: `.agent` generation, validation, publish, activate, or deployment
-
-The generated handoff is explicitly designed so `/agentforce-generate` can consume it as the starting spec input for Agent Script authoring.
-
-## How to Use This Skill
-
-Treat this file as the execution router. Always read the referenced files before executing each step.
-
-Follow this fixed sequence:
-
-1. Intake and normalize source bot artifacts
-2. Build migration mapping model (dialogs/intents/entities/actions/transitions)
-3. Generate Agent Spec handoff artifacts for `/agentforce-generate`
-4. Resolve open questions with the user one-by-one (or auto-apply recommended defaults when `--interactive=false`) and persist decisions
-5. Generate handoff invocation prompt for `/agentforce-generate` when ambiguity is cleared
-
-## Rules That Always Apply
-
-1. **Do not generate `.agent` in this skill.** Stop at Agent Spec + handoff artifacts.
-2. **No implementation invention.** If action target details are unknown, use `NEEDS_STUB`.
-3. **Preserve behavioral intent, not XML shape.** Convert deterministic bot flow into subagent-oriented behavioral design.
-4. **Track uncertainty explicitly.** Every ambiguous mapping must be captured in `open_questions`.
-5. **Mandatory resolution loop.** After artifact generation, process open questions and persist every resolved decision. In interactive mode, resolve them one-by-one with the user; when `--interactive=false`, auto-apply the recommended default for each open question without prompting and record the decision.
-6. **Prompt handoff after clarity.** Once all open questions are resolved without ambiguity, generate a complete invocation prompt package for `/agentforce-generate` (do not invoke the skill from this skill).
-7. **Use deterministic guardrails for risky flows.** Identity checks, escalation, sensitive operations, and regulated advice must be explicit in the spec.
-8. **Input gate is a hard block.** Do not read any workspace files, bot metadata, Apex classes, SFDX project contents, or existing spec files until input mode is explicitly selected and all required inputs for that mode are confirmed. Speculative reading of artifacts found in the workspace is prohibited.
-
-## Task Domains
-
-### Build Agent Spec from Einstein Bot
-
-Use this when user provides Einstein Bot artifacts and asks to migrate/upgrade into Agentforce.
-
-#### Required Steps
-
-0. **Collect mode and required inputs (HARD GATE)** — Parse inputs using this contract:
-   - `--mode <online|offline>` (optional; default to `online` when omitted)
-   - If `mode=online`, required inputs:
-     - `--org-alias <org-alias>`
-     - `--bot <bot-name>`
-     - `--bot-version <bot-version>`
-   - If `mode=offline`, required input:
-     - `--offline-dir <offline-dir>` (directory containing/associated with bot metadata inputs)
-   - `--interactive <true|false>` (optional; default `true`). When `false`, run autonomously: do not prompt at any decision point, apply the recommended default for every open question/ambiguity, and record each auto-applied decision.
-   If required mode-specific inputs are missing, stop and ask in interactive mode; in non-interactive mode halt with an explicit error (do not prompt). Do not read files/metadata/workspace contents until mode and required inputs are confirmed.  
-   Note: if `--mode` is omitted, treat mode as `online` immediately (do not ask user to choose mode in that case).
-
-1. **Ingest source artifacts** — Read [Input Contract](input-contract.md) and normalize user-provided bot inputs into one canonical migration model.
-   - For `mode=online`, run required SF CLI bot/version/dependency retrieval using [SF CLI Bot Reference](sf-cli-bot-reference.md). Use ONLY the query patterns documented there — do NOT invent or modify field names.
-   - For `mode=offline`, skip org retrieval and process **all relevant local metadata** from `--offline-dir`:
-     - bot and botVersion XML metadata (required)
-     - Flow metadata under `flows/` (when present)
-     - Apex classes under `classes/` (when present)
-     - any other local files referenced by bot artifacts that are needed for extraction/mapping fidelity
-   - In offline mode, do not limit ingestion to only two XML files if additional referenced artifacts are available locally.
-2. **Extract migration structure** — Read [Extraction Blueprint](extraction-blueprint.md) and derive:
-   - bot capabilities
-   - dialog graph
-   - intent map
-   - variable/entity usage
-   - invocation/action inventory
-   - fallback/escalation behavior
-3. **Map Einstein Bot -> Agent Spec components** — Read [Mapping Rules](mapping-rules.md) and produce topic/subagent, action, routing, and state mappings.
-4. **Generate handoff artifacts** — Read [Handoff Output Format](handoff-output-format.md) and write:
-   - `<run_project_dir>/<AgentName>-AgentSpec.md`
-   - `<run_project_dir>/<AgentName>-einstein-bot-handoff.json`
-   - `<run_project_dir>/<AgentName>-open-questions.md`
-   Use the same run-specific SFDX project directory created in the SF CLI setup step; do not write handoff artifacts to repository root.
-   The Agent Spec markdown MUST use the same section names/order as
-   `skills/agentforce-generate/assets/agent-spec-template.md`, then append the
-   `## Migration Notes (Einstein Bot -> Agentforce)` appendix defined in [Handoff Output Format](handoff-output-format.md).
-5. **Validate handoff quality** — Read [Quality Checklist](quality-checklist.md) and verify all required sections and mapping completeness before presenting output.
-6. **Resolve open questions loop (required)** — After generating artifacts, resolve all entries in `<run_project_dir>/<AgentName>-open-questions.md`. In interactive mode, guide the user through them one-by-one; when `--interactive=false`, auto-apply the recommended default for each entry without prompting. For each resolved item, immediately update:
-   - `<run_project_dir>/<AgentName>-AgentSpec.md`
-   - `<run_project_dir>/extraction-summary.json`
-   and remove/mark-resolved the corresponding open question.
-7. **Generate `/agentforce-generate` invocation package (no direct invoke here)** — When all open questions are resolved without ambiguity, generate and persist:
-   - `<run_project_dir>/agentforce-generate-invocation-prompt.md` (the exact prompt to pass to `/agentforce-generate`)
-   - `<run_project_dir>/agentforce-generate-output-contract.md` (expected outputs that orchestrator must capture)
-   The prompt must include:
-   - `current_working_directory` (run folder path) for all reads/writes
-   - `<run_project_dir>/<AgentName>-AgentSpec.md` as source-of-truth spec
-   - `<run_project_dir>/extraction-summary.json` as supporting context
-   - `<run_project_dir>/<AgentName>-einstein-bot-handoff.json` and `<run_project_dir>/<AgentName>-open-questions.md`
-   - `input_mode` (`online` or `offline`) explicit context
-   For `input_mode=offline`, include these strict instructions in the prompt:
-   - syntax/structural validation is still mandatory
-   - skip only org-dependent CLI operations
-   - use local artifacts only
-   - keep unresolved implementations as structurally complete `NEEDS_STUB` action definitions
-   - do not deploy/publish/activate
-   Do not invoke `/agentforce-generate` from this skill.
-
-#### Reference Files
-
-1. [Input Contract](input-contract.md) — accepted source types and normalization schema
-2. [Extraction Blueprint](extraction-blueprint.md) — what to extract from Einstein Bot metadata and why
-3. [Mapping Rules](mapping-rules.md) — canonical mapping from bot constructs to Agent Spec constructs
-4. [Handoff Output Format](handoff-output-format.md) — required output files and exact structure
-5. [Quality Checklist](quality-checklist.md) — validation criteria before handoff to `/agentforce-generate`
-6. [SF CLI Bot Reference](sf-cli-bot-reference.md) — required `sf` command sequence to validate bot/version and retrieve dependencies
-
-## Deliverables
-
-At completion, always return:
-
-1. Agent Spec handoff file path
-2. Handoff JSON path
-3. Open questions path
-4. `/agentforce-generate` invocation package status:
-   - `generated` with prompt/output-contract paths when all open questions are resolved
-   - `blocked` when unresolved ambiguity remains (include unresolved question IDs)
-5. Generated `/agentforce-generate` invocation prompt path (when status is `generated`)
-6. Generated `/agentforce-generate` output contract path (when status is `generated`)
-7. Short migration-risk summary (top unresolved items)
-
-## Important Constraints
-
-- Do not invoke deployment/publish/activate flows in this skill.
-- Do not claim parity with Einstein Bot unless all dialogs/intents/actions are mapped or explicitly deferred.
-- Do not collapse critical decision branches into vague LLM-only behavior; represent gates and transitions explicitly in the Agent Spec.

skills/agentforce-bot-upgrade/references/handoff-output-format.md

@@ -1,208 +0,0 @@
-# Handoff Output Format
-
-## Required Files
-
-1. `<AgentName>-AgentSpec.md`
-2. `<AgentName>-einstein-bot-handoff.json`
-3. `<AgentName>-open-questions.md`
-
-The extraction step also persists `extraction-summary.json` in the same directory (see [Extraction Blueprint](extraction-blueprint.md)); it is carried forward as supporting context in the handoff.
-
-Write all required files in the run-specific SFDX project directory for the selected input mode:
-- Mode A: org-backed run project directory created during SF CLI setup
-- Mode B: offline run project directory containing/associated with provided XML inputs
-Do not write handoff artifacts in the repository root.
-
-## 1) Agent Spec Markdown
-
-Create `<run_project_dir>/<AgentName>-AgentSpec.md` by copying:
-`skills/agentforce-generate/assets/agent-spec-template.md`
-
-The handoff Agent Spec MUST:
-
-1. retain the same section names and ordering as the template
-2. fill every section with migration-specific content derived from extraction outputs
-
-Required section order:
-
-1. `## Purpose & Scope`
-2. `## Behavioral Intent`
-3. `## Subagent Posture`
-4. `## Subagent Map`
-5. `## Variables`
-6. `## Actions`
-7. `## Action Invocation Strategy`
-8. `## Deterministic Controls (When Needed)`
-9. `## Architecture Pattern`
-10. `## Agent Configuration`
-
-### Section-by-section generation guidance (from `extraction-summary.json`)
-
-#### `## Purpose & Scope`
-
-1. Derive a meaningful purpose statement from bot description/identity and extracted intent summaries.
-2. Describe the agent's business scope using the intents the bot actually handles.
-3. Restrict scope to capabilities backed by configured actions:
-   - do not claim unsupported capabilities
-   - call out out-of-scope requests when no action support exists
-
-#### `## Behavioral Intent`
-
-1. Start traversal from `Welcome` (or extracted entry dialog when `Welcome` is absent).
-2. Build each workflow using:
-   - `dialog_functionality_summary`
-   - ordered `step_functionality`
-3. Handle navigations by following target dialogs recursively, while preserving navigation semantics:
-   - **`Call` navigation**: transfer control to the target dialog, then return control back to the source dialog after target execution completes. Continue source-dialog remaining steps after return.
-   - **`Redirect` navigation**: transfer control permanently to the target dialog and halt source-dialog execution immediately (no return to source flow).
-4. While reconstructing flows, track `Call` vs `Redirect` semantics internally so downstream agent design preserves return/non-return behavior.
-5. For `Call` flows, capture both:
-   - the delegated target workflow behavior, and
-   - the resumed source workflow behavior after return.
-6. For `Redirect` flows, do not append post-redirect source steps to the same path unless there is an explicit later re-entry edge.
-7. Reconstruct meaningful user conversation flows across traversed dialogs.
-8. Identify hard checkpoints by capturing strict ordering constraints, mandatory preconditions, and enforced branches/escalations.
-9. Final behavioral intent must include:
-   - ordered events for one or more workflows
-   - action invocation scope and sequencing
-   - variable usage scope (reads/writes and gating variables)
-   - escalation/routing behavior
-   - normalized transition behavior (return-after-delegation vs one-way transfer) expressed in agent-native terms only
-   - other critical bot-specific constraints that affect conversation behavior
-
-10. Do NOT emit raw bot navigation constructs (`Call`, `Redirect`) in the final Agent Spec text. Convert them into agent-native behavioral descriptions only.
-
-#### `## Subagent Posture`
-
-1. Derive baseline subagents from dialog clusters (`1 cluster -> 1 subagent`).
-2. Ensure each subagent has coherent responsibility boundaries based on associated dialog behavior and actions.
-3. Add additional subagents when dialogs are not assigned to any cluster but represent distinct bot functionality.
-4. Ensure all dialog functionality is covered by at least one subagent.
-5. Record any uncertain assignments in open questions instead of forcing low-confidence grouping.
-
-### Bot-specific artifact translation rules (required)
-
-When generating the Agent Spec, do not retain raw bot-only entities. Translate them into agent-native behavior.
-
-1. Do not carry forward bot-only references directly, including:
-   - intent names derived from dialog naming
-   - intent utterance lists as bot-training artifacts
-   - dialog identifiers/names
-   - menu redirection constructs
-2. Replace each with equivalent capability-level descriptions:
-   - user goal summaries
-   - behavioral routing intent
-   - reasoning instructions for when/how to route or invoke actions
-3. Menu redirections must be translated by:
-   - capturing the user intent behind each menu option
-   - converting each option into an equivalent reasoning-based LLM instruction
-   - preserving functional outcomes without reproducing rigid bot menu mechanics
-4. Evaluate every bot return message/response shown to users:
-   - if a message contains no actionable information and is only small talk, ignore it
-   - otherwise, preserve equivalent user-facing messaging in the relevant subagent behavior
-   - do not miss messages containing information about next steps, required actions, documentation, policy, or handoff guidance
-5. For each subagent, evaluate whether menu translation is necessary at all:
-   - prefer direct intent/reasoning behavior when menus are unnecessary
-   - retain a lightweight guided-choice pattern only when it materially improves clarity or control
-6. If menu translation approach is ambiguous, ask the user and record the decision in open questions before finalizing. When `--interactive=false`, do not ask — apply the recommended translation, record it in open questions as an auto-applied decision, and continue.
-
-Then add this migration-specific appendix section at the end:
-
-11. `## Migration Notes (Einstein Bot -> Agentforce)`
-    - Source bot identity and version
-    - Mapping confidence summary
-    - Unmapped constructs
-    - Open decisions requiring user approval
-
-### Action Invocation Optimization Rules
-
-Use this step to optimize conversation efficiency by reducing unnecessary action invocations while preserving behavior and data contracts.
-
-#### Allowed optimization operations
-
-1. **Add action** — only when required to preserve an existing conversational outcome after removing/replacing bot-only behavior.
-2. **Update action** — only for invocation optimization (for example, replacing multi-hop equivalent invocations with one semantically equivalent action).
-3. **Delete action** — only when action is bot-only or redundant in the agent architecture.
-
-#### Hard constraints
-
-1. Do not merge or modify unrelated actions just to reduce invocation count.
-2. Do not change action inputs/outputs in a way that causes data loss.
-3. Preserve all variable assignments needed by downstream steps/subagents.
-4. Preserve required action side effects that are part of business behavior.
-
-#### Bot-only action handling
-
-If an action is applicable only to Einstein Bot runtime (for example, internal bot-state bookkeeping actions):
-
-1. Mark the action as `candidate_for_removal`.
-2. Show the user why it is bot-only and why it is not needed in Agentforce.
-3. Do not remove it automatically.
-4. Remove only after explicit user confirmation. When `--interactive=false`, do not remove it — keep the action in place as the safe recommended default and record it as a deferred `candidate_for_removal` decision in open questions.
-
-#### User review gate (required)
-
-When `--interactive=false`, skip the interactive review: apply only non-destructive recommended optimizations (adds/updates), never auto-delete actions, record every applied and deferred change in open questions, then treat those recommended changes as final without prompting.
-
-Before finalizing optimized actions, present a complete change summary to the user:
-
-1. Added actions
-2. Updated actions
-3. Candidate removals
-4. For each affected action, include:
-   - action description/purpose
-   - full input contract
-   - full output contract
-   - variable assignments (reads/writes)
-   - rationale for optimization
-
-Apply changes only after user approval.
-
-#### Persistence requirement
-
-After user confirms, update the Agent Spec file to reflect all finalized action changes (adds/updates/deletes), including:
-
-- action descriptions
-- input/output contracts
-- variable read/write assignments
-- action invocation strategy updates required by the optimization
-
-Do not treat non-confirmed changes as final.
-
-## 2) Open Questions Markdown
-
-Include:
-
-- Blocking decisions (must resolve before `/agentforce-generate` handoff)
-- Non-blocking clarifications (resolve when they materially affect generated spec/actions)
-- Recommended defaults for each question
-
-Write this file as:
-
-- `<run_project_dir>/<AgentName>-open-questions.md`
-
-## 3) Einstein Bot Handoff JSON
-
-Create `<run_project_dir>/<AgentName>-einstein-bot-handoff.json` as a machine-readable companion to the Agent Spec markdown, derived from `extraction-summary.json` and the mapping produced per [Mapping Rules](mapping-rules.md).
-
-The handoff JSON MUST:
-
-1. Capture the structured mapping used to build the spec:
-   - subagent/topic mapping
-   - action inventory with input/output contracts and `EXISTS`/`NEEDS_STUB`/`NEEDS_CREATION`/`CANDIDATE_FOR_REMOVAL` status
-   - variable mappings (`mutable`/`linked`)
-   - routing/transition mapping
-   - unmapped items
-2. Stay aligned with the finalized Agent Spec markdown — after the open-questions loop completes, regenerate it so it reflects the resolved spec before handoff (no contradictory mappings).
-
-## Open Question Resolution Loop (Required)
-
-After generating initial artifacts, resolve open questions one-by-one with the user. When `--interactive=false`, do not prompt — auto-apply the recommended default recorded for each question and mark it resolved.
-
-For each resolved question:
-
-1. Update `<run_project_dir>/<AgentName>-AgentSpec.md` with the resolved decision.
-2. Update `<run_project_dir>/extraction-summary.json` with the same resolved finding and any downstream mapping updates.
-3. Mark the question as resolved (or remove it) in `<run_project_dir>/<AgentName>-open-questions.md`.
-
-Do not leave ambiguous or contradictory outcomes in any artifact.

skills/agentforce-bot-upgrade/references/input-contract.md

@@ -1,101 +0,0 @@
-# Input Contract
-
-## Mode Selection
-
-Input mode is selected from `--mode <online|offline>`:
-
-1. **Online (Mode A: org-backed retrieval)** — Use org alias + bot identity, then fetch metadata/dependencies via SF CLI.
-2. **Offline (Mode B: local metadata input)** — Use provided local metadata/artifacts directly without org fetch.
-
-If `--mode` is omitted, default to **online**.
-Only ask the user to clarify mode when provided inputs are insufficient or contradictory for the inferred/default mode. When `--interactive=false`, do not ask — proceed with the inferred/default mode and record the assumption; halt only if the inputs cannot support any mode.
-
-## Supported Input Modes
-
-### Mode A: Org-backed retrieval
-
-Required inputs:
-
-1. `--org-alias <org-alias>` — Salesforce org alias used as source context (for discovery, validation, and traceability).
-2. `--bot <bot-name>` — Einstein Bot developer name/identifier to migrate.
-3. `--bot-version <bot-version>` — specific version to migrate (for example: `v3`).
-
-### Mode B: Offline metadata input (new)
-
-Required inputs:
-
-1. `--offline-dir <offline-dir>` — directory containing/associated with local bot metadata inputs.
-
-Within `--offline-dir`, `.bot-meta.xml` and `.botVersion-meta.xml` inputs are treated as authoritative bot metadata sources for extraction/mapping.
-
-## Offline Directory Processing Scope (Required)
-
-When `--mode offline` is selected, process **all relevant local artifacts** in `--offline-dir` (recursively), not just bot XML:
-
-1. Bot metadata:
-   - `*.bot-meta.xml`
-   - `*.botVersion-meta.xml`
-2. Flow artifacts:
-   - files under `flows/` (for example `*.flow-meta.xml`)
-3. Apex artifacts:
-   - files under `classes/` (for example `*.cls`, `*.cls-meta.xml`)
-4. Misc referenced artifacts:
-   - any other files referenced by bot/flow/action mappings that improve extraction/mapping fidelity
-
-Processing rules:
-
-1. If `flows/` exists, parse flow signatures and mappings to improve action inventory contracts.
-2. If `classes/` exists, parse invocable Apex signatures (`@InvocableMethod`, `@InvocableVariable`) to improve action I/O contracts.
-3. If both bot mapping and local implementation artifacts exist, prefer concrete local implementation signatures over inferred placeholders.
-4. If referenced artifacts are missing locally, continue with inferred signatures and mark unresolved details in `open_questions`.
-5. Never require org retrieval in offline mode.
-
-If required inputs for the selected mode are missing, stop and ask for them before processing artifacts.
-
-## Identity Resolution Rules
-
-- For Mode A, use `org-alias + bot + bot-version` as the run identity key.
-- For Mode B, use `bot + bot-version` derived from provided XML metadata (or confirmed from user when not derivable).
-- Do not merge artifacts from different versions in the same run.
-- If source files contain a mismatched bot identity, pause and ask the user which identity is authoritative. When `--interactive=false`, do not pause — treat the identity declared in the authoritative bot metadata as the recommended default and record the assumption in `open_questions`.
-
-## Missing/Partial Input Handling
-
-- If action signatures are missing: keep action in inventory with `target: NEEDS_STUB`.
-- If intent training data is missing: infer intent purpose from dialog labels/descriptions and mark confidence.
-- If transitions are unclear: preserve as unresolved branch in `open_questions`.
-
-## Post-Input Finalization Workflow (Required)
-
-### Mode A: Org-backed retrieval
-
-After `--org-alias + --bot + --bot-version` are finalized, execute the SF CLI sequence in:
-
-- [SF CLI Bot Reference](sf-cli-bot-reference.md)
-
-This is the canonical command list for:
-
-1. Enforcing SF CLI and org access prerequisites
-2. Validating bot and bot version
-3. Retrieving bot metadata
-4. Retrieving required Apex/Flow/ML domain dependencies
-
-Any unresolved dependency must be recorded in `open_questions` and mapped as `NEEDS_STUB` where applicable.
-
-### Mode B: Offline metadata input
-
-When both XML files are provided (`.bot-meta.xml` + `.botVersion-meta.xml`):
-
-1. Create a run folder in repo root named `<bot-name>-<bot-version>-agent`.
-2. Copy the provided bot metadata files into that run folder:
-   - `<BotName>.bot-meta.xml`
-   - `<version>.botVersion-meta.xml`
-3. Use that run folder as the working directory for this offline run.
-4. Skip all SF CLI org validation/retrieval commands.
-5. Do not fetch bot/dependency metadata from org.
-6. Continue directly with extraction and mapping using all available local artifacts in `--offline-dir` as source inputs.
-7. If `flows/` and/or `classes/` are present, include them in extraction before finalizing action contracts.
-8. If referenced dependencies (Apex/Flow/MLDomain/etc.) are not available locally, record them as unresolved in `open_questions` and map as `NEEDS_STUB` where applicable.
-9. If action signatures (Apex/Flow/etc.) cannot be fully resolved in offline mode, continue execution with best-effort signature expansion and mark unresolved fields.
-
-All generated outputs for that run (for example `extraction-summary.json`, Agent Spec handoff, and open questions) must be written inside the same run-specific SFDX project directory for the selected mode.

skills/agentforce-bot-upgrade/references/mapping-rules.md

@@ -1,113 +0,0 @@
-# Mapping Rules
-
-## Objective
-
-Convert extracted Einstein Bot behavior into a high-quality Agent Spec that `/agentforce-generate` can execute.
-
-## Canonical Mappings
-
-- **Dialog clusters** -> **Subagents/Topics**
-- **Intent catalog** -> **Router instructions + transition actions**
-- **Entity/slot collection** -> **Variables + eligibility/guard conditions**
-- **Action inventory** -> **Action inventory in spec** (`NEEDS_STUB` when implementation unknown)
-- **Fallback dialogs** -> **Boundary handling and recovery behavior**
-- **Transfer/system handoff** -> **Built-in `@utils.escalate`** (escalation policy; never a new/standalone action)
-
-## Escalation Mapping Rule
-
-Escalation/transfer behavior (Einstein Bot `SystemMessage` `Transfer`, or any "hand off to a live agent/human" handoff) MUST be mapped implicitly to the built-in `@utils.escalate` utility. Do NOT:
-
-- create a new action for it in the action inventory (no `Transfer_To_Agent`-style action, no `NEEDS_STUB`/`NEEDS_CREATION` entry for the transfer),
-- model it as a flow/apex/standard-invocable action, or
-- represent it as generic "hand off to a human" prose without the explicit `@utils.escalate` control.
-
-Instead:
-
-- Express the escalation as an explicit `@utils.escalate` invocation in the relevant subagent's instructions (typically a terminal step of an escalation subagent).
-- Exclude the transfer from the action inventory entirely (it is not an authored action).
-
-## Dialog Functionality Extraction Rules
-
-Capture the functional behavior of each bot dialog before action optimization.
-
-### Processing steps
-
-1. Process each bot dialog independently.
-2. Parse the dialog's bot steps strictly in configured order.
-3. For each bot step, generate one or more meaningful functional sentences that describe what the bot does at that step.
-4. Build an ordered list per dialog (`step_functionality`) that preserves original step sequence.
-
-### What each step description must capture
-
-For each step, include applicable details:
-
-- step intent/purpose (message, collect, invoke, transition, system behavior)
-- conditions/guards (for example variable comparisons and branching criteria)
-- action invocations (action name and type, when invoked)
-- variable updates (set/unset/collect, including affected variable names)
-- transition behavior (target dialog and transition type when present)
-
-### Exhaustive bot-step handling
-
-When generating `step_functionality`, handle all supported Einstein Bot step families using the rules below.
-
-1. **Message**
-   - Describe user-facing message intent and any branch context.
-2. **VariableOperation**
-   - **Set**: capture source -> target variable assignment.
-   - **Unset**: capture variable clear/reset behavior.
-   - **Collect**: capture which variable is collected, requiredness, and option source (static/dynamic).
-   - **SetConversationLanguage**: capture locale/language state update.
-   - **CollectAttachment**: capture file-collection requirement and resulting variable update.
-3. **Invocation**
-   - Capture invocation target, invocation type (`apex`, `flow`, `standardInvocableAction`, `externalService`, `quickAction`, `api`), input mappings, output mappings, and resulting variable writes.
-4. **Navigation**
-   - Capture transition type (`Redirect` / `Call`), target dialog, and trigger condition.
-5. **Wait**
-   - Capture as intent-routing pause point where control waits for user input and may route to intent-enabled dialogs.
-6. **Group**
-   - Process nested steps recursively in order, preserving parent conditions and emitting child step sentences in sequence.
-7. **SystemMessage**
-   - **Transfer**: capture escalation behavior and resolved target type/value, and map it implicitly to the built-in `@utils.escalate` (see Escalation Mapping Rule) — do not emit it as a new action.
-   - **EndChat**: capture terminal behavior and conversation close.
-8. **RecordLookup**
-   - Capture queried object/entity, filter criteria, and output variable/list assignment.
-9. **RichMessage**
-   - Capture rich interaction type (for example forms/payments/selectors/links) and expected follow-up behavior.
-10. **GoalStep**
-    - Mark as bot-specific/non-agentic telemetry unless it drives business behavior; include only if behaviorally relevant.
-
-### Step rendering rules
-
-1. Preserve original step order exactly.
-2. Emit one or more concise functional sentences per step.
-3. Include conditional prefix when step is gated (for example `If <condition> ...`).
-4. Preserve variable names and action names verbatim in step descriptions.
-5. Do not skip nested steps inside `Group`.
-
-### Output requirement
-
-For every dialog, produce:
-
-1. `dialog_functionality_summary` (short high-level summary)
-2. `step_functionality` (ordered list of functional sentences derived step-by-step)
-
-This output is the baseline for downstream subagent grouping and mapping decisions.
-
-## Risk and Safety Rules
-
-- Explicitly capture:
-  - identity verification points
-  - sensitive action boundaries
-  - escalation to human support
-  - refusal boundaries for unsupported asks
-
-## Persistence Requirement
-
-At the end of mapping, update `extraction-summary.json` with bot dialog functionality details for every dialog, including `dialog_functionality_summary` and ordered `step_functionality`.
-
-When updating `extraction-summary.json` during mapping:
-
-1. Preserve the canonical schema defined in [Extraction Blueprint](extraction-blueprint.md) (do not add/remove/rename top-level keys).
-2. Update existing sections in place (`dialog_graph`, `intent_catalog`, `variables`, `action_inventory`, `dialog_clusters`, `unmapped_items`) instead of reshaping them.
-3. Keep enum/status normalization stable (`redirect/call/intent_redirect`; `EXISTS/NEEDS_STUB/NEEDS_CREATION/CANDIDATE_FOR_REMOVAL`).

skills/agentforce-bot-upgrade/references/planner-workflow-reference.md

@@ -1,78 +0,0 @@
-# Planner Workflow Reference
-
-Use this reference during orchestrator Step 3 when processing multiple bots in a single invocation.
-
-## When To Apply
-
-- Apply only when there are more than 1 ready-for-authoring Agent Specs.
-- If there is 1 or fewer specs, skip planner workflow and keep specs unchanged.
-
-## Inputs
-
-Required inputs to this workflow:
-
-1. `spec_paths`: all ready-for-authoring Agent Spec paths
-2. `working_dir`: orchestrator working directory where planner output must be written
-3. associated artifacts for each spec when present:
-   - handoff JSON
-   - open questions
-
-## Required Workflow
-
-1. Read all specs and associated artifacts.
-2. Build a final candidate set of specs that will each map to one actual downstream agent.
-3. Identify existing subagent grouping/context in each spec.
-4. Attempt regrouping based on:
-   - intent
-   - underlying object/entity
-   - broad category
-5. Allowed structural operations across specs:
-   - merge
-   - split
-   - move
-   - delete
-6. Apply operations only when they improve:
-   - modularity
-   - context-awareness
-   - interactive user experience
-7. Never perform changes for superficial consistency only.
-8. Preserve full functional coverage:
-   - no input functionality may be lost
-   - if any functionality loss risk is detected, abandon changes and mark unchanged
-
-## Required Output File
-
-Write:
-- `<working_dir>/bot-upgrade-planner-output.json`
-
-Schema:
-
-```json
-{
-  "specs_changed": true,
-  "updated_specs": [
-    {
-      "original_spec_path": "/path/original/spec-a.md",
-      "updated_spec_path": "/path/updated/spec-a.md",
-      "run_project_dir": "/path/updated/run-project-dir",
-      "handoff_json_path": "/path/updated/spec-a-einstein-bot-handoff.json",
-      "open_questions_path": "/path/updated/spec-a-open-questions.md"
-    }
-  ]
-}
-```
-
-Rules:
-
-1. `specs_changed` is boolean.
-2. If `specs_changed=false`, then `updated_specs=[]`.
-3. If `specs_changed=true`, `updated_specs` must include entries for all changed specs.
-4. Every changed entry must include:
-   - `original_spec_path`
-   - `updated_spec_path`
-   - `run_project_dir`
-   - `handoff_json_path`
-   - `open_questions_path`
-5. If any functionality-loss risk exists, force:
-   - `specs_changed=false`
-   - `updated_specs=[]`

skills/agentforce-bot-upgrade/references/post-conversion-enhancements-reference.md

@@ -1,67 +0,0 @@
-# Post-Conversion Enhancements Reference
-
-Use this reference during orchestrator Step 5 after `/agentforce-generate` completes.
-
-## Scope
-
-Apply per generated Agent Script artifact (`.agent`) independently.
-
-## Inputs
-
-Required:
-
-1. `agentscript_file`: path to one generated `.agent` file
-2. `mode` (`online|offline`): the effective orchestrator run mode
-
-Conditionally required:
-
-3. `org_alias`: target org alias used to redeploy in Step 9. Required when `mode=online`; omit when `mode=offline`.
-
-## Required Workflow
-
-1. Read the full `.agent` file.
-2. Enforce `start_agent` router behavior:
-   - ensure the subagent marked `start_agent` contains explicit instructions that 
-        - it is only a router and should route immediately to the correct downstream agent
-        - it never responds directly to the user
-   - if this instruction is missing, add it
-3. Improve transition quality with meaningful `available when` conditions:
-   - add or refine conditions between subagents wherever possible
-   - conditions should be meaningful and correct for transition intent
-   - conditions should reduce routing noise and improve next-step navigation in the final agent
-4. Validate action data flow integrity:
-   - ensure action inputs/outputs are correctly mapped through conversation variables or LLM inputs
-   - where needed, persist required LLM-derived values via `setVariables`
-   - ensure downstream actions can consume required values deterministically
-5. Enforce numeric action I/O typing:
-   - when an action input/output is numeric and flows between actions (e.g. rewards points
-     feeding a merchandise action), use the publish-safe form: an object field with
-     `complex_data_type_name: lightning__numberType`, not a bare `number`, so numeric typing
-     survives publish across all orgs.
-6. Validate escalation mapping:
-   - ensure any escalation/transfer behavior (Einstein Bot `SystemMessage` `Transfer`, or any "hand off to a live agent/human") is implemented via the built-in `@utils.escalate` utility.
-   - confirm escalation is NOT modeled as a standalone/new action: there must be no `Transfer_To_Agent`-style action and no action-inventory entry (including `NEEDS_STUB`/`NEEDS_CREATION`) representing the transfer.
-   - if the escalation is present in bot and missing in spec, or was authored as an action instead of `@utils.escalate`, fix it: remove the erroneous action and invoke `@utils.escalate` in the appropriate escalation subagent (keeping any resolved transfer target as a variable/context, not an action signature).
-7. Preserve intended functionality and behavioral coverage.
-8. Write the optimized/enhanced content back to the same file path (in-place update).
-9. Validate the resulting file:
-   - remains readable and structurally coherent
-   - is a valid Agent Script
-10. If enhancements modified the Agent Script:
-   - when `mode=online`, deploy/publish the updated Agent Script to the org again using the provided `org_alias`
-   - do not activate as part of this step
-   - when `mode=offline`, skip deploy and keep the updated local file only
-
-## Output
-
-- Enhanced Agent Script at the same input file location.
-
-## Capture Requirements
-
-For each processed file, capture:
-
-1. `agentscript_file`
-2. status (`success` or `partial`)
-3. short enhancement summary
-4. `agentscript_modified` (`true|false`)
-5. redeploy status (online mode only): `deployed`, `skipped`, or `failed`

skills/agentforce-bot-upgrade/references/quality-checklist.md

@@ -1,33 +0,0 @@
-# Quality Checklist
-
-Run this checklist before handing off to `/agentforce-generate`.
-
-## Completeness
-
-- Input mode is explicitly recorded for the run (Mode A org-backed or Mode B offline).
-- Agent Spec uses the exact section names/order from `assets/agent-spec-template.md` in `agentforce-generate`.
-- Every major bot capability is represented in the Agent Spec.
-- Every critical dialog/intent/action is either mapped or listed in `unmapped_items`.
-- Fallback and escalation behavior is explicit.
-
-## Fidelity
-
-- Action purpose and I/O are preserved from source metadata where available.
-- For Mode B (offline), action signatures are inferred from bot metadata mappings and unresolved signature details are tracked in `open_questions` (non-blocking).
-- Dialog-to-subagent and intent-to-subagent mappings are consistent.
-- High-risk flows contain clear deterministic guidance.
-
-## Handoff Readiness
-
-- Agent Spec markdown is coherent and structured for implementation.
-- Handoff JSON is machine-readable and aligned with markdown.
-- Open questions are specific, non-duplicative, and decision-ready.
-- Open questions are resolved — one-by-one with the user in interactive mode, or auto-applied from recommended defaults when `--interactive=false` — and each resolution is reflected in both Agent Spec and `extraction-summary.json`.
-- Migration appendix is present and includes confidence, gaps, and approval gates.
-
-## Failure Conditions (must fix before handoff)
-
-- Missing action inventory for flows that clearly invoke actions
-- Claimed parity while unresolved items are not documented
-- Ambiguous routing with no fallback
-- Unresolved or ambiguous open questions remain before automatic handoff to `/agentforce-generate`

skills/agentforce-bot-upgrade/references/sf-cli-bot-reference.md

@@ -1,116 +0,0 @@
-# SF CLI Bot Reference
-
-Essential SF CLI command sequence for Mode A (org-backed retrieval) after inputs are finalized (`--org-alias`, `--bot`, `--bot-version`).
-
-Do not use this reference in Mode B (offline metadata input). In offline mode, skip SF CLI retrieval and continue with extraction/mapping from local XML metadata files.
-
-## 1) Prerequisite checks
-
-```bash
-sf --version
-sf org display --json --target-org <org-alias>
-```
-
-If no orgs are available (no authenticated orgs are found), branch on the effective `--interactive` value:
-
-- **`--interactive=true`**: ask the customer to log in to an org using:
-
-```bash
-sf org login web --instance-url <LOGIN_URL> --alias <ALIAS>
-```
-
-  When asking, inform the customer about the default values so they can accept them or override:
-  - `--instance-url` defaults to `https://login.salesforce.com` when omitted. Tell the customer to use the default for production and Developer Edition orgs, `https://test.salesforce.com` for sandboxes.
-
-- **`--interactive=false`**: do NOT prompt. Halt with an explicit error: `No authenticated org found for the provided --org-alias; run sf org login web and retry.`
-
-## 2) Validate bot and version
-
-`BotVersion.VersionNumber` is a numeric field, but `<bot-version>` is supplied in the `v1`/`v2`/`v3` format. Derive `<version-number>` by stripping the leading `v` from `<bot-version>` (e.g. `v1` -> `1`, `v12` -> `12`) and use that numeric value in the SOQL filter. Keep the original `<bot-version>` (`vN`) form for the metadata retrieval in section 3.
-
-Listing bots:
-```bash
-sf data query --json --target-org <org-alias> \
-  --query "SELECT BotDefinition.MasterLabel FROM BotDefinition WHERE Type = 'Bot'"
-```
-
-Listing bot versions:
-```bash
-sf data query --json --target-org <org-alias> \
-  --query "SELECT Id, VersionNumber, Status FROM BotVersion WHERE BotDefinition.Type = 'Bot'"
-```
-
-## 3) Retrieve bot metadata
-
-Before retrieval, ensure an SF project directory exists:
-
-1. If no project exists for this migration run (`sfdx-project.json` doesn't exist), create one:
-   `sf project generate --name <bot-name>-<bot-version>-agent --template "empty" --output-dir "."`
-2. Change into that project directory.
-3. Run all remaining sf cli commands from that same project directory.
-
-```bash
-sf project retrieve start --target-org <org-alias> \
-  --metadata "Bot:<bot-name>" "BotVersion:<bot-name>.<bot-version>"
-```
-
-## 4) Retrieve related ML domains (only if referenced)
-
-After bot metadata retrieval, discover referenced ML domains from the retrieved bot XML metadata using the same pattern as the migration script (`relatedMlIntent` entries in `<Domain.Intent>` format), then retrieve each domain.
-
-Bot XML exists at: `force-app/main/default/bots/<bot-name>/<bot-name>.bot-meta.xml` (relative to the generated SFDX project directory from section 3).
-
-Use this sequence:
-
-1. Read the bot metadata XML file.
-2. Find all `relatedMlIntent` values.
-3. For each value, split on `.` and keep only the domain name prefix.
-4. De-duplicate the discovered domain names.
-5. For each discovered domain, run:
-   `sf project retrieve start --target-org <org-alias> --metadata "MlDomain:<domain_name>"`
-
-If no `relatedMlIntent` entries are found, skip MLDomain retrieval.
-
-## 5) Retrieve invocation dependencies (Apex/Flow)
-
-The pipeline extracts invocation names from bot metadata, then retrieves only those exact classes/flows.
-
-### Apex classes
-
-```bash
-sf project retrieve start --target-org <org-alias> --manifest <apex-package.xml>
-```
-
-`<apex-package.xml>` should contain only required classes:
-
-```xml
-<?xml version="1.0" encoding="UTF-8"?>
-<Package xmlns="http://soap.sforce.com/2006/04/metadata">
-  <types>
-    <members>ClassA</members>
-    <members>ClassB</members>
-    <name>ApexClass</name>
-  </types>
-  <version>67.0</version>
-</Package>
-```
-
-### Flows
-
-```bash
-sf project retrieve start --target-org <org-alias> --manifest <flow-package.xml>
-```
-
-`<flow-package.xml>` should contain only required flows:
-
-```xml
-<?xml version="1.0" encoding="UTF-8"?>
-<Package xmlns="http://soap.sforce.com/2006/04/metadata">
-  <types>
-    <members>FlowA</members>
-    <members>FlowB</members>
-    <name>Flow</name>
-  </types>
-  <version>67.0</version>
-</Package>
-```

skills/analyzing-omnistudio-dependencies/CREDITS.md

@@ -0,0 +1,5 @@
+# Credits & Acknowledgments
+
+This skill draws on established patterns and platform knowledge from the broader OmniStudio ecosystem.
+
+---

skills/analyzing-omnistudio-dependencies/SKILL.md

@@ -1,11 +1,11 @@
 ---
-name: omnistudio-dependencies-analyze
-description: "Cross-cutting OmniStudio analysis skill for namespace detection, dependency visualization, and impact analysis across OmniScripts, FlexCards, Integration Procedures, and Data Mappers. TRIGGER when: user asks about OmniStudio dependencies, wants namespace detection (Core vs vlocity_cmt vs vlocity_ins), needs impact analysis, requests dependency graphs or Mermaid diagrams, or asks which components are affected by a change. DO NOT TRIGGER when: authoring OmniScripts (use omnistudio-omniscript-generate), building FlexCards (use omnistudio-flexcard-generate), creating Integration Procedures (use omnistudio-integration-procedure-generate), or configuring Data Mappers (use omnistudio-datamapper-generate)."
+name: analyzing-omnistudio-dependencies
+description: "Cross-cutting OmniStudio analysis skill for namespace detection, dependency visualization, and impact analysis across OmniScripts, FlexCards, Integration Procedures, and Data Mappers. TRIGGER when: user asks about OmniStudio dependencies, wants namespace detection (Core vs vlocity_cmt vs vlocity_ins), needs impact analysis, requests dependency graphs or Mermaid diagrams, or asks which components are affected by a change. DO NOT TRIGGER when: authoring OmniScripts (use building-omnistudio-omniscript), building FlexCards (use building-omnistudio-flexcard), creating Integration Procedures (use building-omnistudio-integration-procedure), or configuring Data Mappers (use building-omnistudio-datamapper)."
 metadata:
   version: "1.0"
 ---
 
-# omnistudio-dependencies-analyze: OmniStudio Cross-Component Analysis
+# analyzing-omnistudio-dependencies: OmniStudio Cross-Component Analysis
 
 Expert OmniStudio analyst specializing in namespace detection, dependency mapping, and impact analysis across the full OmniStudio component suite. Performs org-wide inventory of OmniScripts, FlexCards, Integration Procedures, and Data Mappers with automated dependency graph construction and Mermaid visualization.
 
@@ -14,7 +14,7 @@ Expert OmniStudio analyst specializing in namespace detection, dependency mappin
 ## Scope
 
 - **In scope**: Namespace detection (Core / vlocity_cmt / vlocity_ins), org-wide component inventory, dependency graph construction, impact analysis, Mermaid diagram generation
-- **Out of scope**: Authoring or modifying OmniScripts (use `omnistudio-omniscript-generate`), building FlexCards (use `omnistudio-flexcard-generate`), creating Integration Procedures (use `omnistudio-integration-procedure-generate`), configuring Data Mappers (use `omnistudio-datamapper-generate`)
+- **Out of scope**: Authoring or modifying OmniScripts (use `building-omnistudio-omniscript`), building FlexCards (use `building-omnistudio-flexcard`), creating Integration Procedures (use `building-omnistudio-integration-procedure`), configuring Data Mappers (use `building-omnistudio-datamapper`)
 
 ---
 
@@ -59,7 +59,7 @@ Each analysis run produces one or more of:
 >
 > When multiple OmniStudio skills are involved, follow this dependency chain:
 >
-> `omnistudio-dependencies-analyze` → `omnistudio-datamapper-generate` → `omnistudio-integration-procedure-generate` → `omnistudio-omniscript-generate` → `omnistudio-flexcard-generate`
+> `analyzing-omnistudio-dependencies` → `building-omnistudio-datamapper` → `building-omnistudio-integration-procedure` → `building-omnistudio-omniscript` → `building-omnistudio-flexcard`
 >
 > This skill runs first to establish namespace context and dependency maps that downstream skills consume.
 
@@ -190,7 +190,7 @@ sf data query --query "SELECT Id, Type, SubType, Language, IsActive FROM OmniPro
 
 #### Algorithm: BFS with Circular Detection
 
-```text
+```
 1. Initialize empty graph G and visited set V
 2. For each root component C:
    a. Enqueue C into work queue Q
@@ -221,7 +221,7 @@ OmniScript and IP elements store references in the `PropertySetConfig` JSON fiel
 | Apex Remote Action | `remoteClass` | Apex Class |
 
 **Parsing PropertySetConfig**:
-```text
+```
 For each OmniProcessElement:
   1. Read PropertySetConfig (JSON string)
   2. Parse JSON
@@ -235,7 +235,7 @@ For each OmniProcessElement:
 
 FlexCards store their data source configuration in the `DataSourceConfig` JSON field (NOT `Definition` — that field does not exist on `OmniUiCard`):
 
-```text
+```
 Parse DataSourceConfig JSON:
   1. Access dataSource object (singular, not array)
   2. For each dataSource where type === 'IntegrationProcedures' (note: PLURAL):
@@ -254,7 +254,7 @@ Parse DataSourceConfig JSON:
 
 Data Mappers reference Salesforce objects via their items:
 
-```text
+```
 For each OmniDataTransformItem:
   1. Read InputObjectName → source sObject
   2. Read OutputObjectName → target sObject
@@ -343,7 +343,7 @@ graph LR
 
 #### Output Format 3: Human-Readable Report
 
-```text
+```
 OmniStudio Dependency Report
 =============================
 Org Namespace: Core (Industries)
@@ -431,13 +431,13 @@ sf data query --query "SELECT Id, OmniDataTransformationId, InputObjectName, Out
 
 | Skill | Relationship | How This Skill Helps |
 |-------|-------------|---------------------|
-| omnistudio-datamapper-generate | Provides namespace and object dependency data | Data Mapper authoring uses detected namespace for correct API names |
-| omnistudio-integration-procedure-generate | Provides namespace and IP dependency map | IP authoring uses dependency graph to avoid circular references |
-| omnistudio-omniscript-generate | Provides namespace and element dependency data | OmniScript authoring uses namespace-correct field names |
-| omnistudio-flexcard-generate | Provides namespace and data source dependency map | FlexCard authoring uses detected IP references for validation |
-| external-diagram-mermaid-generate | Consumes dependency graph for visualization | This skill generates Mermaid output compatible with external-diagram-mermaid-generate styling |
-| platform-custom-object-generate / platform-custom-field-generate | Provides sObject metadata for Data Mapper analysis | Object field validation during dependency extraction |
-| platform-metadata-deploy | Deployment uses namespace-correct metadata types | This skill provides the correct metadata type names per namespace |
+| building-omnistudio-datamapper | Provides namespace and object dependency data | Data Mapper authoring uses detected namespace for correct API names |
+| building-omnistudio-integration-procedure | Provides namespace and IP dependency map | IP authoring uses dependency graph to avoid circular references |
+| building-omnistudio-omniscript | Provides namespace and element dependency data | OmniScript authoring uses namespace-correct field names |
+| building-omnistudio-flexcard | Provides namespace and data source dependency map | FlexCard authoring uses detected IP references for validation |
+| generating-mermaid-diagrams | Consumes dependency graph for visualization | This skill generates Mermaid output compatible with generating-mermaid-diagrams styling |
+| generating-custom-object / generating-custom-field | Provides sObject metadata for Data Mapper analysis | Object field validation during dependency extraction |
+| deploying-metadata | Deployment uses namespace-correct metadata types | This skill provides the correct metadata type names per namespace |
 
 ---
 
@@ -457,21 +457,14 @@ sf data query --query "SELECT Id, OmniDataTransformationId, InputObjectName, Out
 
 ## Notes
 
-- **Dependencies**: Requires `sf` CLI with org authentication. Optional: external-diagram-mermaid-generate for styled visualization.
+- **Dependencies**: Requires `sf` CLI with org authentication. Optional: generating-mermaid-diagrams for styled visualization.
 - **Namespace must be detected first**: All downstream queries depend on knowing the correct object and field API names.
 - **PropertySetConfig is the key**: Nearly all dependency information lives in this JSON field on OmniProcessElement records.
 - **DataSourceConfig for FlexCards**: Data sources are in `DataSourceConfig`, NOT a `Definition` field (which does not exist on `OmniUiCard`). Card layout/states are in `PropertySetConfig`.
 - **Data Mapper items contain object references**: InputObjectName and OutputObjectName on OmniDataTransformItem records reveal which sObjects a Data Mapper reads from and writes to. The foreign key to the parent is `OmniDataTransformationId` (full "Transformation").
 - **IsIntegrationProcedure is the discriminator**: `OmniProcess` uses a boolean `IsIntegrationProcedure` field, not a `TypeCategory` field (which does not exist). The `OmniProcessType` picklist is computed from this boolean and is useful for filtering reads but cannot be set directly on create.
 - **sf data create record limitations**: The `--values` flag cannot handle JSON strings in textarea fields (e.g., PropertySetConfig). Use `sf api request rest --method POST --body @file.json` instead for records with JSON configuration.
-- **Related skills**: `omnistudio-datamapper-generate`, `omnistudio-integration-procedure-generate`, `omnistudio-omniscript-generate`, `omnistudio-flexcard-generate` — install these to enable the full OmniStudio authoring suite
-
----
-
-## Pre-Delivery Checklist
-
-- [ ] Namespace detected before any downstream queries
-- [ ] Orchestration order followed (this skill runs first in the chain)
+- **Related skills**: `building-omnistudio-datamapper`, `building-omnistudio-integration-procedure`, `building-omnistudio-omniscript`, `building-omnistudio-flexcard` — install these to enable the full OmniStudio authoring suite
 
 ---
 

skills/analyzing-omnistudio-dependencies/references/dependency-patterns.md

@@ -1,4 +1,4 @@
-<!-- Parent: omnistudio-dependencies-analyze/SKILL.md -->
+<!-- Parent: analyzing-omnistudio-dependencies/SKILL.md -->
 
 # OmniStudio Dependency Patterns
 
@@ -10,7 +10,7 @@ OmniStudio components form a directed graph where each component type can refere
 
 ## Dependency Direction Summary
 
-```text
+```
 OmniScript ──→ Integration Procedure (via IP Action element)
 OmniScript ──→ Data Mapper (via DataRaptor Action element)
 OmniScript ──→ OmniScript (via embedded OmniScript element)
@@ -206,7 +206,7 @@ Integration Procedures use the same element types as OmniScripts but are filtere
 
 An Integration Procedure can call another Integration Procedure, creating a chain:
 
-```text
+```
 IP: OrderValidation
   └── IP Action → IP: CustomerLookup
        └── DR Action → DM: CustomerExtract
@@ -322,7 +322,7 @@ Each `OmniDataTransformItem` (Core) or `DRMapItem__c` (Vlocity) record contains:
 
 ### Extract Type Data Mapper Example
 
-```text
+```
 DM: AccountExtract (Type: Extract)
 ├── Item 1: InputObjectName = "Account"
 │   InputFieldName = "Name"
@@ -339,7 +339,7 @@ Dependencies: Account (read), Contact (read)
 
 ### Load Type Data Mapper Example
 
-```text
+```
 DM: OrderCreate (Type: Load)
 ├── Item 1: OutputObjectName = "Order"
 │   InputFieldName = "OrderData.accountId"
@@ -355,7 +355,7 @@ Dependencies: Order (write), OrderItem (write)
 
 Transform type Data Mappers do not reference Salesforce objects directly — they map between data structures. They have no sObject dependencies but may participate in a chain:
 
-```text
+```
 OmniScript → DR Extract (reads Account) → DR Transform (reshapes data) → DR Load (writes CustomObj__c)
 ```
 
@@ -373,7 +373,7 @@ Circular references happen when component A depends on component B, which direct
 
 ### Detection Algorithm
 
-```javascript
+```
 function detectCircularDependencies(graph):
     cycles = []
     for each node N in graph:
@@ -402,7 +402,7 @@ function dfs(node, visited, path, graph, cycles):
 
 When a cycle is detected, report it clearly:
 
-```text
+```
 CIRCULAR DEPENDENCY DETECTED:
   OS:editAccount → IP:validateAccount → OS:editAccount
 
@@ -421,7 +421,7 @@ a termination condition.
 
 ### Step-by-Step Process
 
-```text
+```
 1. DETECT namespace (see namespace-guide.md)
 
 2. QUERY all container objects:
@@ -465,7 +465,7 @@ a termination condition.
 
 To answer "what breaks if I change Data Mapper X?", reverse the dependency direction:
 
-```text
+```
 Given: DM:AccountExtract
 
 Direct dependents (components that reference this DM):

skills/analyzing-omnistudio-dependencies/references/namespace-guide.md

@@ -1,4 +1,4 @@
-<!-- Parent: omnistudio-dependencies-analyze/SKILL.md -->
+<!-- Parent: analyzing-omnistudio-dependencies/SKILL.md -->
 
 # OmniStudio Namespace Reference Guide
 
@@ -20,7 +20,7 @@ Salesforce OmniStudio exists under three distinct namespaces depending on the or
 
 Run SOQL queries against each namespace's primary object. The first query that succeeds determines the namespace.
 
-```text
+```
 1. Probe Core:
    SELECT COUNT() FROM OmniProcess
    → Success? Namespace = Core. Stop.

skills/applying-cms-brand/SKILL.md

@@ -1,7 +1,7 @@
 ---
-name: experience-cms-brand-apply
-description: "Extracts, retrieves, and applies CMS brand guidelines (voice, tone, style, colors, typography) to generated content. Use this skill ANY TIME a user request involves branding, brand voice, brand tone, brand guidelines, brand identity, brand styling, or applying a brand to content. Triggers for requests like \"apply my brand\", \"use our brand voice\", \"match our brand guidelines\", \"find my brand\", \"search for brand\", \"get brand instructions\", \"apply brand tone\". Handles the full workflow: searching for brands in Salesforce CMS, extracting brand instructions, and applying brand voice/tone/guidelines to generated content. Does not apply to media/image search (use experience-content-media-search skill), logo search, or creating new brand definitions."
-compatibility: "Requires get_brand_instructions and/or search_media_cms_channels MCP tools"
+name: applying-cms-brand
+description: "Extracts, retrieves, and applies CMS brand guidelines (voice, tone, style, colors, typography) to generated content. Use this skill ANY TIME a user request involves branding, brand voice, brand tone, brand guidelines, brand identity, brand styling, or applying a brand to content. Triggers for requests like \"apply my brand\", \"use our brand voice\", \"match our brand guidelines\", \"find my brand\", \"search for brand\", \"get brand instructions\", \"apply brand tone\". Handles the full workflow: searching for brands in Salesforce CMS, extracting brand instructions, and applying brand voice/tone/guidelines to generated content. Does not apply to media/image search (use searching-media skill), logo search, or creating new brand definitions."
+compatibility: "Requires get_brand_instructions and/or search_brands MCP tools"
 metadata:
   version: "1.0"
 ---
@@ -23,14 +23,14 @@ Universal skill for searching, extracting, and applying CMS brand guidelines to
 - Apply brand styling, tone, or voice to a page, component, or app
 
 **DO NOT use this skill when the user wants to:**
-- Search for images or media (use experience-content-media-search skill)
+- Search for images or media (use searching-media skill)
 - Create a new brand from scratch
 - Edit brand definitions in CMS
 - Generate logos or visual brand assets
 
 ## Before You Start
 
-**CRITICAL: You must retrieve brand instructions BEFORE applying any brand.**
+**CRITICAL: You must retrieve brand instructions BEFORE generating or modifying any brand.**
 
 When a user requests branded content:
 
@@ -44,7 +44,7 @@ When a user requests branded content:
 
 Copy this checklist and track your progress:
 
-```text
+```
 CMS Branding Progress:
 - [ ] Step 1: Determine if brand is already identified or needs search
 - [ ] Step 2: Search for brands (if needed) and present options to user
@@ -63,63 +63,35 @@ Check if the user has already specified which brand to use:
 
 ## Step 2: Search for Brands
 
-**Tool:** `search_media_cms_channels`
-
-Brands are stored as CMS content of type `sfdc_cms__brand`. Search for them by
-querying the CMS channels with the brand content type.
-
-> **Note:** Brand content search (`contentTypeFqn=sfdc_cms__brand`) is explicitly
-> excluded from the `experience-content-media-search` skill's scope. Calling
-> `search_media_cms_channels` directly here is correct and intentional — do not
-> route brand search through `experience-content-media-search`.
+**Tool:** `search_brands`
 
 **Process:**
 
-1. **Determine search query** — Use the user's keyword. Brand search matches on
-   brand title and description.
-2. **Build the request** with the fixed brand-search input contract:
+1. **Determine search query** — Use the user's description, company name, or a general keyword
+2. **Build the request:**
 
 ```json
 {
   "inputs": [{
-    "searchKeyword": "keyword",
-    "searchLanguage": "<detected_language>",
-    "channelType": "PublicUnauthenticated",
-    "contentTypeFqn": "sfdc_cms__brand",
-    "pageOffset": 0,
-    "searchLimit": 25
+    "searchQuery": "keyword or brand name"
   }]
 }
 ```
 
-   Field rules:
-   - `searchKeyword` — the user's keyword input
-   - `searchLanguage` — auto-detect from the user's input; if unsure, use `en_US`
-   - `channelType` — always `PublicUnauthenticated` (brand content is delivered
-     via the public CMS channel; authenticated-channel brand search is not
-     supported by this tool)
-   - `contentTypeFqn` — always `sfdc_cms__brand`
-   - `pageOffset` — `0`
-   - `searchLimit` — `25`
-
-3. **Call `search_media_cms_channels`** with the request
-4. **Parse the response** — A brand result has an ID starting with **`9Ps`**. Extract:
+3. **Call `search_brands`** with the query
+4. **Parse the response** — Extract brand results:
    - `managedContentId` — Unique ID (use this for extraction in Step 3)
    - `managedContentKey` — Content key identifier
    - `title` — Brand display name
-   - `contentUrl` — URL to the brand content, found under
-     `managedContentChannelDeliveryDetails[0].contentUrl`
-   - `pageNumber`, `pageSize`, `totalResults` — pagination summary
+   - `contentUrl` — URL to the brand content
+   - `totalResults` — Number of brands found
 
 ### Presenting Brand Results
 
-**If brands found**, first show a summary line, then use `ask_followup_question`
-to present options:
+**If multiple brands found**, use `ask_followup_question` to present options:
 
-```text
-Showing [N] of [totalResults] total results (page [pageNumber], page size [pageSize]).
-
-Which brand should I apply?
+```
+I found [N] brands in your CMS. Which one should I apply?
 
 1. [Brand Title 1]
 2. [Brand Title 2]
@@ -128,18 +100,15 @@ Which brand should I apply?
 Which brand would you like to use?
 ```
 
-When the user replies with their selection, do NOT perform another search —
-proceed immediately to Step 3.
-
 **If one brand found**, confirm with the user:
 
-```text
+```
 I found the brand "[Brand Title]". Should I apply this brand's guidelines to the content?
 ```
 
 **If no brands found:**
 
-```text
+```
 No brands found in Salesforce CMS. To use branding:
 1. Create a brand in Salesforce CMS (Content Type: sfdc_cms__brand)
 2. Provide brand guidelines directly in this conversation
@@ -183,7 +152,7 @@ The extracted brand instructions typically include:
 
 | Error | Response |
 |---|---|
-| `search_media_cms_channels` unavailable | "Brand search is unavailable. Please provide your brand name or guidelines directly." |
+| `search_brands` unavailable | "Brand search is unavailable. Please provide your brand name or guidelines directly." |
 | `get_brand_instructions` unavailable | "Cannot retrieve brand instructions. Please share your brand guidelines in this conversation and I'll apply them manually." |
 | Org lacks Vibes branding | "CMS branding is not enabled for this org. Contact your admin to enable the Agentforce Vibes branding feature." |
 | Permission denied | "You don't have permission to access CMS brands. Ensure you have Managed Content Authoring permission." |

skills/applying-slds/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: design-systems-slds-apply
+name: applying-slds
 description: "Apply SLDS-compliant UI using the correct blueprints, styling hooks, utility classes, and icons. Use when building any UI that needs SLDS, choosing between Lightning Base Components and SLDS Blueprints, applying styling hooks for theming, using utility classes for layout and spacing, or selecting icons. Triggers include \"build a modal\", \"create a form\", \"data table\", \"SLDS styling\", \"style with hooks\", \"add an icon\"."
 metadata:
   version: "1.0"
@@ -11,7 +11,7 @@ The **Salesforce Lightning Design System (SLDS)** is a CSS framework with thousa
 
 > **Version:** This skill targets **SLDS v2**. Legacy `--lwc-*` tokens and `slds-*--modifier` syntax are deprecated.
 >
-> **Audit scope:** The companion `design-systems-slds-validate` skill analyzer only scans `.css`, `.html`, and `.js` files. Use it directly for LWC and similar HTML/CSS/JS components; treat it as a partial signal for JSX/TSX or other framework-specific template formats and supplement with manual review.
+> **Audit scope:** The companion `validating-slds` skill analyzer only scans `.css`, `.html`, and `.js` files. Use it directly for LWC and similar HTML/CSS/JS components; treat it as a partial signal for JSX/TSX or other framework-specific template formats and supplement with manual review.
 
 ## What is SLDS?
 
@@ -85,7 +85,7 @@ If no LBC exists (or not using LWC), select an SLDS Blueprint. See [references/c
 
 ## Hook Naming Traps
 
-SLDS hook families do NOT all follow the same naming pattern. Agents frequently invent hooks that don't exist by assuming `{prefix}-{number}` works universally. **Always verify a hook exists** via the bundled `search-hooks.cjs` script or `assets/hooks-index.json` before using it.
+SLDS hook families do NOT all follow the same naming pattern. Agents frequently invent hooks that don't exist by assuming `{prefix}-{number}` works universally. **Always verify a hook exists** via the bundled `search-hooks.cjs` script or `metadata/hooks-index.json` before using it.
 
 ### Trap 1: Font size hooks are NOT numbered
 
@@ -130,10 +130,10 @@ Run the appropriate search command **before** emitting any SLDS artifact:
 
 | Artifact | Verification command | Source of truth |
 |----------|---------------------|-----------------|
-| Styling hook (`--slds-g-*`) | `node scripts/search-hooks.cjs --prefix "<hook-name>"` | `assets/hooks-index.json` |
-| Utility class (`slds-*`) | `node scripts/search-utilities.cjs --search "<class-name>"` | `assets/utilities-index.json` |
-| Blueprint / CSS class | `node scripts/search-blueprints.cjs --search "<pattern>"` then read the YAML | `assets/blueprints/components/*.yaml` |
-| Icon | `node scripts/search-icons.cjs --query "<description>"` | `assets/icon-metadata.json` |
+| Styling hook (`--slds-g-*`) | `node scripts/search-hooks.cjs --prefix "<hook-name>"` | `metadata/hooks-index.json` |
+| Utility class (`slds-*`) | `node scripts/search-utilities.cjs --search "<class-name>"` | `metadata/utilities-index.json` |
+| Blueprint / CSS class | `node scripts/search-blueprints.cjs --search "<pattern>"` then read the YAML | `metadata/blueprints/components/*.yaml` |
+| Icon | `node scripts/search-icons.cjs --query "<description>"` | `metadata/icon-metadata.json` |
 
 If the search returns no match: **do not use the artifact.** Find an alternative from the search results or build custom with verified hooks.
 
@@ -187,10 +187,10 @@ This skill bundles comprehensive SLDS knowledge. Read files as needed -- don't r
 
 | Folder | Content | Index |
 |--------|---------|-------|
-| `references/overviews/` | Foundational concepts (color, spacing, typography, etc.) | [references/README.md](references/README.md) |
-| `references/styling-hooks/` | Hook categories with detailed usage | [references/README.md](references/README.md) |
-| `references/utilities/` | 27 utility class categories | [references/README.md](references/README.md) |
-| `references/slds-development-guide.md` | Full SLDS development guide | -- |
+| `guidance/overviews/` | Foundational concepts (color, spacing, typography, etc.) | [guidance/README.md](guidance/README.md) |
+| `guidance/styling-hooks/` | Hook categories with detailed usage | [guidance/README.md](guidance/README.md) |
+| `guidance/utilities/` | 27 utility class categories | [guidance/README.md](guidance/README.md) |
+| `guidance/slds-development-guide.md` | Full SLDS development guide | -- |
 
 ### Raw Metadata (structured data for lookup)
 
@@ -198,10 +198,10 @@ This skill bundles comprehensive SLDS knowledge. Read files as needed -- don't r
 
 | File | Content | Lines |
 |------|---------|-------|
-| `assets/blueprints/components/*.yaml` | 85 blueprint specs (classes, variants, a11y, HTML) | ~50-200 each |
-| `assets/hooks-index.json` | 523 hooks with values and CSS properties | ~6,300 |
-| `assets/icon-metadata.json` | 1,732 icons with synonyms for search | ~38,500 |
-| `assets/utilities-index.json` | 1,147 utility classes with CSS rules | ~6,900 |
+| `metadata/blueprints/components/*.yaml` | 85 blueprint specs (classes, variants, a11y, HTML) | ~50-200 each |
+| `metadata/hooks-index.json` | 523 hooks with values and CSS properties | ~6,300 |
+| `metadata/icon-metadata.json` | 1,732 icons with synonyms for search | ~38,500 |
+| `metadata/utilities-index.json` | 1,147 utility classes with CSS rules | ~6,900 |
 
 ---
 
@@ -219,7 +219,7 @@ Identify:
 
 1. **If LWC**: Check the [Lightning Component Library](https://developer.salesforce.com/docs/component-library/overview/components) for an LBC
 2. **Search blueprints**: `node scripts/search-blueprints.cjs --search "<pattern>"`
-3. **Read the blueprint YAML**: `assets/blueprints/components/<name>.yaml` for exact classes, modifiers, states, and accessibility requirements
+3. **Read the blueprint YAML**: `metadata/blueprints/components/<name>.yaml` for exact classes, modifiers, states, and accessibility requirements
 4. **No match?** Build custom with hooks (see Phase 3)
 
 Details: [references/component-selection.md](references/component-selection.md)
@@ -249,7 +249,7 @@ npx @salesforce-ux/slds-linter@latest lint <component-path>
 
 The linter catches hardcoded values, class overrides, and deprecated tokens. **Fix all violations before proceeding.** Do not rationalize violations as acceptable.
 
-**Step 2: Verify no invented hooks.** Confirm every `--slds-g-*` hook in the output exists in `assets/hooks-index.json`. Cross-reference against the T051 check in [checklists.md](checklists.md).
+**Step 2: Verify no invented hooks.** Confirm every `--slds-g-*` hook in the output exists in `metadata/hooks-index.json`. Cross-reference against the T051 check in [checklists.md](checklists.md).
 
 **Step 3: Run through [checklists.md](checklists.md)** for the checks the linter cannot automate:
 - All `var(--slds-g-*)` have fallback values (T002)
@@ -259,7 +259,7 @@ The linter catches hardcoded values, class overrides, and deprecated tokens. **F
 - All icons have accessibility text (A004)
 - Custom classes use `my-*` or `c-*` prefix (Q010)
 
-**Step 4 (optional): Run the full quality audit** using the `design-systems-slds-validate` skill for a scored report before code review or deployment. Use it directly for LWC / HTML-CSS-JS components; for JSX/TSX outputs, treat the result as partial coverage only. Target a B grade (≥80) or higher before marking work complete.
+**Step 4 (optional): Run the full quality audit** using the `validating-slds` skill for a scored report before code review or deployment. Use it directly for LWC / HTML-CSS-JS components; for JSX/TSX outputs, treat the result as partial coverage only. Target a B grade (≥80) or higher before marking work complete.
 
 ---
 
@@ -310,7 +310,7 @@ See [examples.md](examples.md) for worked examples demonstrating the full workfl
 
 ## Validation
 
-See [checklists.md](checklists.md) for validation checklists aligned with the design-systems-slds-validate skill.
+See [checklists.md](checklists.md) for validation checklists aligned with the validating-slds skill.
 
 ## Resources
 

skills/applying-slds/checklists.md

@@ -1,6 +1,6 @@
 # Validation Checklists
 
-Run through these checks before finalizing any SLDS-authored component. Check IDs align with the design-systems-slds-validate skill's quality-checks.md.
+Run through these checks before finalizing any SLDS-authored component. Check IDs align with the validating-slds skill's quality-checks.md.
 
 
 ## Theming & Styling (T-series)
@@ -22,7 +22,7 @@ Code produced by this skill should score high on T-series checks.
 | **Shadow hooks** | Shadows use `var(--slds-g-shadow-*)` | T040 |
 | **Border radius hooks** | Border radius uses `var(--slds-g-radius-*)` | T041 |
 | **Color hooks numbered** | Every `--slds-g-color-*` hook ends in a number (no bare `on-surface`, `on-accent`, etc.) | T050 |
-| **No invented hooks** | Every hook referenced actually exists in `assets/hooks-index.json` | T051 |
+| **No invented hooks** | Every hook referenced actually exists in `metadata/hooks-index.json` | T051 |
 | **No hardcoded colors** | No hex, rgb, or named colors (linter also catches this) | linter |
 | **No class overrides** | No `.slds-*` class overrides (linter also catches this) | linter |
 | **No deprecated tokens** | No `--lwc-*` tokens (linter also catches this) | linter |

skills/applying-slds/examples.md

@@ -24,7 +24,7 @@ node scripts/search-blueprints.cjs --search "modal"
 # Found: Modals (category: Overlay, root: slds-modal)
 ```
 
-**Read blueprint YAML** for class details: `assets/blueprints/components/modals.yaml`
+**Read blueprint YAML** for class details: `metadata/blueprints/components/modals.yaml`
 
 Key takeaway: `LightningModal` handles the `slds-modal`, `slds-backdrop`, and ARIA attributes automatically. No need to apply blueprint classes manually in LWC.
 
@@ -99,8 +99,8 @@ node scripts/search-blueprints.cjs --search "badge"
 ```
 
 **Read YAMLs:**
-- `assets/blueprints/components/cards.yaml` -- classes: `slds-card`, `slds-card__header`, `slds-card__body`, `slds-card__footer`
-- `assets/blueprints/components/badges.yaml` -- classes: `slds-badge`, modifiers: `slds-badge_lightest`, `slds-badge_inverse`
+- `metadata/blueprints/components/cards.yaml` -- classes: `slds-card`, `slds-card__header`, `slds-card__body`, `slds-card__footer`
+- `metadata/blueprints/components/badges.yaml` -- classes: `slds-badge`, modifiers: `slds-badge_lightest`, `slds-badge_inverse`
 
 ### Phase 3: Apply Styling
 

skills/applying-slds/guidance/slds-development-guide.md

@@ -158,13 +158,13 @@ export default class MyModal extends LightningModal {
 
 ## Core Rules
 
-### Do
+### Do ✅
 - Follow hierarchy: LBC → Blueprints → Styling Hooks → Custom CSS
 - Use `var(--slds-g-*)` with fallbacks for all themeable values
 - Create custom classes (e.g., `my-*`) instead of overriding `.slds-*`
 - Verify components/hooks exist before implementing
 
-### Don't
+### Don't ❌
 - Hard-code colors, spacing, or typography
 - Override `.slds-*` classes directly
 - Use deprecated `--lwc-*` tokens as primary values

skills/applying-slds/guidance/styling-hooks/index.md

@@ -245,7 +245,7 @@ font-size: var(--slds-g-font-size-base); /* Or use rem values */
 
 ## Critical Rules
 
-### DO:
+### ✅ DO:
 
 - Reference hooks with `var()`: `color: var(--slds-g-color-accent-1);`
 - Use numbered spacing: `spacing-4` not `spacing-medium`
@@ -254,7 +254,7 @@ font-size: var(--slds-g-font-size-base); /* Or use rem values */
 - Pair container colors with on-colors for text/icons
 - Follow the 50-point rule for text contrast, 40-point rule for UI elements
 
-### DON'T:
+### ❌ DON'T:
 
 - Reassign hook values: `--slds-g-color-accent-1: #ff0000;` ❌
 - Use private hooks (`--_slds-*` or `--slds-s-*`)