Guía de la API Abilities de WordPress para flujos de trabajo con IA

La API Abilities de WordPress puede exponer capacidades tipadas y detectables, pero cada ability sigue necesitando metadatos precisos, callbacks de permisos, validación de entradas, gestión de salidas y evidencia de que la ejecución coincide con el contrato publicado.

Aquí la IA resulta más útil como organizadora de evidencia, motor de comparación y asistente de redacción. Puede facilitar la inspección de una tarea compleja de WordPress, pero no puede crear autoridad faltante, certificar hechos que no observó ni convertir silenciosamente una recomendación en permiso para actuar.

En una frase: La API Abilities de WordPress puede exponer capacidades tipadas y detectables, pero cada ability sigue necesitando metadatos precisos, callbacks de permisos, validación de entradas, gestión de salidas y evidencia de que la ejecución coincide con el contrato publicado.

Lo que esta guía le ayuda a lograr

Explicar y documentar un camino seguro para registrar, descubrir y probar abilities de WordPress antes de exponerlas a clientes de IA o capas de ejecución remota.

• Una distinción clara entre la definición de una ability, su callback de ejecución y su lógica de autorización.
• Una lista de comprobación de registro para metadatos, esquemas, anotaciones y exposición REST.
• Una matriz de permisos y pruebas negativas.
• Un contrato versionado para clientes y responsables de mantenimiento.

El artefacto terminado debe ser comprensible para la persona responsable de la decisión y reproducible por alguien que no participó en el prompt original. Una respuesta fluida no basta. Cada conclusión sustancial necesita una fuente, un alcance y una ruta de verificación. Cuando la evidencia no puede establecer algo, la salida correcta es un desconocido explícito o una hipótesis comprobable.

Evidencia y entradas que preparar

• La documentación actual de la API Abilities de WordPress y la versión de destino.
• La acción empresarial y la regla de permisos que es autoritativa.
• Esquemas de entrada y salida con fixtures seguras.
• Efectos secundarios esperados, modos de fallo y requisitos de observabilidad.
• El cliente o adaptador que descubrirá o ejecutará la ability.

Antes de proporcionar evidencia a un asistente, elimine credenciales, valores secretos e información personal no relacionada. Conserve los identificadores, versiones, marcas de tiempo, configuración regional, unidades y etiquetas de fuente necesarios para interpretar lo que permanece. Una captura de pantalla sin URL, estado o fecha puede ser un contexto útil, pero rara vez es autoridad suficiente para una decisión de producción.

No empiece con una solicitud amplia como «revise esto», «arregle esto» o «mejórelo». Defina la decisión que debe apoyar el trabajo, la población incluida, la fuente que es autoritativa para cada campo, las operaciones permitidas y las acciones que siguen prohibidas. La etapa de planificación o investigación debe usar un repositorio local, una fixture aislada o evidencia exportada y no requiere acceso de producción a WordPress.

Una ability es un contrato, no un prompt

Su nombre, descripción, esquemas, anotaciones y callbacks definen una operación invocable por máquina. La claridad del lenguaje natural importa, pero la validación ejecutable y las comprobaciones de permisos siguen siendo autoritativas.

Detectable no significa ejecutable por todos

Enumerar metadatos y ejecutar una ability son operaciones distintas. La autorización debe aplicarse en el límite de ejecución.

Las anotaciones no deben prometer demasiado

Las afirmaciones sobre comportamiento de solo lectura, efectos destructivos o idempotencia deben reflejar la implementación probada, no solo la intención.

Mantenga separadas la observación, la inferencia y la autoridad

Una revisión controlada debe distinguir al menos cuatro estados:

1. Observado: presente directamente en un registro, archivo, respuesta, página renderizada o prueba ejecutada identificados.
2. Inferido: una interpretación plausible respaldada por evidencia, pero no establecida directamente.
3. Recomendado: una decisión humana propuesta o una acción siguiente.
4. Autorizado y verificado: un cambio aprobado por separado que se ejecutó y luego se comprobó conforme a criterios de aceptación.

La salida de IA normalmente comienza en los tres primeros estados. No se autoriza solo porque sea detallada, internamente coherente o técnicamente convincente. Conserve esta distinción en tablas, informes, tickets y estudios de caso públicos.

Un flujo de trabajo seguro

1. Defina una capacidad empresarial limitada y su propietario responsable.
2. Especifique nombres estables, descripción, esquema de entrada, esquema de salida y efectos secundarios.
3. Implemente callbacks explícitos de permisos y validación.
4. Registre la ability en el ciclo de vida y el entorno compatibles.
5. Pruebe el descubrimiento, la ejecución válida, la entrada no válida y la ejecución no autorizada.
6. Revise si la exposición REST o MCP es adecuada y compatible.
7. Documente el versionado, los errores, la observabilidad y el comportamiento de rollback.
8. Exponga la ability solo después de que el contrato y las pruebas negativas sean satisfactorios.

Esta secuencia coloca deliberadamente una revisión responsable entre el análisis y la implementación. Si una etapa posterior necesita un acceso más amplio, cree una nueva tarea, una nueva identidad o un cambio explícito de permisos. No eleve silenciosamente la identidad analítica porque alcanzó un límite correcto.

Receta de prompt

Sustituya cada valor entre corchetes antes de usar el prompt. No pegue contraseñas, claves API, cookies de autenticación, registros privados de clientes ni información personal no relacionada.

Está revisando [TASK SCOPE] para [SITE, REPOSITORY OR DATASET] usando solo la evidencia proporcionada.

Objetivo:
Explique y documente un camino seguro para registrar, descubrir y probar abilities de WordPress antes de exponerlas a clientes de IA o capas de ejecución remota.

