rizqinrr/get-prd

Obtener PRD

Resumen

get-prd convierte una solicitud vaga en un PRD aprobado en una sola pasada continua. Fusiona tres flujos de trabajo que normalmente se ejecutan por separado:

1. Entrevista con árbol de decisiones — mapea cada decisión como un árbol, trabaja el árbol frontera por frontera en rondas, y da una recomendación con cada pregunta. Esta es la mecánica que hace que una entrevista converja en lugar de divagar.
2. Extracción de intención — captura lo que el usuario realmente quiere, no lo que cree que debería querer, con un número de confianza explícito en cada paso. Esta es la disciplina que evita que el agente complete silenciosamente los vacíos.
3. Redacción de especificaciones — escribe los requisitos en un artefacto estructurado con límites, criterios de éxito y una puerta de aprobación. Este es el entregable que consume la planificación descendente.

La razón para fusionarlos es que dividirlos pierde contexto. Cuando la entrevista es una habilidad y la redacción de especificaciones es otra, la segunda habilidad comienza en frío: vuelve a preguntar lo que la primera ya aprendió, o asume silenciosamente respuestas que nunca se dieron. Un PRD escrito a partir de un resumen desactualizado es peor que ningún PRD, porque parece autoritario.

Dos consecuencias de la fusión, ambas intencionales:

• Esta habilidad es larga. Lleva la metodología completa de las tres fases en lugar de delegar en otras habilidades. Sigue los pasos en orden; no te saltes a la plantilla.
• Esta habilidad nunca delega la entrevista. El mecanismo de entrevista vive aquí. No invoques otra habilidad para hacer las preguntas.

El resultado es un PRD completo guardado en docs/PRD.md (o docs/prd/<nombre>.md), aprobado por el usuario, listo para get-tasks y get-design.

Para nuevos usuarios o conceptos en etapa temprana, get-prd incorpora lentes de descubrimiento para refinar ideas, mapeo de restricciones no funcionales y definiciones de entidades/relaciones centrales directamente en el documento, de modo que no se requieren habilidades separadas de esquema o refinamiento.

Cuándo Usarlo

Usa esta habilidad cuando:

• El usuario está iniciando una nueva aplicación, sistema, funcionalidad o cambio significativo y aún no existe un documento de requisitos
• El usuario dice "get prd", "bikin PRD", "buat PRD", "mau bikin sistem baru" o "mau develop X"
• El usuario pide ser entrevistado, puesto a prueba o evaluado para una especificación
• La solicitud es convencional y está subespecificada ("hazme un dashboard", "hazlo más rápido") y no puedes definir qué significa "terminado"
• Estás a punto de planificar o construir algo que llevaría más de un día, y no existen requisitos escritos

Cuándo NO usarlo:

• Corrección de errores, correcciones tipográficas, renombrados y operaciones mecánicas
• Ya existe un PRD o especificación y el usuario quiere cambiar una pequeña parte — modifica el documento directamente
• Solicitudes de información pura ("¿cómo funciona esto?")
• El usuario quiere explícitamente saltarse la documentación y empezar a construir — respeta eso, pero menciona el riesgo una vez
• Contextos no interactivos (pipelines de CI, ejecuciones programadas, bucles autónomos). Esta habilidad requiere un usuario vivo y receptivo. Si la solicitud está subespecificada en un contexto no interactivo, márcala como un bloqueante en lugar de adivinar.

El Proceso

get-prd se ejecuta en ocho fases. Cada fase tiene una condición de salida. No avances más allá de una fase cuya condición de salida no se haya cumplido.

0. Puerta de alcance       -> ¿es una capacidad o varias?
1. Semilla de hipótesis    -> ¿qué creo que quieren, y qué tan seguro estoy?
2. Construir el árbol      -> ¿qué decisiones existen, y cuáles están en la frontera?
3. Preguntas por rondas    -> preguntar la frontera, una ronda a la vez
4. Sonda de intención      -> querer vs. deber-querer
5. Reformulación           -> decirlo de vuelta, en sus palabras
6. Verificación de vacíos  -> ¿qué necesita el PRD que la entrevista no produjo?
7. Escribir y aprobar      -> el PRD, luego un sí explícito

Principios Universales para el Entrevistador

