to-prd

Resumen de to-prd

Qué hace to-prd

El skill to-prd convierte el contexto actual de la conversación y la comprensión del codebase en un PRD, y luego lo publica en el tracker de issues del proyecto. Está pensado para situaciones en las que ya tienes suficiente contexto para redactar y quieres un brief de producto estructurado, no una entrevista de descubrimiento ida y vuelta.

Para quién encaja mejor

Usa el skill to-prd cuando trabajas dentro de un repo existente, ya conoces de forma general el cambio y necesitas un PRD que respete la terminología del proyecto, los ADRs y el flujo del tracker. Es especialmente útil en flujos de Skill Authoring o de implementación dirigida por agentes, donde el siguiente paso es pasarle el trabajo a otro agente.

Qué lo hace distinto

El principal diferenciador de to-prd es su enfoque de “no entrevistar”: sintetiza a partir de lo que ya se sabe y luego envía el resultado al tracker con la etiqueta de triage correcta. Eso lo hace más rápido que un prompt genérico, pero también más dependiente de que el contexto del repo y la configuración del tracker estén disponibles desde el principio.

Cómo usar el skill to-prd

Instalación y contexto esperado

Para to-prd install, usa el instalador de skills del proyecto y después confirma que el repo está conectado al flujo de issue tracker que quieres usar. El skill asume que el issue tracker y el vocabulario de etiquetas de triage ya están disponibles; si no, ejecuta primero /setup-matt-pocock-skills. Si omites esa configuración, el skill puede generar un borrador de PRD, pero fallar al publicarlo correctamente.

Cómo pedir el uso de to-prd

El mejor to-prd usage empieza con un objetivo de implementación claro, una ruta de repo o área de funcionalidad y cualquier restricción que ya conozcas. Un buen input sería: “Crea un PRD para añadir manejo de refresh de OAuth en apps/web, usando el glosario del repo y los ADRs existentes, y publícalo en el tracker”. Un input débil es solo una meta vaga como “escribe un PRD para auth”, porque el skill está diseñado para sintetizar, no para entrevistar.

Archivos y señales que revisar primero

Antes de confiar en el resultado, revisa SKILL.md, después README.md, AGENTS.md, metadata.json del repo y cualquier carpeta rules/, resources/, references/ o scripts/ si existen. En este repositorio, SKILL.md es la fuente principal, así que el flujo es deliberadamente ligero; eso también significa que la calidad del PRD depende mucho del contexto vivo del codebase que aportes.

Flujo práctico para obtener mejores resultados

Usa el skill cuando ya puedas describir el cambio en términos de producto y deja que lo convierta en un PRD con problema, solución y user stories. Pídele que respete el vocabulario del glosario del dominio y los ADRs, y sé explícito sobre qué módulos podrían cambiar y dónde importa la cobertura de tests. Si estás usando to-prd for Skill Authoring, mantén el prompt acotado al comportamiento del skill que quieres documentar, no a todo el repositorio upstream.

Preguntas frecuentes sobre el skill to-prd

¿to-prd encaja en cualquier tarea de PRD?

No. El skill to-prd funciona mejor cuando el cambio ya está entendido lo suficiente como para redactarlo desde contexto. Si necesitas discovery, entrevistas de producto o investigación de mercado, un flujo de prompting normal encaja mejor que to-prd.

¿En qué se diferencia to-prd de un prompt genérico?

Un prompt genérico puede pedir un PRD, pero to-prd añade comportamiento consciente del repo: busca términos del glosario, respeta los ADRs, esquematiza módulos profundos y publica en el issue tracker con la etiqueta ready-for-agent. Eso lo hace más operativo que una petición de PRD abierta.

¿Pueden usarlo personas principiantes?

Sí, si pueden aportar una dirección concreta de funcionalidad y entienden que el skill no hace preguntas de seguimiento. Las personas principiantes obtienen mejores resultados cuando incluyen el área del repo, el problema del usuario y cualquier restricción no negociable en la solicitud inicial.

¿Cuándo no debería usar to-prd?

No uses to-prd cuando el tracker no esté disponible, no conozcas el vocabulario de etiquetas o la funcionalidad siga en exploración. Tampoco es buena opción cuando necesitas entrevistas iterativas con stakeholders antes de redactar el PRD.

Cómo mejorar el skill to-prd

Dale al skill una entrada más precisa

La mayor palanca de calidad es la especificidad. Incluye la ubicación en el repo, el problema que hay que resolver, el resultado esperado para el usuario y cualquier restricción como plataforma, rendimiento o límites de despliegue. Un input más sólido ayuda a to-prd a producir un PRD más cercano a la realidad de implementación y menos genérico.

Indica expectativas sobre módulos y tests

El skill busca explícitamente módulos profundos y pregunta qué módulos deberían tener tests. Si quieres una mejor salida, nombra módulos candidatos, di cuáles deberían mantenerse superficiales y señala cualquier lógica aislada que convenga extraer. Esto reduce la fricción en el handoff y hace que el PRD sea más accionable para el siguiente agente.

Vigila los fallos más comunes

El fallo principal es un contexto poco específico: el PRD acaba siendo texto amplio, listo para el tracker, pero no un plan que ayude a tomar decisiones. Otro riesgo es usar terminología desactualizada si el glosario del repo o los ADRs no están al día. Para corregir ambos, ancla el prompt en el estado actual del codebase y actualiza el brief antes de pedir la publicación.

Itera a partir del primer borrador

Después del primer PRD, afínalo ajustando las user stories, aclarando los límites de aceptación y comprobando que la etiqueta del issue y el destino del tracker sean correctos. En to-prd, iterar suele consistir en eliminar ambigüedad, no en ampliar el alcance.