executing-plans
executing-plans
Use when executing an implementation plan in the current session as the implementer yourself — your human partner chose inline execution, or no subagent tool is available
job-story-mapperEscribir historias de trabajos basadas en Jobs-to-be-Done (JTBD) y mapear empleos de clientes en dimensiones funcionales, sociales y emocionales. Úsalo cuando estés definiendo necesidades de usuario, escribiendo historias de trabajos, realizando investigación JTBD o reenmarcando características alrededor de resultados de clientes. Produce un mapa de histori…
Independent GitHub snapshot · Automated classification · Original documentation governs
Deja de escribir características. Empieza a entender los trabajos. Esta skill traduce requisitos de producto y entrevistas de usuario en historias de trabajos precisas que mantienen al equipo enfocado en resultados — no en productos.
Un "trabajo" es el progreso que un cliente está tratando de lograr en una situación dada. Las personas no compran productos — los contratan para hacer un trabajo.
Tres dimensiones de cada trabajo:
Los grandes productos abordan las tres. La mayoría de roadmaps solo abordan la funcional.
Plantilla:
Cuando [situación/disparador], quiero [motivación/objetivo], para poder [resultado esperado].
No es una user story: Las user stories se enfocan en roles y características: "Como [rol] quiero [característica] para que [beneficio]." Las historias de trabajos se enfocan en situaciones y motivaciones: "Cuando [estoy en esta situación específica] quiero [esta capacidad] para poder [lograr este resultado]."
La situación es la parte más importante. "Cuando estoy en medio de un sprint y mi PM me pide una actualización" es un disparador mucho más rico que "Como desarrollador."
Una oración: ¿Cuál es el trabajo principal por el que se contrata tu producto?
"Ayudar a [tipo de usuario] a [lograr resultado] cuando [contexto]."
¿Cuáles son todas las subtareas dentro del trabajo principal? (Usa un mapa de trabajos: Definir → Ubicar → Preparar → Confirmar → Ejecutar → Monitorear → Modificar → Concluir)
¿Dónde falla el trabajo hoy? ¿Dónde usan clientes soluciones alternativas?
Una historia de trabajo por cada par situación-motivación distinto.
¿Cuáles historias de trabajos están desatendidas? ¿Cuáles tienen soluciones existentes? ¿Dónde está tu diferenciación?
Declaración de Trabajo Principal:
Cuando [contexto], [tipo de usuario] quiere [resultado del trabajo principal], para poder [objetivo final].
Mapa de Trabajos:
| Paso | Sub-Trabajo | Solución Actual | Puntos de Dolor | ¿Desatendido? |
|---|---|---|---|---|
| Definir | [Qué hace el usuario] | [Herramienta/método usado] | [Frustración] | A/M/B |
| Ubicar | ||||
| Preparar | ||||
| Confirmar | ||||
| Ejecutar | ||||
| Monitorear | ||||
| Modificar | ||||
| Concluir |
Historias de Trabajos (priorizadas por desatención):
Historia de Trabajo 1 — [Etiqueta de situación]
Cuando [situación específica], quiero [motivación], para poder [resultado].
Dimensión funcional: [Qué necesitan lograr] Dimensión emocional: [Cómo quieren sentirse] Dimensión social: [Cómo quieren ser percibidos]
Solución alternativa actual: [Qué hacen hoy] Intensidad del dolor: [Alta / Media / Baja] Frecuencia: [Con qué frecuencia ocurre esta situación] Oportunidad de producto: [Qué podríamos construir para abordar esto]
Repetir para cada historia de trabajo principal.
Puntuación de Oportunidades: Califica cada historia de trabajo en:
Esta skill incluye archivos de apoyo — úsalos cuando estén disponibles:
references/situation-mining.md — Situation Mining — el "Cuando" es Todo el Método. Aplícalo mientras produces la salida; lleva la calibración y llamadas de juicio que el resumen del método anterior comprime.templates/job-story-canvas.md — una versión para rellenar del entregable con los quality gates integrados. Ofrécela cuando el usuario quiera trabajar el documento él mismo en lugar de que sea generado.Puntúa cualquier salida de esta skill antes de entregarla; 32+ es calidad lista para producción.
| Dimensión | 0 | 5 | 10 |
|---|---|---|---|
| Especificidad de la situación | Las cláusulas "Cuando" son roles o deseos genéricos ("como usuario que quiere gestionar trabajo") | Las situaciones nombran una tarea pero no un momento — sin disparador, tiempo o contexto emocional | Cada situación es un momento concreto y reconocible ("un inquilino me envía un texto a las 11pm") que hace la motivación evidente |
| Completitud dimensional | Solo el trabajo funcional mapeado; campos emocionales y sociales vacíos o ausentes | Los tres campos rellenos, pero entradas emocionales/sociales solo restatan el trabajo funcional en palabras de sentimiento | Las dimensiones funcional, emocional y social cada una lleva contenido distinto, y al menos una dimensión no funcional forma el análisis de oportunidades |
| Fundamentación de soluciones alternativas | No se identifican soluciones alternativas actuales; los trabajos flotan libres de lo que los clientes hacen hoy | Soluciones alternativas nombradas pero tratadas como triviales — nada inferido de ellas | Cada historia de alto potencial nombra su solución alternativa y la lee como evidencia de lo que vale el trabajo (tiempo invertido, dinero pagado, retraso tolerado) |
| Disciplina de puntuación y priorización | Sin puntuaciones de oportunidad, o puntuaciones inventadas sin los inputs de Importancia/Satisfacción | Puntuaciones calculadas correctamente pero tratadas como el orden de construcción — sin verificación de viabilidad o ajuste estratégico | La aritmética se muestra y es consistente, las puntuaciones borderline no se redondean hacia arriba, y las puntuaciones altas que el roadmap no puede servir se marcan como preguntas de estrategia en lugar de ponerse en cola |
Trabaja con lo que se da. Si alguno de estos falta, aún produce la salida completa: rellena cada brecha con una suposición razonable marcada como (asumido, confirma) y lista esas suposiciones al final. Haz una pregunta primero solo cuando el sujeto principal en sí está faltando (no hay nada de qué escribir).