Cómo configurar las IAs para programar WordPress: CLAUDE.md, AGENTS.md, Copilot y Cursor

Si usas inteligencia artificial para programar plugins o temas de WordPress, sabes que repetir las mismas instrucciones en cada conversación es un rollo. Que si «usa el prefijo tal», que si «sigue los WordPress Coding Standards», que si «hazlo compatible con WooCommerce»… una y otra vez.

La buena noticia es que todas las IAs de programación permiten configurar instrucciones persistentes: una vez las defines, se aplican automáticamente a cada conversación o sesión de código.

El problema es que cada plataforma lo hace de forma diferente: unas usan archivos en el proyecto, otras preferencias en la interfaz, y algunas ambas cosas.

En esta guía te explico cómo configurar cada una de las principales IAs para desarrollo WordPress, con plantillas listas para usar que puedes copiar y adaptar a tus proyectos.

Configuración de preferencias (interfaz)

Estas son las configuraciones que haces desde la propia interfaz de cada herramienta, sin tocar archivos de código. Son ideales para preferencias generales que aplican a todos tus proyectos.

Claude.ai (modo chat)

Claude en su versión web ofrece tres niveles de personalización:

Preferencias de perfil (globales)

Aplican a todas tus conversaciones con Claude, en cualquier proyecto.

Cómo acceder: Haz clic en tus iniciales (esquina inferior izquierda) → Configuración → Perfil

Aquí puedes indicar cosas como tu stack tecnológico habitual, preferencias de formato de código, o el idioma en que quieres las respuestas.

Instrucciones de proyecto

Aplican solo a las conversaciones dentro de ese proyecto específico. Muy útiles cuando trabajas en varios proyectos WordPress con requisitos diferentes.

Cómo acceder: Abre un proyecto → Icono de configuración (engranaje) → Instrucciones

Las instrucciones de proyecto tienen prioridad sobre las preferencias de perfil cuando hay conflicto.

Estilos de respuesta

Controlan el tono y formato de las respuestas de Claude (conciso, explicativo, formal, etc.).

Cómo acceder: Menú de usuario → Estilos

Puedes crear estilos personalizados basados en tu propia forma de escribir, lo cual es útil si quieres que el código generado siga tu estilo personal.

ChatGPT (modo chat)

ChatGPT gestiona la personalización mediante Custom Instructions y memoria.

Instrucciones personalizadas

Son dos campos de texto de 1.500 caracteres cada uno:

• Qué quieres que ChatGPT sepa de ti: Tu contexto, stack, nivel de experiencia
• Cómo quieres que responda: Formato, tono, nivel de detalle

Cómo acceder: Haz clic en tu foto de perfil → Personalizar ChatGPT

Estas instrucciones se aplican a todas las conversaciones nuevas automáticamente.

Memoria

ChatGPT tiene dos tipos de memoria:

• Memoria guardada: Cosas que le pides explícitamente que recuerde («Recuerda que prefiero código con comentarios en inglés»)
• Historial de chat: Información que extrae automáticamente de conversaciones anteriores

Cómo gestionar: Configuración → Personalización → Memoria

Puedes desactivar cualquiera de las dos por separado si prefieres más control.

Instrucciones de proyecto (Projects)

Similar a Claude, ChatGPT permite crear proyectos con sus propias instrucciones, archivos y contexto.

Cómo acceder: Crear nuevo proyecto → Configuración del proyecto → Instrucciones

GitHub Copilot

Copilot se configura principalmente desde el IDE (VS Code, JetBrains, etc.).

User Rules (reglas de usuario)

Son instrucciones globales que aplican a todos tus proyectos.

En VS Code: Cmd/Ctrl + May + P → Copilot: Configure User Instructions

En JetBrains: Settings → Tools → GitHub Copilot → Customizations

Estas reglas son texto plano, sin formato especial requerido.

Cursor

Cursor diferencia entre reglas de usuario (globales) y reglas de proyecto.

User Rules (reglas de usuario)

Aplican a todos los proyectos que abras con Cursor.

Cómo acceder: Cmd/Ctrl + May + P → Settings → Rules → User Rules

Aquí van preferencias generales como tu estilo de código, idioma de comentarios, o frameworks que usas habitualmente.

Configuración por proyecto (archivos)

Esta es la parte potente: archivos que viven en tu repositorio y que la IA lee automáticamente cada vez que trabajas en ese proyecto. Los puedes versionar con Git y compartir con tu equipo.

