Habilidades De Agentes on KnightLi Blog

Uso de las habilidades de los agentes de IA para mantener un blog multilingüe de Hugo

Mon, 06 Apr 2026 10:00:00 +0800

Si mantiene un blog multilingüe de Hugo, probablemente se encuentre con un problema frecuente:

Después de terminar el contenido en chino, aún necesitarás las versiones sincronizadas en inglés y chino tradicional.
Todos los archivos de idioma deben mantener la misma estructura.
La portada debe traducirse respetando las reglas del formato Hugo.

sync-post-translations está diseñado exactamente para este escenario.

¿Qué problema resuelve esta habilidad?

El posicionamiento de sync-post-translations es sencillo:

Utilice index.zh-cn.md como archivo fuente
Genere o actualice index.en.md e index.zh-tw.md en el mismo directorio
Mantenga coherente la estructura de Markdown
Aplique reglas explícitas al principio (especialmente “fecha” y “slug”)

Ejemplos de frases desencadenantes:

“Sincronizar traducción al inglés y chino tradicional”
“Traducir esta publicación al inglés y chino tradicional”

Estructura del directorio de habilidades

.\sync-post-translations\
├─ SKILL.md
└─ agents\
   └─ openai.yaml

Código central 1: SKILL.md

A continuación se muestra el archivo de reglas básicas de esta habilidad:

---
name: sync-post-translations
description: 将 Hugo 文章从简体中文源文件（`index.zh-cn.md`）同步翻译为英文（`index.en.md`）和繁体中文（`index.zh-tw.md`）。当用户提出“en 繁体”“同步翻译英文繁体”或要求同时生成/更新两种语言版本且需保持 front matter 与 Markdown 结构一致时使用。
---

# 同步文章翻译

使用此技能为同一篇文章生成或更新多语言版本。

## 工作流程

1. 在目标文章目录中定位源文件 `index.zh-cn.md`。
2. 读取完整 front matter 与正文内容。
3. 在同目录创建或更新 `index.en.md` 与 `index.zh-tw.md`。
4. 确保三语结构对齐后执行 Hugo 构建检查。

## 翻译规则

1. 严格保留 `slug` 原值。
2. `date` 统一规范为 Hugo 常用带时间格式（RFC3339），示例：`2026-04-05T10:00:00+08:00`。
3. 自然翻译以下 front matter 字段：`title`、`description`、`tags`、`categories`。
4. 保持 Markdown 结构不变：标题层级、列表形态、代码块、链接与命令行示例。
5. 技术标识符保持原样：文件名、CLI 参数、模型名、设备名、URL、包名等。
6. 若 YAML 的 `title` 含有 `:`，必须加引号，避免解析报错。
7. 在不改变语义前提下，使用目标语言自然标点与表达习惯（`en`、`zh-tw`）。

## 输出约定

1. 仅在源文章同目录写入目标文件。
2. 汇报变更的文件路径。
3. 条件允许时执行 `hugo --source . --destination public`，并反馈通过/失败；失败时给出关键报错行。

## 质量标准

1. 全文术语前后一致。
2. 避免机器直译感，优先可发布文风。
3. 章节内容完整，不省略示例、注意点与总结。

Código central 2: agentes/openai.yaml

Este archivo define cómo se presenta y solicita la habilidad en el lado del agente:

interface:
  display_name: "同步文章翻译"
  short_description: "生成或更新 EN + ZH-TW 翻译稿"
  default_prompt: "使用该技能在同一 Hugo 文章目录中，从 `index.zh-cn.md` 生成或同步 `index.en.md` 与 `index.zh-tw.md`，保留 `date` 与 `slug`，保持 Markdown 结构一致，并执行 Hugo 构建校验。"

Ejemplo de uso práctico

1) Activador del lenguaje natural

1
2

请把 content/post/2026/04/06/index.zh-cn.md 同步翻译成英文和繁体，
要求 date 用 RFC3339，slug 不变，最后跑 hugo 校验。

2) Resultado esperado

已更新：
- content/post/2026/04/06/index.en.md
- content/post/2026/04/06/index.zh-tw.md

构建校验：
- hugo --source . --destination public
- 结果：PASS

Por qué son importantes estas reglas

Mantener “slug” sin cambios conserva las URL estables y los vínculos de retroceso históricos.
Normalizar la “fecha” a RFC3339 con zona horaria evita la ambigüedad en el análisis de Hugo/tema.
Mantener la estructura de Markdown sin cambios evita problemas de representación de TOC, bloques de código y códigos cortos.
No traducir identificadores técnicos reduce significativamente las discrepancias entre archivos y comandos rotos.

