TeamDijon

Composition strategy

Every new UI need maps to one layer in the stack below — from the design-system substrate up to specialized sections. Walk the decision flow before writing code for a new pattern.

The foundation: substrate + HTML elements

Two layers sit below the five, applied ambiently.

Supporting systems (the substrate). Metaobjects (theme_color, text_style, typeface/font, content_width, spacing…), color schemes, and Shopify platform APIs. They apply with zero per-element config: a bare <h2>Your cart</h2> renders per theme configuration without metadata on the element. The bare-tag text_style binding (in utility--css-variables) styles h1–h6; --color-* variables and color-scheme values cascade in.

TeamDijon

#!/bin/sh
# Strip Anthropic Co-Authored-By trailers and the "Generated with Claude Code" line.
sed -i -e '/<noreply@anthropic\.com>/d' \
       -e '/🤖 Generated with \[Claude Code\]/d' "$1"
# Trim trailing blank lines left behind.
sed -i -e :a -e '/^\s*$/{$d;N;ba' -e '}' "$1"

TeamDijon

.context/ Worktree Pattern

A git pattern for keeping markdown context files (docs, specs, decisions, notes) in the same repo as code but on a completely separate history.

What it is

An orphan git branch mounted as .context/ via git worktree. Context and code share the same repo but have fully separate histories. Markdown files on the context branch are accessible to both humans and AI agents alongside the codebase, without cluttering the main branch or polluting the code commit log.

Setup

TeamDijon

Claude Code Context Management Guide

Context Loading Overview

SESSION START (always in context)
├── CLAUDE.md                    → Full content loaded
├── .claude/rules/*.md           → Full content loaded
├── Skill metadata               → Names + descriptions only
└── Subagent metadata → Names + descriptions only

TeamDijon

{% liquid
  # CSS only block/section
  render 'utility--asset-loader', name: 'hero', js: false
  
  # Regular block/section
  render 'utility--asset-loader', name: 'featured-product'
%}

{% # Dynamic style %}
{% capture dynamic_style %}

TeamDijon

@media (prefers-reduced-motion: no-preference) {
  details {
    transition: 0.3s ease-in-out;

    @supports (interpolate-size: allow-keywords) {
      interpolate-size: allow-keywords;

      &::details-content {
        block-size: 0;
        opacity: 0;

TeamDijon

  /**
   * Manages interface with the Gorgias third-party chat widget.
   */
  window.mx.utils.gorgias = {
    /**
     * Gets the Gorgias chat container element.
     * @returns {HTMLElement|null} The Gorgias chat container or null if not found.
     */
    getContainer: () => {
      try {

TeamDijon

{% liquid
  # Using the collections object is necessary as we can't paginate collection settings, only collectionDrop objects
  assign featured_collection = collections[section.settings.featured_collection]
  assign product_list = section.settings.product_list
  
  if featured_collection == null and product_list == blank
    # Default behavior handling can go there
  endif
  
  assign pagination_size = section.settings.pagination_size

TeamDijon

{% comment %}
  Findings: 
    - The filter works really good as far as I can tell
    - Need to test with a bunch of SVGs (only one maybe hardly stress the performance) with effective caching
    - If you use the SVG multiple times, do not hesitate to store the markup in a variable instead of using the filter multiple times
    
  First batch : One SVG / no filter piped to the markup / 50k iterations
    - Case #1, #2 and #3: around 350ms (no significant difference)
    - Case #4: around 2500ms+

TeamDijon

import { promises as fs } from 'fs';
import { extname, join, resolve } from 'path';

const DEFAULT_ASSETS_DIR = 'assets';
const CSS_EXTENSION = '.css';
const DISCLAIMER = '/* CAUTION: Source document was rebased from 10px to 16px rem root */';
const DRY_RUN = process.env.DRY_RUN === 'true';

let processedFiles = 0;
let skippedFiles = 0;