Claude Code

Claude Code usa archivos CLAUDE.md con una jerarquía bien definida.

Tipos de archivo y ubicación

Jerarquía de prioridad

Claude Code lee los archivos en este orden, donde los más específicos tienen prioridad:

1. ~/.claude/CLAUDE.md (global)
2. CLAUDE.md en la raíz del proyecto
3. CLAUDE.md en subdirectorios (según dónde estés trabajando)
4. CLAUDE.local.md (siempre al final, mayor prioridad)

Generar CLAUDE.md automáticamente

Claude Code puede analizar tu proyecto y generar un CLAUDE.md inicial:

/init

Esto crea un archivo base que luego puedes refinar. Es un buen punto de partida, pero no te quedes solo con lo que genera: añade tus propias convenciones.

Truco: Mi consejo es que no generes el fichero hasta que no tengas una primera versión revisada del proyecto, con las correcciones. Así partes de un fichero CLAUDE.md refinado y mejorado. También te recomiendo volver a generarlo antes de cada nueva sesión, para depurar errores y añadir mejoras. Esto es válido para todos los modelos.

Añadir instrucciones al vuelo

Durante una sesión, pulsa # para dar una instrucción que Claude guardará automáticamente en el CLAUDE.md correspondiente:

# Usa siempre prepare_items() en lugar de prepare() para las tablas WP_List_Table

Estructura recomendada del archivo

No hay formato obligatorio, pero esta estructura funciona bien:

# Project Overview
Brief description of what this plugin/theme does

# Tech Stack
- WordPress 6.x
- PHP 7.4+
- MySQL/MariaDB

# Commands
- composer install: Install dependencies
- npm run build: Build assets
- ./vendor/bin/phpcs: Run code sniffer

# Code Style
- Follow WordPress Coding Standards
- Use plugin_prefix_ for all functions
- Comments in English, user-facing strings translatable

# Architecture
- /includes: PHP classes
- /assets: CSS and JS files
- /templates: Template files

# Testing
- Run phpunit in plugin root
- Test in WordPress 6.0+ and PHP 7.4, 8.0, 8.2

OpenAI Codex (CLI)

Codex usa AGENTS.md, un formato que se está convirtiendo en estándar de la industria (lo admiten también Copilot, Cursor y otros).

Tipos de archivo y ubicación

Jerarquía de prioridad

Codex construye una cadena de instrucciones al iniciar:

1. ~/.codex/AGENTS.override.md (si existe) o ~/.codex/AGENTS.md
2. AGENTS.md desde la raíz del proyecto hacia abajo
3. AGENTS.override.md en cualquier directorio (sobrescribe todo lo anterior en ese nivel)

Configuración adicional en config.toml

Codex permite configurar nombres de archivo alternativos y límites:

# ~/.codex/config.toml

# Nombres de archivo adicionales que Codex reconocerá
project_doc_fallback_filenames = ["CLAUDE.md", "CODING_GUIDELINES.md"]

# Tamaño máximo del archivo de instrucciones (por defecto 32KB)
project_doc_max_bytes = 65536

# Modelo por defecto
model = "codex-1"

Esto es útil si ya tienes un CLAUDE.md y quieres que Codex también lo lea.

GitHub Copilot

Copilot admite múltiples formatos de archivo de instrucciones, lo que facilita la migración desde otras herramientas.

Archivo principal

.github/copilot-instructions.md

Este es el archivo que Copilot lee en todas las conversaciones del repositorio.

Instrucciones específicas por ruta

Puedes crear archivos adicionales en .github/instructions/ con un frontmatter que indica a qué archivos aplican:

---
applyTo: "src/admin/**/*.php"
---

# Admin Panel Guidelines

- All admin pages must check current_user_can()
- Use Settings API for options pages
- Enqueue admin scripts only on plugin pages

Esto permite tener instrucciones diferentes para el código del admin, el frontend, los tests, etc.

Compatibilidad con otros formatos

Desde agosto de 2025 Copilot también lee:

• AGENTS.md (raíz del proyecto)
• CLAUDE.md
• GEMINI.md

Esto significa que puedes usar un único archivo AGENTS.md y que funcione con Copilot, Codex y otros agentes.

Cursor

Cursor ha evolucionado su sistema de reglas. El formato antiguo (.cursorrules) sigue funcionando, pero el nuevo es más potente.

