Saltar al contenido
kenjtecJournal
Buscar en el Journal

Tu flujo de trabajo como skill de Claude: explícalo una vez y reutilízalo de forma deliberada

Una skill propia empieza con un contrato de entrada. Un ejemplo completo muestra la estructura de archivos, los detalles abiertos y contraejemplos útiles.

En el banco de trabajo, Hanne coloca una breve tarjeta de instrucciones, unos bocetos sueltos y un cuenco terminado uno al lado del otro. Ilustración creada con IA.

El tercer chat vuelve a empezar con la misma explicación: ¿qué datos deben ir en el briefing, qué términos usa el equipo y qué debe pasar cuando falta algo? La repetición es una buena señal de que puedes poner por escrito una forma de trabajar. Una skill la convierte en una instrucción reutilizable que aplicas de forma deliberada y sigues manteniendo.

Para Claude Code, la documentación oficial de skills describe un SKILL.md con metadatos e instrucciones. Puede usarse cuando una tarea encaja o cuando se invoca explícitamente. Esto cambia la instrucción para el trabajo, no los pesos entrenados del modelo. Los archivos siguientes son un borrador ilustrativo propio, no el informe de una ejecución realizada.

Primero la decisión, después el archivo

Nuestro ejemplo es una tarde mensual de reparaciones. A partir de unas notas organizativas debe elaborarse un briefing interno. En él, los voluntarios necesitan los acuerdos confirmados, las tareas y las decisiones pendientes. Es un encargo más pequeño que planificar todo el evento.

Redacta antes un contrato de entrada. Cada dato necesita un valor y un estado. «Inicio 18:00, confirmado» es distinto de «Inicio 18:00, sugerencia». La IA debe conservar esa diferencia. Si falta el lugar, se trata de una pregunta abierta; una dirección sustituta que suene plausible rompería el encargo.

Mantén el SKILL.md breve e inequívoco

Una posible ubicación a nivel de proyecto es .claude/skills/reparaturbrief/. Podría contener la siguiente instrucción de trabajo propia. Los metadatos explican cuándo se necesita; el texto que va debajo describe lo que debe entregar.

---
name: reparaturbrief
description: Creates internal briefings for repair evenings from organisational notes.
---
Record confirmed details and suggestions separately.
Do not invent venues, dates, names or commitments.
If there are contradictions: state both details and phrase a follow-up question.

Output:
1. Confirmed arrangements
2. Tasks with confirmed responsibility
3. Open decisions with a reference to the input
4. Next coordination step

Una descripción como «ayuda con todo lo relacionado con la organización» diría menos. Hace difícil ver dónde encaja la skill y cuándo es más adecuada otra forma de trabajar. Un límite claro también facilita el mantenimiento posterior.

Una entrega de ejemplo con una laguna real

Usa notas ficticias: la sala está confirmada, la hora de inicio todavía es solo una sugerencia y los materiales solo se pedirán cuando se haya aprobado el presupuesto. Indica estas condiciones directamente. Un resultado esperado puede contener la tarea «Aclarar el presupuesto». En cambio, «Materiales pedidos» sería una afirmación nueva sin respaldo.

Una instrucción adicional útil dice: «Para cada decisión pendiente, indica qué parte de la entrada la origina». Así se crea un vínculo entre la laguna y su origen. La skill no tiene que repetir todo el texto original; debe hacer que el dato en cuestión sea fácil de encontrar.

Mantén las preferencias de estilo separadas de las reglas de contenido. Un ejemplo de descripciones de tareas breves puede servir como archivo de apoyo. En cambio, los datos del evento que cambian con frecuencia corresponden al encargo concreto. Así, la instrucción general no se queda desfasada con la siguiente fecha.

Tres casos revelan debilidades distintas

En el primer caso, proporcionas datos completos y coherentes. En el segundo, falta la fecha y dos notas sobre el presupuesto se contradicen. En el tercero, pides algo fuera del ámbito de la skill, como planificar un viaje. Esto te permite examinar por separado la estructura, el manejo de la incertidumbre y los límites de uso.

Para cada caso, anota lo que debe conservarse sin falta. Valora una respuesta primero por eso y solo después por su estilo. Una redacción elegante no compensa una fecha inventada. Del mismo modo, una pregunta de seguimiento no es un error si es precisamente esa decisión la que falta en la entrada.

Mantener una pequeña instrucción de trabajo

Cuando un problema se repite, cambia una regla concreta y repite los casos existentes. Añade un caso nuevo que aún no se conocía cuando se redactó el cambio. Así es más fácil ver si la regla solo reproduce un único ejemplo.

Anota el motivo del cambio y su estado. Al principio, eso no requiere ninguna gran infraestructura. Una nota breve como «Las condiciones del presupuesto deben conservarse en la lista de tareas» es más fácil de seguir que una reescritura completa sin motivo. Una skill merece la pena cuando sus reglas hacen que la siguiente entrega real sea más fácil de entender.

Fuentes y estado de la documentación: 25 de octubre de 2026.

Hamburgo es nuestro punto de partida.

Lo útil viaja contigo.

IA práctica desde Hamburgo, explicada para todos.

Artículos guardados