Plantilla de PRD en Markdown para programar con IA

Un documento de requisitos de producto (PRD, product requirements document) es la prosa que enuncia el problema y el alcance antes de partir el trabajo en tareas. Una especificación de funcionalidad es el archivo de SpecScore para una capacidad del producto: qué hace, por qué existe y cómo se comporta. Markdown es el formato de texto plano de ese archivo. El desarrollo basado en especificaciones (SDD, spec-driven development) es la práctica de escribir la especificación antes del código y tratar la especificación como la fuente de verdad. En SpecScore, un requisito (REQ) es una regla con nombre dentro de una funcionalidad, un criterio de aceptación (AC, acceptance criterion) es una condición abstracta y opcional que apunta a una o más de esas reglas, y un escenario es un ejemplo concreto escrito en pasos Given, When y Then. Un plan es el documento que parte la funcionalidad en tareas, y una tarea es una unidad de trabajo que una persona o un agente puede terminar. La integración continua (CI, continuous integration) es una comprobación automática en cada cambio propuesto. La comprobación es un comando de la interfaz de línea de comandos (CLI, command-line interface), specscore spec lint, de la CLI en specscore/specscore-cli. Easy Approach to Requirements Syntax (EARS) es un patrón de frase que un requisito puede usar. Claude Code es el agente de programación con IA para el que está escrito el complemento CLI Skills de este sitio. Esta plantilla de especificación de funcionalidad es ese archivo, más el plan y la tarea que apuntan de vuelta a él.

Última actualización: 5 de noviembre de 2026

Qué es esta plantilla de especificación

Un PRD suele ser un archivo de prosa que una persona lee. SpecScore guarda el mismo encargo en archivos que un linter puede comprobar. La especificación de funcionalidad llama funcionalidad a la unidad atómica de especificación de producto: un directorio bajo spec/features/ cuyo README.md es la única fuente de verdad de lo que hace la funcionalidad. La especificación de plan llama plan al documento que descompone esa funcionalidad en tareas. Un escenario, en la especificación de escenario, es un archivo concreto Given/When/Then en el directorio _tests/ de la funcionalidad. La especificación de criterios de aceptación mantiene el criterio abstracto: dice qué debe ser cierto, y el escenario dice cómo probarlo.

El archivo de checkout de abajo es la plantilla rellena. Junto con el índice de funcionalidades, un README de la especificación y specscore.yaml, specscore spec lint lo aceptó con 0 violaciones. Esa comprobación se ejecutó el 2 de noviembre de 2026 con specscore 0.55.1 y con 0.39.1, la etiqueta que instala dogfood.yml. La línea de la barra de SpecScore Studio en el archivo es la línea que llevan los README de funcionalidad en specscore/specscore. La tabla de secciones obligatorias de la especificación de funcionalidad no la incluye.

El README de la funcionalidad

La tabla de secciones obligatorias dice que todo README de funcionalidad tiene un título # Feature: {Title}, una línea **Status:** justo después del título, un Summary, un Problem, una sección Behavior, una sección Acceptance Criteria, una sección Open Questions y un pie de adhesión. El estado es uno de Draft, In Review, Approved, Implementing, Stable, Amending, Rejected o Deprecated. Contents solo es obligatorio cuando la funcionalidad tiene directorios hijos. **Source Ideas:** es opcional. El archivo comprobado lo deja en —.

Open Questions no se omite nunca. Si no hay ninguna, la sección dice None at this time. Acceptance Criteria tampoco se omite. Si no hay criterios, esa sección dice Not defined yet. y Open Questions debe incluir entonces Acceptance criteria not yet defined for this feature. El pie es la última línea y su URL es https://specscore.md/feature-specification.

La convención de frontmatter de artefactos dice que todo artefacto lleva una clave format: en el frontmatter YAML, y un artefacto con estado lleva además status:, espejo del **Status:** del cuerpo. La misma especificación dice que las reglas de lint que lo exigen salen tras un periodo de gracia. El archivo comprobado incluye ambas claves. Esta página no afirma que el pin v0.39.1 rechace un archivo que las omita.

README de funcionalidad que specscore spec lint aceptó (2 de noviembre de 2026)

---
format: https://specscore.md/feature-specification
status: Draft
---

# Feature: Checkout validation