Errores comunes y cómo evitarlos

Si title contiene : sin comillas, el análisis de YAML puede fallar.
Traducir --flags, URL o nombres de paquetes interrumpirá los ejemplos de comandos.
Si los niveles de encabezado difieren entre idiomas (por ejemplo, ## se convierte en ###), los anclajes pueden volverse inconsistentes.
Traducir solo el contenido del cuerpo, pero no el texto inicial, puede romper las páginas de la lista y los metadatos de SEO.

Análisis de la habilidad del agente docx de Anthropic: características, estructura del código, uso y advertencias

Sat, 04 Apr 2026 11:00:00 +0800

skills/docx de Anthropic es esencialmente una especificación de flujo de trabajo más un conjunto de herramientas de script para manejar documentos de Word de manera más confiable con IA.
No solo le dice a un modelo que “genere un .docx”. En cambio, divide el trabajo del documento en rutas explícitas: crear, leer, editar archivos existentes, manejar cambios rastreados, agregar comentarios, convertir formatos y validar la estructura OOXML.

Si lo reducimos a una línea:

Trata .docx como restricciones de compatibilidad ZIP + XML + Office, no como un cuadro negro.

Qué resuelve esta habilidad

Cuando los modelos de uso general manejan archivos de Word, a menudo vemos los mismos patrones de falla:

Generan texto, pero no un .docx estructuralmente válido.
Rompen OOXML al editar documentos existentes.
No saben qué partes XML actualizar para comentarios o seguimiento de cambios.
La salida se abre en una aplicación pero se comporta de manera inconsistente en Word, LibreOffice y Google Docs.
Carecen de una ruta clara sobre cuándo usar pandoc versus desempaquetar/editar/reempaquetar.

El valor de esta habilidad es que adelanta esas decisiones:

Utilice pandoc o desempaquetado para lectura y análisis.
Utilice docx-js para crear nuevos archivos .docx.
Utilice “desempaquetar -> editar XML -> recomprimir -> validar” para los documentos existentes.
Utilice scripts dedicados para realizar seguimiento de cambios/comentarios/operaciones sensibles a esquemas.

Ese enfoque funciona porque los problemas de Word generalmente no tienen que ver con la calidad de la redacción. Se trata de corrección estructural y compatibilidad.

Directorio y estructura de código

Esta habilidad se puede entender en cuatro capas.

1. Capa de orientación: `SKILL.md`

SKILL.md hace dos trabajos importantes:

Define las condiciones de activación.
Si una solicitud menciona Word, .docx, comentarios, seguimiento de cambios, TOC, números de página o formato de documento pulido, se debe activar esta habilidad.
Define rutas de ejecución.
Los diferentes tipos de tareas se asignan a diferentes cadenas de herramientas, en lugar de improvisar cada ejecución.

También captura reglas prácticas de compatibilidad, por ejemplo:

docx-js por defecto es A4, no Carta estadounidense.
El tamaño de la página horizontal debe seguir las normas internas de docx-js.
Las listas no deben crearse a partir de viñetas Unicode manuales.
El ancho de la tabla necesita ajustes coordinados a nivel de tabla y celda.
Se requiere “tipo” de imagen.
Los archivos generados deben ser validados.

Esta es una fuerte señal de que el objetivo no es simplemente “generar algo”, sino “generar algo que sea sólido”.

2. Capa de paquete de Office: `scripts/office/*`

Esta capa trata .docx/.pptx/.xlsx como paquetes Open XML.

`desempaquetar.py`

Este script descomprime archivos y prepara XML para una edición más segura:

Extrae el contenido del paquete ZIP
Imprime XML y .rels
Opcionalmente ejecuta merge_runs para DOCX
Opcionalmente ejecuta simplify_redlines para DOCX
Escapa de comillas tipográficas a entidades XML

Entonces no se trata sólo de descompresión. Normaliza el contenido en una forma fácil de editar.

`paquete.py`

Este script vuelve a empaquetar un directorio en .docx/.pptx/.xlsx.
Antes del envasado, puede:

Ejecutar validación y reparación automática.
Condensar el formato XML de forma segura

Si se proporciona “–original”, se compara y valida con el contexto de origen.
Eso es importante porque “reempaquetado exitosamente” no es igual a “semánticamente seguro”.

`validar.py`

Ésta es la puerta de la calidad. Comprueba:

XML bien formado
Corrección del espacio de nombres
Restricciones de identificación únicas
Consistencia de relación/tipo de contenido
Cumplimiento de XSD
Reglas de preservación de espacios en blanco.
Restricciones de inserción/eliminación/marcador de comentarios

Para el trabajo DOCX, este es un componente principal, no un extra opcional.

`soffice.py`

Este asistente envuelve la ejecución de LibreOffice para entornos restringidos/aislados.
Configura SAL_USE_VCLPLUGIN=svp y puede aplicar una corrección para las limitaciones del socket AF_UNIX cuando sea necesario.

Eso nos dice que la habilidad está diseñada para flujos de trabajo de agentes automatizados, no solo para uso manual local.

3. Capa específica de Word: comentarios, revisiones y líneas rojas

`comentario.py`

Este script agrega comentarios a DOCX, incluida la configuración de paquetes requerida en varias partes:

palabra/comentarios.xml
comentariosExtendido.xml
comentariosIds.xml
comentariosExtensible.xml
marcadores de rango de comentarios en document.xml
declaraciones en [Content_Types].xml y document.xml.rels

Si las partes de comentarios aún no existen, puede inicializar plantillas y relaciones/tipos de contenido requeridos.

`aceptar_cambios.py`

Este script acepta todos los cambios rastreados a través de LibreOffice headless + macro (.uno:AcceptAllTrackedChanges) en lugar de una frágil cirugía XML sin formato.

Esa es una elección pragmática porque aceptar revisiones es una operación a nivel de comportamiento, no solo eliminar etiquetas <w:ins>/<w:del>.

`validadores/redlining.py`

Esta es una de las piezas más valiosas.
Elimina los cambios rastreados para un autor específico tanto en documentos originales como modificados, luego compara el texto resultante para verificar que los cambios estén representados correctamente en el marcado de revisión.

Por tanto, valida la semántica de revisión, no sólo la sintaxis XML.

4. Esquema y capa de soporte: `schemas/`, `helpers/`, `templates/`

`esquemas/`

Contiene archivos XSD relacionados con OOXML/ECMA/Microsoft utilizados por los validadores.
Por lo tanto, la validación se basa en restricciones de esquema formal.

`ayudantes/`

Incluye utilidades como:

-merge_runs.py

simplificar_redlines.py

Estos estabilizan la estructura XML para lograr ediciones y diferencias más claras.

`plantillas/`

Contiene plantillas XML necesarias para admitir comentarios, que incluyen:

comentarios.xml
comentariosExtendido.xml
comentariosIds.xml
comentariosExtensible.xml
personas.xml

Estas plantillas ayudan a evitar inconsistencias a nivel de paquete al crear partes relacionadas con comentarios.

Patrones de uso típicos

Desde SKILL.md, los flujos de trabajo más comunes son:

Escenario 1: leer/analizar un DOCX existente

Utilice pandoc para la extracción a nivel de texto con seguimiento de cambios:

`1`	`pandoc --track-changes=all document.docx -o output.md`

Utilice el desembalaje para la inspección XML sin formato:

`1`	`python scripts/office/unpack.py document.docx unpacked/`

Escenario 2: crear un nuevo DOCX

Utilice docx-js para la generación:

`1`	`npm install -g docx`

Luego valide:

`1`	`python scripts/office/validate.py doc.docx`

Escenario 3: editar un DOCX existente

Flujo de trabajo principal:

1
2
3

python scripts/office/unpack.py document.docx unpacked/
# edit XML under unpacked/
python scripts/office/pack.py unpacked/ output.docx --original document.docx

--original es la parte crítica porque permite controles estructurales y de revisión más sólidos.

Escenario 4: aceptar todos los cambios rastreados

`1`	`python scripts/accept_changes.py input.docx output.docx`

Requiere LibreOffice; útil para producir un archivo limpio posterior a la revisión.

Escenario 5: Agregar comentarios

1
2

python comment.py unpacked/ 0 "Comment text"
python comment.py unpacked/ 1 "Reply text" --parent 0

Aún necesita colocar marcadores de rango de comentarios en document.xml donde debe adjuntarse el comentario.

Advertencias clave para recordar

1. `.docx` no es un archivo de texto sin formato

Una única edición puede implicar cuerpo XML, relaciones, tipos de contenido, partes de comentarios, ID y restricciones de esquema.

2. La generación `docx-js` todavía necesita barreras de seguridad explícitas

Los valores predeterminados pueden ser incorrectos para el diseño objetivo y los objetivos de compatibilidad.

3. Los comentarios y los cambios rastreados son operaciones de varias partes

Son funciones a nivel de paquete, no ediciones de una sola etiqueta.

4. “Se abre correctamente” no significa “modificado correctamente”

Muchos problemas solo surgen más tarde durante la edición, revisión, apertura entre aplicaciones o aceptación de cambios.

5. La preparación ambiental importa

Necesita herramientas como pandoc, LibreOffice/soffice, docx-js y Python deps (defusedxml, lxml) disponibles.

Para qué sirve esta habilidad (y para qué no)

Buen ajuste

Generación de informes de Word por lotes
Producción de documentos formales estructurados.
Ediciones automatizadas a .docx existente
Flujos de trabajo conscientes de los cambios rastreados
Inserción automática de comentarios.
Canalizaciones de documentos basados en agentes/scripts

No es ideal

Casos de salida muy simples solo en PDF
Extracción de texto puro sin requisitos de fidelidad del documento.
Flujos de trabajo de edición visual totalmente manuales.
Expectativas de dependencia cero para la automatización de Word de un extremo a otro

Resumen

skills/docx de Anthropic es fuerte no porque pueda “generar archivos de Word”, sino porque codifica por qué falla la automatización de Word y cómo manejar esos modos de falla sistemáticamente.
Combina generación, edición XML de bajo nivel, semántica de revisión, validación de esquemas y compatibilidad entre aplicaciones en un flujo de trabajo ejecutable.

Si su caso de uso incluye ediciones DOCX existentes, comentarios, cambios rastreados o automatización sensible a la compatibilidad, este diseño es muy práctico y de gran valor.

Ubicación del código: https://github.com/anthropics/skills/tree/main/skills/docx

Cómo crear y utilizar habilidades: especificación y principios prácticos de SKILL.md

Sat, 28 Mar 2026 16:30:00 +0800

Este artículo se centra en dos preguntas:

¿Cómo debería escribirse y estructurarse SKILL.md?
¿Cómo creamos habilidades reutilizables, mantenibles y de alta calidad?

1. Especificación de HABILIDAD.md

SKILL.md es el archivo de descripción principal de una habilidad. Suele contener dos partes:

Portada de YAML: define metadatos de habilidades.
Cuerpo de Markdown: define la guía de ejecución y el flujo de trabajo práctico.

1.1 Ejemplo de portada

---
# === Required fields ===
name: skill-name
# Unique skill identifier; kebab-case is recommended

description: >
  Brief but precise description of:
  1) What this skill does
  2) When it should be used
  3) What its core value is
