How I published my first WordPress.org plugin with Cursor, Git, and AI

Matt Hummel published his first WordPress.org plugin, TOCguide, a Gutenberg table-of-contents block with an optional reading guide, now live at version 1.6.3. He used Cursor (including cloud agents on the repo), Grok Bot for site and content work, and Git with GitHub Actions CI to compress weeks of PHPCS passes, readme tweaks, and packaging into hours. "The agent drafts. I decide what merges," he wrote, noting that rules, reviews, and CI keep AI-assisted output from lowering the bar.

Today I published my first plugin on WordPress.org https://wordpress.org/plugins/tocguide/ : TOCguide . It is a Gutenberg Table of Contents block with an optional Reading Guide. No accounts, no tracking, no outside APIs. The listing is live at version 1.6.3. This is a slightly shorter Dev.to version of a longer write-up on my site. The full notes are here: How I published my first WordPress.org plugin with Cursor, Git, and AI https://matthummel.com/first-wordpress-org-plugin-tocguide-ai/ . I am a dad of twins. I also have a full-time job and a freelance WordPress side gig. Evenings and weekends are short. Shipping a Plugin Directory product the old way — every PHPCS pass, every readme tweak, every packaging step — would have sat on a list for years. I used AI tools on purpose: Cursor including cloud agents on the repo , Grok Bot for site and content work around matthummel.com, and normal Git + GitHub Actions so the machine checks stayed honest. I am not saying AI replaces judgment. I am saying it compressed weeks of typing and rework into hours I actually had. People are right to be careful with AI. Used poorly, it invents APIs, ships insecure PHP, and fights the WordPress.org guidelines. Used with rules, reviews, and CI, it can raise daily output without lowering the bar. Feedback and pushback are welcome in the comments. TOCguide is a single-purpose block plugin. Display name TOCguide . Slug, folder, text domain, shortcode, and CSS prefix are all tocguide . That one identity mattered for WordPress.org guideline 17 and for long-term support. tocguide shortcode, accessible <nav Cursor rules and cloud agents. Under .cursor/rules/ I keep always-on rules for block coding, brand typography, and the WordPress.org Plugin Directory FAQ plus the 18 guidelines. A CLAUDE.md file states the product intent in plain language. Cloud agents handled large slices as pull requests. I still read every PR. The agent drafts. I decide what merges. Git and GitHub Actions. CI on push and pull request runs lint, build, PHP lint, and PHPCS. Tags like v1.6.2 fire a Release workflow that builds the plugin zip with @wordpress/scripts plugin-zip and attaches it to a GitHub Release. That zip is what goes through SVN to the directory after review. Block architecture. TOCguide is a dynamic block: block.json apiVersion 3 , save.js returns null, and src/render.php prints the nav. Heading maps live in TOCguide Headings so render stays thin. Where Grok Bot fits. Cursor owns the plugin code. Grok Bot owns a different lane for me: site drafts, Rank Math, media, and turning repo facts into readable posts. Same person reviewing both. Different tools for code vs. site content. What helped: If you build plugins with AI, or you refuse to, leave a comment. What worked, what broke review, what you would never trust an agent with. — Matt Hummel