Automate Your WordPress Theme Development 🔗 **Source:** [Automate Your WordPress Theme Development](https://georgestephanis.wordpress.com/2026/01/06/automate-your-wordpress-theme-development/) > [!note]+ Document Notes > ```yaml > tags: [WordPress, Themes, Automation] > author: George Stephanis > source: WordPress.com > reference: [https://georgestephanis.wordpress.com/2026/01/06/automate-your-wordpress-theme-development/] > date created: 2026-01-07 00:00 > > --- > > # 🏷️ Title: Automate Your WordPress Theme Development > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - Include links cited in or relevant to the article. ## 📝 Summary - What happened: The author built a reusable boilerplate and workflow to rapidly spin up Full Site Editing (FSE) themes from Figma designs using Create Block Theme, GitHub Actions, Composer/@wordpress/scripts, Sass, Playground, and Starter Content. - Why it matters: Dramatically reduces repetitive setup, improves consistency, and enables easy client demos. - Key stakeholders: Theme developers, agencies, clients reviewing designs, WordPress core/tooling teams. - Risks and tradeoffs: Boilerplate can drift from best practices; automation hides complexity; Playground demos may differ slightly from production hosting. - Bottom line: Investing in opinionated automation around FSE, Playground, and starter content pays off for recurring theme work. ## 📖 Main Content - The article starts from the need to ship many FSE themes quickly from Figma, motivating a “solid starter theme” instead of reinventing the wheel. - The core tool is the **Create Block Theme** plugin, which lets you edit templates, headers/footers, colors, and typography in the Site Editor and then write those changes back into the theme on disk ([Create Block Theme section](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=00008_00002-003Q&startLexposition=00006&emphasizeText=it+then+gives+you+a+simple+option+to+write+your+changes+to+disk+in+the+theme+itself)). - As a base, the author prefers starting from the official Create Block Theme boilerplate, which is minimal—header/footer partials, a basic index template, and a `theme.json` that you extend via the Site Editor ([boilerplate explanation](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=0000I_00000-004M&startLexposition=0000A&emphasizeText=There%E2%80%99s+really+not+a+lot+to+it.+A+header+and+footer+partial%2C+a+general+index+template%2C+and+a+theme.json+file)). - He then layers automation: - **Automatic namespacing** via a GitHub Action, adapted from Automattic’s Special Projects templates. Creating a new repo from the template triggers automatic renaming of the theme folder and namespaces to match the new theme name, replacing older fragile local string-replace scripts ([automatic namespacing description](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=0000Q_00001_00000-001f&startLexposition=0000K&emphasizeText=as+soon+as+you+use+the+boilerplate+to+create+a+new+repository%2C+with+one+click+you+can+have+the+theme+folder+and+all+the+namespaces+reflecting+the+new+instance%E2%80%99s+name)). - **Build tools automation** using `@wordpress/scripts` for JS/CSS bundling and Composer for translations, PHP formatting, etc., wired in so everything works out of the box ([build tools section](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=0000Y_00002-000V&startLexposition=0000S&emphasizeText=That%E2%80%99s+why+I%E2%80%99ve+got+my+boilerplate+leveraging+a+lot+of+the+public+work+that+the+Special+Projects+Team+built)). - For styling, the author likes Sass but increasingly uses `theme.json` for block theme styles so they’re editable via the Site Editor and avoid CSS specificity issues, while also improving WYSIWYG in the editor ([Sass vs theme.json reasoning](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=0000e_00000-006g&startLexposition=0000a&emphasizeText=I+find+I%E2%80%99ve+moved+more+toward+%28where+possible%29+defining+the+styles+in+theme.json)). - A major feature is **WordPress Playground** integration: - Playground runs WordPress entirely in the browser, without a server. - The real value is instant test sites: clients or stakeholders can try a theme or feature via a link backed by the current GitHub repo state, once the boilerplate is configured ([Playground utility](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=0000o_00001_00000-000Q&startLexposition=0000g&emphasizeText=It+makes+it+trivial+to+set+up+a+test+site+and+let+a+user+%28or+client+or+stakeholder%29+instantly+test+out+a+plugin+or+trial+a+theme)). - To avoid blank demo sites, he uses **Playground Blueprints** plus **Starter Content**: - Blueprints can import WXR exports or run an `importThemeStarterContent` step, reusing the older Starter Content feature from WordPress 4.7 and adapting it for block themes ([starter content overview](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=0000y_00005_00000-000V&startLexposition=0000q&emphasizeText=Starter+Content+is+a+feature+that+was+introduced+through+the+Customizer+way+back+in+WordPress+4.7)). - A snag: Starter Content still imports classic nav menus, but FSE themes use navigation blocks: - Core offers a class to convert legacy menus to block navigation, but it isn’t directly referenceable. - The boilerplate runs custom PHP during Playground setup (via a Blueprint step) that can bootstrap a theme file, clean up imported Starter Content, fix permalinks, and reconcile navigation menus. - Since navigation blocks only accept menu IDs, the author adds a custom slug property in templates that maps to the appropriate Starter Content menu, ensuring header/footer menus are wired correctly ([navigation handling and slug mapping](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=0001C_00001_00000-000z&startLexposition=00010&emphasizeText=Finally%2C+core%E2%80%99s+navigation+block+only+supports+specifying+menus+by+ID+%E2%80%94+no+support+for+slugs)). - He closes by acknowledging the boilerplate isn’t perfect but has saved significant client time and invites others to use it and build “super-cool-stuff” ([closing reflection](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=0001K_00000-0017&startLexposition=0001E&emphasizeText=For+me%2C+though%2C+it%E2%80%99s+a+great+starting+point%2C+and+has+saved+me+a+bunch+of+time+for+client+work.)). ### 🗒️ Notes - Motivation: recurring client work building FSE themes from Figma leads to creating a “solid starter theme” instead of repeating set-up work ([opening motivation](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=00004_00000-0025&startLexposition=00000&emphasizeText=Whatever+is+a+programmer+to+do+but+make+sure+I%E2%80%99m+being+efficient+and+not+reinventing+the+wheel+by+creating+a+solid+starter+theme.)). - Create Block Theme (CBT): - Acts as the main bridge between Site Editor customization and the theme files on disk. - Encourages designing in the editor first, then persisting to the filesystem ([CBT description](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=00008_00002-003Q&startLexposition=00006&emphasizeText=While+you%E2%80%99re+editing+your+theme+in+the+Site+Editor+%E2%80%94+customizing+page+templates%2C+headers%2C+footers%2C+colors%2C+typefaces+%E2%80%94+it+then+gives+you+a+simple+option+to+write+your+changes+to+disk)). - Boilerplate base: - Uses the official CBT boilerplate repo, which is intentionally minimal and expects you to expand via Editor-made templates and patterns. - `theme.json` is central for defining theme parameters and later editor overrides ([boilerplate repo reference](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=0000I_00000-004M&startLexposition=0000A&emphasizeText=a+theme.json+file+that+starts+defining+parameters.)). - Namespacing automation: - Earlier, Automattic’s team relied on local scripts to clone and string-replace template repos; fragile and manual. - A GitHub Action now handles renaming, so creating a new repo from the boilerplate yields a correctly namespaced theme immediately. - Build tooling: - `@wordpress/scripts` abstracts complex JS build configuration. - Composer coordinates translation generation, PHP formatting, and other tooling, bundled into the boilerplate so you can just run the provided scripts. - Styling approach: - Sass is still preferred for writing CSS, but the author shifts much logic to `theme.json`: - Theme.json-driven styles are cleaner for overrides in the Site Editor. - Avoids classic CSS specificity fights and ordering issues. - Improves block editor WYSIWYG fidelity, since editor and front output share the same design tokens. - Playground: - WordPress running entirely in-browser is reframed from a novelty into a practical client tool. - By wiring Playground to a GitHub repo, stakeholders always see the latest code without needing to set up hosting. - Boilerplate configuration hides the complexity so “it’ll just work magically” for each new theme. - Starter Content & Blueprints: - Pain point: blank sites after theme install vs polished screenshots. - Blueprints can: - Import a WXR export for bulk content. - Use `importThemeStarterContent` to leverage core’s Starter Content feature. - Starter Content, originally tied to the Customizer, is revived for block themes by mapping it into Playground flows. - Menus and navigation: - Block theme navigation differs from legacy Appearance → Menus. - Starter Content still creates classic menus, so: - Core offers a conversion class, but it isn’t directly referenced in configuration. - Blueprint runs custom PHP from within the theme to: - Convert menus to block navigation. - Tidy imported content and set things like permalinks. - Because the navigation block only accepts IDs, templates add a custom slug which is then mapped to the correct menu created by Starter Content, allowing different header/footer menus to wire up reliably. - Evaluation: - The stack (CBT + boilerplate + GitHub Actions + Composer/@wordpress/scripts + Playground + Starter Content) forms an opinionated workflow optimized for agencies and frequent FSE work. - It favours convention over configuration—ideal when you own the workflow, but requires ongoing maintenance as WordPress evolves. - The article is practical and implementation-focused, not theoretical; no benchmarking, but strong experiential justification. ## 📚 References - Automate Your WordPress Theme Development (original article): https://georgestephanis.wordpress.com/2026/01/06/automate-your-wordpress-theme-development/ - Create Block Theme plugin (overview): https://wordpress.org/plugins/create-block-theme/ - CBT boilerplate in the official repo (mentioned base): https://github.com/WordPress/create-block-theme/tree/trunk/assets/boilerplate - WordPress Playground: https://developer.wordpress.org/playground/ - Playground Blueprints docs: https://developer.wordpress.org/playground/blueprints/ - `@wordpress/scripts` package: https://developer.wordpress.org/block-editor/reference-guides/packages/packages-scripts/ - WordPress Starter Content (4.7 feature): https://make.wordpress.org/core/2016/11/30/starter-content-for-themes-in-4-7/ - Example theme repository template PR (navigation slug mapping): https://github.com/georgestephanis/theme-repo-template/pull/1 ## 🗣️ Paraphrase - Paragraph A: The author needed to ship many FSE themes from Figma designs, so instead of starting from scratch each time, they invested in a reusable, automated starter theme. - Paragraph B: Using tools like Create Block Theme, build tooling, GitHub Actions, Playground, and Starter Content, they built a boilerplate that can quickly be cloned, renamed, demoed in-browser with content, and extended via the Site Editor. ## 📰 Newsletter WordPress theme work getting repetitive? George Stephanis outlines a practical automation stack for Full Site Editing themes: start from the official Create Block Theme boilerplate, wire in GitHub Actions for automatic namespacing, lean on `@wordpress/scripts` and Composer for build tasks, and ship Playground-powered demos loaded with Starter Content so clients see “real” sites, not blank slates. If you regularly turn Figma into themes, this workflow is worth a close look. ## ✅ Action Items #### DevRel - Highlight this boilerplate-based FSE workflow in talks, tutorials, and live-coding sessions for agencies. - Build a short course on Create Block Theme + Playground Blueprints for rapid prototyping. - Add copy-pastable examples of Blueprint configs, starter content, and navigation conversion to official docs. #### OSPO - Document patterns for sharing boilerplate themes as open templates, including governance for accepting changes. - Ensure dependencies like `@wordpress/scripts` and Composer packages are license-compliant and scanned regularly. - Promote upstream contributions to WordPress Playground and Starter Content where gaps are found. #### Community - Host theme automation clinics where maintainers share boilerplate setups and CI recipes. - Pair new contributors on issues around FSE theme tooling, Blueprint examples, and starter content. - Encourage sponsors to fund improved Starter Content and Playground UX for agencies. #### WordPress - Core: Improve APIs for Starter Content in block themes and better navigation migration from classic menus. - Core Performance: Benchmark Playground-based flows vs traditional local setups for developer productivity. - Core AI: Explore assisted theme.json generation and automated starter content scaffolding from Figma or copy. - **Core Program Team:** Coordinate cross-team work on Create Block Theme, Playground, and starter content to keep flows coherent. - Mobile: Investigate how Playground and starter content could complement mobile theme previews. - Playground: Ship more first-class Blueprints for FSE theme demos, including menu and permalink setup. - Community: Document “demo-ready” theme practices for meetups and WordCamps. - Training: Produce lessons on FSE theme automation, from boilerplate to Playground demos. - Marketing: Highlight case studies where automation significantly cut theme delivery time. - Support: Add KB entries guiding developers to CBT, Playground, and starter content for client demos. - Design: Provide `theme.json` starter palettes and typography sets for common use cases. - Documentation: Expand examples showing end-to-end flows: CBT → boilerplate → Playground → Starter Content. - Photos: Curate photo packs suitable for starter content in demo sites. - TV: Record short walkthroughs of building a theme and exposing it via Playground. - Polyglots: Ensure starter content and demo sites are translation-ready. - Accessibility: Audit starter content templates and playground demos for WCAG compliance. - Meta: Consider adding links from the theme directory to Playground-powered demos. - CLI: Offer commands to scaffold FSE themes with Playground and starter content wiring. - Hosting: Coordinate with managed hosts who might embed Playground demos in their dashboards. - Tide: Factor in structured theme.json usage and starter content quality into scoring discussions. - Openverse: Suggest Openverse-powered image starter content for Playground demos. - Themes: Encourage reviewers to recognise structured starter content and automation in theme reviews. - Plugins: Support plugins that complement CBT, Playground, and starter content pipelines. #### The WPOCC - Programs: Support fellows working on FSE boilerplates, demo kits, and starter content upgrades. - Projects: Run documentation sprints around FSE automation workflows. - Funding experiments: Pilot microgrants for agencies that open-source their automation stacks. ### FAIR - Technical independence: Encourage local copies of boilerplates with clear provenance, tags, and signed releases. - Policies and covenants: Publish transparent guidelines on sponsorship or funding for playground-based tooling. - Productized governance artifacts: Provide templates for boilerplate governance, contributor roles, and evaluation scorecards. ## 🧪 Hypotheses - H1: Teams using a CBT-based boilerplate with automatic namespacing will reduce initial setup time for new FSE themes by at least 50%. - H2: Themes demoed via Playground with Starter Content will receive more useful client feedback than blank or minimally populated demos. - H3: Moving most styling into `theme.json` instead of Sass/CSS will reduce editor vs front-end visual discrepancies. - H4: Preconfigured Composer and `@wordpress/scripts` pipelines will increase the proportion of themes that ship with translations and code formatting enabled. ### 📊 Methodology - Run time-tracked experiments across several teams spinning up new themes with and without the boilerplate. - A/B test client demos: Playground with rich starter content vs basic staging sites; survey perceived quality and clarity. - Compare bug reports and support tickets related to visual mismatches before and after adopting `theme.json`-centric styling. - Analyze repo histories for presence of build scripts, translations, and formatting in projects using vs not using preconfigured tooling. ### ❓ Questions - How can Create Block Theme and Starter Content be more directly integrated for block themes, without extra bootstrap PHP? - Could Playground Blueprints eventually manage navigation migrations and slug/ID mapping automatically? - What’s the best way to keep a boilerplate updated as FSE and core APIs evolve without breaking existing themes? - How might Figma or design tokens flow directly into `theme.json` in a repeatable way? ### 🔮 Future Research - Explore more robust navigation mapping APIs (e.g., slug-based and location-based configurations). - Investigate standardized “demo blueprints” that theme authors can bundle or link from the directory. - Prototype design-to-`theme.json` pipelines that integrate with popular design tools. - Study long-term maintenance costs and benefits of complex boilerplates in agency environments. ### 💡 Implications - Practice: Agencies can standardize on automation-heavy FSE workflows, improving delivery speed and consistency. - Policy: WordPress could recommend minimum automation and demo standards for themes marketed to clients. - Security: Preconfigured Composer and CI flows can embed security checks and linting by default. - Education: Training materials need to shift from hand-built themes to editor-first + automation-first approaches. - Funding: Sponsoring shared boilerplates and Playground tooling may be a high-leverage way to support the ecosystem. ### 🧠 Learning Styles Assessment - Reading level estimate: Approximately late high school / early college. (Rough Flesch-Kincaid estimate based on sentence length and technical vocabulary.) #### 👀 Visual learners - Present: Descriptive explanations of flows (e.g., how Playground ties to GitHub), but mostly text. - Improve: Add diagrams of theme creation pipelines, Blueprint flowcharts, and before/after screenshots of starter content demos. #### 🔊 Aural learners - Present: None explicitly. - Improve: Provide a short audio walkthrough or screencast narration of setting up a new theme from the boilerplate. #### 🗣️ Verbal learners - Present: Clear explanations of tools (CBT, Playground, Starter Content) with contextual examples. - Improve: Add analogies (e.g., “boilerplate as a factory line”) and a short glossary for newer FSE terms. #### 🧩 Kinesthetic learners - Present: Implied hands-on steps (clone repo, run Playground, etc.), but not fully procedural. - Improve: Add step-by-step checklists and small “try this” labs for creating a demo theme. #### 🧠 Logical learners - Present: Reasoned arguments about why automation and `theme.json`-first styling are beneficial. - Improve: Include more explicit comparisons, tables of pros/cons, and simple metrics (time saved, errors avoided). #### 🧑‍🤝‍🧑 Social learners - Present: References to client/stakeholder feedback loops. - Improve: Suggest team-based exercises (e.g., pair building a theme, review each other’s Blueprints). #### 🧘‍♀️ Solitary learners - Present: Article is suitable for independent, deep reading. - Improve: Add reflection prompts (e.g., “list your current theme setup steps and where automation fits”). #### 🌿 Naturalistic learners - Present: None. - Improve: Light analogies to ecosystems (e.g., boilerplates as habitats that support many theme “species”) or sustainability of reusing patterns vs bespoke work. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Standard blog structure likely with headings; no detailed info in the article itself about semantics. - Improve: Ensure all code snippets, links, and images (if any) have descriptive text and proper heading hierarchy. #### Keyboard navigation - Present: Default theme likely supports focus and logical reading order. - Improve: Verify skip links and clear focus styles in any sample themes built from the boilerplate. #### Contrast and readability - Present: Depends on the WordPress.com theme used; article text likely adequate. - Improve: Encourage high-contrast palettes in starter `theme.json` presets. #### Text resizing and reflow - Present: Standard WordPress responsiveness. - Improve: Test themes derived from the boilerplate at 200% zoom and with reduced-motion preferences. #### Media and captions - Present: Article is text-based; no media discussed. - Improve: Add captions/transcripts for any future video demos of the workflow. #### Forms and interactions - Present: Not applicable within the article; indirectly relevant to playground demos. - Improve: Ensure any demo forms in starter content follow accessible label and error patterns. #### Standards reference - Map potential gaps in starter content and demo themes to WCAG 2.2 AA (e.g., 1.4.x contrast, 2.1.x keyboard, 2.4.x navigation). ### 🌍 DEIB Assessment #### Cultural breadth - Present: Focused on tooling; culturally neutral. - Improve: Include examples from different locales and languages when discussing starter content. #### Inclusive language - Present: Neutral, technical tone; minimal jargon but assumes some FSE familiarity. - Improve: Add brief explanations when introducing specialized tools and link to beginner resources. #### Neurodiversity support - Present: Clear structure and short sections, but dense concepts. - Improve: Use more subheadings, bullet lists, and consistent patterns for describing each tool. #### Representation - Present: No people depicted or quoted beyond the author. - Improve: Share use cases from a range of agencies and contributors globally. #### Psychological safety - Present: Encouraging, non-judgmental tone; emphasizes experimentation. - Improve: Explicitly invite questions and experimentation, and link to community spaces where help is available. ### ✅ Logical Validity #### Strong reasoning - The argument that automation via boilerplates and GitHub Actions replaces fragile manual scripts is causally strong: fewer manual steps → fewer errors and faster setup. - The claim that `theme.json`-driven styles improve WYSIWYG consistency is supported by shared configuration between editor and frontend. - Using Playground for client demos is logically justified: instant, up-to-date demos lower friction for feedback. #### Fallacies - None obvious. Some claims are experiential rather than empirically measured but not overstated. #### Tone of voice - Practical, conversational, and modest: acknowledges imperfection (“No, of course not. But no project ever really is.”) while still advocating for the workflow’s usefulness. ### 🛡️ DARVO Analysis - Deny: No denial or minimization of harm; article is purely technical. - Attack: No attacks on individuals or groups. - Reverse victim/offender: Not present; there is no conflict or accusation context. - The piece is cooperative and solution-oriented rather than defensive. ## 🎯 Conclusion The article presents an opinionated but practical automation stack for FSE theme development centered on Create Block Theme, a lean boilerplate, GitHub Actions, Composer + `@wordpress/scripts`, Playground, and Starter Content. For developers repeatedly building themes, adopting similar patterns can significantly reduce setup time, improve demo quality, and create a more reliable, editor-first workflow. ## 🧱 Refactor Appendix (append after 🎯 Conclusion) ### 📚 Literature Split Pad - Purpose: Stage Konik CEE units that become per-source Literature notes. - Split level: **H3**. - Include verbatim quotes under 25 words and a [view highlight] link. ### [H1] Automating FSE theme boilerplates accelerates delivery > [!quote] [Automate Your WordPress Theme Development](https://georgestephanis.wordpress.com/2026/01/06/automate-your-wordpress-theme-development/) by [[George Stephanis]] via [[WordPress.com]]. Published 2026-01-06. Accessed . > “For me, though, it’s a great starting point, and has saved me a bunch of time for client work.” Used to justify investing in standardized, automated FSE boilerplates. [view highlight](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=0001K_00000-0017&startLexposition=0001E&emphasizeText=For+me%2C+though%2C+it%E2%80%99s+a+great+starting+point%2C+and+has+saved+me+a+bunch+of+time+for+client+work.) #xref #articleseed ID:rw_[MISSING] ### [H2] Playground demos make FSE themes easier to trial > [!quote] [Automate Your WordPress Theme Development](https://georgestephanis.wordpress.com/2026/01/06/automate-your-wordpress-theme-development/) > “It makes it trivial to set up a test site and let a user (or client or stakeholder) instantly test out a plugin or trial a theme.” Context for advocating Playground-based demo environments for client feedback. [view highlight](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=0000o_00001_00000-000Q&startLexposition=0000g&emphasizeText=It+makes+it+trivial+to+set+up+a+test+site+and+let+a+user+%28or+client+or+stakeholder%29+instantly+test+out+a+plugin+or+trial+a+theme.) #xref ID:rw_[MISSING] --- ### 🔖 Atomic Split Pad (Zettel Candidates) - Purpose: Promote reusable claims into Atomic notes. - Split level: **H4**. - Each item: one idea, present tense, specific, testable. #### [Z1] Boilerplate automation accelerates FSE theme setup - In agency contexts reusing similar patterns across many client themes. - Pointer: article section on namespacing and boilerplate setup. - Links: [[WordPress-Theming]] [[Developer-Automation]] #### [Z2] Playground demos improve client feedback on themes - When demos are wired to current GitHub state and seeded with starter content. - Pointer: article section on Playground and Blueprints. - Links: [[WordPress-Playground]] [[Client-Feedback-Loops]] --- ### ✏️ Fleeting Queue (Extract by Selection) - Purpose: Capture quick actions or sparks for Fleeting notes. - Extraction: **Select one line** → “Refactor: Extract selection to new note (content only).” - Keep each line short and self-contained. - [F1] Try forking the theme-repo-template and wiring a Playground Blueprint — context/https://georgestephanis.wordpress.com/2026/01/06/automate-your-wordpress-theme-development/ #fleeting #inbox - [F2] Evaluate moving more CSS into theme.json for better editor parity — context/https://georgestephanis.wordpress.com/2026/01/06/automate-your-wordpress-theme-development/ #fleeting #inbox - [F3] Prototype a workshop around CBT + Playground + Starter Content — context/https://georgestephanis.wordpress.com/2026/01/06/automate-your-wordpress-theme-development/ #fleeting #inbox --- <!-- deep-read:sections end -->