> [SpecScore.**Studio**](https://specscore.studio): | [Explore](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=explore) | [Edit](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=edit) | [Ask question](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=ask) | [Request change](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=request-change) |

**Status:** Draft
**Source Ideas:** —

## Summary

The checkout form shows a validation error next to a field when the shopper submits invalid data, and it rejects an email that is not a valid address.

## Problem

A vague sentence such as "the form should handle bad input" does not say which event causes which response. Checkout needs those obligations written so a reviewer and a linter can point at them.

## Behavior

### Field validation

The checkout system checks the form when the shopper submits it.

#### REQ: show-field-error

When a shopper submits the checkout form with invalid data, the checkout system MUST show a validation error next to the invalid field.

#### REQ: reject-invalid-email

If the submitted email is not a valid address, then the checkout system MUST reject the form.

## Acceptance Criteria

### AC: invalid-submission

**Requirements:** checkout#req:show-field-error, checkout#req:reject-invalid-email

Submitting the checkout form with invalid data shows a validation error next to the invalid field, and an email that is not a valid address is rejected.

## Open Questions

None at this time.

---
*This document follows the https://specscore.md/feature-specification*

Índice de funcionalidades de la misma ejecución

---
format: https://specscore.md/features-index-specification
---

# Features

| Feature | Status | Description |
|---|---|---|
| [Checkout validation](checkout/README.md) | Draft | The checkout form shows a validation error next to a field when the shopper submits invalid data, and it rejects an email that is not a valid address. |

## Open Questions

None at this time.

---
*This document follows the https://specscore.md/features-index-specification*

README de la especificación de la misma ejecución

# Checkout specification

## Open Questions

None at this time.

specscore.yaml de la misma ejecución

# SpecScore Repo Config Schema: https://specscore.md/repo-config

project:
  title: Checkout sample
  host: github.com
  org: example
  repo: checkout

El identificador de la funcionalidad es la ruta del directorio relativa a spec/features/. El enlace del índice checkout/README.md significa que el archivo vive en spec/features/checkout/README.md, así que el id que usan requisitos y criterios es checkout. El índice lista cada funcionalidad de primer nivel. Un directorio hijo que no está listado es una violación de index-entries, que describe lintear especificaciones en CI. El README de la especificación de ese árbol tiene una sección, Open Questions, y dice None at this time. El archivo de configuración es lo que la CLI busca hacia arriba. Sin specscore.yaml el comando termina con 3 y nombra specscore init.

Identificadores REQ, criterios de aceptación y escenarios

La especificación de requisito coloca cada regla bajo un encabezado de tema dentro de ## Behavior. El encabezado es #### REQ: {slug}, con un espacio tras los dos puntos. El slug usa letras minúsculas, números y guiones. El id canónico es {feature-path}#req:{slug}. En el archivo de checkout eso es checkout#req:show-field-error y checkout#req:reject-invalid-email. Un requisito enuncia una sola obligación. La especificación dice que los requisitos SHOULD usar las palabras clave RFC 2119 MUST, MUST NOT, SHOULD, SHOULD NOT y MAY. Un encabezado REQ: no es válido fuera de ## Behavior. Una frase EARS puede ser esa prosa. El linter no puntúa el inglés. Los patrones están en la sintaxis de requisitos EARS.

Criterio de aceptación

La especificación de criterios de aceptación dice que cada criterio es un encabezado ### AC: {slug} dentro de ## Acceptance Criteria, luego una línea **Requirements:** que lista valores {feature-id}#req:{slug}, y después un enunciado abstracto de lo que debe ser cierto. Los criterios son opcionales. La especificación dice añadir uno cuando agrupar dos o más requisitos relacionados aporta claridad. El archivo de checkout agrupa ambas reglas en checkout#ac:invalid-submission. El enunciado no contiene Given, When ni Then. Cómo escribir criterios de aceptación es la guía de redacción. La regla ac-heading-format (ac_heading.go en la etiqueta v0.55.1 de la CLI) comprueba que el encabezado sea ### AC: <id> con un id en kebab-case. El artículo sobre lint registra que esta regla no exige la línea **Requirements:** y no puntúa las palabras. La especificación de criterios de aceptación sí exige esa línea.

Escenario

La especificación de escenario coloca un escenario en _tests/, que no es una subfuncionalidad y queda fuera del índice. El archivo empieza con # Scenario: {Title}, una línea **Validates:** que apunta a un requisito o a un criterio, y una sección ## Steps cuyas palabras clave van en mayúsculas: GIVEN, WHEN, THEN y AND. Todo directorio _tests/ debe contener un README con un índice de escenarios. La muestra de abajo es esa forma de archivo. No formó parte de la ejecución del 2 de noviembre. specscore spec lint no comprueba las palabras clave de los pasos. specscore rehearse ejecuta los archivos de escenario. Rehearse es ese ejecutor. El workflow dogfood ejecuta el linter y no llama a rehearse.

Forma de archivo de escenario, según la especificación de escenario

# Scenario: Reject an invalid email

**Validates:** [checkout#ac:invalid-email-rejected](../README.md#ac-invalid-email-rejected)

## Steps

GIVEN the shopper is on the checkout form
WHEN the shopper submits the email "not-an-email"
THEN the page shows "Enter a valid email address" beside the email field
AND the order is not placed

Lee las tres capas en orden. El requisito dice la regla. El criterio de aceptación dice qué debe ser cierto para las reglas que nombra. El escenario da un flujo concreto. Un agente que solo ve la prosa del PRD tiene que inventar ese corte. La plantilla ya lo trae.

Planes y tareas

Un README de plan vive en spec/plans/{plan-slug}/README.md. La especificación de plan exige el título # Plan: {Title} y los campos de cabecera Status, exactamente una línea de origen, Date, Owner y Supersedes. Un plan con origen en una funcionalidad usa **Source Feature:** más el slug, aquí checkout. Las otras líneas de origen válidas son **Source:** idea:{slug} y **Source:** none. Las secciones obligatorias son Summary, Approach, Tasks y Open Questions. Dentro del plan, cada tarea es un encabezado ### Task N: con una línea **Verifies:** de la forma feature-slug#ac:ac-slug. La regla P-001 en plan_rules.go informa un encabezado de criterio que ninguna tarea cubre y que no está bajo ## Deferred AC Coverage. La regla P-002 informa un valor **Verifies:** que no resuelve. Los planes con origen en una idea y los planes con **Source:** none están exentos de P-001.

El plan de abajo sigue esa forma publicada para la funcionalidad checkout, incluido el frontmatter format: y status:. No estuvo en la ejecución del 2 de noviembre. Una funcionalidad que un plan toca debe incluir una tabla ## Plans con columnas Plan, Status, Author y Approved. El archivo comprobado no tiene sección Plans porque ese árbol no tiene plan.

La especificación de tarea define además una tarea como su propio directorio y README.md bajo el plan. El título es # Task: {Title}. Los campos obligatorios son **Status:**, **Depends on:** (el literal none si no hay dependencia) y **Model:** (small, medium, large o inherit). Un directorio que contiene directorios de tareas hijas es un plan, no una tarea. El archivo de tarea de abajo usa esos campos para la primera tarea de checkout. No estuvo en la ejecución del 2 de noviembre. La URL del pie de un documento de tarea es https://specscore.md/task-specification.

Forma de plan de la especificación de plan, rellena para checkout

---
format: https://specscore.md/plan-specification
status: Draft
---

# Plan: Show checkout validation errors

**Status:** Draft
**Source Feature:** checkout
**Date:** 2026-11-05
**Owner:** @example
**Supersedes:** —

## Summary

This plan decomposes the checkout feature into the work that shows a field error and rejects an email that is not a valid address.

## Approach

Both tasks verify the same acceptance criterion, which bundles the two requirements. Nothing is deferred, so this plan has no Deferred AC Coverage section.

## Tasks

### Task 1: Show a validation error beside the invalid field

**Verifies:** checkout#ac:invalid-submission

When the shopper submits the checkout form with invalid data, show a validation error next to the invalid field.

### Task 2: Reject an email that is not a valid address

**Verifies:** checkout#ac:invalid-submission

If the submitted email is not a valid address, reject the form.

## Open Questions

None at this time.

---
*This document follows the https://specscore.md/plan-specification*

Forma de documento de tarea de la especificación de tarea

---
format: https://specscore.md/task-specification
status: queued
---

# Task: Show a validation error beside the invalid field

**Status:** queued
**Depends on:** none
**Model:** medium

## Acceptance Criteria

- Submitting the checkout form with invalid data shows a validation error next to the invalid field.

## Open Questions

None at this time.

---
*This document follows the https://specscore.md/task-specification*

El archivo de funcionalidad responde qué debe hacer el formulario de checkout. El plan responde cómo se parte ese trabajo, y cada tarea en línea nombra el criterio que verifica. El documento de tarea es la hoja que recoge una persona o un agente. Mantén estable el id del criterio. checkout#ac:invalid-submission es la cadena que usan tanto la funcionalidad como el plan.

Lintear la plantilla en CI

specscore spec lint valida el árbol de especificación frente a violaciones de convención estructural. Una ejecución limpia imprime 0 violations found y termina con 0. Una ejecución con violaciones imprime una línea por hallazgo y termina con 1. Ese código de salida hace fallar un job de CI. Los argumentos inválidos terminan con 2. Un specscore.yaml ausente termina con 3. dogfood.yml instala la CLI con SPECSCORE_VERSION en v0.39.1 y luego ejecuta specscore spec lint en pull requests y en pushes a main. El extracto del workflow, el informe de fallo y el catálogo de reglas están en lintear especificaciones en CI.

La licencia del formato es CC BY 4.0 en specscore/specscore. La licencia de la CLI es Apache-2.0 en specscore/specscore-cli.

Otras herramientas de desarrollo basado en especificaciones publican comprobaciones distintas. Las frases de abajo usan solo lo que dicen las páginas de esos proyectos. La comparativa de herramientas registra esas páginas como leídas el 30 de octubre de 2026, salvo la portada de la documentación de Spec Kit, que imprime el 28 de septiembre de 2026.

OpenSpec documenta openspec validate en su referencia de CLI. Ese comando comprueba la estructura de cambios y especificaciones de OpenSpec y termina distinto de cero si la validación falla. No comprueba un encabezado ### AC: de SpecScore ni un índice de SpecScore.

El README de Task Master describe partir un PRD en tareas con task-master parse-prd. No describe un linter para ese PRD. Un PRD puede seguir siendo el texto que reescribes en el archivo de funcionalidad de esta página. specscore spec lint es lo que entonces comprueba ese archivo.

GitHub Spec Kit describe un flujo de agente cuyas fases escriben artefactos Markdown. Esa portada de documentación no describe un comando que lintee un README de funcionalidad SpecScore en CI. La comparación de esas herramientas es la comparativa de herramientas.

Una plantilla de especificación que Claude Code puede leer

Los archivos son Markdown, así que un agente que puede leer un repositorio puede leer la plantilla. Claude Code es el agente al que apunta la página CLI Skills. Esa página documenta ai-plugin-specscore, un complemento delgado de Claude Code que envuelve la CLI. El repositorio del complemento es specscore/ai-plugin-specscore. La página dice que el complemento expone specscore spec lint, specscore feature, specscore task y specscore feature change-status como comandos del complemento. Las líneas de instalación de esa página son /plugin marketplace add specscore/ai-marketplace y /plugin install cli-skills@specscore.

La misma página documenta specscore agent setup <agent-name> para claude, copilot, cursor, codex, antigravity.google, pi.dev u opencode, ejecutado dentro de un proyecto gestionado por SpecScore. SpecStudio Skills es el flujo guiado (/ideate, /specify, /plan, /implement) y también es un complemento de Claude Code. La plantilla de esta página es el archivo que esos comandos lintean. El complemento no sustituye el README de la funcionalidad.

Preguntas frecuentes

¿Qué es una plantilla de PRD en Markdown?

Es un documento de requisitos de producto escrito como archivos Markdown con una forma fija. En SpecScore esa forma es un README de funcionalidad: título, estado, resumen, problema, comportamiento con reglas #### REQ:, criterios de aceptación y preguntas abiertas. El archivo de checkout de esta página es uno que specscore spec lint aceptó.

¿Dónde van los identificadores REQ en la plantilla?

Bajo un encabezado de tema dentro de ## Behavior, como #### REQ: {slug}. El id es {feature-path}#req:{slug}. Los criterios de aceptación listan esos ids en **Requirements:**. Una tarea del plan lista el id del criterio en **Verifies:**.

¿En qué se diferencian un criterio de aceptación y un escenario?

Un criterio de aceptación es una condición abstracta. Un escenario es un flujo concreto Given/When/Then en _tests/. La especificación de criterios de aceptación dice que el criterio no debe prescribir los pasos. El archivo de escenario sí lo hace.

¿El linter califica la prosa del PRD?

No. specscore spec lint comprueba la estructura: encabezados, secciones obligatorias, filas del índice y referencias como P-001 y P-002. No decide si el producto es una buena idea. Lintear especificaciones en CI cuenta ese comando con más detalle.

¿Puede Claude Code usar esta plantilla de especificación?

Sí. La plantilla es Markdown en el repositorio. El complemento CLI Skills expone specscore spec lint y los comandos de funcionalidad y de tarea dentro de Claude Code. specscore agent setup claude escribe un archivo de instrucciones para ese agente. El complemento no inventa otra plantilla.

¿Un plan sustituye a la especificación de la funcionalidad?

No. El README de la funcionalidad es la fuente de los requisitos y de los criterios de aceptación. El plan descompone esa funcionalidad en tareas, y cada tarea apunta de vuelta con **Verifies:**. La especificación de plan y la especificación de tarea son los dos documentos de ese corte.

Fuentes

La funcionalidad checkout, el índice de funcionalidades, el README de la especificación y specscore.yaml fueron aceptados por specscore spec lint el 2 de noviembre de 2026 con specscore 0.55.1 y con 0.39.1. Las muestras de plan y de tarea siguen las especificaciones publicadas y no formaron parte de esa ejecución. Las páginas de terceros son las enlazadas abajo; la comparativa de herramientas las registra como leídas el 30 de octubre de 2026, salvo la portada de Spec Kit, que imprime el 28 de septiembre de 2026.