agentsclimarketplace
Sign in

Claude squarespace skill

Skill SipMyBeers/claude-squarespace-skill

Port a designed static/custom site (Cloudflare Pages, a static build, a Figma-to-code export, etc.) INTO Squarespace 7.1 by pasting markup into Code Blocks and CSS into the Design / Custom CSS panel, and driving the admin via a browser. Use this WHENEVER the task involves editing a Squarespace 7.1 site's Custom CSS or Code Injection, pasting HTML/CSS into a Squarespace Code Block, making a Squarespace site match an existing design, or debugging why a Squarespace page "looks off," has invisible text, a white/blank hero, broken mobile, giant mobile headings, a stuck image carousel, an empty/oversized footer section, or unstyled pasted markup. Also use for Squarespace + WebGL/canvas heroes, native Form Block styling, and "make it match the Cloudflare/worker version." These platform behaviors are non-obvious and have burned real sessions — consult this before hand-editing, not after.From its SKILL.md

Install
npx -y skills add SipMyBeers/claude-squarespace-skill

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

3 things to look at

  • 22 days oldThe repository was created 22 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

14.4 KB, ~3.3k tokens by cl100k_base, as published. Nobody here has run it

Porting a designed site into Squarespace 7.1

Squarespace is not a blank canvas. It injects its own CSS, strips some of your code, wraps everything in fluid-engine grids, and its editor preview lies about mobile. Every item below cost real debugging time. Read the relevant section before editing, and verify by measuring, not by eyeballing.

The two facts that reframe everything

  1. Custom CSS lives at Design → Custom CSS — direct URL https://<site>.squarespace.com/config/design/custom-css. It is NOT under Settings, NOT "Website > Styles", and NOT at /config/custom-css. A capable agent looked in all those places, concluded there was no Custom CSS panel, and almost put global styles into a per-page Code Block instead. If you can't find it, you're looking in the wrong place — go to /config/design/custom-css.

  2. Squarespace strips <style> out of Code Blocks but keeps <script>. So when you paste a page whose markup and CSS lived together (a <style> block + HTML in one Code Block), the HTML renders and any <script> runs, but the CSS silently vanishes — the page looks unstyled/broken. All CSS must go in Design → Custom CSS. Markup goes in Code Blocks; CSS goes in the global panel. Keep them separate.