Formato nuevo (recomendado)

Las reglas van en .cursor/rules/ como archivos .mdc:

.cursor/
  rules/
    wordpress.mdc
    woocommerce.mdc
    testing.mdc

Cada archivo tiene un frontmatter YAML que define cuándo aplicarlo:

---
description: WordPress plugin development standards
globs:
  - "**/*.php"
  - "!vendor/**"
alwaysApply: false
---

# WordPress Development Rules

- Follow WordPress Coding Standards
- Escape all output with esc_html(), esc_attr(), etc.
- Use prepare() for database queries with variables

Opciones del frontmatter

• description: Descripción de la regla (aparece en la UI)
• globs: Patrones de archivos a los que aplica
• alwaysApply: Si es true, aplica siempre; si es false, solo cuando trabajas con archivos que coinciden con los globs

Formato legacy (.cursorrules)

Un único archivo en la raíz del proyecto:

.cursorrules

Sigue funcionando, pero no tiene los niveles de profundidad del formato nuevo. Si ya tienes uno, no necesitas migrarlo inmediatamente.

Excluir archivos del contexto

Usa .cursorignore para que Cursor no indexe ciertos archivos (similar a .gitignore):

# .cursorignore
vendor/
node_modules/
*.min.js
*.min.css

Plantillas WordPress listas para usar

Aquí tienes plantillas optimizadas para desarrollo WordPress. Están en inglés, mil perdones, pero es debido a que los modelos procesan mejor las instrucciones en ese idioma, pero vamos, que he incluido comentarios en español para que sepas qué hace cada sección.

Puedes copiarlas directamente. Si quieres optimizarlas aún más para tu caso específico prueba el optimizador de prompts de AyudaWP.

Plantilla global para Claude Code

Ubicación: ~/.claude/CLAUDE.md

Esta plantilla aplica a todos tus proyectos WordPress. Define tu estilo general de código.

# Global WordPress Development Guidelines
# Directrices globales - aplican a todos los proyectos WordPress

## Developer Context
I am a WordPress developer. I work primarily with plugins and themes.
My primary language for code comments is English.
User-facing strings should always be translation-ready.

## Code Standards
- Follow WordPress Coding Standards (WPCS)
- PHP 7.4+ compatibility required, test up to PHP 8.3
- WordPress 6.0+ minimum version
- Always escape output: esc_html(), esc_attr(), esc_url(), wp_kses()
- Always sanitize input: sanitize_text_field(), absint(), etc.
- Use prepare() for all database queries with variables
- Enqueue scripts and styles properly, never hardcode

## File Organization for Plugins
- Main plugin file: Only bootstrap code, hooks, and includes
- /includes/: PHP classes and functions (one file per class/feature)
- /assets/css/: Stylesheets
- /assets/js/: JavaScript files
- /templates/: Template files if needed
- /languages/: Translation files

## Naming Conventions
- Functions: prefix_function_name (snake_case with unique prefix)
- Classes: Prefix_Class_Name (capitalized with prefix)
- Hooks: prefix/hook_name or prefix_hook_name
- Database tables: {$wpdb->prefix}prefix_tablename

## Documentation
- PHPDoc blocks for all functions and classes
- Inline comments for complex logic only
- README.md in English

## Security First
- Verify nonces for all form submissions
- Check capabilities before actions: current_user_can()
- Validate and sanitize ALL user input
- Escape ALL output

## WooCommerce (when applicable)
- Use WooCommerce hooks, don't modify templates directly when possible
- Follow WooCommerce CRUD patterns for custom data
- Test with latest WooCommerce version
- Declare HPOS compatibility if working with orders

Plantilla de proyecto para Claude Code

Ubicación: CLAUDE.md en la raíz del plugin/tema

Personaliza esta plantilla para cada proyecto específico.

# Plugin/Theme Name
# Nombre del plugin o tema - personaliza esta sección

## Project Overview
Brief description of what this plugin does and its main purpose.
Target users: [describe who will use this]

## Tech Stack
- WordPress 6.4+
- PHP 7.4 - 8.4
- MySQL 5.7+ / MariaDB 10.3+
- [Add any additional dependencies]

## Commands
# Comandos disponibles en este proyecto
- composer install: Install PHP dependencies
- composer phpcs: Run WordPress Coding Standards check
- composer phpcbf: Auto-fix coding standards issues
- npm install: Install Node dependencies
- npm run build: Build production assets
- npm run dev: Watch mode for development

