Audita los skills de herramientas de trabajo antes de que salven —o desperdicien— tu flujo de trabajo de la oficina

Comienza con la primera trampa concreta: la regla de no-JSON de apply_patch. El inventario del banco de pruebas da la escala de la auditoría: 232 interfaces de herramientas, 44 archivos principales de skill, 223 herramientas de registro y 9 controles directos de sesión. Las herramientas son endpoints invocables; un skill de herramienta de trabajo es un paquete de instrucciones reutilizable que guía cómo se usan esas herramientas. Aprobar significa que el archivo de definición predice la salida y la lista de herramientas cubre las acciones requeridas; reprobar significa que el skill añade ceremonia a una tarea que ya sabes hacer.

El peligro es que un skill puede sonar como una ganancia mientras se convierte silenciosamente en un impuesto de prompts. Si la ruta manual ya es corta, el skill tiene que justificarse. Por eso importa una auditoría: convierte un vago «esto parece útil» en una decisión que puedes defender.

Lo que realmente estás auditando

Un skill no es lo mismo que las herramientas que puede llamar. La referencia contiene la lista de herramientas y los archivos principales de skill. Cada página de skill es una copia literal de su archivo principal de definición. Estás leyendo las instrucciones que seguirá el modelo, incluidas las partes que parecen aburridas pero determinan si la salida es utilizable.

El lado de las herramientas es igualmente importante. La referencia de herramientas describe lo que cada herramienta puede hacer. Conserva las descripciones expuestas y las declaraciones de TypeScript. Si un skill pide una capacidad, la descripción de la herramienta es donde sabes si el modelo puede hacerla de forma limpia o si improvisará ante una capacidad faltante.

La disponibilidad no es fija; puede cambiar con la configuración de la sesión y los permisos. Es la diferencia entre un flujo de trabajo que funciona y un flujo de trabajo que produce un mensaje de error educado.

La auditoría de skills de cinco puntos

Usa esta auditoría antes de activar un skill para una tarea de oficina recurrente. Mantenla lo suficientemente corta para que realmente la hagas y lo suficientemente específica para que puedas comparar skills entre sí.

1. Nombra el flujo de trabajo. Aprueba si el disparador y las entradas esperadas del archivo de definición coinciden con una sola frase: quién lo usa, qué entrada llega, qué salida se necesita y cómo se ve «hecho».
2. Lee el archivo principal de definición del skill. Aprueba si el archivo es lo suficientemente claro para predecir el disparador, las entradas esperadas, los pasos, el formato de salida y el comportamiento ante el fallo.
3. Mapea las herramientas que llama. Aprueba si la referencia de herramientas cubre las acciones requeridas para cada herramienta que el skill espera.
4. Confirma la disponibilidad y los permisos. Aprueba si la sesión expone las herramientas requeridas y el usuario tiene el permiso necesario.
5. Compara la sobrecarga de prompts con un prompt manual. Aprueba si el prompt esperado del skill reduce la repetición sin añadir ceremonia en comparación con el prompt manual más corto que obtendría un resultado utilizable.

Regla de decisión: activa un skill para un alcance limitado solo cuando apruebe las cinco comprobaciones; de lo contrario, corrige el fallo específico, descarta el skill o mantén el prompt manual.

El quinto paso separa un skill útil de uno decorativo. Un skill debería reducir la distancia entre la solicitud y la salida, no convertir una tarea simple en un formulario. Si el prompt manual ya es corto, el skill debe ofrecer una estructura consistente, un uso más seguro de las herramientas, menos seguimientos o un formato repetible.

Cómo decidir qué activar

Comienza con un flujo de trabajo, no con todo un departamento. Elige una tarea lo suficientemente frecuente para que importe y lo suficientemente molesta para que notes la diferencia. Ejecuta la auditoría con un conjunto pequeño de skills, no con uno grande. Una lista corta es más fácil de evaluar que un catálogo.

Para cada skill, registra el resultado en lenguaje claro. Una nota puede describir una práctica útil, pero «Quizás» no. Aplica la regla de decisión una vez y luego observa el primer fallo real.

El objetivo no es coleccionar skills. Es construir un pequeño conjunto de skills de herramientas de trabajo que hagan el flujo de trabajo de la oficina más rápido, más consistente y más fácil de explicar. Un buen skill debería sentirse como una herramienta bien etiquetada: sabes qué hace, cuándo usarla y no te sorprende cuando lo haces. Veredicto del laboratorio: aplica la regla de decisión a la trampa inicial. Si el archivo de definición no puede predecir la salida, o la lista de herramientas no puede cubrir las acciones requeridas, el skill es un impuesto de prompts, no un ahorro de flujo de trabajo.