Automatiza tu flujo con skills en Cursor

Si ya sabes convertir un requerimiento difuso en un documento listo para ejecutar, el siguiente paso es automatizar ese flujo con un skill en Cursor. Aquí verás cómo empaquetar todo el proceso de discovery en un solo comando que orquesta desde las preguntas iniciales hasta el pull request final, deteniéndose solo cuando tu decisión humana importa.

¿Qué es un skill en Cursor y para qué sirve?

Un skill es un paquete de instrucciones que le da a un agente la capacidad de ejecutar un flujo completo de forma estructurada. En lugar de repetir manualmente cada paso, el agente sigue una secuencia definida en un archivo skill.md.

El objetivo aquí fue tomar todo el trabajo previo del curso (convertir un requerimiento vago en specs implementables listas para paralelizar) y empaquetarlo dentro de un solo skill llamado Discover Feature [00:34].

¿Qué es un skill en Cursor? Es un paquete de instrucciones que orquesta un flujo de trabajo completo para un agente. Se define en un archivo skill.md y puede detenerse en puntos de decisión humana antes de continuar.

La documentación oficial en cursor.com explica qué es un skill, cómo funcionan, cuáles trae Cursor por defecto y cómo se organizan los directorios, incluyendo el nesting o directorios anidados [00:50].

¿Cómo se crea un skill con /create skill?

Cursor ofrece algo curioso: un skill para crear skills. Se llama /create skill y funciona con un prompt donde le describes exactamente qué quieres que haga tu nuevo skill [01:22].

El prompt usado pidió crear un skill de proyecto que:

• Reciba un requerimiento incompleto o vago.
• Haga preguntas para desenredar el problema.
• Redacte el PRD y se detenga hasta que lo apruebes.
• Cree las specs solo después de tu aprobación.
• Se apoye en las Cursor Rules del proyecto sin repetir lo que ya está en las reglas.

Un detalle clave: el skill no debe duplicar información que ya vive en las reglas, sino referenciar dónde están el PRD y las specs [02:00]. Esto mantiene tu proyecto limpio y evita instrucciones contradictorias.

¿Por qué el skill se detiene en checkpoints humanos?

El skill generado orquesta el flujo en tres checkpoints humanos [02:35]. La idea no es delegar todo, sino usar la herramienta para tomar decisiones rápido.

Las fases quedaron así:

1. Preguntas de alcance cuando hay huecos críticos.
2. Guardar o crear el PRD en el folder correcto.
3. Crear las specs, asignando un número y un slug a cada una.

Después vienen los commits atómicos y la creación del pull request [03:05]. Así el humano entra solo cuando es relevante.

¿Cómo responde el skill a un requerimiento ambiguo?

Aquí viene lo interesante. Se le dio un requerimiento tan vago como los que cualquier jefe te daría: la app mezcla verde y azul, algunas partes del dashboard siguen azules después del login, y encima "quiero más diseño en los botones" [03:45].

Ante esa ambigüedad, el skill lanzó cuatro preguntas concretas [04:20]:

• ¿Cuál debe ser la paleta principal? Acciones primarias, links y focus.
• ¿Qué alcance quieres? ¿Toda la app o solo el área autenticada?
• ¿Qué nivel de diseño en los botones? Incluso propuso un design system.
• ¿El verde esmeralda en badges y chips se mantiene como color semántico distinto del brand?

Las respuestas fueron: verde de marca, toda la app, arrancar con un mini design system y mantener el verde esmeralda como color semántico.

¿Cómo maneja un skill un requerimiento vago? Hace preguntas de alcance para llenar los huecos críticos antes de escribir nada. Solo cuando el requerimiento está claro redacta el PRD y espera tu aprobación.

¿Qué pasa después de aprobar el PRD?

Con las respuestas claras, el skill revisó la plantilla, redactó el borrador del PRD y lo dejó en docs/PRDs [05:30]. El documento incluía contexto del problema, objetivo de unificar la identidad visual, métrica de éxito y hasta el glosario de conceptos.

Ese glosario no salió de la nada: el skill se apoyó en el PRD inicial creado en las primeras clases del curso, entendiendo el lenguaje compartido del proyecto [06:50].

Una vez aprobado el PRD, el siguiente paso fue dividirlo en specs.

¿Cómo divide el skill el trabajo en specs paralelizables?

El skill creó cuatro specs y, mejor aún, recomendó cómo ejecutarlas [07:40]:

• Spec 12: los tokens del design system.
• Spec 13: app shell y páginas de auth.
• Spec 14: migración visual de flags.
• Spec 15: migración visual del simulador y el history.

Lo valioso es la recomendación de paralelización. El spec 12 bloquea todo: sin tokens no puedes modificar la parte visual de las demás interfaces. Por eso se ejecuta primero, y luego el 13, 14 y 15 corren en paralelo sin solapamiento de archivos [08:05].

¿Qué es un spec y por qué se paraleliza? Un spec es una unidad de trabajo implementable derivada del PRD. Se paralelizan las que no comparten archivos; las que son dependencia de otras se ejecutan primero.

Aquí tu tarea como desarrollador es leer cada spec, aprobarlo si está bien o dar feedback para que el skill lo actualice. En la demo se aprobaron sin leer, pero eso es mala práctica y no deberías repetirlo [08:40].

¿Qué entrega el skill al final del flujo?

Una vez aprobadas las specs, el skill creó la rama, generó commits atómicos por cada spec y abrió un pull request [09:00]. En el navegador quedó visible el summary, el orden y el test plan, con el PRD y las specs dentro de docs.

Esta es la nueva forma de desarrollar software: delegamos la escritura del código a agentes y entramos como humanos solo cuando somos relevantes [09:40]. Si tienes los pasos estructurados, puedes automatizar el flujo con skills, con un harness usando MCP o con hooks.

Ahora te toca a ti: construye tu propio skill y automatiza tu proceso. ¿Qué flujo repetitivo automatizarías primero? Cuéntame en los comentarios.