Cómo crear un plugin WordPress con IA sin tener ni idea de programar

Si llevas tiempo usando WordPress seguramente has pensado alguna vez «me gustaría un plugin que hiciera exactamente esto» pero lo has descartado porque no sabes programar o no tenías dinero para contratar a alguien que te lo programe. Eso, hasta hace poco, era un muro infranqueable, pero la realidad es que ya no.

Con la inteligencia artificial conversacional puedes crear un plugin de WordPress completo, funcional, seguro y hasta publicable en el repositorio oficial de WordPress.org sin escribir ni una sola línea de código tú mismo. Se le llama vibe coding y, como ya te conté en detalle, consiste en describir lo que quieres a una IA y dejar que ella genere el código por ti.

Pero ojo, que no sea magia no significa que no requiera trabajo. La IA escribe el código, sí, pero tú tienes que saber qué pedirle, cómo probarlo y cómo asegurarte de que lo que te ha dado funciona de verdad y no es un desastre que va a romper tu web. Eso es exactamente lo que vamos a hacer en este tutorial.

Vamos a crear juntos, paso a paso, un plugin de barra de progreso de lectura con tiempo estimado. Un plugin real, útil, con página de ajustes, permisos por rol, selección de tipos de contenido, personalización de colores y posición. Al final del tutorial lo tendrás funcionando en tu WordPress de prueba y, si quieres, publicado en tu web, GitHub o incluso en el repositorio oficial de WordPress.org, esto ya lo decides al final.

Si quieres contexto sobre por qué es bueno que más gente cree plugins con IA o prefieres valorar los argumentos en contra y a favor antes de empezar, ahí tienes los artículos. Aquí vamos directos a la práctica.

Lo que necesitas antes de empezar

No necesitas saber programar, pero sí tener unas cuantas herramientas preparadas. Sin ellas el tutorial no funciona.

Un sitio WordPress de prueba: Esto es innegociable: nunca pruebes un plugin nuevo en tu web en producción. Necesitas un WordPress local o un staging donde puedas romper cosas sin consecuencias. Si no tienes uno montado, sigue esta guía de entornos de desarrollo local y vuelve aquí cuando lo tengas listo.

Un editor de texto/código: Te recomiendo Visual Studio Code, que es gratuito, funciona en todos los sistemas operativos y es el que usa casi todo el mundo. No vas a escribir código en él, pero lo necesitas para organizar los archivos del plugin y copiar lo que te dé la IA en cada archivo correspondiente.

Acceso a una IA conversacional: No voy a recomendar ninguna en concreto. Hay varias buenas para generar código (Claude, ChatGPT, Gemini, Copilot…) y cada una tiene sus ventajas. Lo que sí te digo es que para generar código de plugins las versiones de pago suelen dar resultados bastante mejores que las gratuitas, y lo ideal es una que permita conversaciones largas y adjuntar archivos. Si quieres ahorrar costes, también puedes usar IA en local, aunque los resultados para código complejo suelen ser inferiores a los de los modelos grandes.

Plugin Check (PCP): Instálalo en tu WordPress de prueba. Es el plugin oficial del equipo de revisión de WordPress.org y analiza tu plugin buscando problemas de seguridad, rendimiento y cumplimiento de estándares. Vas a usarlo bastante.

Query Monitor: Otro plugin imprescindible para el WordPress de prueba. Query Monitor te muestra indicadores visuales de si algo va mal: consultas lentas a la base de datos, errores de PHP, problemas de rendimiento… No necesitas entender el código para ver que hay alertas rojas donde no debería haberlas.

WP Crontrol: También obligatorio, y no solo como desarrollador. Este plugin sirva para crontrolar lo que hacen las tareas en segundo plano que se ejecutan en WordPress, de plugins, temas, del mismo WordPress. A los efectos de desarrollo muchas veces te va a ayudar a parar procesos, ejecutarlos anticipadamente para comprobar si funcionan, montones de cosas que cuando las necesites me entenderás.

Kit de emergencia anti-caché: ¿A que no quieres tener que andar vaciando cachés cada vez que hagas un cambio? Pues instala este plugin, lo creé justo para no pelearte con la caché en entornos de desarrollo, y Vibe Coder o no, estás en modo desarrollo ¿o no te habías dado cuenta?

Download Plugin: Este plugin no hace falta que lo tengas siempre instalado, pero conviene para después de hacer las pruebas, para descargarte el zip finalizado de la instalación de desarrollo. Cuando lo activas añade un enlace en la pantalla de plugins para descargarlo fácilmente.

Activar el modo debug: Tienes dos opciones. La sencilla es instalar un plugin como Debug Log Manager, que te permita activar y desactivar las constantes de depuración de WordPress directamente desde el escritorio, sin tocar archivos, y que además incluye un visor del registro de errores integrado.

La manual pasa por abrir el archivo wp-config.php de tu instalación (está en la carpeta raíz de WordPress) y añadir estas líneas justo antes de donde dice /* That's all, stop editing! */:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Con esto WordPress guardará todos los errores en un archivo llamado debug.log dentro de la carpeta wp-content. Si estás en local cualquiera de las dos opciones te vale, si estás en un staging online el plugin es más cómodo.

Para una visión completa de todas las herramientas disponibles para desarrollo WordPress tienes este artículo con todas las imprescindibles.

Antes de pedirle nada a la IA, piensa y planifica

Este es el paso que separa un plugin decente de un engendro con 47 errores, y también es un paso previo que a la larga te va a ahorrar una enorme pérdida de tiempo posterior. Hazme caso, aprende de mis errores y antes de abrir la IA, siéntate y piensa.

¿Hace falta tu plugin?

Antes de dedicar tiempo a crearlo, comprueba lo más obvio:

• Busca en el directorio de plugins de WordPress.org con diferentes términos. ¿Existe ya algo que hace exactamente lo mismo?
• Si hay varios que hacen algo parecido, ¿el tuyo aporta algo diferente? ¿Lo resuelve de otra forma, es más sencillo, más ligero, tiene un enfoque distinto?
• ¿Resuelve un problema real que tenga suficiente gente, o es un capricho personal que no le interesa a nadie más?