## Plugin Structure
# Estructura del plugin
/plugin-name.php    - Main plugin file (bootstrap only)
/includes/          - PHP classes (one per file)
  /Admin/           - Admin-specific functionality
  /Frontend/        - Public-facing functionality  
  /Core/            - Core plugin classes
/assets/
  /css/             - Stylesheets (source)
  /js/              - JavaScript (source)
  /build/           - Compiled assets (gitignored)
/templates/         - PHP template files
/languages/         - Translation files (.pot, .po, .mo)

## Code Conventions for This Project
# Convenciones específicas de este proyecto
- Function prefix: pluginprefix_
- Text domain: plugin-text-domain
- Option prefix: pluginprefix_
- Capability: manage_options (adjust as needed)
- Minimum PHP: 7.4
- Minimum WP: 6.0

## Database
# Si el plugin usa tablas propias
Custom tables (if any):
- {$wpdb->prefix}pluginprefix_tablename: Description

## Hooks Reference
# Hooks principales del plugin
Actions provided:
- pluginprefix_before_process: Fires before main process
- pluginprefix_after_process: Fires after main process

Filters provided:
- pluginprefix_settings: Filter plugin settings array
- pluginprefix_output: Filter output before display

## Testing
# Instrucciones de testing
- Run phpunit in plugin root
- Test in clean WordPress install
- Test with debug mode enabled (WP_DEBUG)
- Verify no PHP notices or warnings

## Known Issues / TODO
# Problemas conocidos o tareas pendientes
- [ ] Task 1
- [ ] Task 2

Plantilla global para OpenAI Codex

Ubicación: ~/.codex/AGENTS.md

# WordPress Development Agent Guidelines
# Instrucciones globales para Codex en proyectos WordPress

## Role
You are a senior WordPress developer assistant. You write secure, performant, and standards-compliant code.

## Core Principles
1. Security is non-negotiable: sanitize, validate, escape, verify
2. Follow WordPress Coding Standards strictly
3. Write code that works from PHP 7.4 to 8.3
4. All strings must be translation-ready
5. Performance matters: minimize database queries, use caching

## Coding Standards
- WordPress Coding Standards (WPCS) for all PHP
- ESLint with WordPress config for JavaScript
- BEM methodology for CSS class names (when not using blocks)

## File Structure Conventions
Plugins should follow this structure:
- Main file: Bootstrap and hooks only
- /includes/: All PHP logic, one class per file
- /assets/: CSS and JS source files
- /templates/: PHP template files

## Security Checklist
Always verify:
- [ ] Nonces for forms and AJAX
- [ ] Capability checks before actions
- [ ] Data sanitization on input
- [ ] Data escaping on output
- [ ] Prepared statements for queries

## WooCommerce Development
When working with WooCommerce:
- Use CRUD classes for products, orders, customers
- Declare HPOS compatibility
- Use wc_get_template() for template overrides
- Hook into WooCommerce actions, don't override files

## Before Completing Any Task
1. Run linter/PHPCS if available
2. Check for PHP notices with WP_DEBUG
3. Verify security measures are in place
4. Ensure code is translation-ready

Plantilla de proyecto para OpenAI Codex

Ubicación: AGENTS.md en la raíz del proyecto

# [Plugin Name] Development Guide

## Quick Start
Commands to run before making changes:
- composer install
- npm install

Commands to verify changes:
- composer phpcs (coding standards)
- composer test (if tests exist)
- npm run build (compile assets)

## Project Context
This plugin does: [brief description]
Target WordPress version: 6.4+
Requires PHP: 7.4+
Requires WooCommerce: [yes/no, version if yes]

## Architecture Overview
[Describe main components and how they interact]

## Coding Rules for This Project
- Prefix all functions with: pluginprefix_
- Text domain is: plugin-text-domain  
- Main capability required: manage_options
- Custom post type slug: pluginprefix_cpt
- Custom taxonomy slug: pluginprefix_tax

## File Purposes
- plugin-name.php: Plugin header, constants, bootstrap
- includes/class-main.php: Main plugin class, singleton
- includes/class-admin.php: Admin pages and settings
- includes/class-frontend.php: Public-facing features

## Database Schema
[Document any custom tables]

## API Endpoints
[Document any REST API endpoints]

## Integration Points
[Document hooks that other plugins/themes can use]

