# Plantilla de PRD en Markdown para programar con IA Canonical: https://specscore.md/es/articles/feature-spec-template/ Última actualización: 5 de noviembre de 2026 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](https://specscore.md/feature-specification) 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](https://specscore.md/es/spec-driven-development/) (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](https://specscore.md/), un requisito (REQ) es una regla con nombre dentro de una funcionalidad, un [criterio de aceptación](https://specscore.md/acceptance-criteria-specification) (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](https://specscore.md/plan-specification) es el documento que parte la funcionalidad en tareas, y una [tarea](https://specscore.md/task-specification) es una unidad de trabajo que una persona o un agente puede terminar. La [integración continua](https://specscore.md/es/validators/) (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](https://specscore.md/es/cli/) (CLI, command-line interface), `specscore spec lint`, de la CLI en [specscore/specscore-cli](https://github.com/specscore/specscore-cli). [Easy Approach to Requirements Syntax](https://specscore.md/es/articles/ears-requirements/) (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](https://specscore.md/es/ai/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. ## 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](https://specscore.md/feature-specification) 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](https://specscore.md/plan-specification) llama plan al documento que descompone esa funcionalidad en tareas. Un escenario, en la [especificación de escenario](https://github.com/specscore/specscore/blob/main/spec/features/scenario/README.md), es un archivo concreto Given/When/Then en el directorio `_tests/` de la funcionalidad. La [especificación de criterios de aceptación](https://specscore.md/acceptance-criteria-specification) 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](https://github.com/specscore/specscore/blob/main/.github/workflows/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](https://github.com/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](https://github.com/specscore/specscore/blob/main/spec/features/artifact-frontmatter-convention/README.md) 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) ```markdown --- 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 ```markdown --- 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 ```markdown # Checkout specification ## Open Questions None at this time. ``` ### specscore.yaml de la misma ejecución ```yaml # 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](https://specscore.md/es/articles/lint-specs-in-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](https://github.com/specscore/specscore/blob/main/spec/features/requirement/README.md) 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](https://specscore.md/es/articles/ears-requirements/). ### Criterio de aceptación La [especificación de criterios de aceptación](https://specscore.md/acceptance-criteria-specification) 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](https://specscore.md/es/articles/acceptance-criteria/) es la guía de redacción. La regla `ac-heading-format` ([ac_heading.go](https://github.com/specscore/specscore-cli/blob/v0.55.1/pkg/lint/ac_heading.go) en la etiqueta v0.55.1 de la CLI) comprueba que el encabezado sea `### AC: ` con un id en kebab-case. El [artículo sobre lint](https://specscore.md/es/articles/lint-specs-in-ci/) 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](https://github.com/specscore/specscore/blob/main/spec/features/scenario/README.md) 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](https://specscore.md/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 ```markdown # 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](https://specscore.md/plan-specification) 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](https://github.com/specscore/specscore-cli/blob/v0.55.1/pkg/lint/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](https://specscore.md/task-specification) 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 ```markdown --- 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 ```markdown --- 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](https://github.com/specscore/specscore/blob/main/.github/workflows/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](https://specscore.md/es/articles/lint-specs-in-ci/). La licencia del formato es [CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE) en [specscore/specscore](https://github.com/specscore/specscore). La licencia de la CLI es [Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE) en [specscore/specscore-cli](https://github.com/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](https://specscore.md/es/spec-driven-development/tools/) 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](https://github.com/Fission-AI/OpenSpec) documenta `openspec validate` en su [referencia de CLI](https://openspec.dev/docs/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](https://github.com/eyaltoledano/claude-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](https://github.github.io/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](https://specscore.md/es/spec-driven-development/tools/). ## 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](https://specscore.md/es/ai/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](https://github.com/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 ` para `claude`, `copilot`, `cursor`, `codex`, `antigravity.google`, `pi.dev` u `opencode`, ejecutado dentro de un proyecto gestionado por SpecScore. [SpecStudio Skills](https://specscore.md/es/ai/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](https://specscore.md/acceptance-criteria-specification) 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](https://specscore.md/es/articles/lint-specs-in-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](https://specscore.md/es/ai/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](https://specscore.md/plan-specification) y la [especificación de tarea](https://specscore.md/task-specification) 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. - [Especificación de funcionalidad](https://specscore.md/feature-specification) - [specscore/specscore — especificación de funcionalidad](https://github.com/specscore/specscore/blob/main/spec/features/feature/README.md) - [specscore/specscore — especificación de requisito](https://github.com/specscore/specscore/blob/main/spec/features/requirement/README.md) - [Especificación de criterios de aceptación](https://specscore.md/acceptance-criteria-specification) - [specscore/specscore — especificación de criterios de aceptación](https://github.com/specscore/specscore/blob/main/spec/features/acceptance-criteria/README.md) - [specscore/specscore — especificación de escenario](https://github.com/specscore/specscore/blob/main/spec/features/scenario/README.md) - [Especificación de plan](https://specscore.md/plan-specification) - [specscore/specscore — especificación de plan](https://github.com/specscore/specscore/blob/main/spec/features/plan/README.md) - [Especificación de tarea](https://specscore.md/task-specification) - [specscore/specscore — especificación de tarea](https://github.com/specscore/specscore/blob/main/spec/features/task/README.md) - [specscore/specscore — convención de frontmatter de artefactos](https://github.com/specscore/specscore/blob/main/spec/features/artifact-frontmatter-convention/README.md) - [specscore/specscore](https://github.com/specscore/specscore) - [specscore/specscore — licencia CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE) - [specscore/specscore-cli](https://github.com/specscore/specscore-cli) - [specscore-cli — licencia Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE) - [specscore/specscore — dogfood.yml (CLI v0.39.1)](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) - [specscore-cli v0.55.1 — ac-heading-format](https://github.com/specscore/specscore-cli/blob/v0.55.1/pkg/lint/ac_heading.go) - [specscore-cli v0.55.1 — reglas de plan P-001 y P-002](https://github.com/specscore/specscore-cli/blob/v0.55.1/pkg/lint/plan_rules.go) - [Lintear especificaciones en CI con un linter de especificaciones](https://specscore.md/es/articles/lint-specs-in-ci/) - [Cómo escribir criterios de aceptación que un agente de IA pueda verificar](https://specscore.md/es/articles/acceptance-criteria/) - [Sintaxis de requisitos EARS explicada, con ejemplos](https://specscore.md/es/articles/ears-requirements/) - [CLI Skills — la CLI de SpecScore dentro de Claude Code](https://specscore.md/es/ai/cli-skills/) - [SpecStudio Skills](https://specscore.md/es/ai/specstudio-skills/) - [specscore/ai-plugin-specscore](https://github.com/specscore/ai-plugin-specscore) - [Qué valida SpecScore](https://specscore.md/es/validators/) - [Rehearse](https://specscore.md/rehearse) - [Referencia de la CLI de OpenSpec — openspec validate](https://openspec.dev/docs/cli) - [Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec) - [eyaltoledano/claude-task-master](https://github.com/eyaltoledano/claude-task-master) - [Documentación de GitHub Spec Kit (fecha de página 28 de septiembre de 2026)](https://github.github.io/spec-kit/) - [Herramientas de desarrollo basado en especificaciones](https://specscore.md/es/spec-driven-development/tools/) ## Relacionado - [Desarrollo basado en especificaciones con Claude Code y Cursor](https://specscore.md/es/articles/claude-code-specs/) - [Especificación de funcionalidad](https://specscore.md/feature-specification) - [Especificación de criterios de aceptación](https://specscore.md/acceptance-criteria-specification) - [Especificación de plan](https://specscore.md/plan-specification) - [Especificación de tarea](https://specscore.md/task-specification) - [Cómo escribir criterios de aceptación que un agente de IA pueda verificar](https://specscore.md/es/articles/acceptance-criteria/) - [Sintaxis de requisitos EARS explicada, con ejemplos](https://specscore.md/es/articles/ears-requirements/) - [Lintear especificaciones en CI con un linter de especificaciones](https://specscore.md/es/articles/lint-specs-in-ci/) - [Desarrollo basado en especificaciones](https://specscore.md/es/spec-driven-development/) - [Herramientas de desarrollo basado en especificaciones](https://specscore.md/es/spec-driven-development/tools/) - [CLI Skills para Claude Code](https://specscore.md/es/ai/cli-skills/) - [CLI](https://specscore.md/es/cli/)