Si la respuesta honesta es «ya hay cinco que lo hacen igual de bien», ahórrate el tiempo y usa uno de esos. No pasa nada, la idea es crear cosas que aporten, no duplicar por duplicar.

Ten muy claro qué es lo que quieres

Esto es lo que va a convertirse en tu prompt, así que cuanto más claro lo tengas aquí, mejor será el resultado. Tienes obligatoriamente que hacerte estas preguntas:

• ¿Qué hace el plugin exactamente? Funcionalidad concreta, nada de ideas vagas tipo «algo para mejorar la experiencia de lectura».
• ¿Dónde aparece? ¿Solo en el frontend, solo en el panel de administración, en ambos?
• ¿Qué opciones puede configurar el usuario?
• ¿Quién puede configurarlo? ¿Solo el administrador, también los editores?
• ¿En qué tipos de contenido funciona? ¿Entradas, páginas, custom post types?
• ¿Qué NO debe hacer? Limitar el alcance es tan importante como definir lo que sí hace.

Para nuestro plugin de ejemplo, la especificación quedaría así:

• Qué hace: muestra una barra de progreso de lectura que avanza según el usuario hace scroll, y el tiempo estimado de lectura del contenido.
• Dónde aparece: la barra en el frontend (parte superior o inferior de la ventana), el tiempo estimado dentro del contenido. Los ajustes en el panel de administración.
• Opciones configurables: color de la barra, posición (arriba o abajo), altura de la barra, mostrar u ocultar el tiempo estimado, velocidad de lectura en palabras por minuto, en qué tipos de contenido aparece.
• Quién lo configura: solo usuarios con rol de administrador.
• En qué contenido: entradas por defecto, pero configurable para incluir páginas u otros tipos de contenido.
• Qué NO hace: no guarda datos de los visitantes, no añade analytics, no se conecta a servicios externos, no modifica el contenido del post.

Dale habilidades a la IA: skills para WordPress

Antes de pedirle que genere código hay algo que marca la diferencia entre un resultado mediocre y uno profesional, y es ni más ni menos algo que habrás leído por ahí que es un nivel avanzado, pero que resulta que es muy sencillo de aplicar. Me refiero a darle a la IA conocimiento especializado sobre cómo se programa bien en WordPress.

Las skills o instrucciones especializadas son archivos de texto que enseñan a la IA las buenas prácticas, los patrones correctos y los errores más comunes, en este caso en el desarrollo de plugins. Sin ellas, la IA tiende a generar código anticuado, con fallos de seguridad o que no pasaría la revisión del directorio de plugins de WordPress.org, que debe ser nuestro estándar a conseguir, lo vayamos a publicar o no.

¿Y por qué te importa esto si no sabes programar? Porque tú no puedes revisar si el código sigue los estándares de WordPress, pero si la IA tiene instrucciones claras sobre esos estándares antes de empezar, las probabilidades de que lo haga bien suben mucho.

Dónde conseguir skills de IA:

• Las skills de AyudaWP están enfocadas específicamente a desarrollo de plugins, seguridad y rendimiento en WordPress. Son las que yo uso y las que te recomiendo como punto de partida.
• El repositorio oficial de WordPress (agent-skills) tiene un conjunto más amplio que cubre también bloques, temas y la API REST.
• Tanto Anthropic como OpenAI tienen sus propios repositorios de skills con instrucciones genéricas y específicas para distintos tipos de desarrollo.

Cómo usar skills de IA:

Cada IA tiene su forma de cargar este tipo de instrucciones. Algunas permiten adjuntar archivos al inicio de la conversación, otras tienen carpetas de configuración donde las detectan automáticamente, y otras aceptan que pegues las instrucciones directamente en el primer mensaje. Lo importante es que la IA las tenga disponibles antes de pedirle que genere código, no después.

Si quieres profundizar en cómo configurar cada IA concreta (Claude, ChatGPT, Copilot, Cursor…) para que cargue estas instrucciones de forma permanente, tienes esta guía completa sobre cómo configurar las IAs para programar WordPress.

El prompt: unas buenas instrucciones definen la calidad del resultado

No pidas todo de golpe

Este es probablemente el consejo más importante de todo este tutorial. La tentación es describir el plugin entero en un mensaje enorme del tipo «quiero una barra de lectura con ajustes de color, posición, tiempo estimado, permisos por rol, selector de tipos de contenido…».

El problema con las IAs, y en general en la vida, es que cuantas más cosas metes en un solo prompt, más probabilidades hay de que algo falle. Y cuando falla no sabes si el error está en la barra, en los ajustes, en los permisos o en la interacción entre todos ellos.

El enfoque que funciona es hacer peticiones por versiones, de manera que empieces con la versión más básica que haga algo visible y funcional, y una vez eso funcione y esté probado, añades la siguiente pieza, y así paso a paso hasta completar el plugin.

Para nuestro ejemplo, como yo abordaría las versiones sería así:

• Versión 1: solo la barra de progreso, con un color fijo, que aparezca en todas las entradas. Sin ajustes, sin extras. Lo mínimo para ver que funciona.
• Versión 2: página de ajustes con selector de color, posición de la barra (arriba/abajo), altura y selector de tipos de contenido.
• Versión 3: cálculo y visualización del tiempo estimado de lectura, con opción de activarlo o desactivarlo y configurar las palabras por minuto.
• Versión 4: permisos por rol para acceder a la página de ajustes.

Cómo escribir un buen prompt para un plugin de WordPress

La estructura que mejor funciona tiene estas partes:

1. Rol y contexto: dile a la IA quién es y para qué trabaja.
2. Qué tiene que hacer esta versión concreta: solo la funcionalidad de esta versión, nada más.
3. Requisitos técnicos no negociables: estándares de WordPress, seguridad, compatibilidad PHP, archivos separados para CSS y JS, funciones con prefijo propio, preparado para traducción.
4. Estructura de archivos esperada: que sepa de antemano cómo organizar el código.
5. Lo que NO quieres: que no añada nada que no hayas pedido, que no proponga extras, que no sugiera mejoras.

Aquí tienes el prompt real para la versión 1 de nuestro plugin de ejemplo. Puedes copiarlo tal cual y/o adaptarlo a tu propio plugin:

Eres un desarrollador WordPress senior especializado en creación de plugins para el repositorio oficial de WordPress.org.

TAREA:
Crea la versión 1.0.0 de un plugin llamado "Reading Time Progress Bar Pro" con el slug "reading-time-progress-bar-pro" y el prefijo "rpb_" para todas las funciones, clases, constantes y handles.

FUNCIONALIDAD DE ESTA VERSIÓN (solo esto, nada más):
- Muestra una barra de progreso horizontal fija en la parte superior de la ventana del navegador.
- La barra avanza de 0% a 100% según el usuario hace scroll por el contenido del post.
- Solo aparece en entradas individuales (single posts).
- Color fijo: #2563eb (azul).
- Altura fija: 4px.
- La barra debe estar por encima de cualquier otro elemento (z-index alto).

REQUISITOS TÉCNICOS OBLIGATORIOS:
- Cumplir los WordPress Coding Standards.
- Compatible con PHP 7.4 hasta PHP 8.3.
- Todo el CSS en un archivo externo en /assets/css/, cargado con wp_enqueue_style().
- Todo el JavaScript en un archivo externo en /assets/js/, cargado con wp_enqueue_script().
- NUNCA imprimir etiquetas script o style directamente con PHP.
- Todas las cadenas de texto preparadas para traducción con el text domain 'reading-time-progress-bar-pro'.
- Escapar todo el output.
- Incluir archivo readme.txt válido para WordPress.org.
- El archivo PHP principal solo debe contener la cabecera del plugin, constantes y la carga de los archivos de /includes/.
- Cada funcionalidad en su archivo separado dentro de /includes/.
- Entrega todo en un archivo comprimido ZIP, listo para instalar.

ESTRUCTURA DE ARCHIVOS:
reading-time-progress-bar-pro/
├── reading-time-progress-bar-pro.php (archivo principal, solo bootstrap)
├── readme.txt
├── assets/
│   ├── css/
│   │   └── frontend.css
│   └── js/
│       └── frontend.js
└── includes/
    └── class-rpb-frontend.php

NO QUIERO:
- Nada de página de ajustes en esta versión.
- Nada de opciones configurables.
- Nada de funcionalidades extra que no haya descrito.
- Nada de sugerencias de mejoras futuras.
- Nada de explicaciones largas, solo el código de cada archivo.

Optimiza el prompt antes de enviarlo

Si quieres asegurarte de que el prompt tiene buena estructura y no te falta nada importante, puedes pasarlo por el optimizador de prompts de AyudaWP.

Selecciona la plantilla de «Desarrollo de código WordPress», pega tu instrucción principal, ajusta el rol a desarrollador senior, marca las restricciones que apliquen (WordPress Coding Standards, sin anglicismos, código comentado) y genera la versión optimizada. Muchas veces añade contexto que se te había pasado por alto.

Ajustes que te recomiendo si usas el optimizador de prompts para esta tarea:

1. Plantilla inicial – Utiliza la de desarrollador de código WordPress, te ahorra clics en todos estos ajustes:
   • Rol e identidad de la IA.
   • Contexto y audiencia.
   • Formato de salida.
2. Restricciones y lo que debe evitar – Unos pequeños ajustes te quitarán ruido a la respuesta y aportan mejoras:
   • No repetir información básica obvia
   • Código siempre comentado
   • Seguir WordPress Coding Standards
3. Técnicas avanzadas – Te ayudarán y mucho:
   • Usar etiquetas XML para estructurar
   • Permitir preguntas de aclaración
   • Incluir ejemplo de entrada/salida (few-shot)

Lo mejor de usar el optimizador de prompts es que puedes descargarte los prompts mejorados y tener varias versiones, guardarlos para uso futuro, tener el historial. Vamos, imprescindible.

Bola extra: Proyectos y tareas

Si tu IA favorita lo permite organiza tus tareas usando proyectos, carpetas o como lo llame. Este tipo de herramienta facilita cosas muy importantes:

1. Tener tu trabajo organizado
2. Ajustes personalizados para cada tarea, distintos de las preferencias generales
3. Mantener contexto entre distintos prompts del mismo trabajo
4. Memoria contextual del trabajo al estar todo en un mismo entorno

¿Te había dicho ya que en el trabajo con IAs generativas el contexto lo es todo? Pues es así, y usando proyectos, tareas o carpetas, como se estructure tu IA, es el modo más efectivo.

Gestionar la conversación con la IA

Antes de ver el proceso versión por versión, tres reglas que aplican a cada interacción con la IA durante todo el desarrollo del plugin:

• La IA va a preguntar, y eso es normal: Si has hecho bien el prompt, las preguntas serán pocas y concretas: «¿quieres que el z-index sea 9999 o prefieres otro valor?», «¿el color hexadecimal incluye transparencia?». Responde solo a lo que pregunte, sin añadir ideas nuevas. Cada cosa que añadas fuera de plan es una puerta abierta a complicaciones.
• Frena la verborrea: Hay IAs que por cada línea de código te sueltan tres párrafos explicando por qué han tomado esa decisión, qué alternativas había y qué podrías mejorar en el futuro. Si te pasa, córtala: «Genera solo el código tal como lo he descrito. Sin explicaciones adicionales, sin alternativas, sin sugerencias. Solo los archivos con su código.»
• La trampa de las sugerencias infinitas: Esto es especialmente común con GPT, aunque todas lo hacen en mayor o menor medida. No hace más que de darte el código y enseguida te va a soltar cosas como, «¿quieres que añada también un modo oscuro? ¿lo integramos con Google Analytics? ¿quieres que sea compatible con AMP?». La respuesta es siempre NO. Si no estaba en la especificación que preparaste no entra. Anota las ideas que te parezcan buenas para futuras versiones, pero sigue con lo que tenías planeado, no te dejes engatusar.

Si caes en esa espiral de «sí, ponle eso también», en dos horas tienes un engendro con 15 funcionalidades a medio hacer, errores que se cruzan entre sí y ninguna posibilidad real de arreglarlo que no sea empezar de cero.

Dicho esto, pasamos a la acción… ¿no?

Versión 1: Tu primer plugin funcional