## Testing Instructions
1. Activate plugin on clean WordPress
2. Enable WP_DEBUG and WP_DEBUG_LOG
3. [Specific test steps for main features]
4. Check debug.log for errors

## Deployment Notes
- Run npm run build before release
- Update version in main file and readme.txt
- Generate .pot file for translations

Plantilla para GitHub Copilot

Ubicación: .github/copilot-instructions.md

# WordPress Plugin Development Instructions

## Project Type
This is a WordPress plugin project following WordPress Coding Standards.

## Technical Requirements
- PHP Version: 7.4 minimum, 8.4 maximum
- WordPress Version: 6.0 minimum
- MySQL: 5.7+ or MariaDB 10.3+

## Coding Standards
All code must follow WordPress Coding Standards:
- Use tabs for indentation (not spaces)
- Opening braces on same line for functions
- Space inside parentheses: function_name( $param )
- Yoda conditions: if ( true === $variable )
- Single quotes for strings, double only for interpolation

## Security Requirements
ALWAYS implement these security measures:
- Nonce verification for all forms: wp_nonce_field(), wp_verify_nonce()
- Capability checks: current_user_can( 'capability' )
- Input sanitization: sanitize_text_field(), absint(), etc.
- Output escaping: esc_html(), esc_attr(), esc_url()
- Database: $wpdb->prepare() for any variable in queries

## Function Naming
- Prefix: pluginprefix_
- Example: pluginprefix_get_settings()
- Classes: Pluginprefix_Class_Name
- Hooks: pluginprefix_action_name

## Internationalization
All user-facing strings must use:
- __( 'string', 'text-domain' ) for simple strings
- _e( 'string', 'text-domain' ) for echoed strings
- esc_html__() and esc_attr__() for escaped translatable strings
- sprintf with placeholders for dynamic strings

## File Organization
- Keep main plugin file minimal (bootstrap only)
- One class per file in /includes/
- Assets in /assets/css/ and /assets/js/
- Never put PHP logic in template files

## WooCommerce Compatibility
When this plugin interacts with WooCommerce:
- Use CRUD methods for products/orders
- Declare HPOS compatibility
- Use wc_get_template() for template overrides
- Check if WooCommerce is active before using its functions

## Documentation
- PHPDoc for all functions, classes, and methods
- @since tag with version number
- @param and @return tags
- Meaningful inline comments for complex logic only

Plantilla WooCommerce para GitHub Copilot

Ubicación: .github/instructions/woocommerce.instructions.md

---
applyTo: 
  - "**/woocommerce/**/*.php"
  - "**/includes/**/wc-*.php"
  - "**/includes/**/class-wc-*.php"
---

# WooCommerce Specific Instructions

## HPOS Compatibility
This plugin must be compatible with High-Performance Order Storage.
- Declare compatibility in main plugin file
- Never access orders via post meta directly
- Use $order->get_meta() and $order->update_meta_data()
- Use wc_get_orders() instead of WP_Query for orders

## CRUD Operations
Always use WooCommerce CRUD classes:
- Products: wc_get_product(), WC_Product classes
- Orders: wc_get_order(), WC_Order class
- Customers: new WC_Customer()

## Hooks to Use
Preferred hooks for common tasks:
- woocommerce_before_cart: Before cart content
- woocommerce_checkout_process: Validate checkout
- woocommerce_payment_complete: After successful payment
- woocommerce_order_status_changed: Order status transitions

## Template Overrides
- Use wc_get_template() to load templates
- Allow theme overrides via woocommerce/ folder
- Never modify WooCommerce core templates directly

## REST API
When extending WooCommerce REST API:
- Extend WC_REST_Controller
- Use proper permission callbacks
- Follow WooCommerce naming conventions

## Testing
- Test with WooCommerce latest and latest-1
- Test with popular payment gateways
- Test with common themes (Storefront, Astra, etc.)
- Verify cart, checkout, and my-account pages work

Plantilla para Cursor

Ubicación: .cursor/rules/wordpress.mdc

---
description: WordPress plugin and theme development standards
globs:
  - "**/*.php"
  - "!vendor/**"
  - "!node_modules/**"
alwaysApply: true
---

# WordPress Development Standards

## Core Rules
You are assisting with WordPress plugin/theme development. Follow these rules strictly:

1. **Security First**
   - Verify nonces: wp_verify_nonce()
   - Check capabilities: current_user_can()
   - Sanitize input: sanitize_* functions
   - Escape output: esc_* functions
   - Prepare queries: $wpdb->prepare()

