Cómo crear una skill que automatiza el discovery

Automatizar el flujo de discovery en Cursor con skills te permite transformar un requerimiento ambiguo en specs listos para implementar, sin escribir cada paso a mano. Si eres desarrollador o tech lead, aquí verás cómo delegar la orquestación al agente y quedarte solo en los puntos de decisión humana.

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

Una skill es una capacidad reutilizable que encapsula un flujo de trabajo dentro de Cursor. En la documentación oficial de cursor.com, dentro de Capabilities, encuentras qué es una skill, cómo funciona, cuáles vienen por defecto y cómo se organizan los directorios anidados para invocarlas.

Lo interesante es que Cursor incluye una skill nativa llamada /create skill que sirve para crear otras skills. Es decir, usas al agente para construir la herramienta que después va a orquestar tu proceso.

¿Qué hace una skill en Cursor? Encapsula un flujo repetible que el agente ejecuta paso a paso, pausando en los checkpoints donde tú, como humano, debes aprobar o corregir.

¿Cómo crear una skill que automatice el discovery de un feature?

El objetivo es construir una skill de proyecto llamada Discover Feature que convierta un requerimiento vago en specs paralelizables. Para eso, se le entrega al comando /create skill un prompt con instrucciones claras sobre el comportamiento esperado.

El prompt le indica al agente tres cosas: al recibir un requerimiento incompleto, hacer las preguntas necesarias para destrabar el problema; redactar el PRD y esperar aprobación; y solo entonces crear los specs. Además, la skill debe apoyarse en las Cursor Rules del proyecto sin duplicar información y referenciar dónde viven el PRD y los specs.

¿Qué genera el agente al construir la skill?

El resultado es un archivo skill.md con instrucciones claras. La skill orquesta el flujo completo a través de tres checkpoints humanos:

• Fase uno: preguntas de alcance para detectar vacíos críticos.
• Fase dos: guardar o crear el PRD en la carpeta correcta.
• Fase tres: crear los specs en la carpeta correspondiente, asignando un número y un scope a cada uno.

Después vienen los atomic commits y la apertura de un pull request. Todo el ciclo termina con el código versionado y listo para revisión.

¿Cómo se comporta la skill frente a un requerimiento ambiguo?

Para probarla, se abre un nuevo agente, se verifica que el proyecto esté en la rama correcta y se invoca la skill Discover Feature con un requerimiento típico de cualquier jefe: "el diseño de la app no es consistente, mezcla verde y azul, quiero que todo se vea verde y también quiero más trabajo en los botones".

El agente detecta la ambigüedad y lanza cuatro preguntas puntuales:

• ¿Cuál es la paleta principal para acciones primarias, enlaces y focus?
• ¿Cuál es el alcance: toda la app o solo el área autenticada?
• ¿Qué nivel de diseño quieres en los botones: un sistema de variantes o solo una versión más pulida?
• ¿El verde emerald de los badges y status chips se mantiene como color semántico distinto del color de marca?

¿Por qué la skill hace preguntas antes de escribir código? Porque no puedes delegar todas las decisiones al agente. Los checkpoints humanos aseguran que el requerimiento quede claro antes de invertir tiempo en specs.

¿Qué pasa cuando el PRD queda aprobado?

Con las respuestas claras, el agente redacta el PRD y lo guarda en docs/PRDs. El documento incluye: contexto del problema, objetivo, métrica de éxito, audiencia, alcance del MVP, lo que queda fuera de scope y un glosario de conceptos.

Ese glosario es clave porque garantiza que humanos y agentes hablen el mismo idioma dentro del proyecto, tal como se estructuró desde las primeras clases del curso.

Una vez aprobado el PRD, la skill pasa a la siguiente fase: descomponer en specs.

¿Cómo descompone la skill los specs y los paraleliza?

La skill genera cuatro specs con un orden de implementación sugerido y olas de paralelización. En este caso:

• Spec 12: tokens del sistema de diseño. Es bloqueante para el resto.
• 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.

El agente identifica que sin tokens no puedes modificar las interfaces siguientes, así que recomienda ejecutar primero el 12 y luego correr 13, 14 y 15 en paralelo. También reporta que no hay overlaps de archivos entre specs, lo que confirma que la paralelización es segura.

Aquí la responsabilidad del desarrollador es leer cada spec, aprobarlo o dar feedback para que la skill lo actualice. Aprobar sin leer es mala práctica y conviene evitarla.

¿Qué pasa después de aprobar los specs?

La skill marca discovery complete, hace commits atómicos (uno por spec) y abre un pull request automáticamente. En el navegador aparece el PR con resumen, orden de ejecución y plan de pruebas. Dentro de la carpeta docs viven el PRD y los specs versionados.

El flujo completo, que antes tomaba varias sesiones de trabajo manual, se ejecuta con un solo prompt y tres aprobaciones humanas.

¿Qué significa esta nueva forma de desarrollar software?

Con pasos estructurados puedes automatizar tu workflow usando skills, un test harness con MCP o hooks. El código deja de escribirse a mano paso a paso y pasa a ser delegado al agente, mientras tú intervienes solo donde tu criterio suma valor: aclarar requerimientos, aprobar PRDs y revisar specs.

Construye tu propia skill con el flujo que más repites en tu día a día y cuéntame en los comentarios qué proceso automatizaste primero.