Agent Plugins 1.9.0

Agent skills plugin artifacts for b2c-agent-plugins v1.9.0. Download the *-skills.zip files below.

See the Agent Skills & Plugins guide for installation and usage.

Changelog

Minor Changes

• #672 304f0eb - Add b2c-ops runbooks for job health, checkout and failed-order investigation, and incident triage, available as a skills plugin, through CLI installation, and included in the MCP. Add an Operations guide with example requests, recovery checks, and handoffs to administrators, developers, providers, or Salesforce Support. (Thanks @clavery!)

Patch Changes

• 46ab439 - Lead SCAPI checkout guidance with the documented order payment-instrument authorization, placement, and failure lifecycle while retaining single-phase order hook orchestration as an option. (Thanks @clavery!)

• #680 6503d81 - Analyze B2C Commerce sales, merchandising, and technical trends directly through MCP with CIP report discovery and SQL queries. Includes analytics skills, shared configuration and Safety Mode support, and bounded, cancellable queries without a separate CLI installation. (Thanks @clavery!)

  Report discovery includes source tables and sales metric definitions. Sales, payment, and promotion reports return unavailable averages for zero-count groups instead of failing on division by zero.

• #672 304f0eb - Fix SCAPI system-job requests so site archive imports and exports, including Page Designer content exports, use the required configuration format. Preserve OCAPI compatibility retries and clarify content authentication guidance. (Thanks @clavery!)

• #670 407075c - Add embedded Commerce skills through MCP resources and searchable skills_read, with focused configuration, authentication, and workflow guidance and consistent CLI/MCP recommendations. Enable all toolsets by default, streamline debugging and logging, identify tool effects for client approval controls, and support MCP 2026-07-28 alongside earlier clients. Include concise installation, capabilities, configuration, and security documentation. (Thanks @clavery!)

  Update explicit tool selections to use debug_control, debug_inspect, logs_watch, and mrt_logs_watch; remove pwakit_get_guidelines and scapi_custom_api_generate_scaffold. Remove --allow-non-ga-tools from launch commands. Use --toolsets or --tools to customize the catalog and b2c scaffold generate custom-api for local scaffolding.

• #680 6503d81 - Add reusable workflows for job history, execution steps, code versions, and site cartridge paths. Update MCP task guidance and operational runbooks to use these workflows and exact job-log reads with less reliance on the CLI. (Thanks @clavery!)

• #662 2f92310 - Add a --mrt-backend flag (auto | legacy | scapi, default auto; also MRT_BACKEND env var or mrtBackend in dw.json) to b2c mrt commands. It lets mrt bundle history and mrt bundle deploy <bundleId> run over the SCAPI Storefront Deployments API (OAuth, scopes sfcc.storefront.deployments[.rw]) instead of the legacy MRT Cloud API (per-user API key). auto prefers SCAPI when --short-code/--tenant-id and client-credentials or JWT Bearer auth are configured, otherwise uses legacy, and falls back to legacy on safe pre-execution errors (surfacing the SCAPI error instead when no legacy credentials are configured, so the real failure isn't masked); scapi never silently falls back. All other MRT commands — and mrt bundle deploy's local-build push path — remain on the legacy backend. (Thanks @kieran-sf!)

  Under --json, these commands return the serving backend's native response verbatim (legacy {count, next, previous, deployments} vs SCAPI {limit, offset, total, data}) — the human-readable table is normalized across backends, but --json is not, so pin legacy or scapi when a script needs a stable shape. Legacy-only flags (--api-key, --cloud-origin, --credentials-file) now print a warning under --mrt-backend scapi (where the legacy backend that honors them never runs). --project also gains a --storefront / -s alias for the SCAPI storefront ID.

