chore(release): 1.32.0 [skip ci]

chore: remove stale manifest.json and DOCS_ONLY.md @W-23538245@

manifest.json was a hand-curated skill registry last updated Feb 2026
that nothing consumes. DOCS_ONLY.md incorrectly states the repo contains
no code.

CHANGELOG.md

@@ -1,3 +1,71 @@
+# [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)
 
 

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:Open Source,Open Source Workflow,Docs Only
+#GUSINFO:

DOCS_ONLY.md

@@ -1,4 +0,0 @@
-## 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,330 +1,207 @@
-Creative Commons Attribution-NonCommercial 4.0 International Public
-License
-
-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.
-
-
-Section 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.
-
-  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.
-
-  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.
-
-  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.
-
-  f. Licensed Material means the artistic or literary work, database,
-     or other material to which the Licensor applied this Public
-     License.
-
-  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.
-
-  h. Licensor means the individual(s) or entity(ies) granting rights
-     under this Public License.
-
-  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.
-
-  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.
-
-  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.
-
-  l. You means the individual or entity exercising the Licensed Rights
-     under this Public License. Your has a corresponding meaning.
-
-
-Section 2 -- Scope.
-
-  a. License grant.
-
-       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:
-
-            a. reproduce and Share the Licensed Material, in whole or
-               in part, for NonCommercial purposes only; and
-
-            b. produce, reproduce, and Share Adapted Material for
-               NonCommercial purposes only.
-
-       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.
-
-       3. Term. The term of this Public License is specified in Section
-          6(a).
-
-       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.
-
-       5. Downstream recipients.
-
-            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.
-
-            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.
-
-       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).
+Apache License Version 2.0
+
+Copyright (c) 2026 Salesforce, Inc.
+All rights reserved.
+
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "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.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "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.
+
+      "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).
+
+      "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.
+
+      "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."
+
+      "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.
+
+   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.
+
+   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) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; 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
+
+      (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.
+
+      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.
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      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.
+
+   Copyright {yyyy} {name of copyright owner}
+
+   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
+
+   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.
 
-  b. Other rights.
-
-       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.
-
-       2. Patent and trademark rights are not licensed under this
-          Public License.
-
-       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.
-
-
-Section 3 -- License Conditions.
-
-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,14 +4,16 @@ 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
-│   ├── generating-apex/
-│   ├── generating-custom-object/
-│   ├── generating-flow/
+│   ├── platform-apex-generate/
+│   ├── platform-custom-object-generate/
+│   ├── automation-flow-generate/
 │   └── ...
 ├── samples/              # Synced sample apps (e.g. from npm)
 │   └── ui-bundle-template-app-react-sample-b2e/

manifest.json

@@ -1,421 +0,0 @@
-{
-  "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.25.0",
+  "version": "1.32.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 `using-ui-bundle-salesforce-data` skill. Do not write any data access code without consulting it first.**
+**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.**
 
 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 `using-ui-bundle-salesforce-data` skill. Do not write any data access code without consulting it first.**
+**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.**
 
 This applies to: GraphQL queries/mutations, REST calls, SDK initialization, custom hooks that fetch data, or any code that imports from `@salesforce/platform-sdk`.
 

skills/agentforce-architecture-analyze/README.md

@@ -44,7 +44,7 @@ See `SKILL.md` for the full flag table and sample prompts.
 
 ## Directory layout
 
-```
+```text
 agentforce-architecture-analyze/
 ├── SKILL.md                       Skill contract (inputs, outputs, pipeline, invariants)
 ├── README.md                      This file
@@ -73,12 +73,11 @@ agentforce-architecture-analyze/
 │   ├── finalize.py                Merge waves → metadata_tree.json
 │   ├── render_architecture.py     architecture.md + Mermaid graph
 │   ├── resolve_invocation_target.py  ID-prefix router for NGA InvocationTargets
+│   ├── emit_env.py                Env-var emit helper (Phase 0.5)
+│   ├── emit_result.py             Final RESULT block renderer
+│   ├── sanitize.py                Stdin → safe-string filter
+│   ├── write_emit_ctx.py          Per-phase ctx writer
 │   └── tests/                     Unit + integration tests (unittest)
-└── tools/
-    ├── emit_env.py                Env-var emit helper (Phase 0.5)
-    ├── emit_result.py             Final RESULT block renderer
-    ├── sanitize.py                Stdin → safe-string filter
-    └── write_emit_ctx.py          Per-phase ctx writer
 ```
 
 ---
@@ -87,7 +86,7 @@ agentforce-architecture-analyze/
 
 ### Channel strategy — SOQL-first
 
-```
+```text
 Seed query: planner_definition_by_agent_chain (chain-LIKE lookup → planner id)
 
 6 parallel Tooling SOQL channels (keyed on the resolved planner id):
@@ -148,9 +147,3 @@ Per-branch ancestor-path cycle detection is the primary termination primitive: t
 | `INVALID_FIELD` from a SOQL asset | Salesforce renamed / removed the field in a quarterly release. Run with `--reprobe` to refresh the 7-day channel cache and pick up the new schema |
 | `STATUS=PROBE_FAILED` on first run | Channel probe saw a mandatory field missing. Check `channels.json` under the probe cache dir for which sObject / field — may require org-side feature enablement |
 | Tree for classic ReAct agent shows `_unresolved` entries for NGA plugins | Expected — the NGA external-plugin retrieve is skipped when the planner shape is classic. Those entries can be ignored |
-
----
-
-## Author
-
-Raghul Jayagopal (RJ), Salesforce ANZ FDE.

skills/agentforce-architecture-analyze/SKILL.md

@@ -135,7 +135,7 @@ set -e
 # Final RESULT block is emit_result.py's stdout — MUST be the last thing
 # stdout sees. emit_result exits 0 on render success; the bash harness
 # propagates main.py's rc for the agent's exit status.
-WORK_DIR="$WORK_DIR" python3 "$SKILL_ROOT/tools/emit_result.py"
+WORK_DIR="$WORK_DIR" python3 "$SKILL_ROOT/scripts/emit_result.py"
 exit "$_rc"
 ```
 
@@ -157,14 +157,14 @@ exit "$_rc"
 
 All artifacts under `~/.vibe/data/agentforce-architecture-analyze/<org_id15>/<agent_api_name>__<agent_version>/` (default; override with `--data-dir <path>`):
 
-```
+```xml
 <agent>_<ver>_metadata_tree.json   primary artifact — normalized planner/topic/action/flow/apex/prompt/plugin tree
 <agent>_<ver>_architecture.md      human-readable section-by-section rendering (H1 + 7 numbered sections, plus a conditional Dependency graph appendix). Mermaid diagrams are embedded inside the relevant sections (Action tree, Data flow, and Dependency graph)
 ```
 
 ## Pipeline — inline, no subagent
 
-```
+```text
 resolve_bot.py        → BotDefinition + BotVersion + planner name lookup
 retrieve_planner.py   → Metadata API zip retrieve for GenAiPlannerBundle (+ NGA plugins if present)
 parallel_retrieve.py  → 6 parallel Tooling SOQL channels fan out from the planner id

skills/agentforce-architecture-analyze/references/contract.json

@@ -1,5 +1,5 @@
 {
-  "_doc": "retired-name references replaced with plugin-scoped layout. Machine-readable I/O contract for investigating-agentforce-architecture. Orchestrator code reads this file (not SKILL.md prose) to discover the input schema, output keys, STATUS enum, and error-contract rules. The architecture skill runs inline (no subagent).",
+  "_doc": "retired-name references replaced with plugin-scoped layout. Machine-readable I/O contract for agentforce-architecture-analyze. Orchestrator code reads this file (not SKILL.md prose) to discover the input schema, output keys, STATUS enum, and error-contract rules. The architecture skill runs inline (no subagent).",
   "_schema_version": "3.1",
   "_schema_notes": "3.1 (2026-05-05) canonicalizes `invocation_type` on STANDARD_ACTION / UNKNOWN nodes in the metadata tree. Prior versions split this across `raw_invocation_type` (bundle-sourced nodes) and `raw_action_type` (flow-actionCall-sourced nodes). Both legacy keys are still tolerated by readers for one release.",
   "input": {
@@ -35,15 +35,15 @@
       },
       "work_dir": {
         "type": "absolute_path",
-        "description": "Ephemeral scratch. Default: /tmp/investigating-agentforce-architecture-<epoch>-<rand>."
+        "description": "Ephemeral scratch. Default: /tmp/agentforce-architecture-analyze-<epoch>-<rand>."
       },
       "cache_root": {
         "type": "absolute_path",
-        "description": "Internal rebuildable cache root. Default: ~/.vibe/cache/investigating-agentforce-architecture. Override with --cache-dir <path>."
+        "description": "Internal rebuildable cache root. Default: ~/.vibe/cache/agentforce-architecture-analyze. Override with --cache-dir <path>."
       },
       "data_root": {
         "type": "absolute_path",
-        "description": "Durable user-facing output root. Default: ~/.vibe/data/investigating-agentforce-architecture. Override with --data-dir <path>."
+        "description": "Durable user-facing output root. Default: ~/.vibe/data/agentforce-architecture-analyze. Override with --data-dir <path>."
       },
       "force_refresh": {
         "type": "boolean",

skills/agentforce-architecture-analyze/references/soql_fields.md

@@ -64,7 +64,7 @@ Every edge is strictly **forward** from the entry query
 (`GenAiPlannerDefinition WHERE DeveloperName = :planner_name`). No
 backward lookups.
 
-```
+```text
 BotDefinition (Data API, PK Id, matched by DeveloperName)
  └── BotVersion (Data API, FK BotDefinitionId)
  │ [resolved to planner name via Bot metadata retrieve]

skills/agentforce-architecture-analyze/scripts/sanitize.py

@@ -10,7 +10,7 @@ or malformed input could inject fake KEY=VALUE pairs that downstream consumers
 would treat as authoritative.
 
 Usage:
-    _safe=$(python3 "$SKILL/tools/sanitize.py" "$raw_value")
+    _safe=$(python3 "$SKILL/scripts/sanitize.py" "$raw_value")
 
 Arguments:
     argv[1]  raw string (may be empty)

skills/agentforce-architecture-analyze/scripts/tests/_bootstrap.py

@@ -6,7 +6,7 @@ does `from config import ...`. Tests mirror that by inserting scripts/
 onto sys.path.
 
 fs_guard is now sourced via ``from config import fs_guard`` (config.py
-re-exports it from the plugin _shared/ package). No tools/ entry on
+re-exports it from the plugin _shared/ package). No separate entry on
 sys.path is required — config.py's dev-fallback walks up to the repo's
 ``plugins/investigating-agentforce-architecture/shared/`` when ``scripts/_shared/``
 hasn't yet been mirrored by install.sh / the build script.

skills/agentforce-architecture-analyze/scripts/tests/test_end_to_end_fixture.py

@@ -44,10 +44,10 @@ from tests.fixtures import genai_payloads as fx  # type: ignore
 _REPO_SOQL_DIR = Path(__file__).resolve().parent.parent.parent / "assets" / "soql"
 soql_loader.SOQL_DIR = _REPO_SOQL_DIR
 
-# emit_result.py lives under tools/; tests invoke it via subprocess so the
+# emit_result.py lives under scripts/; tests invoke it via subprocess so the
 # tool's RESULT-formatting logic is exercised under the same contract the
 # SKILL.md Bash wrapper uses.
-_TOOLS_DIR = Path(__file__).resolve().parent.parent.parent / "tools"
+_TOOLS_DIR = Path(__file__).resolve().parent.parent
 
 
 # ---------------------------------------------------------------------------

skills/agentforce-architecture-analyze/scripts/tests/test_write_emit_ctx.py

@@ -32,9 +32,9 @@ from . import _bootstrap  # noqa: F401
 
 
 def _tools_dir() -> pathlib.Path:
-    """Absolute path to the skill's tools/ dir — where the scripts live."""
+    """Absolute path to the skill's scripts/ dir — where the emit helpers live."""
     here = pathlib.Path(__file__).resolve()
-    return here.parent.parent.parent / "tools"
+    return here.parent.parent
 
 
 def _run_script(script_name: str, env: dict) -> subprocess.CompletedProcess:
@@ -439,7 +439,7 @@ class EmitResultPositionalSafetyTests(unittest.TestCase):
 
     def test_build_block_happy_path_auto_promotes_without_asserting(self):
         """Sanity: the assertion does NOT fire under normal operation."""
-        # Force import of emit_result from the tools/ dir.
+        # Force import of emit_result from the scripts/ dir.
         import importlib.util
         spec = importlib.util.spec_from_file_location(
             "emit_result_mod", _tools_dir() / "emit_result.py",

skills/agentforce-architecture-analyze/scripts/write_emit_ctx.py

@@ -83,7 +83,7 @@ import sys
 
 # local, dependency-free token scrub mirroring the patterns in
 # `scripts/rest_client.redact_text`. Keeping the redactor inline preserves
-# the tools/ <-> scripts/ decoupling (tools/ is stdlib-only by policy) and
+# the scripts/ emit helpers (stdlib-only by policy) and
 # avoids adding a sys.path hop on every write_emit_ctx invocation. The two
 # implementations must stay in sync; the shared regex shapes are:
 # * Authorization: Bearer <token>

skills/agentforce-bot-upgrade/SKILL.md

@@ -0,0 +1,217 @@
+---
+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

@@ -0,0 +1,242 @@
+# 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

@@ -0,0 +1,128 @@
+# 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

@@ -0,0 +1,208 @@
+# 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

@@ -0,0 +1,101 @@
+# 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

@@ -0,0 +1,113 @@
+# 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

@@ -0,0 +1,78 @@
+# 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

@@ -0,0 +1,67 @@
+# 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

@@ -0,0 +1,33 @@
+# 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

@@ -0,0 +1,116 @@
+# 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/agentforce-observe/references/stdm-queries.md

@@ -24,9 +24,9 @@ Methods:
 mkdir -p <project-root>/force-app/main/default/classes
 
 # Copy from the skill's apex directory
-cp ../apex/AgentforceOptimizeService.cls \
+cp ../assets/apex/AgentforceOptimizeService.cls \
    <project-root>/force-app/main/default/classes/
-cp ../apex/AgentforceOptimizeService.cls-meta.xml \
+cp ../assets/apex/AgentforceOptimizeService.cls-meta.xml \
    <project-root>/force-app/main/default/classes/
 ```
 

skills/analyzing-test-failures/SKILL.md

@@ -1,159 +0,0 @@
----
-name: analyzing-test-failures
-description: "Parses a DevOps Center test-failure or Code Analyzer violation payload and explains it in plain language — failure category, offending file/class/method/line, rule violated, and fix direction — then gives prioritized test-improvement suggestions (distinguishing test-code from production-code fixes). Pure reasoning: no system calls or code authoring. TRIGGER when: a test run failed and the user wants root cause; a quality gate failure needs explaining; Code Analyzer violations need translating to plain language; the user shares a failure payload and asks how to address it; tests keep failing and the user wants suggestions; or the user wants to close coverage gaps, strengthen assertions, or fix flaky/weak tests. DO NOT TRIGGER when: the user wants fix code written (use platform-apex-generate) or new test classes authored (use platform-apex-test-generate)."
-metadata:
-  version: "1.0"
-  minApiVersion: "67.0"
----
-
-# analyzing-test-failures
-
-**Type:** Pure reasoning — no system calls, no code authoring.
-
-**What it does:** Parses a test failure or Code Analyzer violation payload and produces a plain-language explanation, then follows up with concrete, prioritized improvement suggestions per failed test — including whether each fix belongs in the test or in production code. Never exposes raw JSON, stack traces, or API error bodies to the user.
-
----
-
-## Prerequisites
-
-If you need to fetch the failure payload yourself rather than receiving it, load `checking-devops-prerequisites` first, then use `polling-test-results` to obtain the execution result. If the payload is already in context, no prerequisites are needed — this is pure reasoning.
-
----
-
-## Inputs
-
-- JSON failure payload provided by the `polling-test-results` skill, or pasted directly into context from a test run or Code Analyzer execution. Specifically required per failed test:
-  - Test method name
-  - Failure message (the assertion error or exception text)
-  - Failure category (assertion failure, unhandled exception, timeout, compile error)
-
----
-
-## Empty-org / no-data case
-
-If the payload contains no failures or violations, report that clearly (e.g. "No failures found in the provided execution results.") and stop. Do NOT fabricate failures, violations, or improvement suggestions when none are present.
-
----
-
-## Reasoning steps
-
-1. Determine the failure category:
-
-   | Category | Description |
-   |---|---|
-   | **Assertion failure** | A test assertion failed (expected vs actual mismatch) |
-   | **Exception** | An unhandled exception was thrown |
-   | **Code Analyzer violation** | A static analysis rule was violated (e.g. `ApexCRUDViolation`, `ApexSharingViolations`) |
-   | **Timeout** | Test exceeded execution time limit |
-   | **Compile error** | Class failed to compile |
-
-2. For each failure, extract and translate to plain language:
-   - Offending file and class name
-   - Method name
-   - Line number
-   - What rule or assertion was violated, in plain language
-   - Suggested fix direction (without writing code)
-
-3. Group failures by category if more than one.
-
----
-
-## Output format
-
-```text
-Test failure summary:
-
-<N> failure(s) found:
-
-1. [<Category>] `<ClassName>.cls` — `<methodName>()` at line <N>
-   What happened: <plain-language description>
-   Rule violated: <ruleName or assertion description>
-   Fix direction: <plain-language suggestion>
-
-2. [<Category>] `<ClassName2>.cls` — `<methodName2>()` at line <N>
-   ...
-```
-
----
-
-## Code Analyzer violations
-
-For violations, always include:
-- The rule name translated to plain English (e.g. "ApexCRUDViolation" → "A SOQL query was made without checking object-level permissions first")
-- The exact line number
-- The fix direction (e.g. "Add a `Schema.sObjectType.Account.isAccessible()` check before the query")
-
----
-
-## Plain-language rule
-
-Never paste raw stack traces, JSON payloads, or internal Salesforce error codes into the output. Always translate to file name, method, line, and plain description.
-
----
-
-## Suggesting improvements
-
-Invoke this section **after test execution completes with failures**, not on static source code. The failure message is the primary signal — it describes what the test expected vs. what actually happened, which directly informs what the test needs to handle better.
-
-### 1 — Read each failure message
-
-For each failed test in the execution result, extract:
-- Test method name
-- Failure message (the assertion error or exception message)
-- Failure category (assertion failure, unhandled exception, timeout, compile error)
-
-### 2 — Infer what the test is not handling
-
-Reason over the failure message to identify the root cause pattern:
-
-| Failure pattern | Improvement suggestion |
-|---|---|
-| `NullPointerException` | The test is not handling null input — add a null check or a test setup that ensures the data exists |
-| `Assertion failed: expected X but was Y` | The expected value in the assertion is wrong or the test data setup does not produce the right state |
-| `List has no rows for assignment` | The test is querying for data that doesn't exist — test setup is incomplete |
-| `System.LimitException: Too many SOQL queries` | The test is hitting governor limits — the code under test or test setup is making too many queries |
-| `Insufficient access rights on cross-reference id` | The test user lacks the required permissions — the test needs to run as a user with appropriate profile/permission set |
-| `DML currently not allowed` | The test is performing DML inside a method called from a context that doesn't allow it |
-| Code Analyzer violation message | The production code violates a specific rule — the test exposed it but the fix is in the production code, not the test |
-
-### 3 — Produce actionable suggestions
-
-For each failure, describe in plain language:
-- What the failure reveals about what the test is not handling
-- What specifically should be added or changed to make the test robust
-- Whether the fix is in the **test** (assertion, setup, permissions) or in the **production code** (the test is correct but the code under test is broken)
-
-Do not rewrite the test. Only describe what needs to change and why.
-
-### Output format for improvements
-
-```text
-Test improvement suggestions based on execution results:
-
-`<testMethodName>()` — [Assertion Failure / Exception / etc.]
-Failure: "<failure message>"
-What this reveals: <plain-language explanation>
-Suggestion: <specific, actionable recommendation>
-Fix location: Test | Production code
-
-`<testMethodName2>()` — [NullPointerException]
-Failure: "Attempt to de-reference a null object"
-What this reveals: The test is calling the method without setting up the required input data
-Suggestion: Add test data setup for <object/field> before calling the method
-Fix location: Test
-
-Overall: <N> improvement(s) across <M> failed test(s).
-```
-
-### Test fix vs. production-code fix
-
-Suggestions flagged as **Fix location: Production code** indicate a code defect exposed by the test — the test logic itself is sound. These should not block suite promotion on the grounds of test quality; they should be tracked separately as production defects.
-
-Suggestions flagged as **Fix location: Test** indicate the test needs to be hardened — missing setup, wrong assertions, inadequate coverage of edge cases (null inputs, bulk record volumes, mixed permission contexts, governor-limit boundaries).
-
----
-
-## Related skills
-
-- **`polling-test-results`** — obtains the failure payload that feeds into this skill.
-- **`creating-fix-work-item`** — use to create a tracked fix item from the analysis output or to track an approved improvement suggestion as a work item once the user decides to act on it.

skills/automation-flow-generate/SKILL.md

@@ -189,7 +189,7 @@ When no custom objects needed:
         - `referenceTo`: (Lookup only) The target object API name
 - Include only objects and fields that are relevant to the flow being generated
 
-## 🎯 Mandatory Enhancement Rules
+## Mandatory Enhancement Rules
 - **userPrompt**: REQUIRED.
     - If the user requests a **single flow**: use the user's prompt as-is.
     - If the user requests **multiple flows**: you MUST **split** the request and write a **separate, focused `userPrompt` for each individual flow**. Each `userPrompt` must describe only ONE flow. Do NOT pass the entire multi-flow request as a single `userPrompt`. See the multiple flows section below for examples.

skills/configuring-quality-gate/SKILL.md

@@ -1,120 +0,0 @@
----
-name: configuring-quality-gate
-description: "Creates a DevOps Center quality gate with associated rules (PASS_PERCENTAGE, SEVERITY, ESSENTIAL) and links it to a pipeline-stage suite assignment, after showing a mandatory impact preview and obtaining explicit confirmation. Use this skill when a user wants to set or configure a quality gate, change a coverage threshold, or establish testing benchmarks on a pipeline stage. TRIGGER when: the user wants to set/configure a quality gate, change a coverage threshold, or set testing benchmarks on a stage. DO NOT TRIGGER when: only re-running an existing gate (use running-devops-test-suite in retrigger mode)."
-metadata:
-  version: "1.0"
-  minApiVersion: "67.0"
----
-
-## Prerequisites
-
-Load `checking-devops-prerequisites` first — Prerequisites 1–4 AND Prerequisite 5 (stage). You need `doce-org-alias`, `pipelineId`, `stageId`, and the target `DevopsTestSuiteStage` record Id.
-
-## Inputs required
-
-| Input | Source |
-|---|---|
-| `name` | User-provided name for the quality gate |
-| `rules` | List of `{type, threshold?}` — see rule types below |
-| `doce-org-alias` | Established in Prereq 1 |
-| `testSuiteStageId` | Target `DevopsTestSuiteStage` record Id (Prereq 5) |
-
-## Rule types
-
-| Type | Description | Threshold |
-|---|---|---|
-| `PASS_PERCENTAGE` | Minimum % of tests that must pass | Required (0–100) |
-| `SEVERITY` | Maximum allowed severity level of failures | Required (numeric, e.g. 1–5) |
-| `ESSENTIAL` | All essential tests must pass | Not required |
-
----
-
-## MANDATORY IMPACT PREVIEW
-
-**Before executing any commands**, show the user this preview and wait for explicit confirmation:
-
-> "Here's what this quality gate will enforce on `<stageName>`:
-> - Rule: `<type>` — `<description>`
-> - Threshold: `<value>`
-> - Affected pipelines: `<list>`
->
-> Confirm to apply?"
-
-**Never proceed past this point without showing the impact preview first and receiving explicit confirmation.**
-
----
-
-## Confirmation gate
-
-Only proceed with the steps below after the user has explicitly confirmed (e.g., "yes", "confirm", "go ahead"). If the user declines or does not confirm, stop and do not execute any commands.
-
----
-
-## Step 1 — Create the gate record
-
-```bash
-sf api request rest \
-  "/services/data/v67.0/connect/devopstesting/qualityGate" \
-  --method POST \
-  --body '{"name": "<gateName>"}' \
-  --target-org <doce-org-alias>
-```
-
-Extract `qualityGateId` from the response.
-
-## Step 2 — Create each rule as a sObject record
-
-Rules are not accepted in the Connect API payload — create them as `DevopsQualityGateRule` records directly. Only create rules the user has requested. `ESSENTIAL` has no threshold.
-
-```bash
-sf data create record \
-  --sobject DevopsQualityGateRule \
-  --values "DevopsQualityGateId='<qualityGateId>' Rule='PASS_PERCENTAGE' Threshold=<value>" \
-  --target-org <doce-org-alias> --json
-
-sf data create record \
-  --sobject DevopsQualityGateRule \
-  --values "DevopsQualityGateId='<qualityGateId>' Rule='ESSENTIAL'" \
-  --target-org <doce-org-alias> --json
-
-sf data create record \
-  --sobject DevopsQualityGateRule \
-  --values "DevopsQualityGateId='<qualityGateId>' Rule='SEVERITY' Threshold=<value>" \
-  --target-org <doce-org-alias> --json
-```
-
-## Step 3 — Link the gate to the suite stage
-
-Update the `DevopsTestSuiteStage` record to link the new gate:
-
-```bash
-sf data update record \
-  --sobject DevopsTestSuiteStage \
-  --record-id <testSuiteStageId> \
-  --values "IsQualityGateEnabled=true DevopsQualityGateId='<qualityGateId>'" \
-  --target-org <doce-org-alias> --json
-```
-
----
-
-## On success
-
-Confirm to the user:
-> "Quality gate `<gateName>` created with `<N>` rule(s) and assigned to `<suiteName>` on `<stageName>`."
-
-## Error handling
-
-Never expose raw API errors. Use the following responses:
-
-| Status | Response |
-|---|---|
-| 400 | "The quality gate configuration is invalid. Check that all rule types and thresholds are correct." |
-| 403 | "You don't have permission to configure quality gates on this org." |
-| 500 | "A server error occurred. Try again in a few minutes." |
-
----
-
-## Related skills
-
-- To re-run a gate after meeting threshold, use `running-devops-test-suite` (retrigger mode).
-- To assign or map suites to stages, use `managing-suite-assignments`.

skills/configuring-test-provider/SKILL.md

@@ -1,113 +0,0 @@
----
-name: configuring-test-provider
-description: "Configures an available test provider (e.g. Apex Unit Tests, Code Analyzer, Flow Tests, Provar) on a DevOps Center pipeline via the Connect API, after explicit user confirmation, so the provider's test suites become available for assignment to pipeline stages. Takes a pipelineId and a testProviderId. Use this skill when a provider is available on the pipeline but not yet configured and the user wants to enable it. TRIGGER when: the user wants to configure, enable, set up, or add a test provider on a pipeline, or wants a not-yet-configured provider's suites to become available. DO NOT TRIGGER when: re-syncing an already-configured provider to pick up new suites (use syncing-test-providers), or assigning existing suites to a stage (use managing-suite-assignments)."
-metadata:
-  version: "1.0"
-  minApiVersion: "67.0"
----
-
-# Configuring a Test Provider
-
-Configures an available test provider on a DevOps Center pipeline, making its test suites available for assignment to pipeline stages.
-
-**Confirmation required:** Yes — explicit confirmation before the provider is configured.
-
-## Prerequisites
-
-Load `checking-devops-prerequisites` first — Prerequisites 1–4 (org login, Agentforce DX plugin, DevOps Center org auth, pipeline identified). Prerequisite 5 (stage) is **not** required: providers are configured at the pipeline level, not the stage level.
-
-| Variable | Source |
-|---|---|
-| `doce-org-alias` | Established in Prerequisite 1 |
-| `pipelineId` | Identified in Prerequisite 4 (pipeline selection) |
-| `testProviderId` | Resolved by fetching the pipeline's test providers (below) |
-
----
-
-## Step 1 — Fetch test providers to resolve the provider ID
-
-Get all test providers for the pipeline so you can resolve the `testProviderId` and confirm which providers are still available to configure:
-
-```bash
-sf api request rest \
-  "/services/data/v67.0/connect/devopstesting/pipeline/<pipelineId>/testProviders?status=all" \
-  --target-org <doce-org-alias>
-```
-
-Each provider entry includes `testProviderId`, `testProviderName`, and a status (Configured vs. Available). Present a short summary grouped by status:
-
-```text
-Test providers for <pipelineName>:
-
-✓ Configured:
-- Code Analyzer (63 suites)
-- Apex Unit Tests (5 suites)
-
-Available (not yet configured):
-- Flow Tests
-```
-
-- **Only an Available provider can be configured.** If the pipeline has no available providers, report that and stop — do NOT fabricate a provider or ID.
-
-### If the named provider is already Configured
-
-Do **not** present the confirmation gate and do **not** POST to the configure endpoint (Steps 2–3) — that would create a duplicate `DevopsPipelineTestProvider`. Instead:
-
-1. State plainly that the provider is already configured, including its synced suite count and last-sync time if returned (e.g. *"Flow Tests is already configured on `<pipelineName>` with 3 suites synced (last sync 2026-06-23)."*).
-2. Diagnose the user's actual goal and redirect **by name**:
-   - If the user says the provider's **suites don't appear when assigning tests to a stage**, this is a **stage-assignment gap, not a provider-configuration gap** — the suites already exist at the pipeline level; they just need to be linked to the stage. Redirect to **`managing-suite-assignments`**.
-   - If the user expects **newly created suites** that aren't yet synced, redirect to **`syncing-test-providers`** (re-sync via `POST /connect/devops/sync`) to pull them in.
-3. Do not loop back to configuring — finish cleanly after the explanation and redirect.
-
-## Step 2 — Confirmation gate
-
-**Required — do not call the API before the user confirms.**
-
-> "I'll configure `<testProviderName>` on the `<pipelineName>` pipeline. This will make its suites available for assignment to stages. Confirm?"
-
-Do not proceed until the user gives an affirmative response.
-
-## Step 3 — Configure the provider
-
-On confirmation, call the configure endpoint with the provider ID:
-
-```bash
-sf api request rest \
-  "/services/data/v67.0/connect/devops/pipeline/<pipelineId>/testProvider" \
-  --method POST \
-  --body '{"testProviderId": "<testProviderId>"}' \
-  --target-org <doce-org-alias>
-```
-
-## On success
-
-> "Provider `<testProviderName>` is now configured on the `<pipelineName>` pipeline. Its suites are available for assignment to stages."
-
-Newly configured suites can then be assigned to stages with `managing-suite-assignments`.
-
----
-
-## Critical gotcha
-
-This `POST .../pipeline/<pipelineId>/testProvider` endpoint **creates a new provider configuration record** (`DevopsPipelineTestProvider`). Use it ONLY to configure a provider for the first time. To re-sync an already-configured provider for new suites, use `syncing-test-providers` (`POST /connect/devops/sync`) — calling this configure endpoint on an already-configured provider produces **duplicate** `DevopsPipelineTestProvider` records.
-
-## Error Handling
-
-Never expose raw API error messages, stack traces, or JSON payloads to the user. Map response status codes to plain-language messages:
-
-| Status | User-facing message |
-|---|---|
-| 400 | "The request was invalid. Check that the provider ID and pipeline ID are correct." |
-| 403 | "You don't have permission to configure test providers on this pipeline." |
-| 404 | "The pipeline or test provider was not found." |
-| 409 | "That provider appears to already be configured on this pipeline. To pick up new suites, re-sync it instead." |
-| 500 | "A server error occurred. Try again in a few minutes." |
-
----
-
-## Related skills
-
-- **`checking-devops-prerequisites`** — loaded first to establish org and pipeline context.
-- **`syncing-test-providers`** — once a provider is configured, use this to re-sync it later and pull in newly added suites.
-- **`managing-suite-assignments`** — after configuring a provider, use this to assign or map its suites to a pipeline stage.
-- **`recommending-devops-tests`** — to recommend which of the newly available suites to run.

skills/data360-activate/CREDITS.md

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

skills/data360-activate/README.md

@@ -36,4 +36,3 @@ sf data360 data-action-target list -o myorg 2>/dev/null
 - [../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)
-- [CREDITS.md](CREDITS.md)

skills/data360-activate/SKILL.md

@@ -107,11 +107,9 @@ Next step: <destination validation or downstream testing>
 
 ## References
 
-- [README.md](README.md)
 - [../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/UPSTREAM.md](../data360-orchestrate/UPSTREAM.md)
 - [../data360-orchestrate/references/plugin-setup.md](../data360-orchestrate/references/plugin-setup.md)
 - [../data360-orchestrate/references/feature-readiness.md](../data360-orchestrate/references/feature-readiness.md)

skills/data360-code-extension-generate/SKILL.md

@@ -3,6 +3,19 @@ name: data360-code-extension-generate
 description: "Develop and deploy Data Cloud Code Extensions using SF CLI plugin. Use this skill when creating custom Python transformations for Data Cloud, deploying code extensions, or testing data transformations. Supports init, run, scan, and deploy operations."
 metadata:
   version: "1.0"
+  relatedSkills:
+    - "data360-schema-get"
+  cliTools:
+    - tool: ["sf"]
+      semver: ">=2.0.0"
+    - tool: ["pip"]
+      semver: ">=21.0.0"
+    - tool: ["python3"]
+      semver: ">=3.11.0"
+    - tool: ["docker"]
+      semver: ">=20.0.0"
+    - tool: ["git"]
+      semver: ">=2.0.0"
 ---
 
 # data360-code-extension-generate Skill
@@ -30,7 +43,7 @@ Before executing any code extension commands, verify prerequisites:
    ```
    If not installed:
    ```bash
-   sf plugins install @salesforce/plugin-data-codeextension
+   sf plugins install @salesforce/plugin-data-code-extension
    ```
 
 2. **Python 3.11**
@@ -254,7 +267,7 @@ sf data-code-extension script deploy --target-org <org_alias> --name <name> --pa
 
 | Error | Solution |
 |-------|----------|
-| `command data-code-extension not found` | `sf plugins install @salesforce/plugin-data-codeextension` |
+| `command data-code-extension not found` | `sf plugins install @salesforce/plugin-data-code-extension` |
 | `datacustomcode CLI not found` | `pip install salesforce-data-customcode` |
 | `Python version mismatch` | Use pyenv: `pyenv install 3.11.0 && pyenv local 3.11.0` |
 | `Cannot connect to Docker daemon` | Start Docker Desktop |

skills/data360-connect/CREDITS.md

@@ -1,5 +0,0 @@
-# Credits & Acknowledgments
-
-This skill is part of the `*-datacloud` family of skills covering the full Data Cloud workflow lifecycle. Shared upstream source mapping and maintenance notes live in:
-- [../data360-orchestrate/CREDITS.md](../data360-orchestrate/CREDITS.md)
-- [../data360-orchestrate/UPSTREAM.md](../data360-orchestrate/UPSTREAM.md)

skills/data360-connect/README.md

@@ -55,5 +55,3 @@ sf data360 connection schema-upsert -o myorg --name <connector-id> -f examples/c
 
 - [SKILL.md](SKILL.md)
 - [../data360-orchestrate/references/plugin-setup.md](../data360-orchestrate/references/plugin-setup.md)
-- [../data360-orchestrate/UPSTREAM.md](../data360-orchestrate/UPSTREAM.md)
-- [CREDITS.md](CREDITS.md)

skills/data360-connect/SKILL.md

@@ -142,7 +142,6 @@ Next step: <prepare phase or connector follow-up>
 
 ## References
 
-- [README.md](README.md)
 - [examples/connections/heroku-postgres.json](examples/connections/heroku-postgres.json)
 - [examples/connections/redshift.json](examples/connections/redshift.json)
 - [examples/connections/sharepoint-unstructured.json](examples/connections/sharepoint-unstructured.json)
@@ -151,4 +150,3 @@ Next step: <prepare phase or connector follow-up>
 - [examples/connections/ingest-api-schema.json](examples/connections/ingest-api-schema.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)
-- [../data360-orchestrate/UPSTREAM.md](../data360-orchestrate/UPSTREAM.md)

skills/data360-harmonize/CREDITS.md

@@ -1,3 +0,0 @@
-# Credits & Acknowledgments
-
-This skill is part of the `*-datacloud` family of skills covering the Data Cloud lifecycle: ingestion, harmonization, segmentation, and retrieval.

skills/data360-harmonize/SKILL.md

@@ -107,7 +107,6 @@ Next step: <segment / retrieve / follow-up>
 
 ## References
 
-- [README.md](README.md)
 - [../data360-orchestrate/assets/definitions/dmo.template.json](../data360-orchestrate/assets/definitions/dmo.template.json)
 - [../data360-orchestrate/assets/definitions/mapping.template.json](../data360-orchestrate/assets/definitions/mapping.template.json)
 - [../data360-orchestrate/assets/definitions/relationship.template.json](../data360-orchestrate/assets/definitions/relationship.template.json)

skills/data360-orchestrate/CREDITS.md

@@ -1,15 +0,0 @@
-# Credits & Acknowledgments
-
-This skill family distills publicly shared Data Cloud implementation knowledge into sf-skills house style. Attribution is intentionally explicit because contributor credit is a core sf-skills principle.
-
----
-
-This family intentionally:
-- keeps sf-skills naming consistency (`*-datacloud`)
-- keeps the external CLI plugin outside this repo
-- favors deterministic helper scripts and reusable JSON templates
-- rewrites examples into generic sf-skills-style guidance rather than copying workshop-specific payloads
-
-See [UPSTREAM.md](UPSTREAM.md) for the maintenance contract.
-
----

skills/data360-orchestrate/README.md

@@ -47,7 +47,6 @@ See [references/plugin-setup.md](references/plugin-setup.md).
 | [scripts/diagnose-org.mjs](scripts/diagnose-org.mjs) | Classify org readiness by phase before mutating Data Cloud assets |
 | [references/feature-readiness.md](references/feature-readiness.md) | Map high-signal errors and feature gates to concrete next steps |
 | [assets/definitions/](assets/definitions/) | Generic JSON templates for repeatable Data Cloud definition files |
-| [UPSTREAM.md](UPSTREAM.md) | Upstream mapping for future distillation and maintenance |
 
 ## Generic templates
 
@@ -119,9 +118,3 @@ sf data360 activation platforms -o myorg 2>/dev/null
 - [SKILL.md](SKILL.md) - Orchestrator guidance
 - [references/plugin-setup.md](references/plugin-setup.md) - Plugin install and verification
 - [references/feature-readiness.md](references/feature-readiness.md) - Readiness classification and setup guidance
-- [UPSTREAM.md](UPSTREAM.md) - Upstream tracking and distillation policy
-- [CREDITS.md](CREDITS.md) - Contributor and source attribution
-
-## Primary contributor
-
-**Gnanasekaran Thoppae** — primary contributor for the data360-orchestrate family.

skills/data360-orchestrate/SKILL.md

@@ -215,10 +215,8 @@ Next step: <next phase, setup guidance, or cross-skill handoff>
 ## Reference Map
 
 ### Start here
-- [README.md](README.md)
 - [references/plugin-setup.md](references/plugin-setup.md)
 - [references/feature-readiness.md](references/feature-readiness.md)
-- [UPSTREAM.md](UPSTREAM.md)
 
 ### Phase skills
 - [data360-connect](../data360-connect/SKILL.md)

skills/data360-orchestrate/UPSTREAM.md

@@ -1,45 +0,0 @@
-# Upstream Distillation Map for data360-orchestrate
-
-This file exists to make downstream maintenance easy without sacrificing sf-skills consistency.
-
-## Maintenance contract
-
-When upstream changes, do **not** copy blindly.
-
-Instead:
-1. review new upstream commits
-2. identify changed command behaviors, install patterns, or gotchas
-3. update sf-skills prompts and templates in a distilled form
-4. keep naming, attribution, and cross-skill boundaries consistent with sf-skills
-5. update this file with the new reviewed commit SHAs
-
-## High-priority upstream areas to re-check
-
-- installation / linking workflow for the community plugin
-- command counts and topic coverage
-- API-version guidance
-- known issues and bug-fix notes
-- live-tested command set
-- any new commands affecting Connect / Prepare / Harmonize / Segment / Act / Retrieve boundaries
-- connector-specific payload examples worth distilling into generic repo-safe examples
-- search-index / hybrid-search guidance and any command-surface changes around hybrid scoring or prefilter behavior
-- Ingestion API schema-upload flow, send-data examples, and problem-record guidance
-- unstructured-source setup differences between connection-level reruns, stream refreshes, and initial UI seeding
-- UI-only gaps where upstream introduces browser automation; validate before importing
-
-## Cross-skill boundary reminders
-
-Keep Data Cloud product work in `*-datacloud`, but do not blur into:
-- `agentforce-observe` for STDM/session tracing/parquet workflows
-- `platform-soql-query` for CRM SOQL-only tasks
-- `platform-data-manage` for CRM record seeding/cleanup
-- `platform-*-generate` skills for CRM schema creation (custom objects, fields, validation rules, etc.)
-
-## Local helper files in this family
-
-- `references/plugin-setup.md`
-- `scripts/bootstrap-plugin.sh`
-- `scripts/verify-plugin.sh`
-- `assets/definitions/`
-
-These are sf-skills-owned conveniences and should evolve independently from upstream when that improves user experience.

skills/data360-prepare/CREDITS.md

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

skills/data360-prepare/README.md

@@ -48,4 +48,3 @@ sf data360 connection run-existing -o myorg --name <connection-id> 2>/dev/null
 - [SKILL.md](SKILL.md)
 - [examples/ingestion-api/README.md](examples/ingestion-api/README.md)
 - [../data360-orchestrate/assets/definitions/data-stream.template.json](../data360-orchestrate/assets/definitions/data-stream.template.json)
-- [CREDITS.md](CREDITS.md)

skills/data360-prepare/SKILL.md

@@ -183,7 +183,6 @@ Next step: <harmonize or retrieve>
 
 ## References
 
-- [README.md](README.md)
 - [examples/ingestion-api/README.md](examples/ingestion-api/README.md)
 - [../data360-orchestrate/assets/definitions/data-stream.template.json](../data360-orchestrate/assets/definitions/data-stream.template.json)
 - [../data360-orchestrate/references/plugin-setup.md](../data360-orchestrate/references/plugin-setup.md)

skills/data360-query/CREDITS.md

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

skills/data360-query/README.md

@@ -41,4 +41,3 @@ sf data360 query hybrid -o myorg --index Knowledge_Index --query "reset password
 
 - [SKILL.md](SKILL.md)
 - [../data360-orchestrate/assets/definitions/search-index.template.json](../data360-orchestrate/assets/definitions/search-index.template.json)
-- [CREDITS.md](CREDITS.md)

skills/data360-query/SKILL.md

@@ -111,7 +111,6 @@ Next step: <segment / harmonize / follow-up>
 
 ## References
 
-- [README.md](README.md)
 - [examples/search-indexes/vector-knowledge.json](examples/search-indexes/vector-knowledge.json)
 - [examples/search-indexes/hybrid-structured.json](examples/search-indexes/hybrid-structured.json)
 - [../data360-orchestrate/assets/definitions/search-index.template.json](../data360-orchestrate/assets/definitions/search-index.template.json)

skills/data360-segment/CREDITS.md

@@ -1,3 +0,0 @@
-# Credits & Acknowledgments
-
-This skill is part of the `*-datacloud` family of skills covering the Salesforce Data Cloud workflow phases. Shared definitions, templates, and readiness scripts for this family live in the `data360-orchestrate` skill directory.

skills/data360-segment/README.md

@@ -33,4 +33,3 @@ sf data360 calculated-insight list -o myorg 2>/dev/null
 - [SKILL.md](SKILL.md)
 - [../data360-orchestrate/assets/definitions/calculated-insight.template.json](../data360-orchestrate/assets/definitions/calculated-insight.template.json)
 - [../data360-orchestrate/assets/definitions/segment.template.json](../data360-orchestrate/assets/definitions/segment.template.json)
-- [CREDITS.md](CREDITS.md)

skills/data360-segment/SKILL.md

@@ -107,8 +107,6 @@ Next step: <act / retrieve / follow-up>
 
 ## References
 
-- [README.md](README.md)
 - [../data360-orchestrate/assets/definitions/calculated-insight.template.json](../data360-orchestrate/assets/definitions/calculated-insight.template.json)
 - [../data360-orchestrate/assets/definitions/segment.template.json](../data360-orchestrate/assets/definitions/segment.template.json)
 - [../data360-orchestrate/references/feature-readiness.md](../data360-orchestrate/references/feature-readiness.md)
-- [../data360-orchestrate/UPSTREAM.md](../data360-orchestrate/UPSTREAM.md)

skills/design-systems-slds-apply/SKILL.md

@@ -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 `metadata/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 `assets/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>"` | `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` |
+| 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` |
 
 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 |
 |--------|---------|-------|
-| `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 | -- |
+| `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 | -- |
 
 ### 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 |
 |------|---------|-------|
-| `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 |
+| `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 |
 
 ---
 
@@ -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**: `metadata/blueprints/components/<name>.yaml` for exact classes, modifiers, states, and accessibility requirements
+3. **Read the blueprint YAML**: `assets/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 `metadata/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 `assets/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)