Workflow automation

Shopify Product Listing Package

Read source-authority-and-replay.md when combining merchant sheets, official-site data and historical imported packages.

Objective

Turn merchant, ERP, supplier, and approved official-source information into a moderate-completeness Shopify listing package. Treat the merchant-supplied description as the primary content draft: audit, preserve, improve, and fill evidence-backed gaps instead of rewriting it by default.

Produce review artifacts only. Do not upload or mutate online data.

Read:

• listing-manifest-contract.md before creating the product/variant manifest.
• adaptive-content-framework.md before auditing descriptions or defining a new category profile.
• shopify-import-guardrails.md before shaping a Shopify CSV.

Establish The Listing Contract

State before processing:

• Store and target Shopify market.
• Product and variant population with control counts.
• Declared truth source for SKU, barcode, price, weight, dimensions, claims, ingredients/materials, and other hard facts.
• Store profile and category profiles used for this batch.
• Default completeness tier: MODERATE.
• Whether content is OPTIMIZE_SUPPLIED, SOURCE_BACKED_SUPPLEMENT, or the exceptional SOURCE_BACKED_CREATE.
• Image-manifest source and image audit status.
• Explicitly excluded fields and online systems.

Do not silently fall back from MODERATE to MINIMUM.

Apply The Three Completeness Tiers

• MINIMUM: platform-required fields only. Use only when explicitly requested.
• MODERATE: required fields, legal/safety facts, purchase-decision facts, search/discovery fields, operational identity, and useful images. This is the default.
• FULL: deep storytelling, expanded FAQs, comparisons, and exhaustive supporting content. Use only when explicitly requested.

Legal, safety, allergen, compatibility, and regulated claims are never treated as optional merely because the selected tier is lower.

Separate Core Logic From Profiles

Keep the Skill universal. Put store tone, title patterns, SEO limits, allowed claims, and category-specific decision fields into a task-local store profile.

For each represented category:

1. Select an approved existing category profile.
2. If none applies, inspect the supplied description, taxonomy, official sources, and the customer's purchase decision.
3. Draft a category profile listing required and important facts.
4. Mark it REVIEW_FIRST until approved.
5. Reuse it only after approval and canonical closeout.

Do not hard-code How to Use, Size Guide, Ingredients, or any other category section into the universal workflow.

Respect Source Authority

Use the source hierarchy declared for the task. Typical responsibilities:

• ERP or supplier master: SKU, UPC/barcode, MSRP, approved dimensions, weight, or other explicitly governed hard data.
• Merchant product sheet: intended assortment, merchandising title, supplied description, price decision, and launch scope.
• Brand official source: product facts, ingredients/materials, usage/care, compatibility, claims, and approved imagery.
• Existing Shopify export: current platform identifiers and values, but not a replacement for a declared upstream truth source.

Never infer a missing SKU, UPC, price, weight, ingredient, allergen, material, certification, dimension, compatibility claim, or legal claim.

Use sku-upc-exact-reconciliation when identifiers disagree. Use product-image-asset-pipeline for image identity and quality. A future write must use shopify-product-data-safe-update.

Audit And Optimize Supplied Content

1. Preserve the original description and source reference.
2. Extract facts and identify repetition, poor translation, weak hierarchy, missing purchase-decision facts, and unsupported claims.
3. Retain substantive merchant information unless it is demonstrably incorrect, duplicated, or disallowed.
4. Supplement only from approved evidence.
5. Record additions, removals, material rewrites, sources, and unresolved gaps.
6. Arrange content according to the approved category profile.
7. Put the clearest purchase-decision summary first.
8. Generate SEO title, meta description, and keyword intent from verified content rather than mechanically truncating the long description.

Default to conservative optimization. Do not replace a complete merchant description with generic marketing copy.

Build And Validate The Manifest

Create a UTF-8 CSV following listing-manifest-contract.md. Preserve SKU and barcode as text.

Run:

python scripts/validate_listing_manifest.py `
  --manifest listing-manifest.csv `
  --profile store-profile.json `
  --output-dir listing-audit

The validator is local and read-only. It creates:

• REVIEW_FIRST_listing_normalized.csv
• REVIEW_FIRST_listing_gaps.csv
• AUDIT_listing_summary.json

It validates identifiers, variant uniqueness, product-level consistency, prices, compare-at prices, weights, options, SEO length, source evidence, content mode, category facts, image status, alt text, prohibited inventory fields, and control-count closure.

Interpret Readiness

• READY: meets the approved moderate profile with no unresolved blockers or warnings.
• READY_WITH_WARNINGS: import preparation may continue, but non-critical useful information remains missing or under review.
• BLOCKED: hard identity, price, legal/safety, required category fact, product/variant structure, source, or image requirement is missing or conflicting.

Never rename a review or blocked file UPLOAD_THIS.

Prepare Review Deliverables

Provide:

1. REVIEW_FIRST product/variant workbook or CSV.
2. Original and optimized descriptions.
3. SEO title, meta description, and keyword intent.
4. Source register.
5. Content-change register.
6. Missing/conflict report.
7. Image-manifest reference and image readiness.
8. Machine-readable audit with control counts.

Use the current store export or official Shopify template when creating the eventual import shape. Do not assume that one historical CSV schema is safe for another store.

For a large batch, stop at the reviewed CSV/XLSX and let the user upload unless the user separately authorizes another method. For roughly 1-10 products, individual Admin entry may be appropriate, but it is still a separate write task.

Hard Boundaries

• Do not write Shopify, ERP, Nordstrom/Mirakl, Target, Dropbox, or another platform.
• Do not change or populate inventory.
• Do not create identifiers or hard facts from names, images, or sequence.
• Do not convert a warning into a fact.
• Do not use a Shopify CDN URL when a partner workflow requires separately hosted direct image URLs.
• Do not treat an image filename as proof of variant identity.
• Do not overwrite the merchant's source file.
• Do not label an artifact upload-ready before user approval and import-shape validation.

Closeout

Record the listing scope, completeness tier, truth sources, store/category profiles, control counts, content changes, unresolved gaps, image audit, artifacts, validations, and systems not touched. Use canonical-task-closeout before reporting completion.

SKU UPC Exact Reconciliation

When joining operational datasets, freeze grain and source clocks as well as IDs. Product, variant, warehouse, order line and immutable snapshot are not interchangeable. Unknown, absent, stale, inactive and verified zero remain separate. A current barcode match does not prove package-size equivalence or historical inventory coverage. Route stock/history interpretation to cloud-inventory-snapshot-reconciliation; do not import one company's warehouse/STR policy as a generic identifier rule.

Objective

Determine which identifier relationships are proven, missing, duplicated, or conflicting before any product-data update. Keep this Skill read-only.

Use its outputs as evidence for a separately approved update workflow such as shopify-product-data-safe-update. Never convert an audit result directly into an online write.

Establish The Contract

Before comparing files, state:

• Authoritative source for SKU, UPC/barcode, and product grouping.
• Target system being audited.
• Exact population in scope.
• File/sheet and row-count controls.
• Column mappings and data types.
• Whether leading zeros, prefixes, or literal punctuation are meaningful.
• Explicit exclusions.

Do not assume ERP is authoritative unless the user or project rules say so. When ERP is declared authoritative, preserve its literal SKU and UPC values.

Read identity-rules.md before matching. Read output-contract.md before delivering results.

Prepare The Inputs

1. Preserve untouched source files.
2. Convert only the relevant sheet to UTF-8 CSV when using the bundled script.
3. Import SKU and UPC columns as text.
4. Preserve leading zeros.
5. Retain raw value, normalized comparison value, source row, title, variant, group ID, and platform object ID when available.
6. Record duplicate source rows instead of silently deduplicating them.

Excel display, scientific notation, and formula errors are not identity truth. Inspect the underlying cell value and source system.

Exact Matching Hierarchy

Use only deterministic identity:

1. Exact platform object or variant ID when reconciling the same platform.
2. Exact unique UPC/barcode.
3. Exact unique SKU.
4. Exact UPC and SKU pointing to the same row.
5. Explicit parent/group identifier for SPU or variant-group reporting.

Product title, shade name, image, vendor, size, and neighboring rows are review evidence only. Never create an identity link from similarity.

If exact UPC and exact SKU point to different target rows, classify CROSS_IDENTIFIER_CONFLICT. Do not choose one silently.

Keep SPU Grouping Separate

SKU/UPC matching is row identity. SPU grouping is a separate relationship.

Group variants only with an explicit source such as:

• ERP parent/product ID.
• Shopify Product ID or handle from a verified export.
• Mirakl Variant Group Code.
• Approved supplier parent code.

Do not strip shade names from titles and infer that rows belong to one SPU. When no explicit group key exists, keep rows ungrouped and mark the SPU result unknown.

Run The Local Reconciler

The bundled script compares one authoritative CSV with one target CSV:

python scripts/reconcile_identifiers.py `
  --truth authoritative.csv `
  --target target.csv `
  --truth-sku "SKU" `
  --truth-upc "UPC" `
  --target-sku "Variant SKU" `
  --target-upc "Variant Barcode" `
  --truth-title "Product Name" `
  --target-title "Title" `
  --truth-group "Parent ID" `
  --target-group "Product ID" `
  --output-dir reconciliation-output