2. **Coding Standards**
   - Follow WordPress Coding Standards
   - Use tabs, not spaces
   - Yoda conditions: if ( true === $var )
   - Spaces inside parentheses

3. **Naming**
   - Function prefix: [pluginprefix]_
   - Class prefix: [Pluginprefix]_
   - Text domain: [plugin-text-domain]

4. **Internationalization**
   - All strings translation-ready
   - Use __(), _e(), esc_html__(), etc.
   - Proper translator comments for placeholders

5. **Performance**
   - Minimize database queries
   - Use transients for expensive operations
   - Enqueue assets only when needed
   - Use autoloading for classes

## File Structure
- Main file: bootstrap only
- /includes/: PHP classes (one per file)
- /assets/: CSS and JS
- /templates/: PHP templates

## When Writing New Code
1. Check if WordPress has a native function first
2. Implement security measures from the start
3. Add PHPDoc documentation
4. Make strings translatable
5. Consider backward compatibility

Plantilla WooCommerce para Cursor

Ubicación: .cursor/rules/woocommerce.mdc

---
description: WooCommerce specific development rules
globs:
  - "**/woocommerce/**"
  - "**/class-wc-*.php"
  - "**/wc-*.php"
alwaysApply: false
---

# WooCommerce Development Rules

## HPOS Compatibility (Required)
All order-related code must be HPOS compatible:
- Never use get_post_meta() for order data
- Use $order->get_meta() and $order->update_meta_data()
- Use wc_get_orders() instead of WP_Query for orders
- Declare compatibility in main plugin file:
  add_action( 'before_woocommerce_init', function() {
      if ( class_exists( \Automattic\WooCommerce\Utilities\FeaturesUtil::class ) ) {
          \Automattic\WooCommerce\Utilities\FeaturesUtil::declare_compatibility( 'custom_order_tables', __FILE__, true );
      }
  });

## CRUD Pattern
Always use WooCommerce CRUD:
- Products: wc_get_product( $id ), WC_Product_Simple, WC_Product_Variable
- Orders: wc_get_order( $id ), WC_Order
- Customers: new WC_Customer( $id )

## Data Access
- Product price: $product->get_price()
- Order total: $order->get_total()
- Customer email: $order->get_billing_email()

## Safe Hooks
Prefer these hooks:
- woocommerce_loaded: After WC is fully loaded
- woocommerce_init: WC initialization
- woocommerce_checkout_process: Validate checkout
- woocommerce_payment_complete: After payment

## Template Handling
- Use wc_get_template() for loading templates
- Allow overrides in theme's woocommerce/ folder
- Pass variables via $args parameter

Plantilla Custom Instructions para ChatGPT

Copia esto en la sección «Cómo quieres que responda ChatGPT»:

When I ask about WordPress development:
- Follow WordPress Coding Standards strictly
- Always include security measures (nonces, capability checks, sanitization, escaping)
- Make all code translation-ready with proper text domains
- Use proper WordPress functions instead of raw PHP when available
- Consider PHP 7.4 - 8.4 compatibility
- For plugins: separate logic into /includes/, assets into /assets/
- Prefix all functions and classes with a unique prefix
- Include PHPDoc documentation
- When WooCommerce is involved, ensure HPOS compatibility

Code format preferences:
- Provide complete, working code blocks
- Include necessary hooks (add_action, add_filter)
- Add brief comments explaining key parts
- Show file path where code should go

When I share errors:
- Analyze the full error message
- Check for common WordPress issues first
- Suggest debugging steps if cause isn't clear

Descarga de todas las plantillas

Si no quieres andar copiando y pegando las plantillas, porque no tienes tiempo o porque no sabes cuáles vas a usar y cuáles no ahora mismo, en el siguiente enlace las tienes todas en un zip.

→ Descargar plantillas de instrucciones de programación WordPress para IAs

Qué NO incluir en tus instrucciones

Tan importante como saber qué incluir es saber qué evitar.

Estas instrucciones se cargan en cada conversación y consumen tokens del contexto. Si las llenas de información innecesaria, la IA tendrá menos espacio para el código real y puede ignorar partes importantes.

Cosas que NO deberías incluir

Reglas de estilo que un linter puede verificar

No escribas esto:

- Use 4 spaces for indentation
- Add space after opening parenthesis
- Maximum line length 120 characters
- Opening brace on same line

