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

- Link: https://matthummel.com/how-i-published-my-first-wordpressorg-plugin-with-cursor-git-and-ai/
- Published: 2026-09-24T01:23:01+00:00
- Author: 

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/).

## Why AI mattered for finishing this

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.

## What TOCguide is

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.

 * Standard TOC: heading levels, nested lists, five Block Styles, sticky/collapse,
   scroll-spy, smooth scroll offset, auto-insert, `[tocguide]` shortcode, accessible`
   <nav>`
 * Optional Reading Guide: section previews, density bars, read-time badges, reading
   progress, author notes, localStorage reactions and citations — all from post 
   content and meta, not remote services
 * Builder fallbacks for Elementor, Bricks, and HTML-based themes
 * License: GPLv2 or later. Privacy: no phone-home

Docs: [matthummel-pa.github.io/tocguide](https://matthummel-pa.github.io/tocguide/)
Source: [github.com/matthummel-pa/tocguide](https://github.com/matthummel-pa/tocguide)

## The setup in brief

**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.

## An honest take on AI

What helped:

 * Written rules in the repo so agents follow Gutenberg and WordPress.org constraints
 * CI as a second reviewer that never gets tired of PHPCS or lint
 * Cloud agents for packaging and repetitive compliance edits while I was with the
   kids or on client work

What still needs a human:

 * Product taste (what belongs in free vs later)
 * Security and escaping reviews
 * Reading the official guidelines yourself before you argue with a reviewer
 * Saying no when a suggestion would phone home, load a CDN script, or lock features
   behind a paywall on .org

I am not claiming AI is magic. I am claiming that for a busy parent shipping a first
directory plugin, the time cost used to be the blocker — and tooling that respects
WordPress standards can change that. If your experience differs, I want to hear 
it.

## Try it

 * [TOCguide on WordPress.org](https://wordpress.org/plugins/tocguide/)
 * [GitHub Releases](https://github.com/matthummel-pa/tocguide/releases)
 * [Docs site](https://matthummel-pa.github.io/tocguide/)
 * [Full article on matthummel.com](https://matthummel.com/first-wordpress-org-plugin-tocguide-ai/)

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

_Originally posted on [DEV.to](https://dev.to/matthummeldev/how-i-published-my-first-wordpressorg-plugin-with-cursor-git-and-ai-118j)._
