/commerce-b2b-open-code-components-replace

name: commerce-b2b-open-code-components-replace
description: "Replace OOTB (out-of-the-box) B2B Commerce components with open source equivalents in site metadata content.json files, or look up the equivalent open code `site:` component for OOTB definitions. Use when users mention \"replace OOTB components\", \"replace commerce components with open code\", \"swap OOTB for open source\", \"replace commerce_builder:\", \"replace OOTB in site\", \"replace component in site metadata\", \"replace component definition\", \"find open code equivalent\", \"equivalent open code component\", \"OOTB to open code mapping\", \"what is the site component for\", components \"in this view\" or \"for a given view\", or a specific list of component names — and want to update or only discover mappings in their store metadata."
allowed-tools: Bash(grep:*) Bash(ls:*) Read Write
metadata:
  relatedSkills:
    - "commerce-b2b-open-code-components-integrate"
  version: "1.0"

Replacing OOTB B2B Commerce Components with Open Code

This skill replaces OOTB (out-of-the-box) B2B Commerce component definitions in site metadata `content.json` files with their open source `site:` equivalents, or looks up the equivalent open code component for given OOTB definitions without making changes. It uses an authoritative mapping loaded from `assets/ootb-to-open-code-mapping.json`.

Scope

**Modes:** **Full replace** runs the scan (Step 1), user selection if needed, then `content.json` updates (Step 2–3). **Lookup only** (user asks for equivalents but not to change files): apply the mapping-authority rule and report OOTB → `site:` for the named components or for definitions found in the scoped `content.json` — **do not** call Write unless the user confirms replacement. **View-scoped** work: limit file discovery and reads to `sfdc_cms__view/<ViewName>/` (or the path the user gives) instead of all views.

---

Prerequisites

Resolve `<package-dir>`

Read `sfdx-project.json` and pick the active package directory. Extract `packageDirectories[]` and use the entry with `"default": true`; if no entry is flagged default, use the first entry. Use this value as `<package-dir>` everywhere below. If `sfdx-project.json` is missing or has no `packageDirectories`, tell the user and abort.

Delegate setup

Before replacing components, delegate to the **commerce-b2b-open-code-components-integrate** skill to ensure:

1. Open source repository is cloned at `.tmp/b2b-commerce-open-source-components` 2. Store is selected and site metadata is retrieved locally 3. Open code components are copied to the store's site metadata

The integrating skill owns the `.tmp/` clone lifecycle (it prompts the user to reuse or re-clone an existing checkout); this skill assumes the clone is already present.

Send a plain-text chat reply to the user (per Rule 1): "Before replacing components, I need to verify that the open code components are set up in your store. Let me check..."

If any prerequisite is not met, the integrating skill will handle it. Once all checks pass, proceed to the replacement workflow.

**Required state** after prerequisites:

• **Package dir** — the value resolved above (e.g., `force-app`)
• **Store name** — e.g., `My_B2B_Store1`
• **Site metadata path** — `<package-dir>/main/default/digitalExperiences/site/<store-name>/`

---

Replacement Workflow

Step 1: Scan Site and Cross-Reference Mapping

**This step is MANDATORY.** Always scan the site first before attempting any replacements.

Send a plain-text chat reply to the user (per Rule 1): "I'm scanning your store's site metadata to find all OOTB commerce components currently in use and checking which have open code equivalents."

**Step 1a — Find affected files** (one command, simple literal match):

grep -rl '"commerce' \
  <package-dir>/main/default/digitalExperiences/site/<store-name>/sfdc_cms__view/ \
  <package-dir>/main/default/digitalExperiences/site/<store-name>/sfdc_cms__themeLayout/ \
  --include="content.json"

**Step 1b — Read the mapping and parse the matched files.** Read `assets/ootb-to-open-code-mapping.json` once into memory. Then, using the **Read** tool, parse each matched file and extract all `"definition"` values that start with `commerce` (e.g., `commerce_builder:cartBadge`). Collect a deduplicated list of OOTB components across all files.

**Step 1c — List repo components** (one command):

ls .tmp/b2b-commerce-open-source-components/force-app/main/default/sfdc_cms__lwc/

Using the parsed definitions, the `ls` output, and the mapping table, categorize every discovered OOTB component into three groups:

**Show the user a breakdown and a selectable list:**

First, inform the user about skipped and unmapped components:

Found X OOTB components in your site:

In mapping table but NOT in repo (skipping):
  - commerce_builder:quoteSummary → site:quoteSummary (not found in repo)

No mapping available (not in mapping table):
  - commerce_builder:actionButtons
  - commerce_builder:layoutHeaderOne
  - commerce_builder:searchInputContainer
  - commerce_builder:myAccountMegaMenu

Then present the replaceable components as a **multi-select list** so the user can pick from checkboxes instead of typing. Include an "All of the above" option:

Which components would you like to replace?

☐ commerce_builder:heading → site:productHeading
☐ commerce_builder:cartBadge → site:cartBadge
☐ commerce_builder:searchInput → site:searchInput
☐ All of the above

If user provided specific component name(s) in the original request, pre-filter to those and skip the selection prompt.

Step 2: Replace in content.json

Send a plain-text chat reply to the user (per Rule 1): "I'm now replacing the selected OOTB component definitions with their open code equivalents in your site's content.json files."

The affected files are already known from Step 1. For each file that contains selected components: 1. Use the **Read** tool to read