La especificación al detalle

Este capítulo es la referencia dura del curso. En el capítulo 2 viste la anatomía de un skill de forma descriptiva; aquí la vas a ver de forma normativa: cada campo con su tipo, su límite exacto, qué está obligado a cumplir un skill para ser conforme y qué queda fuera del formato.

Todo lo que aparece a continuación sale de specification.md del sitio oficial (idéntica en contenido a docs/specification.mdx del repositorio agentskills/agentskills). Cuando una regla venga de otra fuente, lo digo explícitamente.

Jerarquía de autoridad

Antes de cualquier campo, hay que fijar qué documento manda. El AGENTS.md del repositorio lo dice sin ambigüedad:

docs/specification.mdx is authoritative for format requirements. Explanatory documentation, examples, tests, and implementations do not add requirements to the format.

Y sobre la librería de referencia:

Do not treat skills-ref/ as a general contribution surface. It is a demonstration artifact, not a production SDK or a source of additional format requirements.

La consecuencia práctica es directa y conviene interiorizarla desde ya:

Fuente	Qué aporta	Estatus
specification.md / docs/specification.mdx	Requisitos del formato	Normativo
Home, quickstart, best practices, optimizing descriptions, using scripts, evaluating skills	Guía de autoría	No normativo
client-implementation/adding-skills-support	Guía para implementadores de clientes	No normativo
skills-ref/	Librería Python de demostración	No normativo
Comportamiento de un cliente concreto	Implementación	No normativo

Si un cliente hace algo que la especificación no exige, eso es una decisión de ese cliente. Si skills-ref rechaza algo que la especificación no prohíbe, eso es una decisión de esa librería. Ninguna de las dos cosas amplía el formato.

flowchart TD
    S["specification.mdx<br/>requisitos del formato"] --> C["Skill conforme"]
    G["Guías de autoría<br/>best practices, descriptions, scripts"] -.->|"consejo, no requisito"| C
    I["Guía de implementadores<br/>adding-skills-support"] -.->|"convenciones de cliente"| K["Cliente compatible"]
    R["skills-ref<br/>artefacto de demostración"] -.->|"una lectura posible de la spec"| K
    C --> K

El lenguaje normativo

La especificación de Agent Skills no declara adherencia a RFC 2119 ni escribe las palabras clave en mayúsculas. Usa las formas en minúscula must, should, may, can y la fórmula we recommend. Aun así, el reparto de fuerza es consistente y en este curso lo traduzco siempre igual:

Original	Traducción	Qué implica
must	DEBE (MUST)	Requisito. Incumplirlo hace que el skill no sea conforme.
should	DEBERÍA (SHOULD)	Recomendación fuerte. Se puede ignorar con motivo; no rompe conformidad.
may	PUEDE (MAY)	Permiso explícito. Nadie puede prohibirlo, nadie está obligado a usarlo.
can / we recommend	PUEDE / se recomienda	Consejo. Sin peso normativo.

Los requisitos con must de la especificación son exactamente estos, y no hay más:

1. “The SKILL.md file must contain YAML frontmatter followed by Markdown content.”
2. name: “Must be 1-64 characters”.
3. name: “Must not start or end with a hyphen (-)”.
4. name: “Must not contain consecutive hyphens (--)”.
5. name: “Must match the parent directory name”.
6. description: “Must be 1-1024 characters”.
7. compatibility: “Must be 1-500 characters if provided”.

A eso se suma un requisito expresado con la palabra required en vez de con must: “A skill is a directory containing, at minimum, a SKILL.md file”. Ocho reglas duras en total. Todo lo demás del documento es should, may, can o recomendación.

Qué implica para cada rol

Para quien escribe skills: cumplir los ocho requisitos es la única condición de conformidad. Los should mejoran la probabilidad de que el skill se active y se ejecute bien, pero un skill que los ignore sigue siendo un skill válido.

Para quien implementa un cliente: los must son lo que puedes asumir al parsear. Los should no los puedes asumir. Y hay un matiz importante que trata la guía de implementadores: ser estricto al leer no siempre es lo mejor. Su recomendación explícita es lenient validation — avisar pero cargar igual cuando el nombre no coincide con el directorio o excede 64 caracteres, y saltar el skill solo si falta la description o el YAML es completamente imparseable. La propia guía advierte que eso “deliberately relaxes” las restricciones de la especificación para mejorar la compatibilidad entre clientes. La spec define lo que un autor debe producir; el cliente decide cuánta tolerancia aplica al consumir.