# Note: description is typically the key basis for skill selection

# === Optional fields ===
version: 1.0.0
allowed_tools: [tool1, tool2]
required_context: [context_item1]
license: MIT
author: Your Name <email@example.com>
tags: [database, analysis, sql]
---

1.2 Estructura corporal recomendada

# Skill Title

## Overview
(Skill summary, use cases, technical background)

## Prerequisites
(Runtime environment, dependencies, required permissions)

## Workflow
(Step-by-step guidance: input, process, output)

## Best Practices
(Experience-based tips, caveats, common pitfalls)

## Examples
(Typical cases for faster adoption)

## Troubleshooting
(Common issues and fixes)

2. Principios para escribir habilidades de alta calidad

Con base en la documentación oficial y la práctica comunitaria, se recomiendan los siguientes cuatro principios.

2.1 Mantenga la descripción precisa

La “descripción” es el punto de entrada clave para combinar habilidades. Debería:

Definir claramente el alcance; Evite palabras vagas como “ayuda con el procesamiento de datos”.
Incluya palabras clave desencadenantes para que coincidan con la intención del usuario.
Explicar el valor único y los límites de otras habilidades.

Ejemplo débil:

`1`	`description: Handle database queries`

Ejemplo más fuerte:

description: >
  Convert Chinese business questions into SQL queries and analyze the MySQL employees sample database.
  Suitable for employee info lookup, salary statistics, department analysis, and role-change history.
  Use this skill when users ask about employee, salary, or department data.