Optional title and group columns are retained for review but never used for matching.

Outputs:

• REVIEW_FIRST_identifier_reconciliation.csv
• REVIEW_FIRST_identifier_conflicts_and_gaps.csv
• AUDIT_identifier_reconciliation_summary.json

The script makes zero network calls and zero online writes.

Interpret Results

Use these primary states:

• EXACT_BOTH: unique UPC and SKU agree.
• MATCH_BY_UPC_SKU_MISSING_TARGET: exact unique UPC; target SKU blank.
• MATCH_BY_UPC_SKU_CONFLICT: exact unique UPC; SKU values disagree.
• MATCH_BY_SKU_UPC_MISSING_TARGET: exact unique SKU; target UPC blank.
• MATCH_BY_SKU_UPC_CONFLICT: exact unique SKU; UPC values disagree.
• EXACT_UPC_ONLY: UPC proves the row; no authoritative SKU comparison.
• EXACT_SKU_ONLY: SKU proves the row; no authoritative UPC comparison.
• CROSS_IDENTIFIER_CONFLICT: UPC and SKU point to different target rows.
• DUPLICATE_CONFLICT: an identifier is not unique in truth or target.
• TARGET_REUSED_CONFLICT: multiple truth rows would consume one target row.
• MISSING_IDENTIFIERS: truth row has neither usable SKU nor UPC.
• TRUTH_ONLY: no exact target match.
• TARGET_ONLY: target row was not consumed by any exact match.

Only EXACT_BOTH is fully reconciled without qualification. Missing or conflicting fields require human review and a separate update approval.

Identifier Quality

For UPC/EAN/GTIN:

• Preserve the raw string.
• Normalize only Unicode width, surrounding whitespace, spaces, and hyphens.
• Require remaining characters to be digits.
• Preserve leading zeros.
• Record length.
• Validate standard GTIN lengths 8, 12, 13, or 14 and check digit.

An invalid GTIN check digit is a data-quality flag. It does not authorize changing the value or matching by product name.

For SKU:

• Normalize Unicode width and surrounding whitespace for comparison.
• Preserve case and punctuation by default.
• Preserve unusual prefixes and literal formats.
• Do not generate or shorten SKU values.

Close The Counts

Report:

• Truth rows and unique truth identifiers.
• Target rows and unique target identifiers.
• Duplicate values and affected row counts.
• Exact matched pairs.
• Each conflict/missing state.
• Truth-only and target-only rows.
• Invalid-format and invalid-check-digit counts.

Required controls:

• Every truth row appears once in the truth-side matrix.
• Every target row is either used by one final exact pair or emitted once as TARGET_ONLY.
• Final exact pairs do not reuse a target row.
• Output row counts match the summary JSON.