Regla 0: la unidad es el directorio

A skill is a directory containing, at minimum, a SKILL.md file

Un skill no es un archivo suelto. Es un directorio cuyo nombre importa (porque name debe coincidir con él) y que contiene, obligatoriamente, un SKILL.md.

skill-name/
- SKILL.md     # Required: metadata + instructions
- scripts/     # Optional: executable code
- references/  # Optional: documentation
- assets/      # Optional: templates, resources
- ...          # Any additional files or directories

Ese árbol es literal de la especificación. Los tres subdirectorios son convención, no requisito: “A skill directory may contain any files and directories beyond the required SKILL.md. The conventions below are recommendations for organizing common types of content.”

Nota sobre el nombre del archivo: la especificación escribe siempre SKILL.md en mayúsculas. La guía de implementadores es aún más explícita — hay que buscar “subdirectories containing a file named exactly SKILL.md”. La librería skills-ref acepta además skill.md en minúsculas, pero eso es tolerancia de esa implementación, no parte del formato. Si escribes skills, usa SKILL.md.

Formato de SKILL.md

The SKILL.md file must contain YAML frontmatter followed by Markdown content.

Dos partes, en este orden:

---
name: skill-name
description: A description of what this skill does and when to use it.
---

Aquí empieza el cuerpo Markdown con las instrucciones.

La especificación no define un algoritmo de parseo, ni qué versión de YAML se asume, ni qué hacer con --- que aparezcan más adelante en el cuerpo. La guía de implementadores sí propone un procedimiento — abrir con --- al inicio del archivo, cerrar con el siguiente ---, parsear el bloque intermedio como YAML y tomar todo lo posterior, recortado, como cuerpo — pero es una sugerencia de implementación.

Tabla de referencia rápida

Los seis campos del frontmatter, con las restricciones literales de la especificación:

Campo	Obligatorio	Tipo	Límite duro	Restricciones
name	Sí	string	1–64 caracteres	Solo minúsculas, dígitos y guiones. No empieza ni termina en guion. Sin guiones consecutivos. Debe coincidir con el nombre del directorio padre.
description	Sí	string	1–1024 caracteres	No vacía. Describe qué hace el skill y cuándo usarlo.
license	No	string	—	Nombre de una licencia o referencia a un archivo de licencia empaquetado.
compatibility	No	string	1–500 caracteres si se provee	Indica requisitos de entorno: producto previsto, paquetes de sistema, acceso a red, etc.
metadata	No	mapa string → string	—	Pares clave-valor arbitrarios para metadatos adicionales.
allowed-tools	No	string	—	Cadena separada por espacios de herramientas preaprobadas. Experimental.

Estos seis campos son todos los que define la especificación. No existe version, ni author, ni tags, ni category, ni icon, ni model, ni triggers, ni keywords. Si necesitas algo así, va dentro de metadata.

Y una precisión que se confunde a menudo: el límite de description es de 1024 caracteres, no de 1024 tokens.

Campo name

Reglas literales:

• “Must be 1-64 characters”
• “May only contain unicode lowercase alphanumeric characters (a-z, 0-9) and hyphens (-)”
• “Must not start or end with a hyphen (-)”
• “Must not contain consecutive hyphens (--)”
• “Must match the parent directory name”

Ejemplos válidos de la especificación:

name: pdf-processing

name: data-analysis

name: code-review

Ejemplos inválidos, con el comentario original:

name: PDF-Processing  # uppercase not allowed

name: -pdf  # cannot start with hyphen

name: pdf--processing # consecutive hyphens not allowed

La coincidencia con el directorio

De las cinco reglas, la que más se incumple por descuido es la última: name DEBE coincidir con el nombre del directorio padre. Si renombras la carpeta y olvidas el frontmatter, el skill deja de ser conforme.

flowchart LR
    D["Directorio<br/>pdf-processing/"] --> F["SKILL.md"]
    F --> N["name: pdf-processing"]
    N -->|"must match"| D

Fíjate en la asimetría de consecuencias: la especificación exige la coincidencia, pero la guía de implementadores recomienda a los clientes avisar y cargar el skill igualmente. Es decir, un skill con el nombre desalineado probablemente funcione en la práctica y aun así no sea conforme. No te apoyes en esa tolerancia.