2.2 Diseño modular y responsabilidad única

Una habilidad debe centrarse en un dominio de tarea claramente definido. Si una sola habilidad intenta abarcar demasiado, a menudo conduce a:

Descripciones más amplias y menor precisión de coincidencia.
Instrucciones más largas y carga de contexto más pesada.
Mayores costes de mantenimiento e iteración.

En lugar de una habilidad de “análisis general”, divídala en habilidades especializadas, por ejemplo:

análisis-de-empleados-mysql
análisis-de-datos-de-ventas
análisis-de-comportamiento-de-usuario

2.3 El determinismo primero

Para tareas complejas que requieren precisión, prefiera la ejecución con script a la generación pura de LLM.

Por ejemplo, en escenarios de exportación de datos, en lugar de generar contenido binario de Excel directamente con un LLM, utilice un script dedicado. SKILL.md solo debe definir cuándo y cómo invocarlo.

2.4 Divulgación progresiva

Capa de información por importancia y frecuencia para reducir el uso de contexto innecesario:

Cuerpo SKILL.md: flujo de trabajo principal y patrones comunes
Documentos complementarios (por ejemplo, advanced.md): uso avanzado y casos extremos
Archivos de datos: datos de referencia de gran tamaño a los que se accede bajo demanda mediante scripts

