job-stories

Resumen de la skill job-stories

La skill job-stories te ayuda a convertir ideas de producto todavía imprecisas en job stories al estilo JTBD, con la forma: “When [situación], I want to [motivación], so I can [resultado].” Es especialmente útil cuando necesitas backlog items más claros, una mejor planificación de requisitos o una forma compartida de describir el contexto del usuario antes del diseño de la solución.

Para qué sirve mejor esta skill

Usa la skill job-stories cuando ya conoces un área funcional, pero necesitas afinar el problema del usuario que hay detrás. Encaja bien con product managers, diseñadores, analistas y agentes de IA que redactan requisitos a partir de enlaces de diseño, prompts de funcionalidades o notas de stakeholders.

Por qué es distinta de un prompt genérico

Su valor principal es la estructura: obliga al modelo a partir de la situación y la motivación, y luego añadir criterios de aceptación ligados a resultados observables. Eso hace que job-stories sea más útil que un prompt difuso de “escribe user stories” cuando el equipo se preocupa por el contexto, la intención y resultados verificables.

Cuándo encaja bien

Esta skill es una buena opción para job-stories for Requirements Planning, la definición inicial del backlog antes del discovery y la traducción de conceptos de producto en historias centradas en el usuario. Es menos útil si solo necesitas una lista rápida de ideas en una sola frase, sin criterios de aceptación, o si tu equipo usa por completo otro formato de requisitos.

Cómo usar la skill job-stories

Instálala y actívala correctamente

Para job-stories install, usa el cargador normal de skills del directorio: npx skills add phuryn/pm-skills --skill job-stories. Después, invoca la skill con suficiente información para que el modelo pueda inferir la situación del usuario, el área del producto y el resultado deseado. Un nombre de funcionalidad suelto suele quedarse corto.

Dale la forma de entrada adecuada

La skill funciona mejor cuando tu prompt incluye el producto, la funcionalidad, el contexto del usuario y cualquier referencia de diseño. Un prompt inicial sólido sería: “Create job stories for [product] feature [feature] using these user situations: [context]. Use the design link [design] and focus on outcomes, not roles.” Eso es mejor que “write job stories for checkout.”

Lee primero estos archivos

Empieza por SKILL.md porque ahí están el flujo de trabajo, la plantilla de story y los argumentos obligatorios. Si tu copia local incluye documentación cercana, lee después README.md, AGENTS.md y metadata.json, además de cualquier carpeta rules/, resources/, references/ o scripts/. En este repo, SKILL.md es la fuente principal de verdad, así que no hay mucha superficie adicional que revisar.

Consejos de flujo de trabajo que mejoran el resultado

Usa la skill en dos pasos: primero para obtener job stories en bruto y después para refinarlas según tus restricciones reales. Si la primera salida es demasiado vaga, añade situaciones concretas, puntos de decisión y enlaces de diseño. Si las historias suenan demasiado basadas en roles, pide una reescritura que centre el disparador y el progreso deseado en lugar de la persona.

Preguntas frecuentes sobre la skill job-stories

¿Sirve job-stories para Requirements Planning?

Sí. job-stories está pensada para requirements planning cuando quieres backlog items centrados en el usuario en lugar de tickets definidos primero por la funcionalidad. Ayuda a convertir alcance en situaciones, motivaciones y resultados que luego se discuten mejor con diseño e ingeniería.

¿Necesito un archivo de diseño para usarla bien?

No, pero la skill job-stories funciona mejor si lo aportas. Un enlace de Figma o Miro ayuda al modelo a anclar los criterios de aceptación en comportamientos visibles, en lugar de inventar supuestos.

¿En qué se diferencia de las user stories normales?

Los prompts habituales suelen producir plantillas basadas en roles o criterios de aceptación superficiales. La skill job-stories es mejor cuando la decisión clave es por qué actúa el usuario y qué resultado necesita, no solo qué debería hacer el sistema.

¿Es apta para principiantes?

Sí, si puedes describir una funcionalidad en lenguaje claro. La limitación principal es la calidad de la entrada: los principiantes obtienen mejores resultados cuando aportan una o dos situaciones reales de usuario en lugar de un tema de producto demasiado amplio.

Cómo mejorar la skill job-stories

Aporta situaciones más ricas, no solo nombres de funcionalidades

La mayor mejora de calidad viene del contexto concreto. En vez de “notificaciones”, da una situación como “Cuando un usuario se pierde un recordatorio de pago mientras viaja”, para que la skill job-stories pueda construir una cadena significativa de situación, motivación y resultado.

Añade restricciones y señales de éxito

Si te importan la accesibilidad, los tiempos, los límites de dispositivo o los flujos de aprobación, inclúyelos desde el principio. Los criterios de aceptación son más sólidos cuando el prompt explica cómo se ve el éxito, qué debe ser observable y qué haría fallar la story.

Pide la revisión según el modo de fallo

Si el primer borrador es demasiado genérico, pide menos referencias a roles y más detalle situacional. Si está demasiado cargado de solución, pide job stories que eviten lenguaje de implementación. Si es demasiado amplio, acota la funcionalidad a un objetivo de usuario cada vez.

Usa la primera salida como borrador de planificación

Trata la primera pasada como una herramienta de exploración, no como requisitos finales. El mejor uso de job-stories viene de iterar hasta que las historias encajen con tu roadmap, diseño y restricciones de ingeniería, y después recortar todo lo que no aporte a Requirements Planning ni a la entrega.