Una ambigüedad del texto que conviene conocer

La viñeta del campo dice “unicode lowercase alphanumeric characters (a-z, 0-9)”: menciona Unicode y a la vez acota el conjunto a ASCII. La tabla resumen del mismo documento dice solo “Lowercase letters, numbers, and hyphens only”. Son dos lecturas distintas del mismo requisito y la especificación no las reconcilia.

La librería skills-ref resuelve la ambigüedad por su cuenta hacia el lado permisivo: normaliza el nombre con unicodedata.normalize("NFKC", ...), comprueba name != name.lower() y valida los caracteres con all(c.isalnum() or c == "-" for c in name), acompañado del comentario “Skill names support i18n characters (Unicode letters) plus hyphens”. Eso es una implementación, no una aclaración normativa.

Recomendación práctica mientras el texto siga así: limítate a a-z, 0-9 y -. Es la intersección de ambas lecturas y funciona en cualquier cliente.

Campo description

Reglas literales:

• “Must be 1-1024 characters”
• “Should describe both what the skill does and when to use it”
• “Should include specific keywords that help agents identify relevant tasks”

Solo la primera es un requisito. Las otras dos son recomendaciones — y a la vez son las que más impacto tienen en si tu skill se activa o no, porque este campo es lo único que el agente ve antes de decidir.

Ejemplo bueno de la especificación:

description: Extracts text and tables from PDF files, fills PDF forms, and merges multiple PDFs. Use when working with PDF documents or when the user mentions PDFs, forms, or document extraction.

Ejemplo pobre:

description: Helps with PDFs.

La técnica para redactar y medir descriptions es el tema completo del capítulo 6. Aquí interesa solo el contrato: string no vacío, máximo 1024 caracteres.

Detalle de conformidad relevante para clientes: la guía de implementadores marca la ausencia o vacuidad de description como el único error de campo que justifica saltar el skill, “a description is essential for disclosure”. Sin description no hay nada que poner en el catálogo, y por tanto el skill es inútil aunque el archivo exista.

Campo license

Opcional. Reglas literales:

• “Specifies the license applied to the skill”
• “We recommend keeping it short (either the name of a license or the name of a bundled license file)”

Ejemplo de la especificación:

license: Proprietary. LICENSE.txt has complete terms

Y en el ejemplo de frontmatter con campos opcionales:

license: Apache-2.0

No hay límite de longitud declarado, no hay validación de formato y no se exige un identificador SPDX. El texto libre es válido; el consejo es solo que sea corto.

Campo compatibility

Opcional. Reglas literales:

• “Must be 1-500 characters if provided”
• “Should only be included if your skill has specific environment requirements”
• “Can indicate intended product, required system packages, network access needs, etc.”

Ejemplos de la especificación:

compatibility: Designed for Claude Code (or similar products)

compatibility: Requires git, docker, jq, and access to the internet

compatibility: Requires Python 3.14+ and uv

Es texto libre en prosa: la especificación no define ninguna gramática, ni un rango de versiones parseable, ni ningún comportamiento que el cliente deba derivar del contenido. El único uso documentado lo describe la guía de implementadores, y es informativo: el frontmatter puede llegar íntegro al modelo porque compatibility “notes environment requirements that could inform how the model executes the skill’s instructions”.

La especificación añade una nota que conviene respetar: “Most skills do not need the compatibility field.”

El único límite duro es el de longitud, y solo aplica si el campo está presente. Un compatibility de 501 caracteres rompe conformidad; ausente, no rompe nada.

Campo metadata

Opcional. Reglas literales:

• “A map from string keys to string values”
• “Clients can use this to store additional properties not defined by the Agent Skills spec”
• “We recommend making your key names reasonably unique to avoid accidental conflicts”

Ejemplo de la especificación:

metadata:
  author: example-org
  version: "1.0"

Dos observaciones sobre el tipo. Primera: es un mapa plano de string a string. No está documentado que acepte anidamiento, listas o números. Fíjate en que el propio ejemplo escribe version: "1.0" entrecomillado, precisamente para que YAML no lo interprete como número. Segunda: este es el mecanismo oficial de extensión. Si un cliente quiere adjuntar propiedades propias sin inventar campos de primer nivel, aquí es donde van, y por eso se recomiendan claves razonablemente únicas.

