dful.
Dful Dark
Tema
Árbol de conocimiento
En esta página

Instrucciones, skills y plugins

Qué entra en contexto, qué se carga bajo demanda y qué llega a ejecutar código cuando usas instrucciones de proyecto, skills, plugins, hooks y MCP.
Actualizado 6 oct 2026

Instrucciones, skills, plugins, hooks y MCP suelen aparecer juntos porque amplían lo que puede hacer un agente, pero no producen el mismo efecto. Para orientarse conviene mirar tres cosas: qué entra en contexto, qué código llega a ejecutarse y qué parte depende del harness.

Instrucciones de proyecto

repo/
├── AGENTS.md
├── src/
│   └── AGENTS.md
└── tests/

Un fichero de instrucciones aporta reglas al modelo mientras trabaja en un proyecto. En Codex se utiliza AGENTS.md; Claude Code trabaja con CLAUDE.md y OpenCode admite reglas en AGENTS.md. Las rutas de búsqueda, la herencia y la precedencia concreta cambian entre harnesses.

Una regla como «ejecuta los tests antes de terminar» guía la decisión del agente. Si esa comprobación tiene que ser obligatoria, el test runner o CI deben aplicarla de forma determinista: el Markdown describe el comportamiento esperado, no ejecuta el test por sí mismo.

La longitud también importa. Las instrucciones que se cargan de forma habitual consumen contexto, así que conviene dejar en la raíz lo que aplica a casi todo el proyecto y acercar reglas específicas al código correspondiente cuando el harness lo soporte.

Skills: guía y recursos bajo demanda

Una skill suele empaquetar una guía para una tarea concreta junto con recursos opcionales:

my-skill/
├── SKILL.md
├── references/
│   └── methodology.md
├── scripts/
│   └── validate.py
└── assets/
    └── template.md

SKILL.md explica cuándo utilizar la skill y cómo trabajar. Las referencias permiten mantener detalle fuera del camino principal y los scripts pueden aportar comprobaciones deterministas. Incluir validate.py en la carpeta no lo ejecuta automáticamente: el agente necesita instrucciones para usarlo y una tool/runtime capaces de lanzarlo.

Codex documenta una carga progresiva en la que primero expone nombre y descripción de las skills y carga el SKILL.md completo cuando selecciona una. Claude Code y OpenCode siguen ideas parecidas, con diferencias en discovery, invocación y alcance.

El patrón útil es mantener el contexto inicial pequeño y cargar profundidad cuando la tarea la necesita:

descubrimiento → nombre y descripción → SKILL.md → referencias o scripts necesarios

La guía de una skill puede ser portable entre productos compatibles. Sus scripts siguen dependiendo de paths, dependencias, permisos y tools disponibles en el entorno donde se ejecuten.

Plugins, hooks y MCP

Plugin describe un paquete instalable, pero lo que contiene puede variar mucho. Puede agrupar skills, configuración de servidores MCP o extensiones que ejecutan código dentro del harness.

El Agent Plugins Specification 1.0 define un suelo portable con plugin.json, skills bajo skills/ y configuración MCP en mcp.json:

my-plugin/
├── plugin.json
├── skills/
│   └── review/
│       └── SKILL.md
└── mcp.json

La especificación cubre discovery y empaquetado de esas piezas. No define cómo cada cliente presenta una skill al modelo, qué permisos aplica ni cómo funcionan sus hooks. La versión 1.1 sigue como working draft, así que la compatibilidad depende también de la versión soportada por el cliente.

Un hook sí ejecuta código cuando ocurre un evento que define el harness, por ejemplo después de una tool call. Esa parte es mucho menos portable: depende de la API, los eventos y el entorno que exponga el host.

Un servidor MCP puede exponer tools o recursos a un cliente compatible. Configurarlo dentro de un plugin facilita instalarlo junto con otras piezas, pero la capacidad real sigue dependiendo del servidor, sus credenciales y los permisos con los que se conecta.

Portabilidad

Para mover una configuración entre agentes separaría cada pieza por su efecto:

  • Las instrucciones son texto que el harness debe descubrir e introducir en contexto.
  • Una skill añade instrucciones y recursos que pueden cargarse cuando hacen falta.
  • Una tool realiza una operación a través de una interfaz concreta.
  • Un hook ejecuta código en un punto del ciclo de ejecución definido por el harness.
  • Un plugin empaqueta una o varias de esas piezas.
  • MCP estandariza una interfaz para exponer capacidades externas, pero no elimina las dependencias ni la autorización del servicio que hay detrás.

Copiar una carpeta puede mover el contenido portable. El comportamiento que dependa del runtime o de hooks específicos debe adaptarse al nuevo harness.

Referencias