Esta es la versión más importante de todo el proceso. Y no lo es porque sea la más completa (es la más básica), sino porque es donde aprendes el ciclo completo: pedir, montar, probar, corregir, auditar. Cuando domines este ciclo con la V1, repetirlo con las demás versiones es más mecánico.

Paso 1: Enviar el prompt

Toma el prompt que preparaste en la sección anterior (o adáptalo a tu propio plugin) y suéltaselo a la IA. Si has cargado las skills de WordPress previamente mejor, si no, al menos pégalas en este primer mensaje o adjúntalas como archivo.

Recuerda que este prompt es solo para la versión 1.  Aquí solo queremos la barra de progreso con color fijo, sin ajustes, sin extras.

Es tentador añadir «y ya que estás, ponle también los ajustes» pero no lo hagas. Queremos algo pequeño, que podamos probar por completo y asegurarnos de que funciona antes de añadir nada más.

Regálate pequeños triunfos, no una tarea enorme desde el principio.

Paso 2: Evaluar lo que te devuelve

La IA te debería dar un zip con todos los archivos, y si por algún motivo no puede (limitaciones de su sistema) te entregará los archivos por separado con indicaciones de cómo organizarlos en carpetas. En cualquier caso, y siempre antes de instalar tu recién y flamante nuevo plugin versión 1.0, haz una comprobación rápida:

¿Te ha dado todos los archivos que pediste?

Revisa que estén todos los de la estructura que indicaste en el prompt. En nuestro ejemplo deberían ser cinco: reading-time-progress-bar-pro.php, readme.txt, includes/class-rpb-frontend.php, assets/css/frontend.css y assets/js/frontend.js.

Si falta alguno, pídeselo:

Falta el archivo assets/js/frontend.js. Genéralo siguiendo las mismas instrucciones del prompt original.

¿Ha añadido algo que no pediste?

Mira por encima si hay archivos extra, si ha metido una página de ajustes que no tocaba, o si ha añadido funcionalidades que no estaban en el prompt. Si es así, díselo claramente:

Has añadido una página de ajustes y un selector de color. No los he pedido en esta versión. Elimínalos y dame solo lo que indicaba el prompt: la barra básica con color fijo, sin opciones.

¿Ha empezado a hacer preguntas o sugerencias en vez de darte el código?

Esto pasa bastante. La IA te responde con «Antes de empezar, tengo algunas preguntas sobre la implementación…» seguido de diez preguntas sobre cosas que ya estaban claras en el prompt. Si el prompt estaba bien hecho y las preguntas no aportan nada, responde:

Toda la información necesaria está en el prompt. Genera el código tal como lo he descrito.

Si alguna pregunta es realmente necesaria (algo que se te olvidó especificar) respóndela de forma escueta y pídele que genere el código.

Paso 3: Instalar, activar y primera comprobación

Ve a la pantalla de plugins en el escritorio de WordPress y haz clic en «Añadir nuevo > Subir», esto ya sabes hacerlo, sube el zip y tras subirlo actívalo. Tu plugin debería aparecer en la lista con el nombre «Reading Time Progress Bar Pro», la descripción y los datos de versión que indicaste en el prompt.

Si por lo que sea no aparece comprueba que la carpeta está dentro de wp-content/plugins/, que el archivo PHP principal tiene la cabecera correcta y que no has dejado la carpeta del plugin metida dentro de otra carpeta extra (un error muy habitual al descomprimir ZIPs: plugins/reading-time-progress-bar-pro/reading-time-progress-bar-pro/).

Si aparece actívalo, y pueden pasar tres cosas:

• Se activa sin problema: Perfecto, pasa al siguiente paso.
• Aparece un mensaje de error pero el sitio sigue funcionando: Copia el mensaje de error exacto. Lo vas a necesitar.
• Pantalla blanca o error grave: No te asustes. Accede a tu carpeta de plugins por FTP o gestor de archivos y cambia el nombre de la carpeta del plugin (por ejemplo, de reading-time-progress-bar-pro a reading-time-progress-bar-pro-OFF). Esto lo desactiva inmediatamente. Luego abre el debug log (wp-content/debug.log) y copia el último error que aparezca.

Si has tenido un error salta directamente al paso 7 (corrección). Si todo ha ido bien sigue a continuación con el paso 5.

Paso 4: Probar que funciona de verdad

¿A que da como gustirrinín? No me negarás que es un subidón que se active tu primer plugin hecho con IA ¿verdad?

Pero, ah, el hecho de que se haya activado sin errores no significa que funcione. Ahora toca comprobarlo en la web.

Visita una entrada de tu blog de prueba y comprueba:

• ¿Se ve la barra azul en la parte superior de la ventana del navegador?
• ¿La barra avanza según haces scroll hacia abajo?
• ¿Llega al 100% cuando llegas al final del contenido?
• ¿Se restablece a 0% cuando vuelves arriba del todo?

Ahora comprueba donde no debería aparecer:

• Visita la página de inicio o el archivo del blog. ¿Sale la barra? No debería.
• Visita una página (no una entrada). ¿Sale? No debería en esta versión.
• Entra en el panel de administración. ¿Sale? No debería aparecer nunca ahí.

Prueba también en otro navegador (si usas Chrome, prueba en Firefox o al revés) y en el móvil (o usando el modo responsive de las herramientas de desarrollo del navegador, pulsando F12 y el icono de dispositivo).

Si algo no funciona como debería anota exactamente qué falla para luego decírselo a la IA: «la barra aparece pero no se mueve al hacer scroll», «la barra no aparece en ningún sitio», «la barra aparece también en páginas y no debería». Cuanto más preciso seas más fácil será para la IA corregirlo.

Paso 5: El documento resumen (tu mapa del plugin)

Antes de seguir adelante, pídele a la IA un documento que te explique en lenguaje normal qué hace cada archivo del plugin y cómo se conectan entre sí:

Te adjunto todos los archivos de mi plugin Reading Time Progress Bar Pro versión 1. Necesito un documento resumen en español que explique:

1. Qué hace cada archivo y cuál es su función dentro del plugin.
2. Cómo se conectan los archivos entre sí (qué archivo carga a cuál).
3. Qué hace cada sección o función principal, explicado para alguien que no sabe programar.
4. Dónde está la lógica del frontend (lo que ve el visitante).

