# Delta recipes Reusable workflows you can give a Delta agent. Each entry: title, category, what it does, requirements, page URL, then the recipe text. Source: https://deltatheme.com/recipes/ ## Switch from Delta’s default design system to Automatic.css Category: Design system Description: Turn on Automatic.css and make it your site's design system. The agent matches it to your current look, keeps what Automatic.css has no name for, and takes a snapshot first. Produces: Your site runs on Automatic.css and looks as it did before. Colours, spacing and type come from Automatic.css. Anything it does not cover keeps working, and a snapshot lets you go back. Requirements: Any MCP client URL: https://deltatheme.com/recipes/switch-to-automatic-css/ --- recipe --- Automatic.css is installed on my site. Turn it on and make it my design system, in place of Delta's default one. Keep my pages, layout and look as they are now. Load the skills change-design-system and automaticcss, and follow them. Also: 1. Look first. Tell me what you found. Change nothing yet. 2. Ask me before you turn on Automatic.css. 3. Set Automatic.css to match my live site: colours, fonts and page width. Show me the values before you write them. 4. Pair each name my site uses with the Automatic.css name that does the same job. When Automatic.css has no name for a job (for example the line width, a hero heading size, or a status colour it has switched off), keep my own token with its current value. Ask me once about all of these. 5. Show me the table and wait for my OK. 6. Do a dry run and fix what it reports. Then switch, and tell me the snapshot id. 7. Check a page, a post, the header, the footer, buttons and dark sections. Fix what looks wrong. 8. Tell me in plain words what changed, what you kept, and how to undo it. After the switch, change values in Automatic.css, not in site.css. --- end --- ## Create a Snake game on a Front panel board Category: Build Description: Build a playable browser game on a sketchbook board. The game draws on a canvas and takes every colour from your design tokens. Produces: A new board with a working game: keyboard and touch controls, pause, score and best score, and colours that follow your design system. Requirements: Any MCP client, Replace placeholders in recipe URL: https://deltatheme.com/recipes/snake-game-on-a-board/ --- recipe --- Make a small game that I can play on a new sketchbook board. Game: [name the game and give its rules in one or two lines, for example Snake: steer the snake, eat the food to grow, and do not hit the walls or your own body] Start with get-design-context and get-tokens. Do not change the site, its tokens or its pages. Everything goes on the new board. 1. Make a new board with create-sketchbook-board and give it the name of the game. 2. Write the board with set-board: a. HTML: one section with a title, a score row (for example Score, Best and Length), a stage that holds a canvas, a start screen on the stage with a short message and a Play button, and one line of help text that tells the controls. b. CSS: use only token names as var(--…). Put the stage on the page surface (surface-body) with a border token, so the game is light and the grid is easy to see. Make the game large but keep all of it on the screen: max-inline-size min(64rem, 75svh). Use the site's .btn classes for the buttons. c. JavaScript: draw the game on the canvas. Read each colour from the tokens with getComputedStyle when the game starts (surface, border, ink, success, warning, danger), so the game follows the design system. A board refuses colour values, so do not write hex or rgb values in the CSS. 3. Controls: arrow keys and W A S D, P to pause, and swipe on a touch screen. Pause the game when the canvas loses focus or the visitor goes to a different tab. Give the canvas tabindex="0" and an aria-label that tells the controls. 4. Keep the best score in localStorage, inside try and catch, so the game still works when the browser blocks storage. 5. The canvas gets focus when play starts. Remove its focus ring (outline: none on :focus and :focus-visible of the canvas only). Keep the focus ring on the buttons. 6. Keep the canvas sharp on high-density screens: set its size with a ResizeObserver and devicePixelRatio (2 at most). 7. Open the board, play one round, and tell me what you checked: start, controls, pause, game over, best score, and a narrow screen. Show me the board when it is done. Do not put the game on a page unless I ask. --- end --- ## Run a monthly site check Category: Audit Description: A read-only monthly report on plugin updates, SEO, links, form messages and traffic, with the three actions to do first. Produces: One report, ordered by what needs action now, what can wait and what is fine, and saved to memory so next month's check can compare. Requirements: Any MCP client URL: https://deltatheme.com/recipes/monthly-site-check/ --- recipe --- Run this month's check of my site and give me one short report. Do not change anything, except one memory entry at the end. Start with get-design-context and list-integrations, so you know which plugins and integrations this site has. 1. Plugins: run list-plugins. List each plugin that has an update, with its current and new version. Do not update anything. 2. SEO: if an SEO plugin with abilities is active (for example SureRank), run its checks on the published pages and posts. List only real gaps: a missing search title or description, a missing social image, or a page that is set to noindex by mistake. Some checks read only the post body, so open the live page before you report a missing heading or link. 3. Links: open every published page and check its links. List each link that is broken or that goes through more than one redirect, with the page it is on. 4. Forms: if a form plugin with abilities is active, count the messages that came in since last month, per form. Do not put names, emails or message text in the report. 5. Traffic: if an analytics tool is connected, give the visits and the five most visited pages of the month, compared with the month before. If no tool is connected, say so and skip this step. 6. Changes: list the pages, posts and templates that changed this month, and the open items in Delta memory. Put the report in this order: what needs action now, what can wait, and what is fine. End with the three actions you recommend first. Then add the report to Delta memory as one entry with append-memory, so next month's check can compare. --- end --- ## Find and fix broken links Category: Audit Description: Checks every link in pages, templates and menus, then fixes the broken ones in the place they come from, after your approval. Produces: A table of broken and redirecting links with a fix for each, the approved fixes written to pages, templates and menus, and a final check that shows each link works. Requirements: Any MCP client URL: https://deltatheme.com/recipes/find-and-fix-broken-links/ --- recipe --- Find the broken links on my site and propose a fix for each one. Start with get-design-context, list-pages (published only), list-templates and list-menus. Do not change anything yet. 1. Collect every link: in the stored HTML of pages and templates, in post content, and in each menu (get-menu). Include links in buttons and images, and in the header and footer templates. 2. Check each address once. Record the result: works, redirects (and where to), broken (404 or 410), or failed (time-out or blocked). For an external site that blocks automated checks, mark it as "not checked", not as broken. 3. Show me a table: the link, where it is (page, template or menu, and the link text), the result, and your proposed fix. For an internal link, propose the current address of the same content. For a redirect, propose the final address. For an external link that has no new home, propose to remove the link and keep the text. 4. Wait for my approval. Take a snapshot with create-snapshot before the first fix. Then fix the approved rows one document at a time: patch-page-content for pages, patch-template-content for templates and update-menu for menus. A link in a template shows on every page that uses it, so fix it in the template, not on each page. 5. Check each fixed link again and give me the final list. --- end --- ## Write a handoff guide for a client Category: Content Description: A guide written for the actual site: where each piece of content lives and how the client updates it, in their words. Produces: A short site guide with real page, menu and post type names, steps for the tasks the client will do, what to ask an agent, and what not to touch, saved as a private page. Requirements: Any MCP client, Replace placeholders in recipe URL: https://deltatheme.com/recipes/client-handoff-guide/ --- recipe --- Write a handoff guide for the person who will look after this site after me. Client: [the client's name, and how comfortable they are with WordPress] Start with get-design-context, list-pages, list-templates, list-menus, list-integrations and get-notes. Do not change anything until step 5. 1. Map where each kind of content lives: pages edited in the WordPress editor, pages that are Delta designs, templates (header, footer, single, archive), menus, forms, and any custom post types. Mark which content changes often and which almost never changes. 2. For each task the client will do, write short steps for this site. Use the real names of its pages, menus and post types, and the screen names they see in WordPress admin. Cover at least: add a blog post, change the text on a page, change an image, edit the menu, read form messages, and change the business details. 3. Add an "Ask your agent" part: tasks that are easier to ask an AI agent connected to Delta, such as a new page layout or a change to the site colours, with one example request for each. 4. Add a "Do not change" part: the things that can break the site, such as template code and site.css, and who to contact for them. 5. Show me the guide as a draft and wait for my approval. Then save it as a private page called Site guide, so it stays with the site. --- end --- ## Clean up Delta memory Category: Audit Description: Closes finished items, merges duplicates and keeps the decisions, so the next session starts from a short list that is true. Produces: A memory where every open item is still open on the site, duplicates are merged, decisions are kept, and closed items still show the history. Requirements: Any MCP client URL: https://deltatheme.com/recipes/clean-up-delta-memory/ --- recipe --- Clean up this site's Delta memory, so the next session starts from a short list that is true. Start with list-memory. Read every page of it, open items included. Do not change anything yet. 1. Put every entry in one of four groups: open and still true; open but finished (the work is done on the site); duplicate (the same item said more than once); decision (a choice and its reason, to keep). 2. Before you call an item finished, check the site: read the page, template or setting the item is about, and say what you found. 3. Show me the plan as a table: the entry, its group, the action (keep, close, merge or keep as a decision) and the reason. 4. After my approval, close each finished item with close-memory and a short closing note. For duplicates, keep the clearest entry and close the others with a note that names it. Leave decisions as they are. Do not delete entries unless I ask: closed entries keep the history. 5. Give me the final list of open items. --- end --- ## Design system conformance check Category: Design system Description: Finds raw values, unknown tokens, component drift and broken design rules in every page and template, then fixes them with tokens after your approval. Produces: A report grouped by kind with counts and a proposed token for each raw value, the approved fixes written one document at a time, and a read-back that confirms the raw values are gone. Requirements: Any MCP client URL: https://deltatheme.com/recipes/design-system-conformance/ --- recipe --- Check every page and template against this site's design system. Report what does not follow it, then fix it after my approval. Start with get-design-context, get-tokens, get-notes, list-components and get-site-assets. Then run list-pages (pages with a Delta design) and list-templates. Do not change anything yet. 1. Raw values: read site.css, the CSS of every template and designed page, and the style attributes in their HTML. List every colour, font family, font size, spacing, radius, shadow, duration and z-index that is a raw value (hex, rgb, px, rem and so on) instead of a var() of a token. For each one, propose the nearest token. If no token is near, say so. Do not invent one. 2. Unknown names: list every var(--…) that names a token or property this site does not define. 3. Components: run find-component-usage and check-component-conformance. List instances that no longer match the component's markup, and copies of a component that are not marked as one. 4. Design rules: check the pages against the rules in the design system notes (for example colour roles, type steps, or spacing with gap). List what breaks them. 5. Repeats: list CSS rules that appear in three or more pages or templates and belong in site.css. 6. Report it as a table grouped by kind: where (page, template or site.css), what, the current value, the proposed fix, and how sure you are. Put the counts at the top. 7. Wait for my approval. Take a snapshot with create-snapshot before the first fix. Then fix one document at a time with patch-site-assets, patch-template-content and patch-page-content, and rewrite-component-instances for components. Read each document back after the fix and confirm that the approved raw values are gone. 8. If the same missing token shows up in several places, propose it as a new token in a separate list for me to decide. Do not add it yourself. --- end --- ## Add GSAP animations Category: Build Description: Load GSAP once for the whole site and give it a small set of named animations that take their timing from your motion tokens. Produces: GSAP and ScrollTrigger on every page at a pinned version, animations that follow the duration and curve tokens, a reduced-motion fallback, a demo board, and the rules written in the design system notes. Requirements: Any MCP client URL: https://deltatheme.com/recipes/gsap/ --- recipe --- Add GSAP to my site and set up a motion baseline: a small set of named animations that every page can use. Start with get-design-context, get-tokens, get-notes, get-site-assets (include site.js) and get-site-scripts. Do not change anything yet. 1. Look for motion that is already there: scroll reveals, typing effects or other animation code in site.js, the templates and the designed pages, and any animation library that is already loaded. List what you find, and ask me whether to keep it, replace it with GSAP, or leave those parts alone. 2. Find the motion tokens. This recipe uses the Delta seed names: --duration-fast, --duration-base, --duration-slow, --curve-standard and --curve-entrance. a. If the site has them, use them. b. If the site uses a different design system, look for its own duration and easing values (for example transition or motion variables). Show me a table that matches each seed name to the site's name, and wait for my approval. The setup then reads the site's names. c. If the site has no motion values at all, offer to create the missing tokens with update-tokens, with proposed values (for example 150ms, 250ms and 400ms, and two cubic-bezier curves). Wait for my approval. Do not add tokens without it. 3. Load GSAP 3.15.0 from jsDelivr with patch-site-scripts, in the footer insert, with the defer attribute: gsap.min.js, then ScrollTrigger.min.js and CustomEase.min.js from https://cdn.jsdelivr.net/npm/[email protected]/dist/. Use this exact version, never "latest". If I want no third-party scripts, stop and tell me: the three files must then be put on my own server (WordPress does not accept script files in the Media Library), and you load them from there. 4. Write the motion setup once, at the end of site.js, with patch-site-assets: a. Register ScrollTrigger and CustomEase. b. Read the motion tokens from step 2 with getComputedStyle. Change durations to seconds (150ms is 0.15). Make one CustomEase for each curve token from its four cubic-bezier numbers. Set gsap.defaults to the base duration and the standard curve, so a change to a token changes every animation. c. Use gsap.matchMedia: run the animations only when prefers-reduced-motion is no-preference. With reduced motion, everything shows at once, with no movement. d. Keep content visible when JavaScript fails: hide an element only from the script, just before it animates, never with CSS alone. e. Give each animation a name that HTML can use as data-motion: fade, fade-up, stagger (the children of the element come in one after the other) and parallax (a small vertical drift on scroll). All four use ScrollTrigger: fade, fade-up and stagger run once, when the element comes into view; parallax follows the scroll. f. Animate only opacity and transform, so the layout never moves. g. If soft navigation is on (get-feature soft-navigation), run the setup again after each page change, and kill the old ScrollTriggers first. 5. Make a sketchbook board called Motion with create-sketchbook-board and set-board. Show each data-motion name on a few sample blocks, with enough height to scroll. Tell me what you checked: each animation, a page refresh, and the result with reduced motion turned on. 6. After my approval, add a Motion part to the design system notes with patch-notes: the data-motion names and what each one does, that timing comes from the tokens, that new animations are added to the set in site.js and not written in a page, and that animations move only opacity and transform. Show me each change as a diff and wait for my approval before you write it. --- end --- ## Set up pages, templates and menus Category: Build Description: The agent asks which pages your site needs, then builds them with a header and footer, the page templates, two menus and sample posts. Produces: The pages you chose, two menus, a header and footer, the single, archive, loop item, search and 404 templates, and six sample posts if the site has a blog. Requirements: Any MCP client URL: https://deltatheme.com/recipes/pages-templates-and-menus/ --- recipe --- Set up the pages, templates and menus of my site. Start with get-design-context, list-templates and list-pages. Do not change anything yet. 1. Ask me three questions in one message, and wait for my answers: a. What is the site name? b. What is the site about? c. Which pages does the site need? Suggest Home, About, Contact and Blog, and tell me I can add or remove pages. 2. Load skill build-site-templates. Show me what you will make, and wait for my approval: a. Pages: the pages from my answer. b. Templates: header, footer, single, archive, loop item, search and 404. c. Menus: a primary menu and a footer menu with my pages. d. Six sample posts, if the site has a blog. 3. Set the site title with set-site-identity. Make the pages with create-page, as drafts, with short placeholder text about my site. Set Home as the home page with update-site-settings, and Blog as the posts page if the site has a blog. 4. Make the two menus with update-menu. 5. Make the templates with create-template. The header has the site name and the primary menu. The footer has the footer menu and the year. Give the header and footer the condition entire_site, and give single and archive their conditions with set-condition. 6. If the site has a blog, make six sample posts with create-entry, as drafts. Start each title with "Sample:" so I can find and delete them later. 7. Tell me what you made, with a link to each page. Keep the current look. Use only design tokens for colour, space and type. Do not publish anything until I tell you. --- end --- ## Add Rive animations Category: Build Description: Play Rive animations on any page or template, from one pinned runtime in site.js that loads only where it is used. Produces: Rive animations on your pages, controlled with data binding, with reduced motion and accessible markup, tested on a draft page. Requirements: Any MCP client URL: https://deltatheme.com/recipes/rive/ --- recipe --- Add Rive animations to my site. Start with get-design-context, get-site-assets (include site.js) and get-site-scripts. Do not change anything yet. 1. Ask me which .riv files to use and where they go. upload-media does not accept .riv files, so ask me to upload them to the Media Library (WordPress needs a plugin that allows .riv) or to give you their URL. Use files only from sources I trust. Rive Marketplace files need a CC BY credit. 2. Add one Rive setup at the end of site.js with patch-site-assets: a. Load @rive-app/canvas from jsDelivr at a pinned version, once, and only on pages that have a Rive canvas. Set the .wasm file to the same folder with rive.RuntimeLoader.setWasmUrl. Use @rive-app/webgl2 only if the file needs the Rive Renderer. b. Run it on DOMContentLoaded. Play each canvas[data-rive-src], with optional data-rive-artboard and data-rive-state-machine. Use the stateMachine option: stateMachines is deprecated. c. Size the canvas in CSS with an aspect-ratio. Call resizeDrawingSurfaceToCanvas on load and when the canvas changes size. d. Control the animation with data binding (view models). State machine inputs and Rive event listeners are deprecated. Turn on autoBind only for files that have a view model. e. Pause animations that are off screen. With prefers-reduced-motion set to reduce, show a still frame. f. Controls are real HTML buttons or links. A canvas that only decorates gets aria-hidden="true"; one that carries meaning gets role="img" and an aria-label. 3. Add the animation to the page or template I chose. Test it on a draft page made with create-page, and tell me what you checked. Then ask me if I also want to see it on a sketchbook board. Before the first write, run create-snapshot. Show me each change as a diff and wait for my approval before you write it. --- end --- ## Audit the site for accessibility Category: Audit Description: A read-only pass over every template and designed page, with findings grouped by severity and fixes proposed one at a time. Produces: A findings table and a queue of per-template diffs to approve. Requirements: Any MCP client URL: https://deltatheme.com/recipes/accessibility-audit/ --- recipe --- Audit this site for accessibility against WCAG 2.2 level AA. Start with get-design-context and list-templates, then read every hierarchy template (header, footer, archive, single, search, 404) and every page with a Delta design. Do not change anything yet. For each template or page, check: 1. Heading order and landmarks (one h1, main, nav with labels, no skipped levels). 2. Text contrast against the composited background, including muted text and text on the action colour. 3. Focus visibility on every link, button, and form control. 4. Images: alt text present and meaningful, decorative images marked aria-hidden. 5. Motion: anything that animates respects prefers-reduced-motion. 6. Forms: every field has a visible label, errors are announced. 7. Touch targets of at least 24 by 24 CSS pixels, 44 where the site already uses that size. Report findings as a table: template or page, issue, WCAG criterion, severity, proposed fix. Group by severity. Then propose fixes one template at a time, each as a diff, and wait for my approval before writing. Prefer fixing in site.css or the design tokens when the same issue appears in more than one place. --- end --- ## Create a design system from a brand brief Category: Design system Description: Palette and type proposed step by step with approval gates, written to the tokens only, then a style guide page to check the result. Produces: Updated design tokens, notes.md entries, and a /style-guide/ page. Requirements: Any MCP client, Replace placeholders in recipe URL: https://deltatheme.com/recipes/create-design-system/ --- recipe --- Build the design system for this site from the brief below. Do not build any pages yet. Brief: [describe the business, the audience, three adjectives for the feel, and any colours or typefaces that are fixed] Steps: 1. Run get-design-context and read notes.md and the current tokens. Tell me whether the site still has the seed tokens or an existing design. 2. Propose a palette: one action colour, one ink, one surface, and their derived tints and shades. Show contrast ratios for ink on surface and on-action on action. Wait for my approval. 3. Propose type: a display face and a text face from the Font Manager catalog, with the size ramp and leading. Wait for my approval. 4. Write the approved values into the tokens with update-tokens. Do not write literal colours or sizes anywhere else. 5. Record the decisions and the reasons in notes.md: what the palette is for, what must not change, and anything you rejected. 6. Create a page at /style-guide/ that shows every token in use: colours with their names, the type ramp, spacing, radius, and the button states. At the end, list the tokens you changed and the snapshot id so I can restore if needed. --- end --- ## Export a token spec for a design tool Category: Design system Description: A read-only export of the current tokens and the site context a designer needs. Written for Claude Design, readable by Figma, Paper or any tool that keeps the names. Produces: Two markdown documents: tokens.md (the contract) and context.md (how this site uses it). Pair them with the recipe Port a design back into the site. Requirements: Any MCP client URL: https://deltatheme.com/recipes/export-token-spec/ --- recipe --- Export the design tokens of this site as a spec for a design tool such as Claude Design, together with the context a designer needs to use them. Do not change anything on the site. The same two files work for an agent in Figma, Paper or any other design tool: every name in them is a CSS variable, so a tool that can read a table can use them. 1. Run get-design-context. Then run get-tokens, get-notes, list-components with get-component for each one, and get-site-assets. Export the tokens as they are now. On a new site they are the seed. On a site that has been styled they carry the customisations, and the design agent must work from those. 2. Write the first document, tokens.md, with these sections in this order. Header: the site name, today's date, whether the tokens are still the seed (tokensAreSeed from get-design-context) or have been customised, and one sentence: this spec exists so that a design made outside Delta, in Claude Design, Figma, Paper or another design tool, can be ported back through MCP with the same token names. Token table: one row per token. Columns: Delta name (category and key, for example color / action), CSS variable (for example --color-action; nested steps as --text-sm-size, --title-lg-leading), value. Group the rows by category in this order: color, font, weight, tracking, text, title, space, radius, border, shadow, layout, breakpoint. Above each group, copy that category's purpose note from the token file (the _meta text). For colours, add a fourth column with the job description of each name (the _desc text). Copy these texts as they are. Do not paraphrase and do not invent a description for a name that has none. Rules for the design agent, copied verbatim: - Semantic classes are free. Values are not. Every colour, size, radius, shadow, weight and font in the design maps to a token by its CSS variable name. - Never write a raw value. When no token covers a job, declare a composed property with a bare name (for example --card-bg, not --color-card-bg), build it from tokens, and list it in a section called Composed properties with the tokens it is built from. Compose colours with color-mix(). Never derive a colour by arithmetic. Derive an off-scale size with calc() from the token that shares its meaning. - Propose a new token only for a job no existing name covers. List proposals in a section called Proposed tokens, each with the job it does. Do not use a proposed token as if it existed. - Type steps travel whole: take size, line height and tracking from the same step. - Contrast floor: text 4.5:1, large text and borders 3:1, measured against the composited background. Delta refuses a palette below this floor at write time. - Breakpoints are literal values in media queries, not variables. - An -on-contrast ink is used only on the contrast surface, in the same rule as its background. on-action is used only on action. Port-back contract: the design comes back as HTML and CSS that reference the CSS variables above, plus the sections Composed properties and Proposed tokens, plus a list of every token whose value the design changed, as name and new value. Delta writes changed values through update-tokens, composed properties into site.css once, and pages through the page abilities. Anything that is not a token reference, a listed composed property or a listed proposal is sent back for mapping. 3. Write the second document, context.md, with these sections in this order. Copy from the site. Do not invent. Design notes: the content of notes.md as it is. Say at the top that these are standing rules and the design must follow them. Components: for each component, its name, its purpose line, the class names it uses, and its markup. Tell the design agent to reuse these before inventing a new pattern, and to keep the class names as they are so the design ports back. Composed properties: every custom property declared at the top of site.css, with the tokens it is built from. Tell the design agent to use these before declaring its own, and to add new ones to the Composed properties section of its design, not here. Layout conventions: which space steps this site uses for section gaps and for cluster gaps, which title step maps to each heading level, and the container widths in use. Read them from site.css and the templates. If a convention is not settled, say so rather than guess. 4. Return both documents in chat. Do not upload them and do not write anything to the site. --- end --- ## Port a design back into the site Category: Build Description: Maps every value in an external design to a token before anything is written, then writes tokens, site.css and pages in order, with a snapshot to fall back on. Produces: Updated tokens and composed properties, the pages and templates written from the design, a read-back that confirms no raw values, and a snapshot id to restore. Requirements: Any MCP client, Replace placeholders in recipe URL: https://deltatheme.com/recipes/port-design-back/ --- recipe --- Port the design below back into this site. It was made against the token spec exported from this site, in Claude Design or another design tool that kept the token names. Design: [paste or attach the HTML and CSS exported from Claude Design, Figma, Paper or another tool, together with its Composed properties and Proposed tokens sections and its list of changed token values] 1. Run get-design-context, get-tokens and get-notes. Do not write anything yet. 2. Read the design and list every value that is not one of these three: a var() reference to a token that exists on this site; a composed property declared in the design's Composed properties section and built from tokens; a token listed under Proposed tokens. Show me the list as a table: where it appears, the value, and what you propose instead (an existing token, a composed property, or a new token). Wait for my approval. 3. Compare the design's token values with the site's. List every token whose value changed, as name, current value, new value, and the contrast ratios for ink on surface-body, ink-muted on surface-body, and on-action on action. Wait for my approval. 4. Write in this order, and stop if any step is refused: a. The approved token values, with update-tokens. b. The approved new tokens, with update-tokens. If the ability refuses a new name, add it as a composed property instead and tell me. c. The composed properties, into site.css with patch-site-assets, declared once at the top with bare names. d. The pages and templates, with the page and template abilities, keeping the design's semantic classes as they are. Targets: [name the pages and templates to create or replace] 5. Read back every page and template you wrote. Confirm the CSS contains no colour literal and no size that is not a token or a calc() from one. Report the snapshot id that was taken before the token write, so I can restore. Do not install plugins. Do not change notes.md. Do not change a token the design did not change. --- end --- ## Turn on light and dark mode Category: Design system Description: Turn on the dark colours the seed already ships, follow each visitor’s computer setting, and add an optional switch. Produces: Dark mode that follows the visitor’s setting with no white flash, an optional three-state switch in the header, and a list of what still looks light. Requirements: Any MCP client, Seed tokens URL: https://deltatheme.com/recipes/light-and-dark-mode/ --- recipe --- Turn on dark mode for this site. Follow the visitor’s computer setting. Start with get-design-context. This recipe is for the Delta seed design system, which already has a dark version of every colour in site.css (the :root block for data-theme dark). If the site uses its own design system, stop and tell me: it needs a dark block with my own variable names first. 1. Add a short script to the Header scripts (Delta → Scripts) that runs before the page paints. It reads a stored choice from localStorage and otherwise follows prefers-color-scheme, then sets data-theme on the html element, so the page opens in the right mode with no white flash. 2. In site.css, set color-scheme: light on :root and color-scheme: dark in the dark block, so form fields, scrollbars and dropdowns follow the mode. 3. Add a colour mode switch to the header, next to the menu (skip this step if I say no switch). It cycles through system, light and dark, its label says the current mode, and it uses the same storage key as the header script. System removes the stored choice and follows live changes to the computer setting. 4. If I changed the palette, compare the dark colours with my light colours. Propose a dark value for each one that no longer fits, check that each text and background pair reaches 4.5:1, and show me the table before you write anything. Check the action colour, the text on buttons and the inverted sections in both modes. 5. Open the site in both modes and list everything that still looks light or is hard to read: logos, inline SVGs with fixed fills, bright photos, forms, plugin pages and embeds. Mix colours with colour tokens, never with white or black. Show me each change as a diff and wait for my approval before you write. --- end --- ## A cookie banner that gates Google Analytics Category: Compliance Description: A 2 KB consent banner that keeps Google Analytics out of the browser until the visitor accepts. No plugin. Produces: A consent card in the footer template, styled from the tokens; Google Analytics 4 that loads only after Accept; and a Cookies and analytics section in the privacy policy. Requirements: Any MCP client, Replace placeholders in recipe URL: https://deltatheme.com/recipes/consent-banner-google-analytics/ --- recipe --- Add a cookie banner that gates Google Analytics behind consent. The measurement ID is [G-XXXXXXXXXX]. Style it from the tokens and put it in the footer template. Before you start: if the ID above is still the placeholder, ask me for it and wait. If Site Kit is installed, tell me to turn off “Let Site Kit place the Google tag” first. Remind me to turn on redaction for email addresses and URL query parameters in the GA4 data stream. 1. Run get-design-context and find the default footer template, so the card is on every page. 2. Add a card at the bottom right: a title, one sentence, a link to the privacy policy, Decline as an outline button and Accept as the primary button. On a phone the card is full width and Accept is on top. Use the button component and the colour, type and spacing tokens. The card ships with the hidden attribute and only the script shows it. It is a labelled region, not a modal. 3. Put the measurement ID on the card (data-ga-id). Load gtag.js only after Accept and only for a real G- ID, with Consent Mode v2 in its basic form: analytics granted, all ad signals denied. The value “preview” shows the card with no analytics. 4. Keep the choice in one first-party cookie for 180 days, versioned with data-consent-version. Add a Cookie settings control next to the footer legal links that opens the card again. Decline after Accept removes the Google cookies. Logged-in users are not measured. A browser that sends Global Privacy Control counts as Decline. 5. Test three states in a browser: first visit (the card shows, no cookies), Accept (the _ga cookies appear), and Decline from Cookie settings (the cookies are gone). 6. Add a Cookies and analytics section to the privacy policy: the banner and the Cookie settings link, the consent cookie and its 180 days, what Analytics records, the two Google cookies and their two-year life, consent as the legal basis, and Google LLC under the EU-US Data Privacy Framework. Then write the rule into the site notes, so a later change cannot put the tag in front of the banner. Show me each change as a diff and wait for my approval before you write. --- end ---