I've been writing Claude Code skills for Shopify work for about six months. Most of them died within two weeks of first use because they were scoped wrong. The six that stuck are the ones I use almost every day now. This is what they do, why they stuck, and what they replaced.
- 2025-11-14section-scaffoldOne-line brief to Liquid section file
- 2025-12-02metafield-migrateReads exports, emits migration plan (no writes)
- 2026-01-09capi-probeChecklist-driven Meta CAPI audit on a theme
- 2026-02-07admin-api-backoffLeaky-bucket wrapper around any Admin API call
- 2026-03-04theme-editor-diffMakes live-theme vs local drift visible
- 2026-04-11liquid-reviewOpinionated reviewer for sections and schemas
The common thread across all six: each one owns a single narrow responsibility and produces a diff I can review before it touches a branch. The ones that died were broad and autonomous. The ones that stuck are narrow and advisory.
The six skills that survived
2025-11-14, section-scaffold
The first skill that stuck. It generates a Liquid section from a single-line brief ("a testimonials section with an avatar, star rating, and quote, up to six per page").
Input: one line of prose. Output: a section file in the correct theme folder, a matching schema block, a metafield definition stub if the brief implies per-product overrides, and a rendered preview in a scratch template.
It replaced the first 30 to 45 minutes of every new section I used to build. What I still do myself: naming decisions, the final design pass, and deciding which layouts the section is exposed under.
2025-12-02, metafield-migrate
Reads a product, collection, or page export from the Shopify Admin API, scans for content currently living in section settings that should live on the resource, and writes a migration plan. The plan is a list of (source, destination, Liquid fallback rewrite) triples. No actual writes; it's a plan I apply manually or pass to another skill to execute.
This one I almost scoped too broadly. The first version tried to do the migration itself, which meant it needed access to the Admin API with write scopes, and it made mistakes I couldn't easily reverse. Pulling it back to "produce a plan, don't execute" was what made it survive.
2026-01-09, capi-probe
Opens a Shopify store's theme and checks the Meta CAPI wiring. It looks for the browser pixel, the server-side event endpoint, the event_id threading between them, and any consent gating. It produces a report with match-quality estimate, deduplication risk, and the specific lines of Liquid or JavaScript that need rewriting.
The value is in the checklist structure, not the LLM reasoning. Most of what the skill does is deterministic: find files, check patterns, pattern-match against known failure modes. The LLM's job is narrow, interpret ambiguous cases and explain the finding in plain language. I've written about the underlying CAPI deduplication logic in the Shopify Pixel and CAPI event_id walkthrough; the skill encodes that walkthrough as an executable checklist.
2026-02-07, admin-api-backoff
Wraps any Shopify Admin API call in a leaky-bucket backoff with jitter, logs every retry, and emits a report if the call chain crosses a threshold. I built it after a batch metafield update melted a dev store's API quota three times in one afternoon.
It's the smallest of the six and the one I use most. The skill itself is maybe 80 lines. It's paired closely with the Shopify Admin API rate-limit pattern which describes the math behind the backoff; the skill just automates the math.
2026-03-04, theme-editor-diff
Runs against the current deployed theme and the local development copy, produces a diff of the JSON customization files, highlights settings the merchant has changed in the theme editor that local hasn't picked up, and flags local schema changes that would drop merchant data on next deploy.
This one replaces the thing I hated most about Shopify theme development: the silent drift between theme editor state and local code. The skill makes the drift visible. It doesn't resolve it, that's still a judgment call, but visibility is almost all of the fight.
2026-04-11, liquid-review
A code review skill specifically for Liquid and section JSON. It looks for the anti-patterns I've watched myself make over and over: unbounded block schemas, section settings doing metafield work, unnecessary theme app extensions, Liquid logic that should be in a snippet.
Every section I ship gets run through this before I commit. It catches an average of one legitimate issue per three sections. It's not a static analyzer, it's an opinionated reader.
What the six months taught me
“The skills that survive are narrow, advisory, and produce a diff I can review. The ones that die are broad, autonomous, and ask me to trust them.”
The biggest misconception I had when I started writing skills was that the value was in generation speed. It's not. The value is in reviewability. A skill that writes a 500-line section in 20 seconds is useless if I can't understand why it made the choices it made. A skill that writes the same section but emits a small diff and a rationale is worth an afternoon of human work.
The second lesson was about scope discipline. Every skill I wrote that tried to own more than one step in a workflow eventually produced a change I couldn't trace. Every skill that owned exactly one step, a scaffold, a migration plan, a check, a review, stayed useful. The boundary is the smallest unit of work where I can read the output in under a minute.
The third, which I didn't expect, is that skills are self-documenting in a way internal shell scripts never were. A skill has a description, an input contract, and an output format. When I come back to a skill four months later, the skill tells me what it's for. My old bash one-liners didn't do that.
I've documented the full agent-orchestrated version of this approach for bigger builds in the agent-orchestrated Shopify pipeline post, where the same philosophy gets applied across multiple skills running in sequence. The field notes here are the solo-developer version.
The skills pack
These six and about fifteen others ship in the Claude Code Skills Pack. They come with install instructions, input/output schemas, and the Liquid patterns each one encodes. If you write Shopify themes for a living, the pack pays for itself in the first migration.
For the bigger architectural picture these skills sit inside, see the DTC Shopify theme architecture for brands past 2M. For the case study that proved out the full agent-driven page generator (which uses a subset of these skills under the hood), see the AI page generator build.
What are Claude Code skills and how do they work for Shopify development?
Skills are named procedures Claude Code can invoke on your behalf, described in a SKILL.md file and optionally paired with supporting scripts and references. For Shopify work, a skill might scaffold a new section, migrate content between storage layers, or audit a theme for CAPI wiring. The skill owns one narrow responsibility; Claude Code orchestrates when and how to run it.
Can a Claude Code skill safely write to a live Shopify store?
It can, but I don't let mine. All my skills produce plans, scaffolds, or reviews, not direct writes. The write step stays human-driven. This keeps the skill cheap to audit and cheap to reverse. If you need an autonomous writer, scope it to a dev store and gate the production push behind a manual confirmation.
How do I scope a Claude Code skill so it actually stays useful?
Pick the smallest unit of work where you can read the skill's output in under a minute and know whether it's correct. Generation, not orchestration. One input contract, one output format. Anything broader tends to fail silently the first time you look away.
Do these skills work on any Shopify theme or only Online Store 2.0 themes?
Online Store 2.0 only. The section scaffold, metafield migration, and theme editor diff skills all depend on JSON templates, section groups, and metafield definitions. Vintage themes (pre-2.0) need a different toolkit; I'd treat those as rewrite candidates before trying to wrap skills around them.
What Shopify Admin API scopes do these skills require?
The read-only skills need read_products, read_themes, and read_metafields. The migrate-plan skill reads those same scopes. None of my production skills request write scopes; writes go through a separate, explicit deploy step. Keep the access narrow; it's both safer and easier to audit.
Is it worth building custom Claude Code skills if I only work on Shopify stores occasionally?
Probably not custom ones. Install a pack someone else has maintained and use those. Custom skill authorship pays off when you're shipping Shopify work weekly. If you're shipping monthly or less, the payoff is in the pack, not the authoring.
Sources and specifics
- Claude Code skills matured as a feature through late 2025 into early 2026, with the SKILL.md convention stabilizing in Q4 2025.
- The AI Shopify page generator CLI (194 source files, ~54K lines of tooling) uses a subset of these skills under its orchestration layer.
- All six skills target Shopify Online Store 2.0 themes with JSON templates and section group composition.
- Admin API rate limits referenced are the leaky-bucket defaults on Shopify Plus plans (40 requests per second per store) as of 2026.
- None of my production skills request write scopes on the Shopify Admin API; writes are gated behind manual confirmation.