El documento es para mi uso interno, para poder hablar contigo sobre el plugin sabiendo a qué parte me refiero.

Este documento es tu salvavidas. Cuando algo falle más adelante, necesitas poder decirle a la IA «el problema está en la función que calcula el porcentaje de scroll» en vez de «no funciona». Guárdalo junto al código del plugin como oro en paño, expórtalo, adjúntalo al proyecto, copiapega en un Word, lo que te sea más cómodo.

Paso 6: Comprobaciones de seguridad y calidad

Incluso si todo parece funcionar hay cosas que no se ven a simple vista. Estas herramientas las detectan por ti:

Plugin Check (PCP): ve a Herramientas → Comprobar plugins en tu escritorio de WordPress, selecciona tu plugin, activa todas las casillas y ejecuta el análisis, te dará una lista de resultados:

• Errores: hay que corregirlos sí o sí. Son problemas de seguridad, funciones mal usadas o incumplimientos graves de los estándares.
• Advertencias: recomendaciones que conviene atender. No son graves pero pueden dar problemas en la revisión de WordPress.org.
• Recomendaciones: mejoras a tener en cuenta, casi siempre de rendimiento.

Si tienes errores no los ignores. Copia cada mensaje de error exacto (el texto completo, con la ruta del archivo y el número de línea), o exporta el listado completo usando los botones que ofrece Plugin Check porque los vas a necesitar en el paso siguiente.

Si dudas qué formato elegir descárgalo en formato markdown, es muy ligero y a las IA les encanta.

Debug Log: abre la pantalla del plugin Debug Log Viewer y mira el visor del log, o abre directamente wp-content/debug.log con VS Code, lo que prefieras. Busca líneas que contengan el nombre de tu plugin o sus archivos. Los «Fatal error» y «Error» son problemas graves, los «Warning» y «Notice» son menores pero conviene corregirlos. Copia todo lo que encuentres y luego se lo cascas a la IA.

Query Monitor: mira su panel en la barra de administración mientras visitas una entrada con la barra activa. Fíjate en dos cosas, si la pestaña de errores PHP muestra algo en rojo y si la pestaña de consultas a la base de datos tiene números inusualmente altos o alertas (suele ponerse en rojo). Para una versión 1 tan sencilla no debería haber consultas a la base de datos propias del plugin, si las hay es señal de que algo no está bien.

Paso 7: Correcciones y cambios – El segundo prompt casi siempre es el más importante

Si las pruebas o las comprobaciones han detectado problemas toca corregir. La forma en que le describes el error a la IA es casi tan importante como el prompt original. No vale con decir «no funciona». Necesitas darle toda la información:

El plugin Reading Time Progress Bar Pro versión 1 tiene los siguientes problemas.

PROBLEMA 1 - Error en el debug log:
[pega aquí el mensaje de error exacto, incluyendo archivo y número de línea]

PROBLEMA 2 - Error de Plugin Check:
[pega aquí el mensaje de PCP exacto]

PROBLEMA 3 - Funcional:
La barra aparece correctamente en las entradas pero también aparece en las páginas, y en esta versión solo debería mostrarse en entradas individuales.

Corrige estos tres problemas. No cambies nada más del código, no añadas funcionalidades nuevas, no hagas mejoras que no te haya pedido.

Fíjate en lo último: «no cambies nada más». Esto es importante porque muchas IAs aprovechan una corrección para «mejorar» otras cosas que no les habías pedido, y eso puede romper lo que antes funcionaba. Tú ni caso, aunque insista.

Una vez te dé las correcciones, aplícalas y vuelve al paso 5, probando todo desde el principio. No solo lo que se ha corregido, sino también lo que antes funcionaba, porque una corrección puede romper otra cosa.

Regla de los tres intentos: si llevas tres o cuatro rondas para el mismo problema y la IA no lo resuelve, para. Borra esa parte y pídesela de nuevo desde cero en un mensaje nuevo y más claro. Es más rápido que seguir apilando parches.

Paso 8: Mejorar y auditar

Cuando todo funciona y las comprobaciones salen limpias, quedan dos pasadas finales antes de dar la versión 1 por cerrada.

Pasada de mejora: «Mejóralo»

Pídele a la IA que revise su propio código:

Te adjunto el código completo del plugin Reading Time Progress Bar Pro versión 1. Funciona correctamente y pasa Plugin Check sin errores.

Revisa todo el código buscando:
1. Problemas de seguridad que se te hayan pasado (sanitización, escapado, comprobaciones).
2. Problemas de rendimiento (assets cargándose donde no deben, código ejecutándose en cada petición innecesariamente).
3. Incumplimientos de los WordPress Coding Standards.

Dame solo las correcciones necesarias, sin añadir funcionalidades nuevas.

Casi siempre encuentra algo. A veces un esc_html() que falta, a veces un archivo CSS cargándose también en el admin cuando solo debería cargarse en la web. Aplica las correcciones y vuelve a probar desde el principio.

Pasada de auditoría cruzada: Coge todo el código y dáselo a la misma IA en una conversación nueva (sin contexto previo, sin historial de cómo se generó), o mejor aún, a una IA diferente:

Eres un auditor de seguridad y calidad de plugins de WordPress. Te adjunto el código completo de un plugin llamado Reading Time Progress Bar Pro.

Analiza todo el código buscando:
1. Vulnerabilidades de seguridad (XSS, CSRF, inyección SQL, falta de sanitización o escapado).
2. Problemas de rendimiento.
3. Incumplimientos de los WordPress Coding Standards y de las directrices del repositorio de WordPress.org.
4. Errores lógicos o bugs potenciales.

Sé riguroso. Lista cada problema encontrado con su ubicación exacta (archivo y sección) y la corrección propuesta.

La conversación nueva o con una IA diferente son importantes pues al no tener el contexto de cómo se generó el código, lo analiza con ojos frescos y podría detectar cosas que en la conversación original se pasaron por alto.

Aplica las correcciones relevantes, prueba una última vez, y la versión 1 está lista.

Versión 2: Añadir la página de ajustes

Con la versión 1 funcionando y auditada, es hora de empezar a hacer un plugin ya algo más pro, añadirle la funcionalidad de que el usuario pueda configurar el plugin sin tocar código.