Where things go (the porting architecture)

  • Global stylesheet (your design system + every page's rules) → Design → Custom CSS. One big pane. This is the single source of truth for styling.
  • Per-page body markup → one Code Block per page (Squarespace 7.1 "Code" block). Paste the source page's <body> content. Use absolute asset URLs (see Assets below) or upload to Squarespace and swap the URLs.
  • Site-wide chrome (nav bar, footer, a logo marquee, ambient background, scroll reveals) that the source injects via JS at runtime → rebuild via Settings → Advanced → Code Injection (Header and Footer run site-wide on published pages) or as pure CSS. It does NOT come for free.
  • Assets (images, video) → host on the reference build (e.g. Cloudflare Pages) and reference by absolute URL, OR upload into Squarespace. If a WebGL/canvas hero reads images cross-origin, the host MUST send CORS headers (see WebGL below). Pick ONE host per asset and know which it is — an image uploaded to Squarespace is re-served from images.squarespace-cdn.com/<hash>/, a different origin from your repo/Cloudflare copy, so editing the repo copy changes nothing on the live site. This bites hardest on mobile image swaps: a hero that does src.replace('.jpg','-m.jpg') on an uploaded image builds a Squarespace-CDN URL for a -m.jpg that was never uploaded there → 404 on every phone (and the editor, running at desktop width, hides it). Rebuild the swapped URL against the host where the -m crops truly live. Full writeup + fix: references/gotchas.md §6 "swap-target trap."

Saving Custom CSS reliably (this WILL bite you)

The Custom CSS CodeMirror editor does not reliably persist a programmatic setValue() — Squarespace's dirty-tracking doesn't fire, so clicking Save appears to work but silently reverts on reload. Reading the editor buffer back looks correct (it holds your unsaved text) which fools you into thinking it saved.

The reliable save sequence:

  1. Set the value (paste or cm.setValue(...)).
  2. Click into the visible code and make a real keystroke (type a char, e.g. /*x*/, or space+backspace on an actual code line) so the field is marked dirty.
  3. Click Save.
  4. Navigate away and back, then re-read — confirm the persisted length and that a marker string from your addition is present. Do not trust the buffer; trust a fresh reload.

Always verify persistence this way. Multiple "successful" saves in one session silently reverted and lost hours of work before this pattern was found.

LESS gotchas (Custom CSS compiles as LESS, not plain CSS)

Squarespace runs Custom CSS through an old LESS compiler. Plain-CSS things that LESS mangles:

  • saturate(), contrast(), invert(), grayscale(), hue-rotate() are LESS color functions expecting different args. A one-arg CSS filter like filter: saturate(1.3) errors ("requires at least 2 args") and kills the whole rule — a blurred backdrop collapses to flat black, etc. Wrap the entire filter value in LESS escape: filter: ~"blur(44px) saturate(1.3)". Escape backdrop-filter too. Don't double-escape (~"~"..."").
  • svh/dvh/lvh viewport units are dropped. height: 100svh is silently discarded and the element falls back to its min-height. Use vh.
  • A comment containing */ closes early. Writing body/*/a in a comment terminates the comment, and the parser's error recovery then swallows the next rule (e.g. your entire :root variable block → every var() resolves to nothing, styling collapses site-wide). Never put */ inside comment prose.

Sanity-check any CSS you generate: balanced /* */, balanced { }, :root survives a comment-strip, all filters escaped.

Invisible content: sections carry their own theme

Squarespace sections set their own text color and background. Pasted markup inherits them, so:

  • Dark-on-dark / white-on-white headings. Sections set color: rgb(19,19,16). Your headings inherit it → invisible on a dark page. Set colors explicitly on your components (.your-heading{color:#fff}), never rely on inheritance.
  • The white/blank hero or page. Section backgrounds paint through an absolutely-positioned div.section-border overlay — NOT .page-section, NOT .section-background, NOT body. A white .section-border sits over your dark canvas and hides everything (and any ambient background). Fix: .section-border{background-color:transparent!important;background-image:none!important}. To find this class of culprit, scan every element for large light-colored boxes (getBoundingClientRect().width>500 && light backgroundColor) — the overlay is a sibling, so walking ancestors will never find it.
  • .preFade hides your content. Squarespace stamps .preFade (opacity:0) on headings AND paragraphs inside Code Blocks and expects its own fadeIn script to reveal them — which does not fire for your markup, so text stays invisible. .preFade,.preFade *{opacity:1!important}.

Injected chrome doesn't run; rebuild it

If the source site builds its nav/footer/clients/reveals with a runtime script (app.js, tbn.js, etc.), that script does not run on Squarespace. You must rebuild that chrome:

  • Nav / footer / logo marquee → HTML in a Header/Footer Code Injection script (site-wide, runs on published pages) or as static markup + Custom CSS.
  • Scroll-reveal animations ([data-reveal]{opacity:0} that a script flips to .in) never reveal → add a CSS failsafe so content shows regardless: @keyframes rev{to{opacity:1;transform:none}} [data-reveal]{animation:rev .35s 1.2s forwards}.
  • Other globals that can't be pasted as-is: img{display:block} (scope it to your components), and any heading margins — Squarespace's reset zeroes margin on h1/h2/h3, collapsing spacing you relied on; restore explicitly.

The mobile zoom-out cascade (the biggest mobile trap)

Symptom: on a real phone, headings are gigantic, hero is wrong, footer is broken — "the whole site looks like desktop shrunk down." Cause:

One element wider than the viewport → mobile Safari zooms out → the layout viewport grows past your @media (max-width:760px) breakpoint → mobile rules stop applying → the page renders desktop styles scaled down.

The usual overflow culprit is a full-bleed marquee/track that is thousands of px wide (width: max-content) but whose clip isn't containing it on-device. Fix the overflow first, everything else follows:

html,body{overflow-x:hidden!important}
.your-marquee,.your-full-bleed{overflow-x:hidden!important;max-width:100vw!important}

Then add mobile clamps as backup (headings that had no mobile size, footer that didn't stack). See references/gotchas.md for the full mobile playbook.

The editor preview lies about mobile — verify on a real device

  • Squarespace's "Mobile View" toggle forces a fixed viewport (~428px), so it cannot reproduce the on-device zoom-out — the very bug you're chasing won't show there. It's fine for CSS-only checks (a heading font-size, a footer that stacks) but not for overflow/zoom behavior.
  • A JS-driven hero initializes at load-time width. In the editor preview it inits at desktop width, so mobile image swaps (-m.jpg etc.) don't reflect — the preview shows the desktop image even in "Mobile View." On a real phone the script runs at mobile width and behaves correctly.
  • Browser-automation window resize may not change the rendering viewport (it kept reporting desktop width). You cannot fully trust it for mobile.
  • Bottom line: make the CSS fix, verify the CSS-only parts in the editor mobile preview, and have the human hard-refresh the published site on their actual phone to confirm JS/overflow behavior. Hard-refresh matters — cached stale assets (e.g. old -m.jpg) mask fixes.

Desktop and mobile designs don't always translate

A wide (e.g. 3:1) hero image with object-fit:contain + a blurred backdrop fill looks great on a wide screen, but on a tall phone the contained wide image becomes a tiny strip surrounded by huge blurred/tinted edges. Mobile needs its own treatment — portrait crops (-m.jpg) with object-fit:cover that fill the screen. Don't force the desktop treatment onto mobile; give mobile a @media block that fits a tall screen. When the client says "make mobile like desktop," translate intent (full-screen, on-brand), not the literal CSS.

WebGL / canvas hero: cross-origin textures

Symptom: a canvas image-morph carousel shows the same one image for every slide while captions change. Cause: the hero uploads images into a WebGL texture, but the images are cross-origin (hosted on your reference build, loaded on the Squarespace domain). WebGL taints a cross-origin <img> unless it opts in with crossOrigin='anonymous' — without it, texImage2D throws SecurityError and every slide sticks on the one texture that loaded. The server sending Access-Control-Allow-Origin:* is necessary but NOT sufficient; the <img> element must set crossOrigin before .src.

Fixes, in order of preference:

  1. Header Code Injection shim that sets crossOrigin on your-domain images before they load (works without touching the hero code block): overrides the HTMLImageElement.prototype.src setter to set this.crossOrigin='anonymous' when the URL is your asset host.
  2. If you must disable WebGL entirely, override getContext('webgl') to return null so the hero falls back to a plain <img> crossfade (needs no CORS) — but you lose the effect. Prefer #1.

Verify the theory directly: load a cross-origin image with and without crossOrigin into a throwaway WebGL context and check texImage2D — you'll see SecurityError vs ok.

Native Form Block styling

  • The submit control is a <button class="form-submit-button">, not input[type=submit]. Target the button (and .form-button-wrapper button).
  • Form inputs refuse a background — even inline !important is ignored. Put the fill + border on the wrapping .field, leave the input transparent/borderless, and use :focus-within on the wrapper for focus.
  • The notification/storage email is a form setting (form Storage → Email), not CSS. Field labels are content, edited in the form's field editor.

Fluid-engine sections reserve empty height

A section built with the fluid-engine grid reserves its grid rows even when the content is short → a tall, empty footer/section. Collapse it:

footer .fluid-engine{display:block!important;min-height:0!important;height:auto!important}
footer .fe-block{position:relative!important;inset:auto!important;width:100%!important;height:auto!important;grid-row:auto!important}

(or resize the block in the visual editor).

Verify by measuring, not by screenshots

Screenshot review is how an invisible heading and a white canvas both shipped in this session. For parity work, diff computed styles between the live Squarespace element and the reference-build element (font-size, weight, family, color, text-transform, line-height, aspect-ratio, object-fit, grid-template- columns) and report the diff count. "Looks better" is not "matches." Do a red-on-yellow test when computed style says visible but nothing paints — if the forced color paints, the element renders and something else (a covering sibling, inherited color) is the real problem.

Working alongside other agents

Know your capabilities and don't collide. Claude Code here has filesystem + terminal + browser (edit the local repo, deploy to the reference build, AND drive the Squarespace admin via the browser extension). A browser-only agent (e.g. Comet's built-in assistant) has no filesystem and can't work from ~/Projects/... — it can only edit through the Squarespace UI. Two agents editing the same live Custom CSS / Code Block concurrently will clobber each other (made worse by the flaky save). Coordinate: one editor at a time, and hand off the non-obvious facts (Custom CSS location, the save ritual, the WebGL crossOrigin dependency) rather than letting the next agent rediscover them.

Detailed playbooks

For the exhaustive checklist, the mobile playbook, and copy-paste CSS snippets, read references/gotchas.md.

What ships with it: 3 files

19.3 KB alongside SKILL.md

references/

Keep looking

Skills are one crate of 326,452. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.