Resumen

El objetivo de las habilidades de alta calidad no es escribir más, sino establecer límites más claros, mejores desencadenantes, ejecución estable y mantenimiento sostenible.

Comience con un SKILL.md estandarizado, luego combine la responsabilidad única con la divulgación progresiva para construir un sistema de habilidades más eficiente.

¿Qué son las habilidades de los agentes? Desde los principios de diseño hasta la optimización del contexto

Sat, 28 Mar 2026 00:00:00 +0000

Agent Skills es una forma estandarizada de empaquetar conocimientos procesales. En resumen, responde no sólo a “si existen herramientas” sino también a “cómo utilizarlas correcta y eficazmente”.

1. Principios básicos de diseño

El valor central de Agent Skills es que captura una metodología reutilizable:

Proporciona conocimiento del dominio para guiar cómo los agentes combinan e invocan herramientas en escenarios específicos.
Restringe las rutas de ejecución, reduciendo el ensayo y error y mejorando la coherencia.
Hace que los flujos de trabajo complejos sean reutilizables e iterativos, formando SOP estables a lo largo del tiempo.

Si la capacidad de la herramienta es como una interfaz de hardware, Skills se acerca más a un manual de operaciones más un manual de mejores prácticas, que define qué se debe hacer y cómo.

2. Divulgación progresiva: resolver el cuello de botella del contexto

La innovación clave en Agent Skills es la divulgación progresiva: cargue información solo cuando sea necesario, en lugar de enviar todo a la ventana contextual a la vez.

2.1 Capa 1: Metadatos

Cada habilidad generalmente se almacena en su propia carpeta, con SKILL.md como archivo principal. Este archivo comienza con la información preliminar de YAML que define la información básica de habilidades.

Al inicio, el agente lee solo la parte frontal de todas las habilidades e inyecta esos metadatos en el indicador del sistema. En la práctica:

Los metadatos de una habilidad cuestan alrededor de “100 tokens”.
50 habilidades cuestan alrededor de “5000 fichas”.

2.2 Capa 2: Instrucciones

Cuando una habilidad se considera muy relevante para la tarea actual, el agente lee el SKILL.md completo y carga instrucciones detalladas, notas y ejemplos.

El uso de tokens en esta capa depende de la complejidad de las instrucciones, normalmente:

1000 a 5000 tokens

2.3 Capa 3: Recursos adicionales (guiones y referencias)

Para habilidades más complejas, SKILL.md puede hacer referencia a scripts, archivos de configuración y documentos, que se cargan solo cuando es necesario.

Ejemplo de estructura de directorio:

skills/pdf-processing/
├── SKILL.md                 # Main skill file
├── parse_pdf.py             # PDF parsing script
├── forms.md                 # Form-filling guide (loaded only for form tasks)
└── templates/
    ├── invoice.pdf
    └── report.pdf

Patrón de invocación típico:

Ejecute parse_pdf.py cuando sea necesario analizar PDF
Cargue forms.md solo para tareas de llenado de formularios
Acceda a archivos de plantilla solo cuando genere formatos de salida específicos

3. Por qué funciona este diseño

3.1 Capacidad de conocimiento escalable

Con scripts y archivos externos, una habilidad puede llevar el conocimiento mucho más allá de los límites de la ventana contextual. Por ejemplo, una habilidad de análisis de datos puede incluir un conjunto de datos de “1 GB” más scripts de consulta, y el agente puede acceder a los datos mediante la ejecución en lugar de cargar todo el conjunto de datos en contexto.

