td-ai-tools 1.2.11 → 1.3.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "td-ai-tools",
-  "version": "1.2.11",
+  "version": "1.3.2",
   "description": "Install agent skills and packs into your project",
   "type": "module",
   "scripts": {

package/skills/README.md

@@ -14,9 +14,9 @@
 - `pr-solver`: Resolve GitHub pull request feedback by querying unresolved review conversations with the GitHub GraphQL API…
 - `pull-request`: Generates well-structured GitHub pull request descriptions for Shopify theme development teams by analyzing…
 - `pull-request-statamic`: Generates GitHub pull request descriptions for Statamic and Laravel development by analyzing git diffs and…
-- `record-changes`: Update `docs/changes.md` by summarizing the current branch against the primary development branch.
 - `shopify-cli`: Shopify CLI workflows for theme development.
-- `shopify-lint`: Run Shopify CLI Theme Check and Theory Digital's bundled Liquid and JavaScript rules together, linting…
+- `shopify-lint`: Run Shopify CLI Theme Check and Theory Digital's bundled Liquid, JavaScript, and CSS rules together, linting…
+- `shopify-pre-pr`: Prepare a Shopify theme branch for pull request.
 - `stylesheet-migration`: Migrate Shopify Liquid `{% stylesheet %}` blocks into theme CSS assets using bundled Python scripts.
 - `td-js-vanilla-rules`: Theory Digital vanilla JavaScript standards for Shopify theme work.
 - `td-review`: Run parallel code review agents on a PR (including TD theme compliance) and produce a synthesized findings…

package/skills/shopify-lint/SKILL.md

@@ -1,14 +1,14 @@
 ---
 name: shopify-lint
-version: 1.4.0
-description: Run Shopify CLI Theme Check and Theory Digital's bundled Liquid and JavaScript rules together, linting modified .js files and the JavaScript inside Liquid javascript blocks, while reporting and failing only on offenses in files modified on the current Git branch. Use when Codex needs to lint a Shopify theme, validate branch-scoped Liquid, JavaScript, or theme changes, enforce Theory theme and vanilla JavaScript rules, or avoid surfacing pre-existing offenses from untouched files.
+version: 1.6.0
+description: Run Shopify CLI Theme Check and Theory Digital's bundled Liquid, JavaScript, and CSS rules together, linting modified .js and .css files plus the JavaScript and CSS inside Liquid javascript and stylesheet blocks, while reporting and failing only on offenses in files modified on the current Git branch. Use when Codex needs to lint a Shopify theme, validate branch-scoped Liquid, JavaScript, CSS, or theme changes, enforce Theory theme, vanilla JavaScript, and stylesheet rules, flag Liquid written inside stylesheet or javascript blocks where Shopify never renders it, or avoid surfacing pre-existing offenses from untouched files.
 ---
 
 # Shopify Lint
 
 ## Setup
 
-The bundled `theme-check-theory` (Liquid checks) and `eslint-plugin-theory` (JavaScript rules) packages ship as TypeScript source only; their `node_modules` and compiled `dist/` are not committed. Run setup once before the first run (and after upgrading the skill):
+The bundled `theme-check-theory` (Liquid checks), `eslint-plugin-theory` (JavaScript rules), and `stylelint-config-theory` (CSS rules) packages ship as TypeScript source only; their `node_modules` and compiled `dist/` are not committed. Run setup once before the first run (and after upgrading the skill):
 
 ```bash
 bash .agents/skills/shopify-lint/scripts/setup.sh
@@ -18,15 +18,18 @@ Installing with `td-ai-tools install --setup shopify-lint` runs this automatical
 
 1. Runs `npm install && npm run build` inside `theme-check-theory/`, producing `dist/index.js` — the CommonJS entry point the root `.theme-check.yml` requires.
 2. Runs `npm install && npm run build` inside `eslint-plugin-theory/`, producing the `dist/` that the JavaScript lint runner imports.
-3. Writes a `.theme-check.yml` at the project root wiring in the bundled checks. Setup replaces any existing file with the skill's current configuration so installs and updates cannot retain stale or incomplete settings.
-4. Through the installer's shared project-hook setup, installs matching Claude and Codex Stop hooks and merges their registrations into `.claude/settings.json` and `.codex/hooks.json` without replacing unrelated settings or hooks. Re-running setup updates the Shopify Lint hook in place instead of duplicating it.
+3. Runs `npm install && npm run build` inside `stylelint-config-theory/`, producing the `dist/` that the CSS lint runner imports.
+4. Writes a `.theme-check.yml` at the project root wiring in the bundled checks. Setup replaces any existing file with the skill's current configuration so installs and updates cannot retain stale or incomplete settings.
+5. Through the installer's shared project-hook setup, installs matching Claude and Codex Stop hooks and merges their registrations into `.claude/settings.json` and `.codex/hooks.json` without replacing unrelated settings or hooks. Re-running setup updates the Shopify Lint hook in place instead of duplicating it.
 
-No ESLint configuration is written to the project root, and the theme's own ESLint config is never consulted — the branch lint is a gate, so a theme must not be able to silently disable it. Override the rules per project with `SHOPIFY_LINT_ESLINT_CONFIG=<path>` pointing at a module that exports a `createConfig` function.
+No ESLint or Stylelint configuration is written to the project root, and the theme's own ESLint and Stylelint configs are never consulted — the branch lint is a gate, so a theme must not be able to silently disable it. A project `.stylelintignore` is ignored for the same reason. Override the rules per project with `SHOPIFY_LINT_ESLINT_CONFIG=<path>` or `SHOPIFY_LINT_STYLELINT_CONFIG=<path>`, each pointing at a module that exports a `createConfig` function.
 
-The Stop hooks run this skill's branch-scoped lint before handoff at `--fail-level warning`, so **every reported offense blocks handoff, warnings included** — both the Theory Liquid checks and the Theory JavaScript rules. Only advisory `info` offenses do not block; that severity is reserved for JavaScript parse errors inside Liquid, which masking cannot always avoid and the agent cannot reliably fix. The hooks return modified-file offenses to the agent and allow handoff after three unsuccessful fix rounds. They require `jq`, `python3`, `node`, and Shopify CLI to be available when the hook runs. Directly running `scripts/setup.sh` performs the package builds and Theme Check configuration; use `td-ai-tools install --setup` or `td-ai-tools update --setup` to apply the shared hook manifest as well.
+The Stop hooks run this skill's branch-scoped lint before handoff at `--fail-level warning`, so **every reported offense blocks handoff, warnings included** — the Theory Liquid checks, the Theory JavaScript rules, and the CSS rules alike. Only advisory `info` offenses do not block, and nothing the bundled linters report is graded that way. The hooks return modified-file offenses to the agent and allow handoff after three unsuccessful fix rounds. They require `jq`, `python3`, `node`, and Shopify CLI to be available when the hook runs. Directly running `scripts/setup.sh` performs the package builds and Theme Check configuration; use `td-ai-tools install --setup` or `td-ai-tools update --setup` to apply the shared hook manifest as well.
 
 Keep these dependencies inside each bundled package's `node_modules`; do not install Node dependencies at the theme root.
 
+Stylelint requires Node **>= 20.19**, which is the skill's effective floor.
+
 ## Usage
 
 Run the bundled Python script from the Shopify theme root:
@@ -35,28 +38,33 @@ Run the bundled Python script from the Shopify theme root:
 python3 .agents/skills/shopify-lint/scripts/shopify_lint.py --path .
 ```
 
-The script identifies files changed since the current branch's merge-base, adds staged, unstaged, and untracked files, then runs two linters over that set and merges their results into one report:
+The script identifies files changed since the current branch's merge-base, adds staged, unstaged, and untracked files, then runs three linters over that set and merges their results into one report:
 
-- **Theme Check** — `shopify theme check --output json`. The root `.theme-check.yml` directly requires the bundled `theme-check-theory` package from this skill directory. `DisallowedScriptOrStyleTag` reports inline executable `<script>` and all `<style>` tags in modified Liquid files while allowing external-source and JSON-data scripts. `HardcodedText` reports rendered hard-coded copy, except content inside Liquid `stylesheet`, `javascript`, and `schema` tags.
+- **Theme Check** — `shopify theme check --output json`. The root `.theme-check.yml` directly requires the bundled `theme-check-theory` package from this skill directory. `DisallowedScriptOrStyleTag` reports inline executable `<script>` and all `<style>` tags in modified Liquid files while allowing external-source and JSON-data scripts. `HardcodedText` reports rendered hard-coded copy, except content inside Liquid `stylesheet`, `javascript`, and `schema` tags. The generated `.theme-check.yml` also pins the upstream `StaticStylesheetAndJavascriptTags` to `error`, so Liquid written inside a `{% stylesheet %}` or `{% javascript %}` block always fails the lint.
 - **JavaScript** — ESLint's recommended rules plus the bundled `eslint-plugin-theory`, over modified `.js` and `.mjs` files *and* the JavaScript inside `{% javascript %}` blocks of modified `.liquid` files.
+- **CSS** — `stylelint-config-standard` through the bundled `stylelint-config-theory`, over modified `.css` files *and* the CSS inside `{% stylesheet %}` blocks of modified `.liquid` files.
 
-Standalone JavaScript is linted only when its **filename** contains `td-` (matched case-insensitively, anywhere in the name, so `td-globals.js` and `theme-td-utils.js` both qualify while `vendor.js` does not). This keeps vendored and merchant-authored assets from being reported against Theory conventions they were never written to. The match is on the filename alone — a `td-` directory does not opt its contents in — and `*.min.js` is always skipped.
+Standalone JavaScript and CSS are linted only when the **filename** contains `td-` (matched case-insensitively, anywhere in the name, so `td-globals.js` and `component-td-card.css` both qualify while `vendor.js` and `theme.css` do not). This keeps vendored and merchant-authored assets from being reported against Theory conventions they were never written to. The match is on the filename alone — a `td-` directory does not opt its contents in — and `*.min.js` and `*.min.css` are always skipped.
 
-The filter does **not** apply to Liquid: `{% javascript %}` blocks are linted in every modified `.liquid` file regardless of its name, because that JavaScript is Theory's either way.
+The filter does **not** apply to Liquid: `{% javascript %}` and `{% stylesheet %}` blocks are linted in every modified `.liquid` file regardless of its name, because that code is Theory's either way. A `{% stylesheet 'scss' %}` block is skipped, because its body is Sass rather than CSS, as is any block commented out with `{% comment %}` or `{% raw %}`.
 
-Offenses in a Liquid block are reported at their real line and column in the `.liquid` file. Check codes say where they came from: `PascalCase` is Theme Check, `theory/…` is a Theory JavaScript rule, `eslint/…` is an upstream ESLint rule.
+Offenses in a Liquid block are reported at their real line and column in the `.liquid` file. Check codes say where they came from: `PascalCase` is Theme Check, `theory/…` is a Theory JavaScript rule, `eslint/…` is an upstream ESLint rule, `stylelint/…` is an upstream Stylelint rule.
 
 `theory/guarded-custom-element-define` and `theory/no-unapproved-imports` are errors, as are genuine ESLint correctness failures; the convention rules (`theory/disconnected-callback-cleanup`, `theory/no-class-selectors`, `theory/centralize-selectors`, `theory/require-jsdoc`) are warnings. `theory/require-jsdoc` requires named classes and functions to have JSDoc comments, including typed `@param` and `@returns` tags. The severity distinction only affects `--fail-level`: the Stop hooks run at `--fail-level warning`, so warnings block handoff too. See `eslint-plugin-theory/README.md` for every rule and its blind spots.
 
-Liquid interpolation is masked out before the JavaScript is parsed. Control flow that straddles a JavaScript syntax boundary can defeat that, so parse errors inside `.liquid` are reported at `info` — visible, but never failing a run that cannot reasonably be fixed.
+For CSS, everything `stylelint-config-recommended` turns on is an error — unknown properties and at-rules, duplicate declarations, invalid values, empty blocks — and the notational conventions `stylelint-config-standard` adds on top are warnings. The naming-pattern rules (`selector-class-pattern`, `custom-property-pattern`, and their siblings) ship disabled because their kebab-case defaults reject Theory's BEM-style class names, and `no-descending-specificity` is demoted to a warning. Stylelint no longer checks formatting at all — its stylistic rules were removed in v15 and v16. See `stylelint-config-theory/README.md` for the full policy.
+
+Liquid does not belong inside a `{% stylesheet %}` or `{% javascript %}` block: Shopify concatenates their contents into the compiled asset bundles without rendering them, so interpolation there is served to the browser as literal text. `StaticStylesheetAndJavascriptTags` reports every Liquid construct in one — output tags, control flow, and `{% comment %}`, which is not a comment there either — as an error at its real position. `{% style %}` and `{% script %}`, which Shopify does render, are untouched. Its one false positive is host-language nesting the Liquid parser reads as an output tag, such as `if (a) {{ b(); }}`; the JavaScript and CSS masks treat that as code and keep linting it.
+
+Interpolation is still masked out before the JavaScript or CSS is parsed — an output tag becomes a `0` padded with blanks — so a block that still holds Liquid reports its real CSS and JavaScript offenses alongside the Liquid ones instead of collapsing into a single parse error. Because that Liquid is itself an offense, nothing is relaxed to accommodate the substitution: a `{% stylesheet %}` block is graded exactly as a standalone `.css` file is, and a parse error inside `.liquid` is a plain error. Expect a masked value such as `margin: {{ s.gap }}px` to draw a CSS offense as well as the Liquid one; both are fixed by taking the Liquid out.
 
 ## Workflow
 
-1. Confirm `shopify`, `python3`, and `node` (>= 20) are available.
-2. Run the bundled script instead of calling `shopify theme check` or `eslint` directly.
+1. Confirm `shopify`, `python3`, and `node` (>= 20.19) are available.
+2. Run the bundled script instead of calling `shopify theme check`, `eslint`, or `stylelint` directly.
 3. Treat exit code `0` as no failing offenses in modified files, `1` as filtered offenses at or above the fail level, and `2` as a Git, CLI, Node, or JSON-processing error.
 4. Fix every reported issue, warnings included, and rerun until the command passes. Run with `--fail-level warning` to match what the Stop hooks enforce. Do not fix offenses in untouched files unless the user expands the scope.
-5. Keep bundled-package dependencies inside `theme-check-theory/node_modules` and `eslint-plugin-theory/node_modules`. Do not install Node dependencies at the theme root.
+5. Keep bundled-package dependencies inside `theme-check-theory/node_modules`, `eslint-plugin-theory/node_modules`, and `stylelint-config-theory/node_modules`. Do not install Node dependencies at the theme root.
 
 The default base is `origin/HEAD`, then `origin/main`, `main`, `origin/master`, or `master`. Override it when needed:
 
@@ -64,8 +72,8 @@ The default base is `origin/HEAD`, then `origin/main`, `main`, `origin/master`,
 python3 .agents/skills/shopify-lint/scripts/shopify_lint.py --path . --base-ref origin/develop
 ```
 
-Set `SHOPIFY_LINT_BASE_REF` for the same override in automation. Use `--format json` for machine-readable filtered output. The CLI still defaults to `--fail-level error`; the Stop hooks pass `--fail-level warning` explicitly, and `--fail-level info` additionally fails on advisory Liquid parse errors. When passing `--config <path>`, preserve the bundled package's `require` entry or the Theory checks will not load.
+Set `SHOPIFY_LINT_BASE_REF` for the same override in automation. Use `--format json` for machine-readable filtered output. The CLI still defaults to `--fail-level error`; the Stop hooks pass `--fail-level warning` explicitly, and `--fail-level info` additionally fails on any advisory offense a Theme Check configuration grades that way. When passing `--config <path>`, preserve the bundled package's `require` entry or the Theory checks will not load.
 
-Pass `--skip-js` (or set `SHOPIFY_LINT_SKIP_JS=1`) to report Theme Check offenses only — useful when the JavaScript toolchain is unavailable. Node is not spawned at all when no `.js`, `.mjs`, or `.liquid` file changed.
+Pass `--skip-js` (or set `SHOPIFY_LINT_SKIP_JS=1`) and `--skip-css` (or `SHOPIFY_LINT_SKIP_CSS=1`) to drop those linters — useful when the Node toolchain is unavailable. Passing both reports Theme Check offenses only. Node is not spawned for JavaScript when no `.js`, `.mjs`, or `.liquid` file changed, nor for CSS when no `.css` or `.liquid` file changed.
 
 Do not use Theme Check auto-correction through this workflow because it can modify untouched files before filtering.

package/skills/shopify-lint/eslint-plugin-theory/README.md

@@ -159,20 +159,37 @@ being a literal, it introduces no identifier for `no-undef` to fire on.
 block into one bundle, so identifiers defined in another file are legitimately
 global.
 
-A file with no `{% javascript %}` block produces no blocks at all and is
-skipped.
+A file with no `{% javascript %}` block produces no blocks at all and is skipped,
+as is a file whose every block sits inside a `{% comment %}` or `{% raw %}`
+region — a commented-out block is not code the storefront runs.
 
-**Known limit.** Liquid control flow that straddles a JavaScript syntax
-boundary cannot mask into valid JavaScript:
+### Liquid in a block is an offense, not a case to accommodate
+
+Shopify does not render Liquid inside a `{% javascript %}` tag: the block is
+concatenated into the theme's compiled JavaScript verbatim, so anything the mask
+blanks out is already broken theme code. Theme Check's
+`StaticStylesheetAndJavascriptTags` reports it as an **error**, at its exact
+position in the `.liquid` file — see `theme-check-theory/README.md`. Masking it
+anyway is what lets the author see the Liquid offense and the JavaScript offenses
+in one round, rather than a parse error at the first `{{` standing in for
+everything.
+
+One case diverges: `if (a) {{ b(); }}` is valid JavaScript that the Liquid parser
+reads as an output tag. The mask treats anything between `{{` and `}}` carrying a
+brace or a semicolon as JavaScript and keeps linting it; the Theme Check offense
+on that line is a false positive.
+
+**Known limit.** Liquid control flow that straddles a JavaScript syntax boundary
+cannot mask into valid JavaScript:
 
 ```liquid
 {% if a %}function f() {{% else %}function g() {{% endif %}}
 ```
 
-That produces a genuine parse error. The branch runner reports parse errors
-found in `.liquid` at `info` severity, with a note that the position may be
-approximate, so a masking limitation can never fail a run the author has no
-reasonable way to fix. Parse errors in standalone `.js` files remain errors.
+That produces a genuine parse error, reported as an `error` like any other. It
+used to be demoted to `info`, on the grounds that the author had no reasonable
+way to fix it; the Liquid offense above now names the fix — take the Liquid out
+of the block.
 
 Note also that a rule reporting "at the top of the program" reports at line 1
 of the `.liquid` file rather than at the block.

package/skills/shopify-lint/eslint-plugin-theory/src/liquid/mask.test.ts

@@ -187,6 +187,47 @@ describe('maskLiquid', () => {
     expect(masked).toContain('const b = 2;');
   });
 
+  it('skips a block that is commented out', () => {
+    const source = ['{% comment %}', '{% javascript %}', 'run();', '{% endjavascript %}', '{% endcomment %}', ''].join(
+      '\n',
+    );
+    expect(maskLiquid(source)).toBeNull();
+  });
+
+  it('skips a block inside a raw tag', () => {
+    const source = ['{% raw %}', '{% javascript %}', 'run();', '{% endjavascript %}', '{% endraw %}', ''].join('\n');
+    expect(maskLiquid(source)).toBeNull();
+  });
+
+  it('still lints a live block alongside a commented-out one', () => {
+    const masked =
+      maskLiquid(
+        [
+          '{% comment %}',
+          '{% javascript %}',
+          'old();',
+          '{% endjavascript %}',
+          '{% endcomment %}',
+          '{% javascript %}',
+          'live();',
+          '{% endjavascript %}',
+          '',
+        ].join('\n'),
+      ) ?? '';
+
+    expect(masked).toContain('live();');
+    expect(masked).not.toContain('old();');
+  });
+
+  it('keeps a block that only contains a comment tag', () => {
+    // The comment is inside the block, not the other way around: this is live
+    // JavaScript, and the comment tag itself is reported by Theme Check.
+    const masked = maskLiquid('{% javascript %}{% comment %}note{% endcomment %}run();{% endjavascript %}') ?? '';
+
+    expect(masked).toContain('run();');
+    expect(masked).not.toContain('note');
+  });
+
   it('blanks Liquid control flow inside the block', () => {
     const masked = maskLiquid('{% javascript %}{% if a %}run();{% endif %}{% endjavascript %}');
     expect(masked).toContain('run();');

package/skills/shopify-lint/eslint-plugin-theory/src/liquid/mask.ts

@@ -7,6 +7,13 @@
  * already correct for the original `.liquid` file. That identity mapping is
  * the whole point: the ESLint processor can then remap offenses with no
  * arithmetic at all.
+ *
+ * Shopify does not render Liquid inside a `{% javascript %}` tag, so anything
+ * masked out of a block body is already broken theme code, and Theme Check's
+ * `StaticStylesheetAndJavascriptTags` reports it as an error. Masking it anyway
+ * is what lets the author see the Liquid offense and the JavaScript offenses in
+ * the same round, instead of a parse error at the first `{{` standing in for
+ * both.
  */
 
 /** Matches a `{% javascript %}` … `{% endjavascript %}` pair, capturing the body. */
@@ -25,6 +32,10 @@ const LIQUID_TAG = /\{%[\s\S]*?%\}/g;
  * Characters that never appear inside a Liquid output tag but do appear in the
  * JavaScript constructs that can be mistaken for one — most importantly a
  * nested block, `if (a) {{ b(); }}`.
+ *
+ * Theme Check's `StaticStylesheetAndJavascriptTags` applies no such guard, so it
+ * does report that construct as Liquid. Keeping the guard here means the block
+ * is still linted as the JavaScript it is.
  */
 const NOT_LIQUID_OUTPUT = /[{};]/;
 
@@ -51,6 +62,26 @@ function overlaps(intervals: Interval[], start: number, end: number): boolean {
   return intervals.some((interval) => start < interval.end && end > interval.start);
 }
 
+/**
+ * Whether an offset falls inside one of the intervals.
+ *
+ * Used to decide whether a `{% javascript %}` tag is itself commented out.
+ * Containment, not overlap, is the question: a block that *contains* a
+ * `{% comment %}` is still live JavaScript, and testing for overlap would throw
+ * it away.
+ */
+function contains(intervals: Interval[], offset: number): boolean {
+  return intervals.some((interval) => offset >= interval.start && offset < interval.end);
+}
+
+/** Every `{% comment %}` / `{% raw %}` region in the source, in order. */
+function rawContentRegions(source: string): Interval[] {
+  return [...source.matchAll(RAW_CONTENT_TAG)].map((match) => ({
+    start: match.index,
+    end: match.index + match[0].length,
+  }));
+}
+
 /**
  * Mask the Liquid constructs inside one `{% javascript %}` body, in place.
  *
@@ -101,8 +132,11 @@ function maskLiquidInBody(source: string, out: string[], start: number, end: num
  * Reduce a Liquid source to its `{% javascript %}` content, preserving every
  * character position.
  *
- * Returns `null` when the file contains no complete `{% javascript %}` block,
- * which lets the processor skip the file entirely.
+ * Returns `null` when the file contains no complete `{% javascript %}` block
+ * that is live code, which lets the processor skip the file entirely. A block
+ * that sits inside a `{% comment %}` or `{% raw %}` region does not count:
+ * commented-out blocks are common mid-migration, and linting one would report
+ * offenses in code the storefront never runs.
  */
 export function maskLiquid(source: string): string | null {
   // Indexed per UTF-16 code unit, not per code point, so that offsets stay
@@ -112,9 +146,14 @@ export function maskLiquid(source: string): string | null {
     out[index] = source[index] === '\n' ? '\n' : ' ';
   }
 
+  const rawRegions = rawContentRegions(source);
   let found = false;
 
   for (const match of source.matchAll(JAVASCRIPT_BLOCK)) {
+    if (contains(rawRegions, match.index)) {
+      // A commented-out or raw-quoted block is not live JavaScript.
+      continue;
+    }
     found = true;
     const bodyStart = match.index + match[1].length;
     const bodyEnd = bodyStart + match[2].length;

package/skills/shopify-lint/hooks/claude-stop.sh

@@ -4,9 +4,8 @@
 # offenses in files modified on the current branch.
 #
 # Runs at --fail-level warning so every reported offense blocks, not just
-# errors. Advisory `info` offenses stay non-blocking: they are only used for
-# JavaScript parse errors inside Liquid, where masking interpolation out cannot
-# always yield parseable code and the agent has no reliable fix.
+# errors. Advisory `info` offenses stay non-blocking; nothing the linters report
+# is graded that way today.
 set -u
 
 input=$(cat)

package/skills/shopify-lint/hooks/codex-stop.sh

@@ -4,9 +4,8 @@
 # branch so Codex can fix them before trying to stop again.
 #
 # Runs at --fail-level warning so every reported offense blocks, not just
-# errors. Advisory `info` offenses stay non-blocking: they are only used for
-# JavaScript parse errors inside Liquid, where masking interpolation out cannot
-# always yield parseable code and the agent has no reliable fix.
+# errors. Advisory `info` offenses stay non-blocking; nothing the linters report
+# is graded that way today.
 set -u
 
 input=$(cat)

package/skills/shopify-lint/scripts/setup.sh

@@ -5,8 +5,9 @@ set -euo pipefail
 #
 # Run automatically by the installer (`--setup`) from the installed skill
 # directory, or manually with `bash scripts/setup.sh`. It:
-#   1. Builds the bundled `theme-check-theory` custom-check package and the
-#      bundled `eslint-plugin-theory` JavaScript rules (their node_modules and
+#   1. Builds the bundled `theme-check-theory` custom-check package, the
+#      bundled `eslint-plugin-theory` JavaScript rules, and the bundled
+#      `stylelint-config-theory` CSS configuration (their node_modules and
 #      dist/ are intentionally not committed).
 #   2. Writes a `.theme-check.yml` at the project root that wires the bundled
 #      checks into Shopify CLI Theme Check.
@@ -16,6 +17,7 @@ set -euo pipefail
 SKILL_DIR="$(cd "$(dirname "$0")/.." && pwd)"
 PKG_DIR="$SKILL_DIR/theme-check-theory"
 ESLINT_PKG_DIR="$SKILL_DIR/eslint-plugin-theory"
+STYLELINT_PKG_DIR="$SKILL_DIR/stylelint-config-theory"
 
 # 1. Build the bundled custom-check package.
 echo "shopify-lint setup: building theme-check-theory in $PKG_DIR"
@@ -32,6 +34,16 @@ cd "$ESLINT_PKG_DIR"
 npm install --no-audit --no-fund
 npm run build
 
+# 1c. Build the bundled Stylelint configuration used to lint modified CSS.
+#
+# Like 1b, this runs before the install-layout guard below. No configuration is
+# written to the project root for it: the branch lint is a gate, so a theme must
+# not be able to silently disable it.
+echo "shopify-lint setup: building stylelint-config-theory in $STYLELINT_PKG_DIR"
+cd "$STYLELINT_PKG_DIR"
+npm install --no-audit --no-fund
+npm run build
+
 # 2. Write the project-root .theme-check.yml.
 #
 # The installed layout is <project>/<.agents|.claude>/skills/shopify-lint, so
@@ -63,6 +75,13 @@ HardcodedText:
   enabled: true
   severity: warning
 
+# Upstream check, pinned here so the branch lint always fails on it: Shopify
+# serves `{% stylesheet %}` and `{% javascript %}` bodies verbatim, so Liquid
+# written inside one ships to the browser as literal text.
+StaticStylesheetAndJavascriptTags:
+  enabled: true
+  severity: error
+
 UnusedSectionSettings:
   enabled: false
   severity: warning