Do not call an audit complete when controls do not close.

Prepare A Correction Handoff

When the user later approves changes:

1. Re-read current target records.
2. Keep only rows with exact platform object IDs and authoritative source evidence.
3. Separate fields by owning system.
4. Create a REVIEW_FIRST field-level plan.
5. Route it to the correct specialist.
6. Use a safe-update Skill or platform-specific workflow.

Do not label reconciliation output UPLOAD_THIS. Do not include inventory, price, MSRP, images, descriptions, or taxonomy unless those fields were separately sourced and approved.

Failure Rules

• Name looks identical but identifiers differ: keep separate.
• One UPC appears multiple times: classify duplicate; investigate pack, bundle, typo, or source duplication.
• SKU and UPC point to different rows: stop with cross-identifier conflict.
• Leading zero disappeared: return to the original cell/source and import as text.
• SPU variants split into separate products: require an explicit parent key before regrouping.
• A product exists without SKU but has exact UPC: report missing target SKU; do not invent it.
• A source file is filtered or deduplicated without audit: restore the raw population and rebuild controls.
• Source systems disagree: preserve both raw values and ask which is authoritative.

Closeout

Record source files, sheet names, column mappings, authority decision, raw and unique counts, duplicate lists, output paths, validation, limitations, and systems not touched. Use canonical-task-closeout before reporting completion.

Identifier Rules

Authority

Authority is field-specific and must be declared.

One system may be authoritative for SKU/UPC while another owns customer-facing copy or images.

Raw And Normalized Values

Always retain:

• Raw source value.
• Normalized comparison value.
• Source filename, sheet, and row.
• Column name.
• Record title and variant for human review.

Normalization may remove surrounding whitespace and standard barcode spaces or hyphens. It must not:

• Drop leading zeros.
• Convert scientific notation into a guessed integer.
• Uppercase or rewrite literal SKU by default.
• Remove meaningful prefixes.
• Change check digits.

Duplicate Meaning

A duplicate identifier is not automatically an error in the source, but it is unsafe for automatic matching.

Investigate:

• Duplicate export rows.
• Same barcode reused for a multipack or bundle.
• Parent and child rows sharing a code.
• Incorrect variant entry.
• Marketplace shadow/catalog records.

Keep every affected row visible until the business meaning is proven.

Match Strength

SPU Rules

An SPU contains variants only when an explicit parent relationship proves it. Mixed status, missing images, or variant titles do not change identity.

Keep product grouping and variant identifier reconciliation in separate columns so a grouping correction cannot silently rewrite SKU or UPC.

Reconciliation Output Contract

Matrix Columns

The reconciliation matrix should include:

• Status and match mode.
• Truth and target row numbers.
• Raw and normalized SKU/UPC values.
• Truth and target titles.
• Truth and target explicit group IDs.
• Truth and target platform IDs.
• UPC quality flags.
• Human-readable reason.
• safe_for_automatic_write = false.

Required Files

• REVIEW_FIRST_identifier_reconciliation.csv: all truth rows plus target-only rows.
• REVIEW_FIRST_identifier_conflicts_and_gaps.csv: every state other than EXACT_BOTH.
• AUDIT_identifier_reconciliation_summary.json: mappings, counts, duplicate values, quality checks, controls, and zero-write declaration.

Do not create UPLOAD_THIS during reconciliation.

Handoff Boundary

A later correction handoff must add:

• Fresh target object ID.
• Current target value.
• Proposed value.
• Authoritative source reference.
• User approval status.
• Protected fields.
• Rollback value.

That handoff belongs to a platform-specific safe-update workflow, not this Skill.

Status Interpretation

Full API integration lifecycle