El prompt

El prompt para cada nueva versión siempre empieza adjuntando el código completo de la versión anterior. La IA necesita saber qué hay hecho para construir encima:

Te adjunto el código completo y funcional del plugin Reading Time Progress Bar Pro versión 1.0.0.

TAREA:
Actualiza el plugin a la versión 2.0.0 añadiendo SOLO lo siguiente:

PÁGINA DE AJUSTES:
- Añadir una página de ajustes dentro del menú Ajustes de WordPress (Settings API).
- Solo los usuarios con la capacidad manage_options pueden acceder.
- Los ajustes se almacenan en una única opción en la base de datos (no una opción por cada ajuste).

OPCIONES DE LA BARRA:
- Color de la barra: campo de tipo color con valor por defecto #2563eb.
- Posición: selector con dos opciones, arriba o abajo de la ventana. Por defecto arriba.
- Altura: campo numérico en píxeles, por defecto 4, mínimo 1, máximo 20.

OPCIONES DE CONTENIDO:
- Checkboxes para seleccionar en qué tipos de contenido aparece la barra. Listar todos los post types públicos del sitio dinámicamente.
- Por defecto solo 'post' (entradas) activado.

IMPLEMENTACIÓN:
- El frontend ahora debe leer los ajustes guardados en vez de usar valores fijos.
- El CSS dinámico (color, altura, posición) debe aplicarse con wp_add_inline_style(), no con estilos inline en el HTML.
- Crear un nuevo archivo includes/class-rpb-admin.php para toda la lógica de administración.
- Crear un nuevo archivo assets/css/admin.css para los estilos de la página de ajustes.
- Actualizar el readme.txt con la nueva funcionalidad.

REQUISITOS TÉCNICOS:
[los mismos que en la versión 1: WordPress Coding Standards, PHP 7.4+, archivos separados, prefijo rpb_, translation-ready, escapar todo]

NO QUIERO:
- Nada de tiempo estimado de lectura en esta versión.
- Nada de permisos por rol más allá de manage_options.
- Nada de preview en vivo de los ajustes.
- Nada de funcionalidades extra.
- Nada de sugerencias de mejoras.

¡Revisa todo!

Cuando la IA te devuelva el código comprueba que los archivos originales de la V1 se han actualizado (no reemplazado por completo con algo diferente) y que los archivos nuevos (class-rpb-admin.php, admin.css) están incluidos.

A veces la IA te da solo los archivos nuevos y te dice «el resto queda igual», si es así pídele todos los archivos completos:

Dame todos los archivos del plugin completos, incluidos los que no han cambiado. No quiero tener que adivinar cuáles se han modificado y cuáles no

Monta los archivos igual que con la V1 si fuese necesario, o sea, sustituye los que han cambiado, añade los nuevos y revisa la estructura de carpetas.

Probar la versión 2

Primero, repite todas las pruebas de la versión 1. La barra tiene que seguir funcionando exactamente igual que antes en la web, pues si algo se ha roto al añadir los ajustes necesitas detectarlo ahora.

Luego, las pruebas específicas de los ajustes:

• Ve a Ajustes en el menú del escritorio. ¿Aparece la opción del plugin?
• Entra en la página de ajustes. ¿Se ven todos los campos (color, posición, altura, tipos de contenido)?
• ¿Los valores por defecto son correctos sin haber guardado nada? (Azul, arriba, 4px, solo entradas marcado.)
• Cambia el color a rojo, la posición a abajo, la altura a 8px, quita la marca de entradas y cámbialo a páginas. Guarda. ¿Sale el mensaje de confirmación de WordPress?
• Recarga la página de ajustes. ¿Los valores se han guardado correctamente?
• Ve a la web y visita una página. ¿La barra ahora es roja, de 8px y está abajo?
• Visita ahora una entrada y comprueba que no se ve ninguna barra de progreso.

1. Prueba de permisos: si tienes un usuario con perfil de editor o autor en tu WordPress de prueba, inicia sesión con ese usuario o cambia al usuario tras activar el plugin User Switching. ¿Puede ver la opción de ajustes del plugin en el menú? No debería, y si puede acceder es un problema de seguridad que hay que corregir.
2. Plugin Check, Debug Log y Query Monitor: ejecútalos igual que con la V1. Ahora que hay ajustes guardados en la base de datos Query Monitor debería mostrar las consultas correspondientes, pero no deberían ser excesivas (una o dos como mucho para leer las opciones).

Si hay problemas corrígelos con el mismo patrón del paso 8 de la V1: error exacto, qué esperabas, qué pasa, código adjunto.

Cuando todo esté limpio haz las dos pasadas de mejora y auditoría con los mismos prompts adaptados a la versión 2 y pasa a la siguiente.

Versión 3: Tiempo estimado de lectura

Esta versión añade la funcionalidad que convierte el plugin de algo «útil» a un plugin «completo», que muestra al visitante cuánto tardará en leer el contenido.

El prompt

Te adjunto el código completo y funcional del plugin Reading Time Progress Bar Pro versión 2.0.0.

TAREA:
Actualiza el plugin a la versión 3.0.0 añadiendo SOLO lo siguiente:

TIEMPO ESTIMADO DE LECTURA:
- Calcular el tiempo estimado de lectura del contenido del post actual en PHP.
- Mostrar el tiempo estimado en el frontend, justo antes del contenido del post, con el formato "X min de lectura".
- El cálculo se basa en las palabras del contenido divididas entre las palabras por minuto configuradas.
- Usar el filtro the_content para insertar el tiempo estimado. No modificar plantillas del tema.

NUEVOS AJUSTES (añadir a la página existente):
- Activar/desactivar la visualización del tiempo estimado (checkbox, activado por defecto).
- Palabras por minuto: campo numérico, por defecto 200, mínimo 100, máximo 400.

IMPLEMENTACIÓN:
- Crear un nuevo archivo includes/class-rpb-reading-time.php para la lógica de cálculo e inserción.
- El HTML del tiempo estimado debe tener una clase CSS propia para que el usuario pueda personalizarlo con CSS del tema si quiere.
- Actualizar el readme.txt.

REQUISITOS TÉCNICOS:
[los mismos de siempre]

