An Agent-First Approach to Create Block Theme  🔗 **Source:** [An Agent-First Approach to Create Block Theme](https://www.wpnews.io/an-agent-first-approach-to-create-block-theme/#teaser) > [!note]+ Document Notes > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > --- > tags: [block-themes, wp-cli, agentic-coding, wordpress-theming, developer-tools, version-control] > author: Brian Coords > source: briancoords.com > reference: https://www.briancoords.com/an-agent-first-approach-to-create-block-theme/ > date created: 2026-08-10 > > --- > > # 🏷️ Title: An agent-first approach to Create Block Theme > <!-- 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 - [Create Block Theme (GitHub)](https://github.com/wordpress/create-block-theme) - [wp-theme-control (GitHub)](https://github.com/bacoords/wp-theme-control) - [WP-CLI wp block commands](https://developer.wordpress.org/cli/commands/block/) - [WP_Theme_JSON_Resolver reference](https://developer.wordpress.org/reference/classes/wp_theme_json_resolver/) - [Create Block Theme CLI feature request (2-year-old issue)](https://github.com/WordPress/create-block-theme/issues/688) - [Brian Coords' WCUS 2026 survey](https://www.briancoords.com/wcus-2026/) - [Thoughts on version control for block themes](https://www.briancoords.com/thoughts-on-version-control-for-block-themes/) - [Dev considerations for a new FSE project](https://www.briancoords.com/dev-considerations-for-a-new-fse-project/) ## 📝 Summary - Brian Coords, prepping for a WCUS 2026 talk, surveyed agencies about block-theme workflows and found Create Block Theme (CBT) — the standard plugin for flattening site-editor database changes into theme files — isn't built for agency-scale, version-controlled work, largely because it lacks a CLI and a full pattern manager. - His diagnosis: WordPress moved away from PHP-based themes and made the filesystem central again right as AI coding agents arrived, so the same pain agencies have complained about for years (templates split across PHP/HTML/database, styles split across theme.json/stylesheets/custom CSS/block JSON) is now blocking agents too. - His response is `wp-theme-control`, an experimental Claude/agent skill plus bash-script wrappers around WP-CLI's new (WP-CLI ≥3.0.0) `wp block` commands, which can export blocks, styles, templates, parts, and patterns from the database to the filesystem — no CBT dependency required. - Key stakeholders: WordPress agencies doing block-theme dev, WP-CLI maintainers (whose upcoming release this depends on), Core/CBT maintainers, and the emerging class of AI coding agents that need filesystem-first WordPress tooling. - Risks/tradeoffs: it's explicitly experimental ("test only on a site where there's no critical changes you're afraid you'd lose forever"), depends on an unreleased WP-CLI version (nightly/trunk as a stopgap), doesn't yet handle pages, navigation menus, or locally-added media, and WordPress always favors the database version over theme files — meaning stale exports can silently diverge from what's live. - Bottom line: the underlying architectural split (DB vs. filesystem) is still unsolved technical debt across WordPress theming; `wp-theme-control` is a proof of concept that CLI-first, agent-operable tooling may be a better shape for this problem than another GUI plugin. ## 📖 Main Content - Core argument: CBT solved the "get changes out of the database into git" problem for solo/bundled theme developers, but agencies (who need CLI automation, CI pipelines, and repeatable multi-site workflows) were already building their own tooling or skipping version control — a gap CBT's UI-first design never closed (the linked 2-year-old CLI feature request illustrates how long this has sat unaddressed). - The piece frames this as more than a CBT critique: it's a structural claim that WordPress's shift to block themes decoupled "the site" from "the filesystem" at the exact moment agentic coding tools (which operate by reading/writing files, not clicking a UI) became relevant to WordPress development. - Technical mechanism: WordPress already has an internal (non-public) capability to reconcile `theme.json` and Site Editor changes via `WP_Theme_JSON_Resolver`. The upcoming WP-CLI release exposes granular `wp block` subcommands (plan, export, clear) that operate directly against this database state — no new WordPress core API was needed, just CLI plumbing. - Notable gotcha documented: `wp block pattern` only sees code-registered patterns; user-created (database) patterns require the differently-named `wp block synced-pattern --sync-status=unsynced` command — a real trap for anyone scripting against these commands without reading the docs closely. - Workflow: `plan` (read-only diff of DB-vs-theme) → review → dry run → export to theme files → optionally clear the exported items from the database (necessary so WordPress stops preferring the DB copy and future file edits are respected). - Open problems the author flags himself: page content version control (e.g., WooCommerce Cart/Checkout pages, custom landing pages), navigation-menu robustness (avoiding local dev URLs leaking into exported templates), and whether locally-added media should migrate into the theme the way CBT does it. ### 🗒️ Notes - Author's stated motivation: doing WCUS 2026 talk research surfaced that agencies have been quietly working around CBT's limitations rather than adopting it, which is itself a signal CBT's design target (solo devs / bundled theme distribution) never matched agency needs. - `wp-theme-control` is positioned as "agent-first, rather than UI-first" — the differentiator from CBT isn't new WordPress capability, it's exposing existing capability through a CLI+skill interface an AI agent (or a human via an agent) can drive without clicking through wp-admin. - The author is explicit the agent skill itself is a convenience layer, not the mechanism — "the real power comes from bundled bash scripts... wrappers around WP-CLI commands." This matters for anyone wanting to use the tool without an AI agent in the loop at all. - Dependency risk called out directly: requires WP-CLI ≥3.0.0, not yet released at publish time, with nightly/trunk as the interim workaround — a real adoption friction point for teams on stable WP-CLI releases. - The piece ends as an open call for feedback (four explicit questions) rather than a finished product announcement — this is a working prototype, not a v1.0 tool. ## 📚 References - [Create Block Theme (GitHub)](https://github.com/wordpress/create-block-theme) — the plugin being contrasted against - [wp-theme-control (GitHub)](https://github.com/bacoords/wp-theme-control) — the author's experimental tool discussed in this post - [WP-CLI `wp block` commands](https://developer.wordpress.org/cli/commands/block/) — the underlying CLI surface the tool wraps - [`WP_Theme_JSON_Resolver` reference](https://developer.wordpress.org/reference/classes/wp_theme_json_resolver/) — the internal reconciliation mechanism referenced - [CBT CLI feature request, filed ~2 years prior](https://github.com/WordPress/create-block-theme/issues/688) — primary evidence for the "CBT never got a CLI" claim ## 🗣️ Paraphrase - Coords surveyed agencies for his WCUS talk and learned Create Block Theme isn't what agencies actually use — it's UI-first and lacks a CLI, so agencies build their own tooling or skip theme version control entirely. - He argues the deeper issue predates AI: WordPress split theme templates and styles across PHP, HTML, the database, theme.json, and CSS long before agentic coding existed, and that fragmentation is now exactly what trips up coding agents too. - Rather than patch CBT, he built `wp-theme-control`: an agent skill plus bash scripts wrapping WP-CLI's new `wp block` commands (arriving in WP-CLI 3.0) to plan, export, and optionally clear database-held theme changes into theme files. - He documents a real WP-CLI quirk (user patterns need `synced-pattern`, not `pattern`) and lists explicitly unsolved edges — pages, nav menus, media — while inviting public feedback on whether the approach is worth pursuing further. ## 📰 Newsletter - Brian Coords just shipped an experimental antidote to block-theme version-control pain: `wp-theme-control`, an agent skill that wraps WP-CLI's incoming `wp block` commands to plan/export/clear Site Editor changes straight to your theme's filesystem — no Create Block Theme UI clicking required. - The fun gotcha of the week: if you're scripting pattern exports, `wp block pattern` only grabs code-registered patterns — for your actual user-created ones, you want the oddly-named `wp block synced-pattern --sync-status=unsynced`. File that one away. - Needs WP-CLI ≥3.0.0 (nightly/trunk if you're impatient), and it's explicitly "don't run this on anything you love yet" experimental — but if your agency has been quietly hand-rolling theme.json diffing scripts, this is worth a spin on a throwaway site. [Repo here](https://github.com/bacoords/wp-theme-control), and Coords is actively soliciting feedback ahead of his WCUS 2026 talk. ## ✅ Action Items #### DevRel - Developer advocacy: feature `wp-theme-control` and the underlying `wp block` commands in a WCUS-adjacent demo/talk cycle; coordinate timing with Coords' own WCUS 2026 session rather than competing with it. - Education: produce a short walkthrough (plan → dry-run → export → clear) once WP-CLI 3.0 ships stable, since the nightly/trunk requirement is currently the biggest adoption blocker. - Developer experience: file/upvote docs requests for `wp block synced-pattern` — the naming mismatch with `wp block pattern` is a documented trap worth calling out prominently in official WP-CLI docs, not just a blog aside. - Developer marketing: this is a strong "agentic WordPress dev" case study for content aimed at agencies evaluating AI coding workflows. - Community management: monitor the `wp-theme-control` GitHub repo issues/discussions as an early-warning channel for what agencies actually need from database-to-filesystem tooling. #### OSPO - Policy & Governance: none directly implicated — `wp-theme-control` is an independent third-party project, not a Core/OSPO-governed initiative; watch for whether it gets pitched for Core adoption. - Security Management: any tool that clears database content after export needs a documented rollback/undo story before agencies run it against production; flag this as a security-adjacent data-loss risk worth an advisory note if the tool gains traction. #### Community - Maintainers: `wp-theme-control` maintainer (Coords) is explicitly requesting feedback — a good target for a maintainer office-hours or roadmap clinic once the tool matures past "experimental." - Contributors: the four open questions in the post (page/content version control, nav menu link hygiene, media handling, general feedback) are ready-made "first issue" or discussion-thread seeds for the repo. - Ecosystem: this sits at the intersection of two ecosystem gaps (block-theme version control, agentic coding support) — worth cross-posting to both audiences rather than treating as a niche theming post. #### WordPress - **Core:** the reconciliation logic already exists via `WP_Theme_JSON_Resolver` but isn't public API — Core should evaluate whether to formally expose a public function/hook for DB-to-file theme.json reconciliation rather than leaving third parties to reverse-engineer it. - **Core Performance:** not directly implicated by this post. - **Core AI:** directly relevant — this is a concrete data point that WordPress's DB-first architecture is a friction point for AI coding agents specifically; worth feeding into any Core AI working group evaluating "agent readiness" of WordPress APIs. - **Core Program Team:** coordinate the WP-CLI 3.0 `wp block` command release timeline with Core, since third-party tools (this one, potentially others) are now load-bearing on that release landing. - **Mobile:** not applicable to this source. - **Playground:** the "test only on a throwaway site" caveat is exactly the use case Playground exists for — a WordPress Playground blueprint bundling `wp-theme-control` would let people safely trial the workflow without risking a real site. Worth building. - **Community:** consider a WCUS 2026 session or hallway-track pairing with Coords' talk on agency block-theme workflows. - **Training:** once stabilized, this is good raw material for a Learn WordPress tutorial on WP-CLI-driven block theme workflows. - **Marketing:** low priority; niche developer-tooling story, not a general-audience one. - **Support:** anticipate support questions once WP-CLI 3.0 ships publicly ("why did my patterns disappear" if agencies misuse the clear step) — pre-stage a support doc. - **Design:** not applicable to this source. - **Documentation:** the `wp block` command docs should explicitly disambiguate `pattern` vs `synced-pattern` behavior — this is the single most actionable, concrete documentation fix surfaced by this article. - **Photos:** not applicable to this source. - **TV:** a recording of Coords' WCUS 2026 talk (once given) is a natural WordPress.tv candidate. - **Polyglots:** not applicable to this source. - **Accessibility:** not applicable to this source. - **Meta:** not applicable to this source. - **CLI:** primary team of interest — this article is essentially a field report on the new `wp block` command family; CLI team should treat it as early user feedback and track the `synced-pattern` naming/discoverability issue plus the "clear from DB" safety UX (confirmation prompts, dry-run defaults) before general release. - **Hosting:** hosts offering agency/managed WordPress plans should evaluate whether `wp-theme-control`-style workflows belong in their recommended CI/CD documentation once stable. - **Tide:** not applicable to this source. - **Openverse:** not applicable to this source. - **Themes:** Theme Review team should track whether agent-generated/exported theme files (via tools like this) introduce new review considerations (e.g., leftover local dev artifacts in navigation menus, as the author flags). - **Plugins:** Create Block Theme maintainers are the most directly implicated party — the 2-year-old open CLI feature request cited in this post is concrete, actionable backlog; worth a direct maintainer outreach thread comparing CBT's roadmap to what `wp-theme-control` demonstrates is possible via WP-CLI alone. - **The WPOCC:** no direct connection in this source; if a future agentic-WordPress-tooling working group forms, this article is a good founding case study. - **FAIR:** not applicable to this source — no federation/portability angle here. ## 🧪 Hypotheses - H1: Agencies that adopt `wp-theme-control` (or similar CLI-first tooling) will report higher version-control adoption for block themes than agencies relying on Create Block Theme's UI-driven export. - H2: The `wp block pattern` vs. `wp block synced-pattern` naming ambiguity causes a measurable rate of failed/incomplete pattern exports among early WP-CLI 3.0 adopters until documentation is fixed. - H3: Coding agents (Claude, Copilot, etc.) operating on WordPress sites produce fewer errors/hallucinated file paths when given CLI-exposed, filesystem-first tooling versus attempting to infer database-held Site Editor state. - H4: Making the DB-to-theme reconciliation function (`WP_Theme_JSON_Resolver`) public API would measurably reduce the number of third-party plugins/tools that reimplement equivalent logic. - H5: Agencies underreport theme version-control practices in vendor surveys because ad hoc/homegrown tooling (as found in Coords' WCUS survey) doesn't map cleanly to "do you use a plugin for this" style questions. ### 📊 Methodology - To test H1/H3: controlled or quasi-experimental comparison of agency dev workflows (task completion time, error rate, git diff cleanliness) using CBT vs. `wp-theme-control` vs. no tooling, ideally recruited from Coords' original WCUS survey respondent pool. - To test H2: telemetry or support-ticket analysis from early WP-CLI 3.0 adopters cross-referenced with `wp block pattern`/`synced-pattern` usage patterns. - To test H4: a Trac/Core proposal tracking discussion volume and third-party reimplementation count before/after any public API change. - To test H5: qualitative follow-up interviews with the original WCUS survey respondents who reported "no version control" to distinguish "no tooling" from "unrecognized homegrown tooling." ### ❓ Questions - Will WP-CLI 3.0 ship with the `wp block` commands as described, and on what timeline relative to WCUS 2026? - Does Core have any appetite for making `WP_Theme_JSON_Resolver`'s reconciliation logic a public, stable API rather than leaving it to CLI-layer workarounds? - How will `wp-theme-control` (or a similar tool) handle the "clear from database" step safely enough for production use — is a confirmation/rollback mechanism planned? - Is there enough overlap between `wp-theme-control`'s goals and Create Block Theme's roadmap to warrant a merge or formal collaboration rather than two competing tools? - What does "agent-first" tooling design mean for other WordPress subsystems beyond theming (e.g., plugin scaffolding, content migrations)? ### 🔮 Future Research - A systematic audit of which WordPress database-held state (patterns, nav menus, pages, media, options) lacks any filesystem/version-control representation, prioritized by agency-reported pain. - Investigation into whether AI coding agents specifically need different WordPress tooling ergonomics than human developers (e.g., preferring deterministic CLI output over GUI screenshots), and what that implies for Core API design generally. - A comparative study of `wp-theme-control` against Create Block Theme and any competing agency-built internal tools, once enough real-world usage accumulates. ### 💡 Implications - **Practice:** agencies currently building bespoke theme-export scripts have a lower-effort alternative to evaluate once WP-CLI 3.0 stabilizes — this could shift internal tooling investment toward contributing to shared open-source tools like `wp-theme-control` instead. - **Policy:** if Core AI or Core Program Team teams take the "agent readiness" framing seriously, this could inform which internal WordPress functions get promoted to public API status. - **Security:** the DB-clearing export step needs explicit safeguards before agency-scale or production use — a security/data-loss review is warranted before broad promotion. - **Education:** this is a good concrete teaching example for "how AI coding agents actually interact with WordPress" — more tangible than abstract agentic-coding explainers. - **Funding:** none directly implicated; this is an individual developer's experimental open-source project, not a funded initiative. ### 🧠 Learning Styles Assessment - Reading level estimate: approximately Flesch-Kincaid grade 10-11 (technical WordPress vocabulary — theme.json, WP-CLI, Site Editor — assumed familiar; sentence structure is conversational and moderate-length). #### 👀 Visual learners - Present: no diagrams, screenshots, or labeled code blocks in this post — purely prose with inline `<code>` command references. - Improve: a before/after diagram of "database state → theme filesystem" and a screenshot of the `plan` command's output would substantially help visual learners grasp the workflow. #### 🔊 Aural learners - Present: none — text-only blog post, no audio/podcast version. - Improve: a short audio walkthrough or the WCUS 2026 talk recording (once available) would serve this learner type. #### 🗣️ Verbal learners - Present: clear analogies (comparing to CBT, referencing Laravel migrations) and defined terms in context. - Improve: a short glossary callout for readers unfamiliar with "Site Editor," "block theme," or "WP-CLI" would lower the entry barrier. #### 🧩 Kinesthetic learners - Present: the repo link and "take it for a test drive on a throwaway site" invitation directly support hands-on learners. - Improve: a numbered quickstart (install → plan → dry-run → export) would make the hands-on path more concrete than the current narrative description. #### 🧠 Logical learners - Present: the plan → review → dry-run → export → clear sequence is presented as a clear causal chain. - Improve: a decision table (when to export vs. clear vs. dry-run) would sharpen this for logical learners. #### 🧑‍🤝‍🧑 Social learners - Present: the four closing questions are an explicit invitation to public discussion/feedback. - Improve: linking directly to a GitHub Discussions thread (rather than just "share your thoughts") would give social learners a concrete venue. #### 🧘‍♀️ Solitary learners - Present: the "peruse the repo" option supports self-directed, independent exploration. - Improve: a self-check list ("does your agency need this? checklist") would help solitary learners self-assess fit without needing to ask anyone. #### 🌿 Naturalistic learners - Present: none — no sustainability or ecosystem-impact framing in this technical post. - Improve: not a natural fit for this content type; low priority to add. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: standard semantic HTML — `<p>` paragraphs, `<li>` list items for the closing questions, `<code>` for inline commands, `<strong>` for the WP-CLI version warning, and descriptive link text (e.g., "Create Block Theme," "an experimental agent skill") rather than "click here." - Improve: the closing questions are wrapped in a single `<li>...</li>` run without a visible `<ul>` heading/label in the fetched markup fragment — confirm the live page wraps them in a properly labeled list region for screen reader users to know they're entering a Q&A block. #### Keyboard navigation - Present: standard inline text links throughout, no custom interactive widgets or JS-driven controls to trap focus. - Improve: not assessable further from html_content alone (no site chrome/nav captured); low risk given the simple content model. #### Contrast and readability - Present: cannot be assessed from html_content alone (no styling data captured in this snapshot). - Improve: verify body text meets 4.5:1 contrast against the live site's theme, particularly for inline `<code>` spans which often use lower-contrast styling. #### Text resizing and reflow - Present: no fixed-width elements or embedded images in the article body that would resist reflow. - Improve: none needed based on visible markup; a full page audit would confirm site-wide reflow behavior at 200% zoom. #### Media and captions - Present: no audio/video embedded in this post. - Improve: not applicable — a future WCUS talk recording would need captions when published. #### Forms and interactions - Present: no forms in the article body itself (the referenced survey lives on a separate page). - Improve: not applicable to this source. #### Standards reference - Maps cleanly to WCAG 2.2 AA success criteria for text alternatives (2.1) and info/relationships (1.3.1) given the clean semantic markup; the main open item is confirming list labeling (1.3.1) for the closing questions block on the live page. ## 🌍 DEIB Assessment - Not applicable to this source in most subcategories — this is a narrow technical developer-tooling post with no demographic, cultural, or representation content to assess. #### Cultural breadth - Present: none — single-author, single-region (US-conference-focused, WCUS) framing. - Improve: not a natural fit for this content type. #### Inclusive language - Present: gender-neutral, professional developer language throughout; no exclusionary terms. - Improve: none needed. #### Neurodiversity support - Present: short paragraphs, consistent structure (problem → solution → open questions) aid predictability. - Improve: more subheadings would help readers who benefit from chunked navigation, since the post currently runs as a single unbroken narrative. #### Representation - Not applicable to this source — no people, roles, or identities depicted or discussed beyond the author's own voice. #### Psychological safety - Present: the author explicitly frames the tool as experimental and invites critique ("What's missing? What's broken?") — a low-pressure, collaborative tone. - Improve: none needed; tone already models good open-source community practice. ## ✅ Logical Validity #### Strong reasoning - Causal argument (early, structural): the claim that "WordPress transitioned away from PHP-based themes right before agents came" is presented as a historical timing observation supporting the thesis that block-theme fragmentation and agentic-coding friction share a root cause. This is reasonably strong because it's falsifiable (one could check whether agent-coding tools handle PHP-theme sites more smoothly) and the author has direct evidence (his own agency survey) for the underlying agency pain point. - Evidence-based claim: the CBT CLI limitation isn't just asserted — it's backed by a link to a 2-year-old open GitHub issue, which is a strong, checkable citation practice for a technical blog post. #### Fallacies - None significant identified. This is a low-rhetoric, evidence-grounded technical post; the author qualifies his own claims ("to be fair, not as a public function," "I don't think agencies are the target audience") rather than overstating them, which is good epistemic hygiene rather than a fallacy to flag. #### Tone of voice - Conversational, first-person, self-deprecating in places ("yes, that's my two-year-old issue"), and explicitly hedged/uncertain about scope ("Plenty to think through," open questions at the end) — consistent with a practitioner sharing in-progress work rather than making a definitive claim. ## 🛡️ DARVO Analysis - Not applicable to this source: no accusation, conflict, or interpersonal dispute is present. This is a solo technical blog post about developer tooling; there is no denial, attack, or victim/offender reversal pattern to analyze. ## 🎯 Conclusion - WordPress's DB-vs-filesystem split in block themes remains unsolved technical debt, and Create Block Theme's UI-first design leaves agency and agentic-coding workflows underserved; Coords' `wp-theme-control` is an early, explicitly experimental attempt to close that gap using WP-CLI's upcoming `wp block` commands instead of a new plugin. - Practical next steps for readers: track the WP-CLI 3.0 release for the `wp block` command family, test `wp-theme-control` on a disposable site if doing agency block-theme work, watch for the `wp block pattern` vs. `synced-pattern` naming gotcha, and consider engaging with Coords' four open feedback questions directly on the GitHub repo or at his WCUS 2026 talk. ## 🔄 Refactor Appendix — An agent-first approach to Create Block Theme > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. Resonance filter: if you can't > articulate in one line why a claim matters, drop it. > > Konik claim-header rules: present tense, declarative, ≤10 words when > possible, searchable, unique, mirrors annotation focus if present. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Atoms (H3) #### [H1] Block themes broke filesystem workflows right before agents needed them > [!quote] ID:rw_briancoords_agentfirstcbt_h1 > The problem is that WordPress transitioned away from PHP-based themes right before agents came and made the filesystem important again. **Context & use**: - Third paragraph of the post, the core thesis statement. - Frames the whole article: block-theme DB/filesystem fragmentation is old agency pain that's now also AI-agent pain — a useful cross-link for any note on WordPress + agentic coding readiness. **Tags**: #xref #addendum **Highlight**: [view highlight](readwise://01kzp0pkbd0dq8k4ygceb97zwb) <!-- atomicity: 1 idea ✓ --> #### [H2] WP-CLI 3.0 exposes granular wp block commands for theme export > [!quote] ID:rw_briancoords_agentfirstcbt_h2 > the upcoming release of WP-CLI includes granular wp block commands for managing and exporting blocks, styles, templates, parts, and patterns. **Context & use**: - Mid-article, the technical pivot point that makes `wp-theme-control` possible without new Core API. - Concrete, checkable claim (dependent on WP-CLI ≥3.0.0 release) — good candidate to revisit once that ships. **Tags**: #xref **Highlight**: [view highlight](readwise://01kzp0pkbd0dq8k4ygceb97zwb) <!-- atomicity: 1 idea ✓ --> #### [H3] wp block pattern misses user-created database patterns > [!quote] ID:rw_briancoords_agentfirstcbt_h3 > the wp block pattern command seem to only interact with code-registered patterns, not user-created patterns in the database. Instead we'll use the oddly-named wp block synced-pattern --sync-status=unsynced command **Context & use**: - A hands-on gotcha discovered while building the tool — directly actionable for anyone scripting WP-CLI pattern exports. - Strong candidate for a documentation-fix action item (already routed to CLI/Documentation subteams above). **Tags**: #xref #addendum **Highlight**: [view highlight](readwise://01kzp0pkbd0dq8k4ygceb97zwb) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] Agent-first tooling exposes existing capability via CLI rather than adding new features **Claim** (one sentence, Courtney's voice): When a platform already has the underlying capability (like WordPress's internal theme.json reconciliation), the fastest way to make it agent-usable is a CLI wrapper, not a new GUI plugin. **Evidence pointer**: [[#H2]] **Scope & conditions**: Holds when the underlying capability already exists internally but lacks public/CLI exposure; breaks down when the capability itself is genuinely missing and needs new engineering, not just a new interface. **Links** (≥1 with annotation): - [[WordPress agentic coding readiness]] — because extends - [[Create Block Theme]] — because contrasts on interface-design-philosophy (UI-first vs. CLI/agent-first) <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Check whether WP-CLI 3.0 has shipped stable and whether `wp block` commands landed as described — https://developer.wordpress.org/cli/commands/block/ #xref - [F2] Watch the `wp-theme-control` repo for maturity signal (issues closed, adoption) before recommending it in client work — https://github.com/bacoords/wp-theme-control #xref ### → Things 3 (max 2 actions) - [ ] Test `wp-theme-control` on a throwaway WordPress Playground instance — WP-CLI tooling eval #things > [!note] Duplicate-source capture. Same content as Reader doc 01kzp0pkbd0dq8k4ygceb97zwb (https://www.briancoords.com/an-agent-first-approach-to-create-block-theme/); analysis copied from that canonical deep-read on 2026-08-13. <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/An Agent-First Approach to Create Block Theme.md|An Agent-First Approach to Create Block Theme by WPNEWS.io]] ## Highlights - How I'm considering replacing Create Block Theme with WP-CLI and an agent skill. ([View Highlight](https://read.readwise.io/read/01kzp1g9wtcfarww91bryvq8q6)) - Note: Link-aggregator teaser; full article processed separately from briancoords.com. - Tags: atom/fleeting/f1