shop-redesign

Redesign / restyle an EXISTING store that already has real data (pages, blog, content types/records, media) on this multi-tenant content platform via the shop MCP server — WITHOUT destroying data, changing URLs, or taking the live site down. Works on a DRAFT theme, reuses the real catalog (never seeds/wipes), preserves url_keys & menu handles & core features, screenshot-verifies on the draft, then publishes with instant rollback. Use when the user says "redesign this store", "restyle the theme", "make it look like <design> but keep my products", or when a store already has content and only the LOOK should change. Do NOT use for a brand-new/empty store — use shop-builder for that.

Restyle a live store that already has data. The risk profile is the opposite of shop-builder (which creates data + seeds demo): here the job is to preserve every product, URL, and feature while changing only the look. Get this wrong and you break links, lose data, or take the storefront down.

Read shop-core-rules first — §A (confirm plan), §B (extract design spec), §C (images), §D (verify on draft), §E (links), §F (design contract), §G (palette) + §G.2 (Tailwind utility classes), §H (NO-HARDCODE), §I (durability). This skill adds the data-safe workflow around them.

It composes shop-build-section (sections, palette via core §G) and Layer-2 storefront-theme-design (Liquid/templates), wrapped in a safe redesign workflow.

The four rules (non-negotiable)

1. Never edit the live theme. Work on a DRAFT. customize_theme clones the active theme into a draft; ALL edits go there. The live storefront keeps serving the OLD theme untouched until publish_draft_theme. This is both the safety net and the rollback.
2. Reuse real data. Never seed or wipe. Bind new sections to the store's EXISTING products/collections/pages. Do NOT create_product/create_collection demo data, do NOT delete or recreate the catalog. (Only seed if inventory proves the store is genuinely empty — and say so first.)
3. Preserve URLs. Keep every existing url_key (products), collection slug, page slug, blog slug, and menu handle. Changing them breaks inbound links, bookmarks, and SEO. A redesign changes markup/CSS/settings, not addresses.
4. Preserve core features. Quick-search/autocomplete, cart drawer, account, wishlist, mobile nav, currency/locale switchers, checkout. Restyle them; never strip them — unless the user's design explicitly removes a feature.

Step 0a — PLAN EVERYTHING first (builder-grade orchestration)

A redesign is a FULL-SITE pass, not "restyle the homepage" — the classic fail is a new home while every other page still wears the old theme. After the inventory (Step 1) + spec (Step 2.5), call update_plan with one step per region/page, top to bottom:

• global palette/typography tokens (one set_global_settings),
• the CHROME: header (incl. the active-nav state below) + footer + mobile burger,
• EVERY page/template the inventory found — home, each CMS page, collection/PLP, product/PDP, blog list + article, cart, search, 404 — each as its own step,
• the motion/effects pass, the §D verify pass, the publish. Flip a step done only after it's built AND seen rendering. Delegate independent sections (one build_section_task per section, in parallel) exactly like shop-builder — don't run out of room and leave the bottom half of the plan untouched. Build + place each section ATOMICALLY, top to bottom (build_section then immediately set_section_settings { position: i }, never batch — core §K) so the live preview fills in region by region. If an approved mockup was handed to this redesign (the draw-first gate, shop-design-concept), match it region by region — its data-mock-region order is your section order.

Step 0 — Confirm the plan (core §A, higher bar)

This touches a live store with real data, so after the inventory (Step 1) and design extraction (Step 2.5), present a concrete redesign plan and WAIT for explicit approval before any write. Show: which theme is cloned to a draft, the new look (palette/fonts/sections), that existing products/URLs/data are preserved (nothing wiped), what new pages/menus (if any) get added, and that nothing goes live until you publish. Ask "Proceed on a draft? (or adjust)". The draft means the live site is untouched until the final publish — itself the last confirmation point.

Step 1 — Inventory what exists (BEFORE touching anything)

Map the real data so the redesign binds to it, not to invented slugs (ties into core §E):

• get_context → org / store / active theme id (the one to clone).
• list_products (note url_keys), list_collections (note slugs), list_categories.
• list_blog_posts, list_content_types + list_content_records (if a content site).
• Pages & menus have no dedicated list tool → escape hatch: introspect_schema then graphql_query for pages/menus (capture page slugs + menu handles + items).
• list_theme_files on the active theme → the current sections/templates you're restyling.