• #646 c9cf71f - Add b2c mrt bundle upload-v2 for building and uploading v2-format Managed Runtime bundles. The v2 archive is a gzip tar whose files live under a configurable root directory (default bld/) with the SSR configuration written inside the archive at {root-dir}/{config-path} (default bld/.mrt/config.json), uploaded as multipart/form-data. This command is upload-only — deploy the returned bundle ID with b2c mrt bundle deploy <bundleId> -e <env>. Every server-side parameter (root dir, config path, match mode, SSR patterns/parameters, dependencies, and CC overrides) is exposed as a flag. The SDK adds matching createBundleV2, pushBundleV2, and uploadBundleV2 operations. (Thanks @kieran-sf!)

  Bundle commands now read SSR configuration (ssrOnly/ssrShared/ssrParameters) from config.server.ts in the project directory, loaded straight from source, so it no longer needs to be compiled into the build output. Use --project-directory to point at a project other than the current directory (a compiled config.server.js/config.server.mjs and the legacy build/config.server.js are still accepted). For upload-v2, an on-disk v2 config file ({build-dir}/{config-path}) still takes precedence when present; command flags override the resolved values per key. The SDK's createBundle/createBundleV2 gain a projectDirectory option for this.

  Bundles now include the project's declared dependencies as bundle metadata (v1 bundle_metadata.dependencies; v2 bundleMetadata.dependencies inside the archive config), derived from the project package.json (dependencies + devDependencies) — matching pwa-kit/storefront-next. Explicitly provided dependencies (v2 --dependencies) or dependencies already present in the v2 config file take precedence; collection is best-effort and never blocks a bundle if package.json is missing or unreadable.