Use the full sequence unless the user explicitly requests one stage: (1) business contract and authoritative entities/fields; (2) actual authentication and resource permission probes; (3) exact ID/schema mapping and pagination; (4) read-only parity against authoritative records; (5) transformations, units, null semantics and boundary cases; (6) scoped write, retry/idempotency and concurrency design; (7) integration/UI acceptance with rollback; (8) deployment, monitoring and durable handoff. Record each stage in the project ledger; connecting inventory is one profile, not the entire integration capability. Confirm requested vs granted OAuth scopes and resource-level access for Zoho. Shopify GraphQL requires checking HTTP, top-level errors, userErrors and asynchronous job completion. Mirakl requires correct seller/channel authentication, full pagination and real data parity; a 200 response alone is not integration success. Cloud services require source timestamps, batch identity, complete chunks and actual request/cost counters. Unknown or stale data must not become zero or healthy. Do not store tokens in logs. Restrict writes to approved resources/fields, retry only idempotently, query ambiguous writes before repeating, and stop on permission mismatch, unbounded retries, conflicting IDs or concurrent edits.

Read capability-and-transition-parity for the additional conditional acceptance checks. Existing permissions and preservation requirements remain.

Capability probes and transition parity

Before implementation, record actual capability by organization/environment, resource, action and role. Separate requested scopes, granted scopes and a successful bounded probe. Authentication or Inventory access does not prove access to another resource such as Expenses or Pages. Label denied, unavailable and untested capabilities separately; never bypass access controls or broaden credentials by inference.

Define field ownership and mapping before association or synchronization. Record approved target-side exceptions with exact entity, field, permitted value, authorization and persistence strategy. Connection setup, first successful resource call, full business parity and ongoing preservation are different acceptance stages.

After linking, reconnecting, changing Draft/publication state or running the authorized synchronization, compare exact IDs and the intended plus protected fields against the contract. Include titles, prices, units, status and associations when relevant. Verify asynchronous completion and full population counts; HTTP success alone is insufficient. Query ambiguous outcomes before an idempotent retry.

If a source is expected to overwrite an approved target exception, expose the ownership conflict and propose a supported bounded solution. Do not silently modify global sync settings. A one-time manual repair is not persistent synchronization correctness. Keep acceptance pending for any required next-cycle observation and record its owner/checkpoint. Scheduling or additional collection requires the corresponding authorization.

Use the software delivery procedure for compatible code/configuration rollout and recovery; keep API-specific mapping, access, parity and retry evidence here. Platform behavior observed in one channel is not a universal API guarantee. Preserve the original drift and recovery history.

General software delivery and cloud release

General delivery

Use for application, frontend, backend, cloud or desktop code. Platform adapters are conditional procedures, not the definition of software development. Catalog operations remain with their operations owner; API authentication, mappings and synchronization parity belong to the API integration procedure.

Recover the approved behavior contract, repository, branch/worktree, dirty changes and current deployed identity. Protect unrelated work. Define the observable before/after result and acceptance surfaces before implementation. Implement the smallest complete change and run checks appropriate to affected behavior. Build success and source inspection do not prove runtime or visual acceptance. Preserve the same task checklist through debugging.

Prepare the exact release artifact/hash, destination, configuration delta, compatible rollback target and stop criteria. A reversible local implementation is distinct from deployment approval. Publish only the authorized candidate; compare deployed identity and run scoped live smoke checks. A worker's completion message is not a deployment receipt.

Cloud optimization and migration

Measure a reproducible baseline before claiming improvement: workload, data size, request boundaries, build, environment, observation window and relevant duration, errors, bytes, calls or cost basis. Separate synthetic measurements from production observations. Fewer stored bytes do not establish lower latency, fewer API calls or a proportional bill reduction.

For data/codec/schema changes, define old/new reader and writer compatibility, version markers, integrity checks and resource limits. Preserve the last valid committed state during interrupted writes. Where required, deploy compatible readers before enabling new writers and use a bounded canary with a supported disable-write path. Do not rewrite historical data, enable cleanup or broaden collection without authorization.

Verify readback, error signals and downstream consumption after rollout. Record initial smoke acceptance and the first required ordinary cycle separately; a future cycle stays pending until observed. Reconcile later follow-up evidence rather than retaining obsolete pending claims. Rollback must still read already-written data; disabling new writes may be safer than restoring an incompatible binary. Recheck intervening deployment changes before rollback. Define owner and next checkpoint for remaining observations without inventing a background schedule.