Los linters como PHPCS hacen esto automáticamente y son más fiables. La IA no es la herramienta adecuada para formateo de código; para eso están los formateadores.

Fragmentos de código extensos

No copies funciones completas de ejemplo. En su lugar, referencia el archivo donde está el patrón que quieres seguir:

// MAL: Copiar 50 líneas de código de ejemplo

// BIEN: 
See includes/class-example.php for the pattern to follow when creating admin pages.

Información obvia o que la IA ya conoce

No hace falta escribir:

- PHP is a server-side language
- WordPress uses MySQL database
- Functions should have descriptive names

Esto solo consume espacio sin aportar valor.

Historial de cambios o decisiones pasadas

El archivo de instrucciones no es un changelog ni un documento de arquitectura. Mantén solo lo que es relevante para escribir código ahora:

// MAL:
In version 1.2 we decided to migrate from custom tables to post meta.
The original implementation used transients but we removed them in 1.3.

// BIEN:
Store plugin data as post meta, not in custom tables.

Instrucciones contradictorias o redundantes

Revisa que no tengas cosas como:

- Always use WordPress functions
- Use native PHP file functions for performance

Las contradicciones confunden a la IA y producen resultados inconsistentes.

Información sensible

Nunca incluyas:

• Claves de API o contraseñas
• URLs de servidores de staging con credenciales
• Datos personales de clientes
• Información de vulnerabilidades específicas

Estos archivos normalmente se versionan con Git y pueden acabar en repositorios públicos.

Señales de que tus instrucciones están sobrecargadas

• El archivo tiene más de 2 – 3 páginas (más de 4.000 caracteres aproximadamente).
• Incluyes «por si acaso» información que rara vez usas.
• La IA parece ignorar algunas instrucciones.
• Tienes reglas que aplican solo a partes muy específicas del proyecto.

Solución: divide y vencerás

Si tu archivo es demasiado largo:

1. Mueve lo genérico al archivo global: Las convenciones que usas en todos los proyectos van en ~/.claude/CLAUDE.md o ~/.codex/AGENTS.md
2. Usa archivos por subdirectorio: Las reglas específicas de /admin/ van en un CLAUDE.md dentro de esa carpeta
3. En Cursor, usa múltiples .mdc: Con globs específicos para que solo se carguen cuando trabajas en esos archivos
4. En Copilot, usa .instructions.md: Con frontmatter applyTo para diferentes partes del proyecto

Compatibilidad entre formatos

Buena noticia: hay cada vez más convergencia. Si mantienes un único archivo AGENTS.md en la raíz de tu proyecto, funcionará con:

• OpenAI Codex (nativo).
• GitHub Copilot (desde agosto 2025).
• Claude Code (si añades AGENTS.md a project_doc_fallback_filenames o simplemente mantienes también un CLAUDE.md).
• Otros agentes que adopten el estándar AGENTS.md.

Mi recomendación para una máxima compatibilidad es el siguiente:

1. Mantén un AGENTS.md como archivo principal con las instrucciones del proyecto.
2. Añade un CLAUDE.md que importe o duplique el contenido (o configura Claude Code para leer AGENTS.md).
3. Mantén .github/copilot-instructions.md si usas Copilot y quieres instrucciones específicas adicionales.
4. Usa .cursor/rules/ si trabajas con Cursor y necesitas el nivel de detalle en profundidad de globs.

¿Mucho lío? Empieza con un solo archivo (el de la IA que más uses) y ve añadiendo los demás según lo necesites.

Si te ayuda, aquí te dejo también un resumen visual por si te ayuda a centrar toda la información que hemos visto:

Resumen rápido: dónde se configura cada IA

Antes de entrar en detalle, aquí tienes una tabla resumen para que sepas rápidamente dónde tocar en cada plataforma:

Conclusión

Configurar bien tus IAs de programación es una inversión que se paga rápido. Una vez tienes las instrucciones definidas:

• No repites las mismas indicaciones en cada conversación
• El código generado es más consistente
• Tu equipo trabaja con los mismos estándares
• Reduces errores de seguridad porque las verificaciones están en las instrucciones

Empieza con las plantillas de esta guía, adáptalas a tus necesidades, y ve refinándolas con el uso. Las mejores instrucciones no se escriben de una vez: evolucionan según descubres qué funciona y qué no para tu flujo de trabajo.

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