Devuelva los siguientes campos:
- Nombre de la ability
- Propósito
- Esquema de entrada
- Esquema de salida
- Callback de permisos
- Efecto secundario
- Anotación
- Fixture válida
- Fixture no válida
- Fixture no autorizada
- Versión
- Propietario

Reglas:
1. Use los nombres y firmas actuales de la API oficial.
2. No registre abilities generales que lo abarquen todo.
3. Exija callbacks de permisos explícitos y validación de entradas.
4. Pruebe las descripciones y anotaciones frente al comportamiento real.
5. No exponga una ability a REST o MCP por suposición.

Para cada hallazgo:
- identifique la fuente, el registro, la URL, el archivo, la línea, el ID de objeto, el estado o la fila de conjunto de datos exactos;
- conserve fechas, versiones, unidades, configuración regional, identificadores y denominadores;
- separe observación, inferencia, recomendación y desconocido;
- indique qué evidencia no estaba disponible;
- no cambie WordPress, código fuente, datos comerciales, analítica, sistemas externos ni contenido publicado.

Por qué este prompt se estructura de esta manera

El prompt crea un contrato de evidencia antes de pedir recomendaciones. Hace visibles los datos faltantes, reduce la probabilidad de que un modelo complete un registro incompleto con prosa plausible y produce una salida que se puede revisar sistemáticamente. Los campos estructurados también facilitan comparar ejecuciones repetidas o entregar un subconjunto aprobado a un flujo de trabajo de implementación posterior.

Una implementación de producción puede agregar un esquema JSON, entradas de herramientas tipadas o validación automatizada. Esos mecanismos mejoran la coherencia, pero no establecen que la evidencia de origen sea verdadera, completa o actual. La revisión humana y la verificación específica del sistema siguen siendo obligatorias.

Límite de acceso recomendado

Use Sin acceso a WordPress durante la etapa de planificación o investigación para la etapa descrita en esta guía. Las capacidades exactas disponibles para una identidad deben provenir de la versión de producto instalada, el contrato de cobertura publicado y el método de conexión realmente utilizado.

Lo que debe permanecer fuera de esta tarea

• Registro de abilities en producción
• Capacidad administrativa amplia
• Omisión de permisos
• Cambios de esquema sin validar
• Afirmaciones de compatibilidad universal con clientes

Una acción rechazada puede ser evidencia útil de que el límite de control funciona. No responda a un rechazo esperado otorgando una cuenta de administrador amplia o Full Power. Primero determine si la acción pertenece al mandato actual. Si pertenece, cree una etapa autorizada por separado con la capacidad requerida más limitada.

Cómo encaja WP Agent Control

La carpeta privada guiada para Claude Code o Codex utiliza REST de WordPress y una contraseña de aplicación con un perfil dedicado de solo lectura. Los perfiles existentes Read Only, Draft, Content Editor y Publisher siguen en las opciones avanzadas. No se convierten automáticamente a OAuth ni heredan el modelo de tareas remotas y aprobación exacta.

Obtén información estructurada del sitio e inspecciona páginas publicadas seleccionadas después de conectar. Esta lectura pública no requiere una tarea temporal. También puedes navegar por páginas públicas sin el plugin; Agent Control añade acceso estructurado y continuidad hacia operaciones autorizadas en WordPress.

Conectar tu IA: docs first profile · Ver funciones y compatibilidad: coverage

Lista de comprobación de verificación

• ☐ La tarea, la población, el período, el entorno y la decisión son explícitos.
• ☐ Cada observación sustancial está vinculada a evidencia exacta o etiquetada como hipótesis.
• ☐ Se conservan ID estables, URL, versiones, fechas, unidades, configuraciones regionales y denominadores.
• ☐ La evidencia faltante y los límites de cobertura siguen visibles.
• ☐ La identidad analítica o de investigación no realizó ninguna mutación prohibida.
• ☐ Un propietario cualificado revisó las implicaciones de seguridad, accesibilidad, legales, comerciales o de lanzamiento cuando corresponde.
• ☐ Cualquier implementación tiene un mandato, nivel de acceso, copia de seguridad y plan de verificación separados.
• ☐ Las identidades temporales, fixtures y evidencia sensible se revocan, restablecen o eliminan después de la tarea.

Modos de fallo comunes

• Ability con forma de prompt: una operación amplia acepta instrucciones arbitrarias y omite el diseño explícito de capacidades.
• Autorización por metadatos: la descripción de la ability indica una restricción, pero el callback de ejecución no aplica la restricción.
• Deriva de esquema: la implementación acepta o devuelve campos que el contrato publicado no describe.
• Etiquetado erróneo de solo lectura: una ability anotada como de solo lectura activa escrituras, cachés, correos electrónicos o llamadas externas ocultas.

Un fallo transversal recurrente es la deriva de permisos: la tarea inicial encuentra un límite y el operador amplía el acceso antes de determinar si la operación faltante es necesaria, compatible o segura. Esto destruye el valor probatorio del rechazo y dificulta atribuir resultados posteriores.

Nota avanzada

En una arquitectura gobernada, las abilities son operaciones admisibles cuyos metadatos, permisos y efectos secundarios se versionan independientemente del transporte. REST o MCP pueden proyectar la misma ability, pero ningún transporte puede ampliar su autoridad.

Guías relacionadas

• Cómo exponer una Ability personalizada de WordPress mediante MCP
• Cómo crear una matriz de pruebas de permisos de WordPress para agentes de IA
• Cómo documentar una API REST de WordPress con IA
• Cómo crear un plan de pruebas de WordPress con IA

Siguiente paso

Continúe con la guía de apoyo más relevante y use la guía de niveles de acceso antes de cualquier tarea autenticada. Cuando ya no necesite acceso temporal a WordPress, termine revocando la identidad.