DotMDUna plantilla de PRD en Markdown:cópiala y rellénala.
Un documento de requisitos de producto es más fácil de mantener en un archivo .md junto al código. Esta plantilla es corta, usa requisitos numerados y criterios de aceptación comprobables, y está escrita para que un agente de IA pueda construir a partir de ella.
macOS 14 o posterior. Leer es gratis; editar y revisar se pagan una sola vez.
Respuesta rápida
Un buen PRD expone el problema, los objetivos y lo que queda fuera de alcance, y después lista requisitos numerados con criterios de aceptación que se puedan comprobar. Guárdalo como prd.md o docs/prd/feature-name.md, copia la plantilla de abajo y rellena cada sección con frases sencillas.
# PRD: <Feature name>
## 1. Problem
## 2. Goals
## 3. Non-goals
## 5. Requirements
## 6. Acceptance criteria·
La plantilla
Cópiala en un archivo nuevo y sustituye todo lo que está entre ángulos. Elimina una sección solo si estás seguro de que no aplica, y escribe «none» en lugar de dejarla vacía, para que el lector sepa que se tuvo en cuenta.
# PRD: <Feature name>
Status: Draft | In review | Approved
Owner: <name>
Last updated: <date>
## 1. Problem
Who has the problem, what it is, and what it costs them today.
One short paragraph. No solution here.
## 2. Goals
- <Outcome 1, measurable>
- <Outcome 2, measurable>
## 3. Non-goals
Things this work will NOT do, so nobody builds them by accident.
- <Not in scope 1>
- <Not in scope 2>
## 4. Users and scenarios
- As a <role>, I want <action>, so that <benefit>.
- As a <role>, I want <action>, so that <benefit>.
## 5. Requirements
Number each one so it can be referenced in plans and tests.
- R1. The system must <behavior>.
- R2. The system must <behavior>.
- R3. The system should <optional behavior>.
## 6. Acceptance criteria
- [ ] R1: Given <state>, when <action>, then <result>.
- [ ] R2: Given <state>, when <action>, then <result>.
## 7. Edge cases and errors
- <Empty state>
- <Invalid input>
- <Network or permission failure>
## 8. Data and interfaces
- Data stored or changed: <fields, formats, migrations>
- APIs or screens affected: <names>
## 9. Success metrics
- <Metric>: from <baseline> to <target> by <date>.
## 10. Rollout and rollback
- Release plan: <flag, staged, all at once>
- How to turn it off if it goes wrong: <step>
## 11. Open questions
- [ ] <Question> (owner: <name>)
## 12. Context for the agent
Files to read first: <paths>. Constraints: <stack, style, limits>.Por qué está escrita así
Un PRD para un agente de IA hace el mismo trabajo que uno para una persona, con menos margen para adivinar. Una persona te pregunta en el pasillo qué querías decir. Un agente rellena el hueco con su mejor suposición y sigue adelante.
- Lo que queda fuera de alcance es la protección más barata contra el crecimiento del alcance. Los agentes añaden extras «útiles» si no se les dice que no lo hagan.
- Los requisitos numerados (R1, R2) permiten que un plan, una prueba y un comentario de revisión apunten a lo mismo.
- Los criterios de aceptación como casillas de lista de tareas se convierten en una lista de pendientes que se puede ir marcando. Consulta las listas de tareas en Markdown para la sintaxis.
- Los casos límite son donde el código generado falla primero: datos vacíos, entrada incorrecta, una conexión perdida.
- La marcha atrás te obliga a pensar cómo deshacer el cambio antes de publicarlo.
Cómo rellenarla
-
Escribe el problema sin la solución
Si no puedes describir el problema sin nombrar una función, la función es una suposición. Di a quién afecta y qué pasa hoy.
-
Haz que cada objetivo sea medible
«Un pago más rápido» es un deseo. «Pago mediano en menos de 30 segundos» es un objetivo.
-
Escribe los requisitos como comportamiento
«El sistema debe mostrar un error cuando el archivo pese más de 10 MB» se puede probar. «Buena gestión de errores» no.
-
Empareja cada requisito con un criterio
Usa Given, when, then. Si no puedes escribir la comprobación, el requisito es vago.
-
Termina con las preguntas abiertas
Nombra al responsable de cada una. Un agente debe preguntarlas, no decidirlas.
Los diagramas ayudan con los flujos y los estados; un bloque Mermaid en el archivo es fácil de cambiar. Consulta la sintaxis de los diagramas de flujo de Mermaid.
Entregar el PRD a un agente de IA
Señala el archivo al agente en lugar de pegarlo: «Lee docs/prd/export.md y propón un plan; no escribas código todavía». Pide primero un plan, compruébalo con los requisitos numerados y deja que construya. Un PRD, un plan y una lista de tareas suelen ser tres archivos distintos. El PRD dice qué y por qué, el plan dice cómo y las tareas son los pasos.
Deja las reglas de todo el proyecto (comandos, estilo, carpetas) fuera del PRD y en CLAUDE.md o AGENTS.md, para que el PRD contenga solo lo propio de esta función.
Errores habituales
- Una solución disfrazada de problema. «Necesitamos un desplegable» no es un problema.
- Sin lo que queda fuera de alcance. Todo lo cercano pasa a formar parte del alcance.
- Requisitos que no pueden fallar. Si ninguna prueba podría fallarlo, no dice nada.
- Un PRD que nadie vuelve a leer. Actualiza el estado y las preguntas abiertas sobre la marcha.
- Diez páginas para un cambio pequeño. Una función de un día necesita media página.
Los responsables de producto pueden leer y revisar los PRD en DotMD como documentos renderizados, con comentarios sobre el pasaje exacto. Leer es gratis; consulta los precios para editar y revisar.
Preguntas sobre las plantillas de PRD en Markdown
¿Qué lleva una plantilla de PRD?
El problema, los objetivos, lo que queda fuera de alcance, los escenarios de usuario, los requisitos numerados, los criterios de aceptación, los casos límite, los datos e interfaces, las métricas de éxito, el despliegue y la marcha atrás, y las preguntas abiertas.
¿Por qué escribir un PRD en Markdown?
Un archivo Markdown vive junto al código, tiene un historial legible en Git, es fácil de leer para un agente de IA y se puede revisar y cambiar como cualquier otro archivo.
¿Cómo debería llamar al archivo?
prd.md para un solo producto, o docs/prd/feature-name.md cuando hay varios. Un archivo por función.
¿En qué se diferencia un PRD de una spec?
Un PRD dice qué construir y por qué, desde el punto de vista del usuario. Una spec o un plan dice cómo se construirá. Manténlos separados para que cada uno se pueda revisar por su cuenta.