Visual and device acceptance

Translate the user's visual symptom into visible outcomes, not one presumed CSS property. Inspect all plausible line/layout sources including borders and pseudo-elements. Compare relevant pages, states and viewport with the same approved visual contract; preserve focus, keyboard and intentional outlines. Identify source-only, emulated, browser and physical-device evidence separately. A non-reproduced physical WebView cause remains a hypothesis, even if a defensive fix passes desktop checks.

Release identity and comparable measurement

Re-read the actual environment, store/project, theme/build ID and live/QA role immediately before every release. Names such as QA, Preview or Staging are labels, not authority. If the selected ID became live or changed ownership, stop the write, preserve the approved change set and resolve the mismatch. A previous approval to test QA does not authorize writing live. Keep this platform adapter conditional; general software development is not limited to commerce.

Create a release manifest of exact approved paths, before/after hashes, target identity, protected paths and rollback bytes. When QA contains unrelated work, release only the approved subset; an SEO batch cannot silently include analytics or cart changes. Preserve dirty work. After an ambiguous command error, inspect actual target state before retrying; never duplicate a write merely because a wrapper returned failure. Mark published, read back, interactive QA and business acceptance separately.

For performance comparisons capture requested and final effective URL, actual rendered theme/build identity, authentication/cache state, device/network settings, tool version and run ID. Reject QA preview runs that resolve to live as a QA baseline. Compare like-for-like independent repetitions, disclose variation and source timestamp. Distinguish lab scores from field Core Web Vitals. Smaller files, a passed CLI or a deployed build do not establish faster user experience. When the target cannot be proven, retain the failed sample as excluded and report improvement as unverified.

For design preserve supplied logos, recognizable people/products and brand assets unless the change is requested. Inspect desktop/mobile behavior and image crop/alpha/legibility. Record original defects separately from later taste changes; final acceptance must not erase earlier logo replacements or layout rework. Use the existing general cloud deployment, incident and rollback modules for deployment; API engineering belongs in its own integration Skill, not in the ordinary product flow.

Product Image Asset Pipeline

Objective

Turn a mixed product-image folder and an exact product/variant manifest into a reviewable asset register, channel QA report, and byte-identical staging package. Keep source images untouched and online systems unchanged.

Read channel-image-rules.md before applying channel rules. Read asset-manifest-contract.md before creating the input manifest. Read acquisition-and-recovery-handoff.md for supplier naming, swatches, import failures and gallery recovery.

Establish The Contract

Before touching files, state:

• Source folder and immutable-original boundary.
• Product/variant population and control count.
• Authority for SKU, UPC, product key, variant key, and image selection.
• Target channel: shopify, nordstrom, target, or generic.
• Allowed roles: product main, variant main, packaging, texture, lifestyle, detail, swatch, or model.
• Whether the task is audit-only or includes local staging.
• Explicit exclusions and online systems that must remain untouched.

Do not infer image identity from title similarity, folder adjacency, image color, or filename order. Use an exact UPC, exact SKU, exact platform variant ID, or an explicitly approved product-level fallback.

Preserve The Sources

1. Keep supplier, official-site, Shopify, Dropbox, or marketplace downloads in an immutable source directory.
2. Never overwrite, crop, upscale, remove backgrounds, add canvas, sharpen, or recompress a source file in this Skill.
3. Put audit outputs and staging copies in new dated directories.
4. Record source URL and source tier when known.
5. Keep ambiguous or low-quality images in REVIEW; do not improve their status by enlarging the canvas.

Build The Manifest

Create a UTF-8 CSV following asset-manifest-contract.md. Preserve SKU and UPC as text. Every row must identify one physical file and include at least one exact product identifier.

For VARIANT_MAIN, require:

• variant_key.
• Exact identity evidence such as UPC_EXACT, SKU_EXACT, UPC_AND_SKU_EXACT, or EXPLICIT_VARIANT_ID.
• An approved white-background image for that exact variant.