• #676 2924738 - De-conflict short flags on the mrt command surface so each -x means one thing: (Thanks @kieran-sf!)

  • --cloud-origin moved from -o to -u, freeing -o for --organization (mrt project create / list) and --output (mrt bundle download) — which previously shadowed the base flag. Breaking: update any scripts passing -o for the cloud origin; the long form --cloud-origin is unchanged.
  • mrt project notification create / update: --target (the notification's target-environment list) now also accepts --environment / -e as aliases, since a notification target is an environment. These two commands no longer expose the standalone single-value --environment flag — it was unused there and its --target alias collided with the command's own --target.

• #662 2f92310 - Document SFCC_MRT_BACKEND as a supported way to select the b2c mrt backend (alongside MRT_BACKEND) in the b2c-mrt skill. (Thanks @kieran-sf!)

• #676 2924738 - Add storefront as an alias for project across the mrt command surface, matching the terminology of the SCAPI MRT API. b2c mrt storefront <cmd> now works identically to b2c mrt project <cmd> (including the member and notification subtopics), and --storefront / -s are accepted anywhere --project / -p is. The new MRT_STOREFRONT / SFCC_MRT_STOREFRONT environment variables act as fallbacks for MRT_PROJECT / SFCC_MRT_PROJECT. The project / --project (-p) forms and the existing MRT_PROJECT variables continue to work unchanged. (Thanks @kieran-sf!)

  -s now uniformly means --project / --storefront on every mrt command. To make that consistent, two commands changed their own short flags (breaking):

  • mrt project create no longer has a --slug flag. Set the new project's slug with --project / --storefront (-p / -s) instead — e.g. b2c mrt project create "My Storefront" -o my-org -s my-storefront. When omitted, MRT auto-generates the slug from the name (unchanged). Update any scripts using --slug.
  • mrt bundle save moved --save-dir from -s to -d, freeing -s for the storefront alias. Update any scripts using -s for the save directory (the long form --save-dir is unchanged).

  mrt project get, update, and delete accept the project slug either as a positional argument or via --project / --storefront (-p / -s; also honoring MRT_PROJECT and dw.json). Symmetrically, mrt env create and mrt env delete now accept the environment slug either as a positional argument or via --environment / -e (also honoring MRT_ENVIRONMENT and dw.json). An explicit positional still wins when both are given.

  Error messages surface the alias too: the "MRT project is required" errors now mention --project / --storefront (-p / -s), and passing a flag twice through an alias (e.g. -p x -s y) now reports which long and short forms refer to the same flag instead of the bare "can only be specified once".

  On the mrt project notification commands, --environment (-e) is now the primary flag for specifying environments (previously --target), matching the rest of the mrt surface. --target / -t are retained as aliases so existing scripts keep working, and command output and --help now say "environment" / "Environments" rather than "target". notification list follows suit with an --environment filter and an Environments column.

• #670 407075c - Add SCAPI code mode with offline discovery of 594 Admin and Shopper operations and standard or custom Admin API execution using automatic authentication and SDK Safety Mode. Compose requests and return focused results through scapi_search and scapi_execute, with bounded execution and actionable access errors. (Thanks @clavery!)

  Discover tenant custom API contracts live and execute their declared Admin operations. Live schema reads include custom-property definitions by default; known custom fields work directly in standard Admin requests. Bundled schemas remain tenant-independent.

  Reuse built-in workflows for product creation with optional category assignment, campaign/promotion inspection, and failed-job triage, or save reviewed workflows for later use. Export Account Manager and SLAS tokens when an external client needs them; normal SCAPI requests authenticate automatically. Code mode restricts local filesystem/process APIs to keep programs focused on API workflows; use terminal and file tools for local development.

• #413 3773648 - Migrate job, code, bm users, bm roles, sites, and catalog discovery to SCAPI-first operation with a temporary OCAPI compatibility fallback. auto tries SCAPI when its coordinates and stateless authentication are available, pins the selected backend for multi-request operations, and falls back only on safe capability/auth/request rejections. Site cartridge-path writes, portable BM user search, disabled-user updates, system-job triggers, SDK/CLI/MCP code-version discovery, and VS Code jobs/code/catalog surfaces now participate. Inventory-list enumeration, BM whoami, access-key administration, and raw OCAPI user-search JSON remain temporary OCAPI compatibility operations because the current live SCAPI schemas have no equivalent. Explicit SCAPI mode rejects these operations before contacting OCAPI and identifies B2C Commerce release 26.8 as the current capability baseline. (Thanks @clavery!)

  setup instance create accepts optional SCAPI coordinates for SCAPI-first active-code-version detection. They are not required in auto; missing coordinates select OCAPI, and failed interactive detection reports the reason before allowing manual entry.

  This is a major release because JSON/results can change shape during the migration. job run, job wait, and job search return canonical camelCase fields with either backend, including OCAPI fallback; consumers must update fields such as execution_status to executionStatus. Other commands can retain backend-specific shapes, for which explicitly selecting OCAPI preserves the legacy shape. SDK high-level code helpers accept an explicit scripts backend; dual-backend factories and JobsCompatibilityBackend expose reusable fallback without making implicit backend selection an SDK-wide policy.

  SCAPI currently requires client-credentials or JWT Bearer authentication. Browser-based user auth continues through OCAPI/WebDAV and is selected by auto; explicit SCAPI with user auth errors clearly until the platform adds support.

  GitHub Action v2 adopts CLI 2.x and its camelCase job results. Existing @v1 workflows remain on the maintained CLI 1.x line, preserving the OCAPI behavior and legacy result shapes of operations migrated in CLI 2 until consumers update their Action references to @v2. CLI 1.x commands designed specifically for SCAPI continue to use SCAPI.

  The VS Code extension uses configured tenant IDs consistently in API Browser, keeps partial export discovery warnings in the output log instead of showing notifications, and supports JWT-authenticated OCAPI fallback equivalently to client credentials.

• #413 3773648 - Detect deprecated OCAPI instances and guide users to SCAPI. (Thanks @clavery!)

  When an instance has OCAPI disabled, code, job, bm, sites, and cap commands now fail with an actionable message — naming the exact SCAPI scope the operation needs (e.g. sfcc.scripts / sfcc.scripts.rw) — instead of an opaque "Failed to ..." error. Documentation and agent skills for code, job, and bm are now SCAPI-first, presenting OCAPI as the deprecated fallback.

• #642 a0214e4 - Allow SLAS client get, update, delete, and open commands to use the configured SLAS client ID when their positional client ID is omitted, while keeping the positional value as an explicit override. (Thanks @clavery!)

• #675 b2b026c - Apply shared HTTP middleware to SLAS shopper token flows so custom headers such as SFCC_EXTRA_HEADERS reach every request. Preserve redirect and cancellation settings when adding extra request parameters, and document the token response shape. (Thanks @clavery!)

• #677 de36e4a - Refocus Storefront Next guidance on managing existing storefronts with environment-variable updates, logs, deployments, and assistant support. Link to Salesforce's Business Manager setup guides and align the included skills and documentation search with that workflow. (Thanks @clavery!)