1. Coincidencia de Lenguaje Natural: Conversa siempre en el idioma preferido del usuario. Si el usuario inicia la conversación en indonesio (ej. "bikin PRD aplikasi absensi"), realiza toda la entrevista cálidamente en indonesio manteniendo intactos los términos técnicos estándar de la industria (acceptance criteria, schema, endpoint, payload). Si habla inglés, hazlo en inglés. Nunca fuerces una entrevista en inglés a un usuario que preguntó en otro idioma.
2. Tono Empático y No Intimidante: Los usuarios a menudo llegan con ideas crudas y sin formar. Nunca interrogues ni hagas que se sientan inadecuados por carecer de terminología técnica. Guíalos con paciencia: traduce sus problemas de negocio en opciones técnicas, y siempre adjunta tu respuesta recomendada (-> Rekomendasi: ...) para que solo necesiten reaccionar en lugar de pensar desde cero.
3. Las 3 Preguntas de Oro para Ideas Vagas / Tempranas: Cuando un usuario presente una idea breve de una oración (ej. "mau bikin SaaS seperti Notion untuk resep masakan"), ancla la frontera en torno a tres pilares centrados en el ser humano antes de discutir pilas tecnológicas:
   • Persona Objetivo y Contexto: ¿Quién lo usa, dónde y en qué situación?
   • El Viaje del Usuario Estrella del Norte: ¿Cuál es el flujo de acción más importante de principio a fin que debe tener éxito en esta aplicación?
   • Alcance del MVP: ¿Qué funciones son absolutamente necesarias el primer día, y qué se pospone deliberadamente para la siguiente etapa?

---

Fase 0: Puerta de Alcance

La mayoría de las solicitudes describen una capacidad. Si esta lo hace, dilo en una línea y pasa a la Fase 1. Esta fase existe para la excepción.

Detección. Descompón antes de escribir cualquier cosa cuando una sola solicitud agrupa varias capacidades comprobables de forma independiente:

• La solicitud nombra capacidades distintas con sus propios consumidores o datos (identidad, facturación, notificaciones, informes)
• Los criterios de aceptación se agrupan en conjuntos que podrían entregarse y verificarse por separado
• Una capacidad podría eliminarse o reemplazarse sin reescribir los requisitos de las demás

Cuando se detecte, propón un mapa de capacidades antes de cualquier ronda de entrevista. Pequeño y revisable — una tabla de módulos más un orden de construcción, no un plan de proyecto:

# Mapa de Capacidades: [Nombre de la iniciativa]

| Id del módulo | Responsabilidad | Depende de |
|---|---|---|
| identity | Cuentas, sesiones, SSO | - |
| billing | Planes, facturas, pagos | identity |
| notifications | Distribución de correo electrónico y webhook | identity |
| reporting | Paneles de uso | billing, notifications |

Orden de construcción: identity -> billing, notifications -> reporting

Reglas para el mapa:

• Id de módulo estable. En kebab-case, elegido una vez, nunca renombrado. La planificación descendente selecciona el trabajo por estos ids.
• Dirección de dependencia, sin ciclos. Las flechas apuntan en una dirección. Si dos módulos necesitan el uno del otro, son un solo módulo.
• Las interfaces viven en el límite. El mapa registra que billing depende de identity; el contrato entre ellos pertenece al PRD del módulo proveedor.

El mapa está sujeto a aprobación. Pide al usuario que apruebe los límites de los módulos, la dirección de las dependencias y el orden de construcción antes de entrevistar para cualquier módulo individual. Equivocarse en el mapa es costoso; revisar diez líneas no lo es.

Luego ejecuta las Fases 1-7 una vez por módulo, en orden de construcción, produciendo cada una su propio docs/prd/<id-del-módulo>.md. No escribas un PRD monolítico para una iniciativa de múltiples módulos.

Condición de salida: o la solicitud es de una sola capacidad (dilo explícitamente), o se aprueba un mapa de capacidades.

---

Fase 1: Semilla de Hipótesis

Antes de preguntar nada, escribe tu interpretación actual de la solicitud y un número de confianza honesto.

HIPÓTESIS: Quieres una forma de responder "¿cómo vamos?" en la daily, y "dashboard" fue la convención que vino a la mente.
CONFIANZA: ~30% - falta: para quién es, qué significa "métricas" aquí y cómo se ve el éxito

Reglas:

• Una oración para la hipótesis. Si no puedes escribirla en una oración, aún no tienes una interpretación.
• El número de confianza es un porcentaje de 0 a 100. Obliga a la honestidad: si no puedes predecir la reacción del usuario a las siguientes tres preguntas que harías, el número está mal.
• Por debajo de ~70%, agrega una razón breve en la misma línea nombrando lo que aún no está resuelto. Esto le dice al usuario exactamente lo que la entrevista necesita sacar a la luz.
• Actualiza la hipótesis y la confianza después de cada ronda.

Condición de salida: una hipótesis con un número de confianza está registrada.

---

Fase 2: Construir el Árbol de Decisiones

Mapea el espacio de decisiones antes de preguntar nada. Cada decisión se ramifica en las decisiones que dependen de ella.