Product-level fallback is allowed only when the user or approved source states that the same image legitimately represents multiple UPCs or variants. Record that decision; never hide it.

Run The Audit

Use the bundled read-only auditor:

python scripts/audit_image_assets.py `
  --manifest image-manifest.csv `
  --asset-root source-original `
  --channel nordstrom `
  --output-dir image-audit

It creates:

• REVIEW_FIRST_image_asset_audit.csv
• REVIEW_FIRST_image_asset_gaps.csv
• AUDIT_image_asset_summary.json

The auditor reads images only. It records file hashes, format, dimensions, ratio, mode, alpha, edge-white score, file size, exact duplicate groups, perceptual duplicate candidates, channel findings, and final status.

Treat perceptual duplicates as review signals, not proof of identity.

Interpret Status

• READY: exact identity, approved visual review, valid file, and required channel checks pass.
• REVIEW: usable evidence exists, but quality, duplicate, source, fallback, or non-blocking channel questions remain.
• BLOCKED: missing file, corrupt image, missing exact identity, failed required dimensions/background/mode, or unapproved visual review.

Do not rename REVIEW or BLOCKED assets as upload-ready.

Stage Ready Assets

After reviewing the audit, copy only READY rows into a clean local package:

python scripts/stage_ready_assets.py `
  --audit image-audit/REVIEW_FIRST_image_asset_audit.csv `
  --output-dir staged-ready

The staging script:

• Copies bytes exactly; it does not modify image pixels.
• Refuses to overwrite existing files.
• Uses the audited deterministic filename.
• Verifies source and staged SHA-256 values match.
• Produces STAGED_image_asset_manifest.csv and STAGED_image_asset_summary.json.

Staging is not approval to upload. Dropbox, Shopify, Nordstrom/Mirakl, Target, or partner writes require separate explicit authorization and a platform-specific workflow.

Maintain Media Order

For Shopify product media:

1. Put the approved default/exact white-background product image first.
2. Put exact texture or deterministic supporting media second when available.
3. Follow with packaging, texture, lifestyle/model, detail, and swatch media.
4. Bind each selectable color variant to its exact white-background VARIANT_MAIN.
5. For a one-variant Default Title product without a variant-image selector, keep the approved white main at product-media position 1.

Do not reorder existing Shopify media unless the user approved that exact scope.

For Nordstrom and Target, use channel rules in the reference and prepare separate derivatives or packages outside this first-version Skill. Never use a Shopify CDN URL as the final partner image URL when the approved workflow requires Dropbox-hosted files.

Required QA

Close all controls:

• Manifest rows and unique physical files.
• Unique UPC/SKU/variant counts.
• READY, REVIEW, BLOCKED totals.
• Missing and corrupt files.
• Exact and perceptual duplicate groups.
• Main-image channel pass counts.
• Variant-main exact-binding counts.
• Source hashes and staged hashes.
• Staged rows equal READY rows.
• Original file modification count equals zero.

Visually inspect contact sheets or representative files before approving a large batch. Automated white-edge or duplicate signals do not replace human review for logos, text, watermarks, packaging mismatch, model crops, or incorrect shades.

Failure Rules

• Similar filename but no exact identifier: leave unbound.
• Exact binary reused across different UPCs: flag for review unless an approved product-level fallback explains it.
• Low-resolution image placed on a large canvas: keep the original resolution warning; do not call it high resolution.
• Wrong variant or packaging generation: block the asset.
• Folder-level Dropbox link: reject it as a final image URL.
• Shopify CDN in a partner workbook: replace only after a separately approved local asset and per-file direct URL workflow.
• Source image has text or watermark: require visual review; do not try to remove it automatically.
• Need background removal, expansion, retouching, or image generation: use an image-editing workflow with separate approval and preserve the original.

Closeout

Record source roots, manifest, authority decision, channel, control counts, audit/staging paths, hash verification, visual-review limitations, and systems not touched. Use canonical-task-closeout before reporting completion.