3.2 Determinismo más fuerte

Delegar cálculos complejos, transformación de datos y análisis de formatos al código reduce significativamente la incertidumbre y el riesgo de alucinaciones en la generación de texto puro.

4. Impacto práctico: de 16k a 500 tokens

La práctica comunitaria muestra que la Divulgación Progresiva puede reducir drásticamente los gastos generales del contexto inicial:

Enfoque MCP tradicional: conéctese directamente a un servidor MCP con muchas definiciones de herramientas, alrededor de “16 000 tokens” en la inicialización
Con paquete de habilidades: use una habilidad de puerta de enlace liviana que se describe principalmente al principio, alrededor de “500 tokens” en la inicialización.

Las instrucciones detalladas y los recursos adicionales se cargan sólo cuando la tarea realmente los requiere. Esto reduce el costo inicial y mejora la precisión de la gestión del contexto durante la conversación.

Resumen

El valor clave de Agent Skills es pasar de “las herramientas están disponibles” a “las capacidades son reutilizables”. Con Progressive Disclosure, los sistemas pueden preservar la profundidad de la capacidad y al mismo tiempo optimizar significativamente el costo del token y la estabilidad de la ejecución.

Habilidades De Agentes on KnightLi Blog

Uso de las habilidades de los agentes de IA para mantener un blog multilingüe de Hugo

¿Qué problema resuelve esta habilidad?

Estructura del directorio de habilidades

Código central 1: SKILL.md

Código central 2: agentes/openai.yaml

Ejemplo de uso práctico

1) Activador del lenguaje natural

2) Resultado esperado

Por qué son importantes estas reglas

Errores comunes y cómo evitarlos

Análisis de la habilidad del agente docx de Anthropic: características, estructura del código, uso y advertencias

Qué resuelve esta habilidad

Directorio y estructura de código

1. Capa de orientación: SKILL.md

2. Capa de paquete de Office: scripts/office/*

desempaquetar.py

paquete.py

validar.py

soffice.py

3. Capa específica de Word: comentarios, revisiones y líneas rojas

comentario.py

aceptar_cambios.py

validadores/redlining.py

4. Esquema y capa de soporte: schemas/, helpers/, templates/

esquemas/

ayudantes/

plantillas/

Patrones de uso típicos

Escenario 1: leer/analizar un DOCX existente

Escenario 2: crear un nuevo DOCX

Escenario 3: editar un DOCX existente

Escenario 4: aceptar todos los cambios rastreados

Escenario 5: Agregar comentarios

Advertencias clave para recordar

1. .docx no es un archivo de texto sin formato

2. La generación docx-js todavía necesita barreras de seguridad explícitas

3. Los comentarios y los cambios rastreados son operaciones de varias partes

4. “Se abre correctamente” no significa “modificado correctamente”

5. La preparación ambiental importa

Para qué sirve esta habilidad (y para qué no)

Buen ajuste

No es ideal

Resumen

Cómo crear y utilizar habilidades: especificación y principios prácticos de SKILL.md

1. Especificación de HABILIDAD.md

1.1 Ejemplo de portada

1.2 Estructura corporal recomendada

2. Principios para escribir habilidades de alta calidad

2.1 Mantenga la descripción precisa

2.2 Diseño modular y responsabilidad única

2.3 El determinismo primero

2.4 Divulgación progresiva

Resumen

¿Qué son las habilidades de los agentes? Desde los principios de diseño hasta la optimización del contexto

1. Principios básicos de diseño

2. Divulgación progresiva: resolver el cuello de botella del contexto

2.1 Capa 1: Metadatos

2.2 Capa 2: Instrucciones

2.3 Capa 3: Recursos adicionales (guiones y referencias)

3. Por qué funciona este diseño

3.1 Capacidad de conocimiento escalable

3.2 Determinismo más fuerte

4. Impacto práctico: de 16k a 500 tokens

Resumen

1. Capa de orientación: `SKILL.md`

2. Capa de paquete de Office: `scripts/office/*`

`desempaquetar.py`

`paquete.py`

`validar.py`

`soffice.py`

`comentario.py`

`aceptar_cambios.py`

`validadores/redlining.py`

4. Esquema y capa de soporte: `schemas/`, `helpers/`, `templates/`

`esquemas/`

`ayudantes/`

`plantillas/`

1. `.docx` no es un archivo de texto sin formato

2. La generación `docx-js` todavía necesita barreras de seguridad explícitas