Objetivo: rastreador personal de experimentos
    |
    +-- ¿Qué cuenta como experimento?        (define la unidad)
    |       |
    |       +-- ¿Qué campos describen uno?    (define el esquema)
    |
    +-- ¿De dónde vienen los datos?           (fuente de entrada)
    |       |
    |       +-- ¿Entrada manual o importación? (modelo de interacción)
    |
    +-- ¿Cuándo está "terminado" un experimento? (ciclo de vida)
            |
            +-- ¿Qué señal lo finaliza?         (definición de éxito)

La frontera es cada decisión cuyos prerrequisitos ya están resueltos: las preguntas que puedes hacer ahora sin adivinar respuestas que aún no has escuchado.

Dos reglas que hacen que esto funcione:

1. Pregunta toda la frontera en una ronda. No hagas una pregunta por turno cuando varias son independientes. Las preguntas independientes se responden más rápido juntas, y el usuario ve la forma del espacio de decisiones.
2. Una pregunta cuya respuesta depende de otra pregunta abierta pertenece a una ronda posterior. Preguntarla ahora fija el marco incorrecto.

Los hechos son tu trabajo, nunca del usuario. Cuando una pregunta de la frontera necesita un hecho del entorno (sistema de archivos, código existente, API de una biblioteca, valor de configuración), envía un subagente para encontrarlo. No le preguntes al usuario nada que puedas buscar tú mismo. No bloquees la ronda por ello: la exploración es un prerrequisito no resuelto, por lo que solo las preguntas posteriores esperan. Pregunta el resto de la frontera ahora. Las decisiones son del usuario; los hechos son tuyos.

Condición de salida: el árbol está mapeado y la primera frontera está identificada.

---

Fase 3: Preguntas por Rondas

Pregunta la frontera actual. Formatea cada pregunta exactamente así:

**P1 - <título de la pregunta>**: <cuerpo de la pregunta, posiblemente varios párrafos, a menudo con las opciones candidatas presentadas>

-> <tu respuesta recomendada, con el razonamiento que la produjo>

Reglas:

• Numera cada pregunta. P1, P2, ... Reinicia la numeración por ronda.
• Adjunta siempre una recomendación. El usuario reacciona más rápido a una recomendación incorrecta de lo que genera una respuesta desde cero. También te compromete a una hipótesis sobre la que puedes estar visiblemente equivocado.
• Espera las respuestas antes de hacer la siguiente ronda.
• Recalcula la frontera después de cada ronda. Las decisiones resueltas empujan la frontera hacia afuera y desbloquean preguntas que dependían de ellas.
• Anota las correcciones. Cuando el usuario anule una recomendación, registra tanto la decisión como el razonamiento, porque la sección de "Decisiones Técnicas" del PRD se basa en ello.

Por qué importa la recomendación, y su modo de fallo:

• El usuario puede reaccionar a una suposición incorrecta en segundos, pero puede tardar minutos en producir una respuesta desde la nada.
• Saca a la luz tus suposiciones, que es el objetivo de la entrevista.
• El riesgo es el sycophancy — un usuario cortés que acepta tu suposición para ser complaciente. Mitígalo mostrándote visiblemente dispuesto a equivocarte, y ocasionalmente recomienda una dirección que esperes que el usuario rechace. Si cada recomendación se acepta al primer intento, sospecha sycophancy.

Por qué una ronda a la vez, no todo a la vez:

• La tercera pregunta a menudo depende de la respuesta a la primera; preguntar todo a la vez fija el marco incorrecto.
• La energía del usuario para pensar cuidadosamente es finita. Gárala ronda por ronda.
• Un lote de quince preguntas se lee como una encuesta, no una entrevista, y se hojea.

Condición de salida: las preguntas de la ronda están respondidas y la frontera se recalcula.

---

Fase 4: Sonda de Intención (querer vs. deber-querer)

Las respuestas más peligrosas son aquellas en las que el usuario dice lo que suena a una respuesta reflexiva en lugar de lo que realmente quiere. Estate atento a:

• Respuestas que se ajustan a un patrón de mejores prácticas ("Quiero que sea escalable", "arquitectura limpia") sin detalles específicos
• Respuestas que se remiten a la convención ("como lo hacen la mayoría de las aplicaciones", "el enfoque estándar")
• Frases como "Probablemente debería...", "Creo que se supone que...", "las buenas prácticas de ingeniería dicen que..."
• Palabras de moda como objetivos — cuando "moderno", "escalable" o "robusto" es la respuesta en lugar de un resultado específico

Cuando escuches cualquiera de estas, pregunta:

"Si no tuvieras que justificar esto ante nadie, ¿qué es lo que realmente querrías?"

Esa sola pregunta a menudo hace más trabajo que las cinco anteriores. Ejecútala al menos una vez cada vez que aparezca una respuesta que señale sofisticación. Registra tanto la respuesta declarada como la respuesta sondeada — el PRD debe reflejar la segunda.

Condición de salida: al menos una sonda se ejecutó si apareció alguna respuesta que señale sofisticación, y la respuesta real está registrada.

