Shopify's skeleton theme is a theme with the section model removed

No sections, no JSON templates, no presets

The description says it is a minimal Shopify theme built on block-first composition, where templates compose each page directly from blocks, snippets and inline markup, with no sections and no JSON templates. The stated purpose is to stay lean and to be edited by coding agents as readily as by people, and the non-negotiables section turns that into a list of prohibitions. There is no `sections/` directory and no `{% section %}` or `{% sections %}` tags, no JSON templates and no schema `presets`, no Liquid embedded assets, so the `{% stylesheet %}` and `{% javascript %}` blocks are out as well. That is a sharper departure than it first sounds. Most Shopify themes reach for a section when a page needs a configurable region, and this one answers that with blocks and inline markup instead, so a developer arriving with section habits will have to unlearn them.

Templates are composition roots

The flow is described as one-directional, from `templates/*.liquid` to a `{% block 'container' %}` to blocks, snippets and inline markup. In this theme, templates are Liquid files rather than JSON, and each one is a composition root that wraps its page content in one or more `container` blocks, one per vertical slice, composing blocks, snippets and inline markup inside them. The layout, by contrast, renders `content_for_layout` in a plain `<main>` and reserves the `container` block for the header and the footer only. That split is the architectural centre of the theme. A template owns the vertical structure of a page, and the layout owns the chrome around it. The `index.liquid` example makes the pattern concrete:

{% block 'container' %}
  {% block 'hello-world' %}
    {% block 'liquid-tips', tips: ['hello_world.liquid_tips_1', 'hello_world.liquid_tips_2', 'hello_world.liquid_tips_3'] %}{% endblock %}
  {% endblock %}
{% endblock %}

One file per block, with a doc header and a schema

Blocks are the theme's building units, and each one is a single file in `blocks/` with a specific shape. It opens with a `{% doc %}` header describing its parameters and ends with a `{% schema %}`, with no `presets`. A block renders caller supplied content through `{{ content }}` and keeps `{{ block.shopify_attributes }}` on its root element so the theme editor can work with it, while self contained blocks can omit the content outlet and accept an empty body. The `container` block owns a page region's outer layout element, and `blocks/hello-world.liquid` is the starter demo block. The absence of presets is the part that changes behaviour for a merchant, since presets are what the theme editor uses to offer configurations, so a block here is defined by its schema and its documentation rather than by a set of pre-baked settings.

Parameters are plain named arguments

The parameter rules are spelled out, and they are the kind of detail that saves an afternoon. Executable `{% block %}` calls belong only in `layout/` and `templates/`, and nested calls stay in the caller owned body rather than in a block or snippet implementation, with the body rendering in the caller's scope before the block implementation, so it cannot read that block's settings or local assignments. All parameters are passed as plain named arguments, as in the container example:

{% block 'container', alignment: 'center', tag: 'div' %}
  {{ page.content }}
{% endblock %}

Every argument is a plain variable inside the block, so because the container schema declares `alignment`, that argument also sets `block.settings.alignment` and both reads return `center`, while `tag` has no matching schema setting and is only the variable `tag`, and `class` is likewise an ordinary parameter with no special platform behaviour. LiquidDoc documents parameters, it does not declare, validate or bind them, and the guidance is to use schema settings for merchant editable controls and to say in the documentation whether body content is required or optional.

Assets live in files, not in Liquid

The CSS and JavaScript section is a short rule with a long consequence. All theme CSS and JavaScript live in `assets/` rather than being embedded in Liquid, which keeps blocks focused on markup and does not require assets to live in a single file. In practice that means the `{% stylesheet %}` and `{% javascript %}` blocks that many themes still carry are gone, and the theme directory listing shows the standard set of folders, with `assets` for CSS, JavaScript and other static assets, `blocks` for reusable customizable UI components, `config` for global theme settings and customization options, `layout` for top level page wrappers, `locales` for translation files, `snippets` for reusable Liquid code or HTML fragments, and `templates` for the composition roots, one per page type. There is a `.theme-check.yml` in the root, which is the configuration for Shopify's theme check linter, and a `.shopifyignore` for files excluded from the upload.

Partial updates without a full page reload

The theme supports partial updates, which mark named regions of server rendered HTML that JavaScript can update without reloading the page. The rule is to wrap only the content that actually changes. In this theme, `blocks/liquid-tips.liquid` wraps the tip sentence in `{% partial 'liquid-tip' %}...{% endpartial %}`, and `assets/liquid-tips.js` refreshes it with:

import { partials } from '@shopify/partial-rendering';

await partials.refresh('liquid-tip');

The Liquid region name and the JavaScript target have to match, and `refresh()` fetches and applies updates from the current page URL. Where you need control over the request or the update is not yet visible, the README says to use `fetch()` followed by `apply()`, and to fetch related regions together. Build URLs from the current page URL or the Liquid `routes.*` values so that requests keep their locale and market routing, and note that `apply()` preserves focus, text selection, form values and scroll position, which is the reason to use it rather than replacing markup by hand.

Getting it running needs the Shopify CLI

There is no build step of its own, so the toolchain is Shopify's. The prerequisite is the latest Shopify CLI, which helps download, upload and preview themes, and for VS Code users the Shopify Liquid extension, which provides syntax highlighting, linting, inline documentation and autocompletion for Liquid templates. The repository is cloned with git or with the CLI:

git clone [email protected]:Shopify/skeleton-theme.git
# or
shopify theme init

and previewed with:

shopify theme dev

The theme architecture documentation on shopify.dev is the reference for how the pieces fit together, and `AGENTS.md` is named as the source of truth for the theme's dialect and for the full set of rules that coding agents follow. The presence of that file is itself a signal about the project, since the target audience includes agents editing Liquid, and a dialect that has to be written down precisely enough for a model to follow is a dialect with fewer ambiguities than a conventional theme.

MIT licensed, one release, and a deliberately narrow scope

The README carries an MIT licence badge pointing at `LICENSE.md`, even though the platform classifies the repository licence as a custom one that it cannot map to a standard identifier, so the file itself is the text to read. The release history is short, with a single tag, v1.0.0 published on 2025-05-20, and the last push was on 2026-10-01, so the theme is being touched even though it has not been cut into further releases. The repository also carries a `CONTRIBUTING.md` and a `CODE_OF_CONDUCT.md`, and the CI workflow badge points at `actions/workflows/ci.yml`. What the scope costs you is worth stating plainly. A theme with no sections and no presets gives you a very small surface to learn and a very small surface for an agent to get wrong, but it also means the merchant facing editor will not offer the configuration options a section would have, and any third party snippet or app that expects to inject a section will not work the way it did before.

Editorial conclusion

Adopt the Shopify skeleton theme when you are building a theme from scratch and want a small, explicit set of rules instead of the section and JSON template model, because every page composes from blocks and the constraints are written down in the repository. Do not adopt it if your plan depends on the theme editor's section model or on shipping preset configurations, since the theme deliberately excludes `sections/`, the `{% section %}` tags and schema presets. Verify first that the apps and integrations you need expose their content through blocks, and read `AGENTS.md`, which the README names as the source of truth for the theme's dialect and the rules coding agents follow.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. Shopify/skeleton-theme on GitHub