dist/codex/salesforce-commerce/skills/sf-setup/SKILL.md
Set up a Salesforce Commerce development environment — sfcc-ci CLI for B2C, sf CLI for B2B, Business Manager access, sandbox management, dw.json configuration, .sfdx project setup, and project structures for SFRA, PWA Kit, and Lightning. Use when starting a new Salesforce Commerce project.
npx skillsauth add orcaqubits/agentic-commerce-claude-plugins sf-setupInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Fetch live docs before setting up a project.
https://github.com/SalesforceCommerceCloud/sfcc-ci for sfcc-ci CLI commandshttps://github.com/SalesforceCommerceCloud/storefront-reference-architecture for SFRA referenceB2C Commerce (SFCC) requires:
dev01-realm-customer.demandware.net)B2B Commerce (Lightning) requires:
npm install -g @salesforce/cli)| Tool | Platform | Install | Auth |
|---|---|---|---|
| sfcc-ci | B2C | npm install -g sfcc-ci | sfcc-ci client:auth (client ID + secret) |
| sf CLI | B2B | npm install -g @salesforce/cli | sf org login web or sf org login jwt |
Key sfcc-ci Commands:
sfcc-ci code:deploy -- upload code to sandboxsfcc-ci code:activate -- activate a code versionsfcc-ci sandbox:create / sandbox:list -- manage on-demand sandboxessfcc-ci job:run -- execute Business Manager jobsKey sf CLI Commands:
sf project deploy start -- deploy metadata to orgsf org create scratch -- create scratch orgsf apex run test -- run Apex testssf data import tree -- import sample dataB2C SFRA Cartridge Project:
sfra-project/
cartridges/
app_storefront_base/ # Base (never modify)
app_custom_storefront/ # Custom overlay
cartridge/
controllers/, models/, scripts/
templates/, client/ (js, scss)
dw.json, package.json, webpack.config.js
B2C PWA Kit Project:
pwa-kit-project/
app/
components/, pages/, hooks/, utils/
commerce-api/ # Commerce Cloud API client
config/
default.js, production.js
package.json, .env
B2B Lightning Project:
b2b-lightning-project/
force-app/main/default/
lwc/, classes/, triggers/
objects/, flexipages/
experiences/, permissionsets/
config/project-scratch-def.json
sfdx-project.json, .forceignore
dw.json (B2C):
.env excluded from VCSsfdx-project.json (B2B):
.forceignore (B2B):
B2C dw.json fields:
hostname -- sandbox domainusername / password -- credentials (prefer env vars)code-version -- target code versioncartridges -- array of cartridge names to uploadexclude -- files/directories to skipB2B sfdx-project.json fields:
packageDirectories -- array of source paths (typically force-app)sourceApiVersion -- Salesforce API version (e.g., "61.0")namespace -- package namespace (empty for unmanaged)sfdcLoginUrl -- org login URL| Type | Platform | Purpose |
|---|---|---|
| Development sandbox | B2C | Developer-specific feature work |
| Staging sandbox | B2C | Pre-production validation |
| On-demand sandbox | B2C | Temporary, via sfcc-ci sandbox:create |
| Scratch org | B2B | Short-lived, disposable dev org |
| Developer sandbox | B2B | Partial copy of production |
| Full sandbox | B2B | Full copy of production for UAT |
Store credentials as environment variables, never in committed files.
B2C: SFCC_CLIENT_ID, SFCC_CLIENT_SECRET, SFCC_HOSTNAME, SFCC_USERNAME, SFCC_PASSWORD, SFCC_CODE_VERSION
B2B: SF_USERNAME, SF_ORG_ALIAS, SF_CLIENT_ID, SF_JWT_KEY_FILE (for CI/CD connected app auth)
| Deprecated | Replacement | |---|---| | dwupload | sfcc-ci | | sfdx CLI (old) | sf CLI (unified) | | Prophet Debugger | Official Salesforce VS Code extensions |
sfcc-ci for all deployments; never use manual WebDAV uploadapp_storefront_base directly; always overlay in custom cartridgenpm run compile:js, npm run compile:scss) before deploymentdw.json out of version control (add to .gitignore)sf project deploy start for metadata deployment; avoid Change Setssf project deploy preview) to review changes before deployFetch the sfcc-ci documentation, SFRA getting-started guide, and sf CLI reference for exact commands and latest project structures before setting up.
development
Build with Spree's headless Next.js storefront — the official `spree/storefront` repo (Next.js 16 App Router with Server Actions and Turbopack, React 19 Server Components, Tailwind CSS 4, TypeScript 5, `@spree/sdk`, Sentry), server-only auth (httpOnly JWT cookies + publishable key), MeiliSearch faceted catalog, one-page checkout with Apple/Google Pay/Klarna/Affirm/SEPA, multi-region market routing, GA4 + JSON-LD SEO, and Vercel/Docker deployment. Use when forking or customizing the storefront, or evaluating headless adoption.
tools
Build Spree extensions as Rails engines — gem scaffolding, `bin/rails g spree:extension`, mounting routes/migrations/assets, the modern `prepend` decorator pattern (`*_decorator.rb` with `self.prepended(base)`), generators (`spree:model_decorator`, `spree:controller_decorator`), the four customization surfaces in preference order (Events > Webhooks > Dependencies > Decorators), Spree::Dependencies for swapping service objects, gem release/versioning, and the deprecated Deface engine. Use when building a reusable Spree extension or adding non-trivial customization to an app.
development
Build with Spree's event bus and Webhooks 2.0 — `Spree::Events` publication, `Spree::Subscriber` DSL with `subscribes_to` and `on`, wildcard matching, lifecycle events (`{model}.created/.updated/.deleted` via `publishes_lifecycle_events`), the canonical event catalog (order.*, payment.*, shipment.*, product.*), Webhooks 2.0 endpoints, HMAC-SHA256 signing (`X-Spree-Webhook-Signature`), exponential-backoff retries, and Sidekiq job orchestration. Use when wiring event-driven business logic, building webhook consumers, or replacing ActiveSupport callback chains.
tools
Cross-cutting Spree development patterns — the customization preference hierarchy (Events > Webhooks > Dependencies > Decorators), `Spree::Dependencies` service-object swapping, the `_decorator.rb` + `prepend` + `self.prepended` idiom, idempotent subscribers and webhook receivers, multi-store scoping discipline, prefixed IDs, calculator polymorphism (shipping/promotion/tax share the base), service-object composition with `dry-monads` or simple results, why to avoid `class_eval` reopening and Deface, and Spree-on-Rails idioms (Hotwire/Turbo Stimulus, ActiveStorage, Action Cable, Sidekiq). Use when designing the architecture of a Spree extension or solving cross-cutting concerns.