NO QUIERO:
- Nada de permisos por rol adicionales en esta versión.
- Nada de shortcodes ni bloques de Gutenberg.
- Nada de analytics ni seguimiento.
- Nada de funcionalidades extra.

Probar la versión 3

Lo de siempre primero, todas las pruebas de las versiones anteriores. La barra y los ajustes tienen que seguir funcionando exactamente igual.

Pruebas específicas del tiempo de lectura:

• Visita una página o entrada, lo que tuvieses antes activado en los ajustes. ¿Aparece el texto «X min de lectura» encima del contenido?
• ¿El número es razonable? Si la entrada tiene unas 1.000 palabras y está configurado a 200 palabras por minuto, debería decir «5 min de lectura». Si dice 0 o un número absurdamente alto, algo falla en el cálculo.
• Cambia las palabras por minuto en ajustes (ponlas a 100, por ejemplo). ¿El tiempo estimado cambia acorde (ahora debería decir 10 min para la misma entrada)?
• Desactiva el tiempo estimado en ajustes. ¿Desaparece? ¿La barra de progreso sigue funcionando?
• ¿El tiempo estimado aparece solo en los tipos de contenido seleccionados, igual que la barra?
• Si la entrada tiene poco texto (por ejemplo, una frase), ¿muestra «1 min read» o algo raro como «0 min»?

Pasa como siempre Plugin Check, Debug Log, Query Monitor y corrige si hace falta. Las dos pasadas de mejora y auditoría, ya conoces la retahíla.

Advertencia: No te saltes ningún paso de comprobación en ninguna versión, y especialmente en las más avanzadas, no te confíes, que luego vienen los disgustos.

Versión 4: Permisos por perfil de usuario

La última pieza es permitir que el administrador decida qué perfiles (roles) de usuario pueden acceder a los ajustes del plugin.

El prompt

Te adjunto el código completo y funcional del plugin Reading Time Progress Bar Pro versión 3.0.0.

TAREA:
Actualiza el plugin a la versión 4.0.0 añadiendo SOLO lo siguiente:

PERMISOS POR ROL:
- En la página de ajustes, añadir una nueva sección "Permisos".
- Checkboxes con los roles de WordPress que pueden acceder a la página de ajustes del plugin.
- Por defecto solo el administrador tiene acceso.
- El control de acceso debe usar las capacidades de WordPress (capabilities), no comparar nombres de rol directamente.
- Si un rol deja de tener acceso y hay un usuario de ese rol en la página de ajustes, al recargar debe ver un mensaje de permisos insuficientes.

IMPLEMENTACIÓN:
- Modificar la comprobación de permisos existente para usar la nueva configuración.
- Los ajustes de permisos solo los puede modificar un administrador (manage_options), independientemente de qué otros roles tengan acceso a los ajustes del plugin.
- Actualizar el readme.txt con la nueva funcionalidad y subir la versión a 4.0.0.
- Actualizar el changelog en el readme.txt con los cambios de cada versión (1.0.0, 2.0.0, 3.0.0 y 4.0.0).

REQUISITOS TÉCNICOS:
[los mismos de siempre]

NO QUIERO:
- Nada de capacidades personalizadas (custom capabilities).
- Nada de interfaz de gestión de roles.
- Nada de funcionalidades extra.

Probar la versión 4

Las pruebas de permisos requieren un poco más de trabajo porque necesitas usuarios de prueba con diferentes roles. Si no los tienes en tu WordPress de prueba créalos, uno con perfil de editor y otro con el de autor es más que suficiente.

• Con el de administrador: ve a ajustes del plugin, sección permisos. ¿Aparecen los perfiles de WordPress con casillas?
• Marca «Editor» además de «Administrador» y guarda.
• Inicia sesión como editor (o usa de nuevo User Switching). ¿El editor ve la opción de ajustes del plugin? ¿Puede cambiar el color y la posición?
• ¿El editor puede modificar los permisos de quién accede? No debería poder. Esa sección solo debe ser visible para administradores.
• Vuelve al administrador. Desmarca «Editor». Guarda.
• Vuelve a iniciar sesión como editor. ¿Ya no ve la opción de ajustes?
• Inicia sesión como autor. ¿Puede acceder a los ajustes? No debería, no lo has marcado.

Después de las pruebas funcionales, el ciclo completo: Plugin Check, Debug Log, Query Monitor, las dos pasadas de mejora y auditoría.

La auditoría final de todo el plugin

Con las cuatro versiones terminadas, haz una última auditoría cruzada de todo el código completo. Esta vez el prompt debe reflejar que es la revisión final antes de publicar:

Eres un auditor de seguridad y calidad especializado en plugins de WordPress para el repositorio oficial de WordPress.org. Te adjunto el código completo del plugin Reading Progress Bar versión 4.0.0.

Este plugin va a enviarse a WordPress.org para revisión. Necesito que lo analices como si fueras parte del equipo de revisión del directorio de plugins.

Analiza todo el código buscando:
1. Vulnerabilidades de seguridad (XSS, CSRF, inyección SQL, falta de sanitización, escapado o comprobación de permisos).
2. Incumplimientos de las directrices del directorio de plugins de WordPress.org.
3. Problemas de rendimiento.
4. Incumplimientos de los WordPress Coding Standards.
5. Problemas de internacionalización (cadenas sin preparar para traducción, text domain incorrecto).
6. Problemas en el readme.txt (formato, campos obligatorios, longitud de descripción).
7. Limpieza en la desinstalación (¿se eliminan las opciones de la base de datos al desinstalar?).

Sé exhaustivo. Lista cada problema con su archivo, ubicación exacta y corrección propuesta.

Aplica las correcciones, prueba una última vez, y el plugin está listo para compartirlo (si quieres).

Preparar el plugin para compartirlo

Cuando todas las versiones están terminadas, probadas y auditadas, toca preparar el plugin para que otros puedan usarlo.