Write down every URL that currently resolves — these are the targets your new sections/menus/CTAs must point at.

Step 2 — Open a draft

customize_theme → a draft theme id. From here every build_section/set_section_settings/set_global_settings/upsert_theme_file targets the draft. Confirm the live active_theme_id (step 1) is DIFFERENT from the draft id — that difference keeps the live site safe.

Step 2.5 — Extract the target design spec

A redesign "that doesn't look like the design" almost always skipped this. Do the core §B protocol on the new design: get the real reference in front of you, write an exact per-section spec (layout/grid, exact hex, fonts, spacing/radius/shadow, imagery, components). It's your build target AND the Step-4 grading checklist.

Step 3 — Redesign on the draft

• Global look first: set_global_settings with the extracted hex/fonts (core §G). Write custom Liquid/CSS where stock sections only get "close" (a reused preset looks like the OLD theme).
• Sections: shop-build-section per design block, full {% schema %}, bound to the real content types/records from step 1 (core §H). Restyle existing chrome (header/footer/search) by reading the current file first and keeping its functional bits (rule 4).
• Templates: set_section_settings to arrange sections on index, collection, product, etc.
• Recommendation areas (PDP/home/cart): use Product Blocks with the store's real products if the design has them (core §H / shop-build-section).
• Do NOT touch the catalog, pages content, or menu targets — only their styling/placement. If the design needs a NEW page or nav entry, create it (new slug/handle), but keep all existing ones.

3a. Chrome upgrades that make a redesign feel "pro"

• Active-nav highlight (highlight the nav item of the page you are on): in web-header, mark the nav link whose URL matches the current page — compare each item's URL against the current request path in Liquid (or a 3-line inline script comparing location.pathname, normalizing the trailing slash), then set aria-current="page" + an .is-active class styled from the global tokens (accent underline/dot — not a hard-coded hex, core §G). Home (/) must match exactly, never prefix-match everything.
• Sticky header with a subtle scrolled state (background/shadow shift), restyled search/cart/account icons — keep their function (rule 4), mobile burger per core §L.

3b. Effects / motion pass

Per shop-design-taste: scroll-reveal via the theme's built-in data-anim="fade-up" on section headings/media + data-anim-stagger on grids (the runtime handles it — NEVER load GSAP/AOS in a section); hover states on cards/buttons (background shift / small translateY, ~200ms); carousels prefer CSS scroll-snap. Hero richest, body prose calmest — effects season the page, they are not the meal.

Step 4 — Verify on the DRAFT (mandatory gate — core §D)

screenshot_preview { theme_id:"<draft>" } — preview token, never the live site. Apply the full core §D gate: every page/template (not just home), every section incl. header/footer at mobile/tablet/desktop, grade attribute-by-attribute against the Step-2.5 spec (any mismatch = FAIL, 3–5+ iterations), exercise interactivity, walk every link (core §E — every target a REAL URL from step 1). Biggest hard fail: still looks like the OLD theme (reused preset) → rewrite the markup. Confirm the preserved core features still respond. Diverging / design doesn't cover a page → STOP and ASK (don't improvise).

Step 4.5 — COMPLETENESS GATE (before publish)

Walk the Step-0a plan top-to-bottom against full-page screenshots: is EVERY page restyled (not just home)? Header shows the new chrome + active state on each page? Footer new everywhere? Any plan step still pending → build it NOW. Also confirm the draft theme OWNS (or inherits) every section type that the store's CMS pages/blog posts reference in their sections documents — the platform's publish guard will refuse a draft that's missing types pages still use (it lists them); fix by get_theme_file from the live theme + upsert into the draft, never by removing the page's sections.

Step 5 — Publish + rollback

• Only once the draft matches: publish_draft_theme, then clear_storefront_cache. If publish is REFUSED with "missing section type(s)", that's the completeness guard from Step 4.5 — copy those sections into the draft and retry; do NOT strip them from pages.
• Rollback = the previous theme id (step 1) still exists — re-publish it (or customize_theme again) to instantly restore the old look. Nothing was destroyed because all edits were on the draft.

Durability (core §I)

MCP writes are live on the running store and authoritative for it.

What this skill does NOT do

• Brand-new / empty store → shop-builder.
• Turn a shop into a content/brochure site → shop-content-site (commerce_enabled=false).
• Bulk content/data changes → shop-create-content-type.