Mar 25, 2026 | 8 minute read
written by Tony McAffee
Every commerce integration project has a moment that quietly costs hours: the moment someone has to figure out how a customer's product catalog maps to a target feed format.
It's not glamorous work. You take a CSV from Facebook or Google Merchant, open the customer's Elastic Path catalog structure, and start manually tracing field by field — what maps directly, what needs a transformation, what's missing entirely and needs to be built. For experienced architects it's a familiar ritual. For less experienced ones, it's a minefield of easy-to-miss issues: price formats in minor units vs. major units, nested objects flattened into strings, fields that look like product attributes but are actually feed-level configuration values.
Now imagine finishing that analysis in minutes instead of hours, with a structured report that's ready to anchor a customer workshop. That's what the Catalog Feed Analysis skill makes possible — and in this post, we'll walk through exactly what it does and how to use it.
One note before we dive in: this skill has been built specifically around Elastic Path Composable Commerce's catalog publish format and product extension model. But the underlying concept is platform-agnostic. If you're working with a different commerce platform, the same approach applies — you'd just need to update the skill definition to reflect your platform's catalog structure, field naming conventions, and extension patterns. The analysis logic, report structure, and design principles carry over unchanged.
When Elastic Path Commerce Cloud customers connect their catalog to external channels (Facebook Product Catalog, Google Merchant Center, etc.), they typically need a custom integration. That integration listens to the catalog publish event, fetches the Delta file from the catalog release, and transforms the product data into whatever structure the target system expects.
The design of that transformation is where projects slow down. Someone has to answer questions like:
On a typical project, this analysis happens informally, in a spreadsheet, over the course of several meetings. Important decisions get deferred. Gaps get discovered late in development. Extension field design gets improvised.
The Catalog Feed Analysis skill changes that pattern — turning a multi-session discovery exercise into a focused, AI-assisted analysis that architects can run before the first customer conversation.
The skill is built to run with any skill based AI tooling, e.g. Claude Code, and is configured by ensuring that the skill is present in the tool specific lookup hierarchy. To invoke it, you need three things — one required, two optional:
1. A sample of your target feed format (required) This is the feed you need to produce: a Facebook product catalog CSV, a Google Merchant TSV, a product feed for a ratings and review provider, or any other structured format. The sweet spot is 15–30 rows after the header — enough for the skill to assess field variability and infer the purpose of generic columns like custom_label_1, but small enough to stay within a reasonable token budget.
2. Your Elastic Path catalog structure (optional but recommended) One or a few example product JSON objects from your catalog publish format, showing the shape of your data — field names, types, and nesting. This is structure, not data rows. The skill uses it to know which Elastic Path fields are actually available for mapping.
3. Your existing product extension config (optional) If your project already defines product extension flows and fields (for example, in a config/product-extensions.json file in your repo), supply that config. The skill will map target fields to your existing extensions rather than suggesting duplicates, and will report only the net-new fields that actually need to be added.
With those inputs in hand, paste your invocation prompt into a new AI chat window and let the skill run.
The output is a structured report with seven sections, each designed to feed a specific part of the integration design process.
1. Executive summary
A quick read on scope and risk: total target fields analyzed, counts by mapping type, critical field status (SKU and price), and the number of type mismatches that need attention. If any columns in the target feed have no value variability across the sample — more on that below — they're counted here too.
2. Field mapping table
The core of the analysis. For every field in the target feed, the skill identifies the corresponding Elastic Path field path and classifies the mapping as one of four types:
Each row includes a confidence level and notes — including transformation requirements, type mismatches, and the hardcoded detection described below.
3. Critical field coverage
A dedicated check on SKU and price, the two fields most likely to cause production issues if mishandled. The report examines whether each is present in the target, how it maps, whether the types align, and how currency and tax handling should be approached. If the target feed has sale price or compare-at price columns, those are checked against Elastic Path's named sales structure as well.
4. Type mismatches
Where types don't align between Elastic Path and the target format, the report flags each mismatch with an impact assessment and a short recommendation. The most common example in Facebook feed integrations: Elastic Path stores price as a nested object with the amount in minor currency units, while Facebook expects a flat string like "19.99 GBP". That's an easy transformation to write once you know it needs to exist — but easy to miss if nobody flags it.
5. Recommendations
A concise, actionable list covering the key decisions the integration design needs to resolve: SKU mapping strategy, price conversion logic, fields that need default values, transformation steps to build.
6. Elastic Path catalog model suggestions
For target fields with no Elastic Path equivalent that are genuine product attributes — things like gender, google_product_category, or brand — the skill generates ready-to-use JSON in Elastic Path's flow and fields format. This can be used directly to create extension attributes via the Elastic Path APIs or admin interface.
A few design decisions worth highlighting here. First, the skill names extensions generically (slug: products(base)) rather than channel-specifically. A brand extension field is useful across every feed integration, not just Facebook. Second, for generic columns like custom_label_1 the skill analyzes the sample values to infer semantic purpose — if the values look like designer names, the suggested slug becomes designer, not custom_label_1. Third, if preconfigured extensions were supplied, only net-new fields are suggested. No duplicates.
7. Preconfigured extensions comparison (when applicable)
When you supply an existing extension config, the report adds a comparison table showing which target fields are already covered by your configured extensions, which are net-new, and whether there are any naming or type gaps between what's configured and what the target expects.
One of the subtler things the skill does is detect columns in the target feed that have no variability in the sample. A column where every row shows the same value — say, condition: new or brand: Acme — is likely a feed-level constant rather than a per-product attribute.
The skill flags these explicitly, recommending they be derived from feed configuration rather than stored as extension fields on individual products. It's a small thing, but it prevents a common class of over-engineering: adding a catalog extension attribute for a value that never actually varies per product.
The Catalog Feed Analysis skill is one example of a broader approach: encoding specialist implementation knowledge into reusable AI skills that can be applied consistently across projects.
The knowledge of what Elastic Path’s catalog publish format looks like, how extension fields should be named and structured, which fields are always critical, and which transformation patterns come up repeatedly — that knowledge now lives in the skill definition, not just in the heads of the most experienced architects. That means more consistent quality across projects, faster onboarding for newer team members, and more time in every engagement spent on the decisions that genuinely require human judgment.
For teams evaluating Elastic Path Commerce Cloud, this is part of what a modern implementation experience looks like: not just a platform, but an ecosystem of tools designed to make integration design faster, more consistent, and less dependent on tribal knowledge.
Want to try Catalog Feed Analysis skill on your own feed? Contact us to get access.