1. Revisión final con Plugin Check: Ejecuta PCP una (pen)última vez. Tiene que salir limpio, sin errores. Los avisos menores puedes valorarlos, pero los errores tienen que estar resueltos.
2. Debug log limpio: Usa el plugin un rato con el debug activado y comprueba que no aparece nada nuevo en el log relacionado con tu plugin.
3. Revisa el readme.txt: Asegúrate de que tiene todas las secciones necesarias (descripción, instalación, FAQ, changelog), que la descripción corta no supera los 150 caracteres y que los datos de versión, compatibilidad y tags son correctos. Puedes validarlo con el validador oficial de readme.txt de WordPress.
4. Crear el ZIP: La estructura dentro del ZIP importa: la carpeta raíz tiene que llamarse exactamente como el slug del plugin. Para nuestro ejemplo, el ZIP debe contener una carpeta reading-time-progress-bar/ con todo dentro. Si comprimes los archivos sueltos sin la carpeta contenedora, WordPress no lo instalará bien.
5. Probarlo en otro WordPress: Instala el plugin desde el ZIP en una instalación de WordPress diferente a la de desarrollo, preferiblemente limpia (sin otros plugins extra, con un tema por defecto). Repite las pruebas básicas de funcionamiento. Si algo falla aquí que no fallaba en tu entorno de desarrollo, probablemente hay alguna dependencia que no habías detectado.
6. Compartirlo (o no): Elige si quieres distribuir tu plugin y cómo hacerlo, si es que tenías pensado hacerlo. Nada te lo impide, incluso si has detectado una necesidad podrías venderlo.

Subirlo al repositorio oficial de WordPress.org

Si quieres que tu plugin esté disponible para cualquier usuario de WordPress directamente desde el panel de administración, puedes enviarlo al repositorio oficial. Es un proceso que lleva su tiempo pero merece la pena por múltiples motivos, también para ti.

Requisitos previos:

• Una cuenta en wordpress.org (gratis).
• Que el plugin cumpla las directrices del directorio de plugins (si has seguido el tutorial prácticamente es lo que hemos estado haciendo, aplicando los estándares más exigentes).

Comprobaciones antes de enviar:

• PCP limpio, sin errores.
• Licencia GPL-2.0-or-later (o compatible).
• Sin código ofuscado ni minimizado que no se pueda leer.
• Sin llamadas a servicios externos que no estén declaradas y justificadas.
• Que el nombre del plugin no contenga marcas registradas (no puedes llamarlo «WordPress Progress Bar Pro» ni «WooCommerce Time Reader»).

El proceso:

1. Ve a la página de envío de plugins y sube el ZIP.
2. Espera. El equipo de revisión tarda entre unos días y varias semanas dependiendo de la cola. No envíes mensajes preguntando cuánto falta.
3. Recibirás un email con el resultado. Lo más habitual es que, tras pasar un mínimo de una semana, te pidan correcciones en la primera revisión.

Lo que suelen pedir que corrijas:

Las correcciones más frecuentes son siempre las mismas: escapar correctamente todo el output con funciones como esc_html() o esc_attr(), usar nonces en todos los formularios, sanitizar todos los datos de entrada, y comprobar permisos del usuario antes de ejecutar acciones. Si la IA ha usado las skills de WordPress al generar el código, muchas de estas cosas ya estarán bien, pero el equipo de revisión es muy minucioso.

Cuando te pidan correcciones, copia los comentarios del revisor y dáselos a la IA junto con el código completo del plugin para que aplique los cambios.

Una vez aprobado:

WordPress te dará acceso a un repositorio SVN donde subir el código. SVN es un sistema de control de versiones diferente a Git. Los pasos básicos son:

1. Instala SVN en tu ordenador (viene preinstalado en macOS y la mayoría de distribuciones Linux; en Windows puedes instalar TortoiseSVN).
2. Descarga tu repositorio: svn co https://plugins.svn.wordpress.org/tu-plugin
3. Copia los archivos del plugin dentro de la carpeta trunk/.
4. Copia los assets (banner, icono, capturas) en la carpeta assets/.
5. Sube los cambios: svn add * --force y luego svn ci -m "Primera versión"

Si SVN te parece demasiado, hay plugins y scripts que permiten sincronizar desde GitHub, pero eso ya es para otro tutorial.

Aprovecha lo aprendido para tus próximos plugins

Lo que acabas de hacer no sirve solo para este plugin. Has aprendido un proceso que puedes repetir con cualquier idea. Para que la próxima vez sea más fácil y rápida:

Configura tu IA: La mayoría de herramientas de IA permiten guardar preferencias o instrucciones que se aplican a todas las conversaciones. Configura ahí tus requisitos técnicos de WordPress (estándares, prefijos, estructura de archivos, seguridad) para no tener que repetirlos en cada prompt. Tienes todos los detalles de cómo hacerlo en cada plataforma en esta guía de configuración de IAs para WordPress.

Usa la memoria: Si tu IA tiene memoria entre conversaciones, aprovéchala. Dile que recuerde tus preferencias de desarrollo, tus reglas de código, el tipo de plugins que sueles crear. Cada conversación irá mejor que la anterior porque la IA ya conoce tu contexto.

Crea tus propias skills sencillas: No necesitas ser programador para escribir una skill. Es un archivo de texto con instrucciones claras. Si siempre quieres que tus plugins tengan cierta estructura, ciertos estándares o cierto estilo de código, escríbelo en un documento y adjúntalo al inicio de cada conversación. Con el tiempo lo irás refinando y los resultados serán cada vez mejores.

Sigue aprendiendo. Este tutorial cubre el proceso completo de vibe coding para plugins, pero hay mucho más por explorar:

• Si quieres entender a fondo qué son el vibe coding y el agentic coding y cómo funcionan: Programar con IA en WordPress – Vibe Coding y Agentic Coding.
• Si quieres crear un plugin que integre inteligencia artificial (un plugin con IA, no un plugin hecho con IA): Crear tu propio plugin de IA básico para WordPress.
• Si quieres configurar instrucciones permanentes en cada plataforma de IA: Cómo configurar las IAs para programar WordPress.
• Todas las herramientas de desarrollo para WordPress en un solo sitio: Herramientas de desarrollo WordPress imprescindibles.

Y recuerda que la IA es tu herramienta, no tu jefa. Tú decides qué se construye, cómo se prueba y cuándo se para.

¿Te gustó este artículo? ¡Ni te imaginas lo que te estás perdiendo en YouTube!