Nota importante: version no es un campo del frontmatter. Aparece únicamente dentro de metadata, en un ejemplo. El formato no define versionado de skills.

Campo allowed-tools

Opcional y marcado como experimental. Reglas literales:

• “A space-separated string of tools that are pre-approved to run”
• “Experimental. Support for this field may vary between agent implementations”

Único ejemplo publicado:

allowed-tools: Bash(git:*) Bash(jq:*) Read

Tres cosas que ese ejemplo no establece:

• No es un array YAML. Es una cadena única separada por espacios.
• No hay gramática definida para los patrones. La especificación da un ejemplo y no describe la sintaxis Herramienta(comando:*) como parte del formato.
• No es un mecanismo de seguridad ni un sandbox. El texto dice “pre-approved to run”, nada más.

Por su estatus experimental y por el aviso explícito de soporte variable, un skill no debería depender de que este campo se respete.

Ejemplos canónicos de frontmatter

Mínimo conforme:

---
name: skill-name
description: A description of what this skill does and when to use it.
---

Con campos opcionales:

---
name: pdf-processing
description: Extract PDF text, fill forms, merge files. Use when handling PDFs.
license: Apache-2.0
metadata:
  author: example-org
  version: "1.0"
---

El cuerpo Markdown

The Markdown body after the frontmatter contains the skill instructions. There are no format restrictions. Write whatever helps agents perform the task effectively.

Sin restricciones de formato. Sin secciones obligatorias. Sin encabezados exigidos. La especificación se limita a recomendar tres tipos de contenido: instrucciones paso a paso, ejemplos de entradas y salidas, y casos límite comunes.

Y añade la advertencia de coste que gobierna todo el diseño de un skill:

Note that the agent will load this entire file once it’s decided to activate a skill. Consider splitting longer SKILL.md content into referenced files.

El cuerpo no se carga por partes. Es todo o nada, y por eso el tamaño importa.

Directorios opcionales

La cláusula de apertura ya la vimos: cualquier archivo y cualquier directorio son admisibles. Lo que sigue son convenciones.

scripts/ — “Contains executable code that agents can run.” Los scripts DEBERÍAN:

• “Be self-contained or clearly document dependencies”
• “Include helpful error messages”
• “Handle edge cases gracefully”

Sobre los lenguajes: “Supported languages depend on the agent implementation. Common options include Python, Bash, and JavaScript.” El formato no fija ninguno. El capítulo 7 entra en el diseño de estos scripts.

references/ — “Contains additional documentation that agents can read when needed”. Los nombres que da la especificación son ejemplos, no requisitos: REFERENCE.md para referencia técnica detallada, FORMS.md para plantillas o formatos de datos estructurados, y archivos por dominio como finance.md o legal.md. La recomendación asociada: “Keep individual reference files focused. Agents load these on demand, so smaller files mean less use of context.”

assets/ — “Contains static resources”: plantillas de documento o configuración, imágenes, y archivos de datos como tablas de lookup o esquemas.

Ninguno de los tres directorios es obligatorio, ninguno de los tres nombres es reservado, y usar otros nombres no rompe conformidad.

Progressive disclosure

La especificación describe la carga por etapas como parte del formato, y añade un should sobre cómo estructurar el skill:

Agents load skills progressively, pulling in more detail only as a task calls for it. Skills should be structured to take advantage of this:

1. Metadata (~100 tokens): The name and description fields are loaded at startup for all skills
2. Instructions (< 5000 tokens recommended): The full SKILL.md body is loaded when the skill is activated
3. Resources (as needed): Files (e.g. those in scripts/, references/, or assets/) are loaded only when required

Keep your main SKILL.md under 500 lines. Move detailed reference material to separate files.

Atención a la nomenclatura, porque la documentación oficial usa tres juegos de nombres para las mismas tres etapas según el documento:

Documento	Etapa 1	Etapa 2	Etapa 3
specification.md (normativo)	Metadata	Instructions	Resources
Home / README / quickstart	Discovery	Activation	Execution
Guía de implementadores	Catalog	Instructions	Resources

No hay una cuarta. Cualquier otro nombre es invención.

Límites duros contra recomendaciones

Esta distinción es la que más errores produce al citar la especificación:

Límite	Valor	Naturaleza
Longitud de name	1–64 caracteres	Duro
Longitud de description	1–1024 caracteres	Duro
Longitud de compatibility	1–500 caracteres si se provee	Duro
Metadata cargada al inicio	~100 tokens	Estimación descriptiva
Cuerpo de SKILL.md	< 5000 tokens	Recomendación
Líneas de SKILL.md	< 500 líneas	Recomendación
Profundidad de referencias	un nivel desde SKILL.md	Recomendación

Un SKILL.md de 900 líneas es conforme. Es probablemente mala idea, pero es conforme. Un name de 65 caracteres no lo es.

Resolución de rutas

Regla de la especificación:

When referencing other files in your skill, use relative paths from the skill root

Ejemplo literal:

See [the reference guide](references/REFERENCE.md) for details.

Run the extraction script:
scripts/extract.py

Y la restricción de profundidad:

Keep file references one level deep from SKILL.md. Avoid deeply nested reference chains.

La guía Using scripts refuerza el mismo punto y explica quién hace el trabajo: “Use relative paths from the skill directory root to reference bundled files. The agent resolves these paths automatically — no absolute paths needed.” Añade además que la convención se mantiene dentro de archivos de apoyo como references/*.md, porque las rutas de ejecución en bloques de código son relativas a la raíz del directorio del skill, que es desde donde el agente ejecuta los comandos.

Del lado del cliente, la guía de implementadores describe la contraparte: el directorio base del skill es el directorio padre del SKILL.md, y la instrucción sugerida al modelo es “resolve them against the skill’s directory (the parent of SKILL.md) and use absolute paths in tool calls”.

flowchart LR
    A["SKILL.md escribe<br/>references/REFERENCE.md"] --> B["Cliente conoce el<br/>directorio base del skill"]
    B --> C["Resuelve a ruta absoluta"]
    C --> D["Llamada a herramienta<br/>con ruta absoluta"]

El autor escribe relativo; el cliente resuelve. Nunca al revés: una ruta absoluta en un SKILL.md deja de funcionar en cuanto el skill se instala en otra máquina.

Codificación

La especificación no dice nada sobre codificación de caracteres. No menciona UTF-8, ni BOM, ni finales de línea. No hay una cláusula que puedas citar.

Eso no significa que puedas usar cualquier cosa: significa que el comportamiento es indefinido y depende del cliente. Lo razonable es UTF-8 sin BOM y finales de línea LF, que es lo que asumen los parsers habituales, pero preséntalo siempre como práctica prudente y no como requisito del formato.

Qué es conforme y qué no

Checklist de conformidad. Si las ocho respuestas son sí, el skill es conforme:

• ¿Es un directorio?
• ¿Contiene un archivo SKILL.md?
• ¿SKILL.md empieza con frontmatter YAML seguido de contenido Markdown?
• ¿Existe name, con 1–64 caracteres, en minúsculas, dígitos y guiones, sin guion inicial o final, sin guiones consecutivos?
• ¿name coincide exactamente con el nombre del directorio padre?
• ¿Existe description, no vacía, de 1–1024 caracteres?
• Si hay compatibility, ¿mide entre 1 y 500 caracteres?
• ¿Todos los campos del frontmatter salen de los seis definidos?

El último punto merece un matiz honesto: la especificación no declara que un campo desconocido invalide el skill. Solo la librería skills-ref lo rechaza, mediante un conjunto ALLOWED_FIELDS con los seis nombres. Ponlo en tu checklist porque es la lectura conservadora y porque el mecanismo previsto para extensiones es metadata, pero no lo cites como cláusula de la spec.

Y lo que no afecta a la conformidad, por más que se repita: el número de líneas del cuerpo, el número de tokens, la existencia de scripts/, references/ o assets/, la presencia de un directorio evals/, el estilo imperativo de la description, o dónde esté instalado el skill en el sistema de archivos.

Casos límite y comportamiento indefinido

Preguntas frecuentes cuya respuesta la especificación no da. Enumerarlas es tan importante como enumerar las reglas, porque es donde los clientes divergen:

Caso	Qué dice la especificación	Consecuencia práctica
Archivo llamado skill.md en minúsculas	Solo nombra SKILL.md; la guía de clientes dice “named exactly SKILL.md”	Indefinido. skills-ref lo acepta; no dependas de ello
Campo desconocido en el frontmatter	Nada	Indefinido. skills-ref lo rechaza; usa metadata
Codificación del archivo	Nada	Indefinido. Usa UTF-8
Un --- dentro del cuerpo Markdown	Nada	Indefinido. Depende del algoritmo de parseo del cliente
Valor sin comillas con dos puntos, como description: Use when: ...	Nada	YAML técnicamente inválido. La guía sugiere a los clientes un fallback que entrecomille o convierta a block scalar
name con caracteres Unicode fuera de ASCII	Texto ambiguo entre la tabla y la viñeta	Indefinido. Limítate a a-z0-9-
Dos skills con el mismo name en distintos ámbitos	Nada	Convención de implementadores: “project-level skills override user-level skills”
Dónde se instalan los skills	Nada. “the Agent Skills specification does not mandate where skill directories live”	Convención: .agents/skills/. Ver el capítulo 10
Máximo de skills instalables	Nada	Sin límite documentado. Los límites de escaneo son decisión del cliente
¿El modelo recibe el frontmatter?	Nada	Dos enfoques documentados: archivo completo o solo cuerpo. “Both approaches work in practice”
Longitud máxima de license o metadata	Nada	Sin límite documentado
Versionado de skills	Nada	El formato no define versionado. version solo existe dentro de metadata

Cuando escribas un skill, evita apoyarte en cualquiera de estas zonas grises. Cuando implementes un cliente, decide una postura para cada una, documéntala, y prefiere la tolerancia a la rigidez.

Validación

La especificación remite a una herramienta concreta:

Use the skills-ref reference library to validate your skills:

skills-ref validate ./my-skill

This checks that your SKILL.md frontmatter is valid and follows all naming conventions.

Su README aclara el alcance: “This library is intended for demonstration purposes only. It is not meant to be used in production.” Es la referencia ejecutable de las reglas, no un SDK.

El orden en que valida, leído de su código, es un buen resumen operativo de todo este capítulo:

flowchart TD
    A["Ruta recibida"] --> B{"¿Existe?"}
    B -->|No| E1["Path does not exist"]
    B -->|Sí| C{"¿Es directorio?"}
    C -->|No| E2["Not a directory"]
    C -->|Sí| D{"¿Hay SKILL.md?"}
    D -->|No| E3["Missing required file: SKILL.md"]
    D -->|Sí| F{"¿Frontmatter parseable?"}
    F -->|No| E4["ParseError"]
    F -->|Sí| G["Validar campos permitidos"]
    G --> H["Validar name: longitud, minúsculas,<br/>guiones, coincidencia con directorio"]
    H --> I["Validar description: no vacía, longitud"]
    I --> J{"¿compatibility presente?"}
    J -->|Sí| K["Validar longitud máxima 500"]
    J -->|No| L["Lista de errores vacía = válido"]
    K --> L

Fíjate en que acumula errores en una lista en vez de abortar al primero: te devuelve todos los problemas de una pasada.

Resumen

• La autoridad sobre el formato es specification.mdx. Guías, ejemplos, tests e implementaciones no añaden requisitos.
• La especificación no usa RFC 2119, pero reparte fuerza con must / should / may. Solo hay ocho requisitos duros.
• Un skill es un directorio con un SKILL.md que DEBE contener frontmatter YAML seguido de Markdown.
• El frontmatter define exactamente seis campos: name y description obligatorios; license, compatibility, metadata y allowed-tools opcionales. No hay más.
• Límites duros: name 1–64 caracteres, description 1–1024 caracteres, compatibility 1–500 caracteres si se provee.
• name DEBE ser minúsculas, dígitos y guiones, sin guion inicial ni final, sin guiones consecutivos, y DEBE coincidir con el nombre del directorio padre.
• metadata es el mecanismo de extensión: mapa plano de string a string. version vive ahí, no como campo de primer nivel.
• allowed-tools es experimental y su soporte varía entre implementaciones; es una cadena separada por espacios, no un array.
• Las 500 líneas y los 5000 tokens del cuerpo son recomendaciones, no límites. Los directorios scripts/, references/ y assets/ son convención.
• Las rutas se escriben relativas a la raíz del skill y con una profundidad de un nivel; el cliente las resuelve a absolutas.
• La codificación, los campos desconocidos, la precedencia entre ámbitos y la ubicación de instalación quedan fuera del formato: son comportamiento indefinido o convención de implementadores.

Siguiente: Tu primer skill paso a paso