Comandos reutilizables, Skills y Plugin

Cada viernes debes transformar una lista de commits seleccionados en notas internas, sin publicarlas y sin leer toda la historia de la empresa.

1. Crea directamente una Skill local con dos entradas, intervalo de commits y público destinatario, y una salida fija: cambios, correcciones y riesgos conocidos.
2. Añade dos ejemplos aprobados y una checklist editorial, porque las categorías y el tono forman parte del método y no deben depender del recuerdo del chat.
3. Mantén la Skill en solo lectura y deja la salida como borrador; la aprobación y la publicación siguen siendo acciones humanas separadas.
4. Evalúa un plugin solo si debes recuperar commits de varios repositorios y enviar el borrador a un sistema externo, definiendo identidad, permisos y gestión de errores.

Resultado: El workflow crece cuando aparece una necesidad real. No introduces credenciales ni integraciones mientras una Skill local ya produzca un borrador fiable.

Un workflow lee un CSV y señala filas sospechosas. No debe corregir importes ni cargar nada en el sistema de gestión.

1. Define la entrada: archivo UTF-8 de menos de 5 MB, columnas obligatorias `invoice_id`, `date`, `net`, `tax`, `total` y moneda declarada una sola vez.
2. Valida estructura y tipos antes del análisis; si falta una columna, devuelve `invalid_input` con el nombre exacto y no intentes reconstruir los valores.
3. Fija la salida para cada anomalía: fila, regla incumplida, valores observados y explicación; añade recuento total y controles ejecutados.
4. Usa tres pruebas: factura correcta, total incoherente y archivo sin `tax`; confirma que ninguna prueba modifique el archivo fuente ni llame al sistema de gestión.

Resultado: Quien aprueba la importación recibe un informe comparable y sabe distinguir una factura limpia de un archivo que el workflow no logró leer.

Quieres crear ejemplos para la documentación a partir de tickets reales, eliminando datos personales sin alterar el significado técnico.

1. Crea `.claude/skills/anonimizar-ticket/SKILL.md`. En el frontmatter inserta `name`, una `description` que diga cuándo activarla y solo los `allowed-tools` necesarios; en el cuerpo limita el trabajo a los textos proporcionados para la anonimización.
2. Especifica categorías que detectar, como nombres, correos electrónicos, números de pedido y direcciones IP, y el formato de sustitución estable `[EMAIL_1]`, `[ORDER_1]`.
3. Ordena los pasos: inventario de los datos sensibles, sustitución, segunda revisión e informe final; prohíbe guardado o envío externo sin autorización.
4. Prueba un ticket normal, uno sin el texto y uno que contiene credenciales: en este último caso la Skill debe negarse a reproducirlas y pedir una fuente ya redactada.

Resultado: La Skill produce ejemplos coherentes y un informe de las sustituciones, pero conserva un límite claro: no se convierte en un canal para copiar o archivar secretos.

El equipo quiere transformar vencimientos aprobados en borradores de evento. El plugin proviene de un repositorio público y requiere acceso al calendario.

1. Verifica autor, repositorio, release firmada e historial de cambios; compara el paquete descargado con la versión declarada.
2. Lee manifest, scripts y dependencias: permite la lectura de los vencimientos seleccionados y la creación de borradores, pero rechaza acceso a contactos, correo electrónico y archivos innecesarios.
3. Instala la versión fijada en un calendario de prueba sin datos personales; simula token caducado y servicio inaccesible, comprobando que no se creen eventos parciales.
4. Documenta motivo de la adopción, responsable, procedimiento de revocación del token y eliminación; habilita el calendario real solo después de una review de la salida.

Resultado: La decisión no depende de la reputación percibida. Sabes qué datos atraviesan el plugin, qué acciones puede realizar y cómo interrumpir el acceso sin dejar credenciales activas.