---

Fase 5: Reformular la Intención

Cuando el árbol esté casi resuelto, escribe de vuelta lo que ahora crees que el usuario quiere. Mantenlo conciso, usa su lenguaje, y estructúralo para que puedan confirmar o corregir línea por línea.

Esto es lo que ahora creo que quieres:

- Resultado:      <una línea>
- Usuario:        <una línea - quién se beneficia>
- Por qué ahora:  <una línea - qué cambió>
- Éxito:          <una línea - cómo sabemos que funcionó>
- Restricción:    <una línea - el límite vinculante>
- Fuera de alcance: <una línea - lo que explícitamente no estamos haciendo>

¿Sí / no / refinar?

Reglas:

• "Fuera de alcance" no es negociable. La mitad de la desalineación es un desacuerdo silencioso sobre lo que no se está construyendo.
• De cinco a ocho líneas en total. Si se alarga más, la entrevista no ha terminado.
• Usa las palabras del usuario cuando sea posible; su vocabulario es el contrato compartido.

Condición de salida: una reformulación concreta en las palabras del usuario está registrada.

---

La Condición de Parada

Has terminado de entrevistar cuando ambas condiciones sean ciertas:

1. ¿Puedes predecir la reacción del usuario a las siguientes tres preguntas que harías? Si es así, tienes un entendimiento compartido.
2. ¿La frontera está vacía? Si no, aún hay decisiones que el usuario debe tomar y no puede delegar a la redacción.

Cuando ambas se cumplan, pasa a la Fase 6.

---

Fase 6: Verificación de Vacíos

Antes de escribir el PRD, haz un inventario de lo que toda especificación necesita que la entrevista aún no haya producido explícitamente:

• Restricciones no funcionales: latencia, concurrencia, volumen de datos, almacenamiento, cumplimiento, accesibilidad, idiomas
• Dependencias externas: servicios de terceros, APIs, bibliotecas, costos de licencia
• Entidades de datos centrales: esquemas, relaciones, reglas de validación que aún no se mencionaron
• Suposiciones: cualquier cosa que estés asumiendo en lugar de haberla confirmado

Para cada vacío, decide:

• Preguntar ahora — si afecta decisiones de diseño posteriores o la corrección del PRD
• Anotarlo como suposición — si es menor o puede resolverse más tarde en la implementación. Cuando anotes una suposición, márcala en el PRD con [SUPOSICIÓN: ...] para que el usuario pueda cuestionarla durante la aprobación.

Condición de salida: los vacíos conocidos están preguntados o marcados como suposiciones.

---

Fase 7: Escribir y Aprobar

Escribe el PRD. Una estructura mínima:

# PRD: [Nombre del producto / sistema]

## Resumen
[Contexto y motivación, la reformulación de la Fase 5]

## Usuarios
[Personas principales y sus objetivos]

## Requisitos Funcionales
[Ordenados por agrupaciones lógicas (ej. auth, dashboard, notificaciones)]

## Restricciones No Funcionales
[Latencia, seguridad, escalabilidad, disponibilidad, etc.]

## Modelo de Datos (esquemas centrales)
[Si la entrevista produjo entidades y relaciones]

## Decisiones Técnicas
[Decisiones registradas con justificación, incluyendo alternativas consideradas]

## Límites / Fuera de Alcance
[Lo que explícitamente no estamos construyendo en esta iteración]

## Criterios de Éxito
[Indicadores medibles de éxito, no solo requisitos funcionales]

Reglas:

• Guarda el archivo en docs/PRD.md para sistemas de una sola capacidad, o docs/prd/<id-del-módulo>.md para iniciativas multi-módulo.
• Incluye la reformulación de la Fase 5 tal cual.
• Marca cualquier suposición con [SUPOSICIÓN: ...].
• Después de escribir, pide una aprobación explícita:

"He escrito el PRD basado en nuestra entrevista. ¿Puedo considerar esto aprobado o hay algo que modificar?"

Condición de salida: el usuario ha dicho "sí", "aprobado", "listo" u otra afirmación explícita. No asumas aprobación por silencio.

---

Notas Finales

• Esta habilidad está diseñada para una sola capacidad. Usa el mapa de capacidades de la Fase 0 para cualquier cosa que sea más grande que una capacidad.
• El PRD es un punto de partida, no un testamento. Debe evolucionar a medida que el equipo aprende durante la implementación, capturando cambios y sus justificaciones.
• Prioriza la velocidad sobre la perfección. Una especificación del 80% con suposiciones explícitas es mejor que una especificación del 100% nunca publicada. Confía en la capacidad del equipo para navegar los vacíos durante la implementación.
• El tono importa. El usuario no debería sentirse interrogado. Debería sentirse como si un colega reflexivo estuviera ayudándole a aclarar sus pensamientos antes de construir.