Pack de plantillas de desarrollo de software: 15 documentos gratuitos para cada fase del proyecto

Yury Pukhov CEO & Mobile Engineering Lead, YuSMP Group

Una plantilla de desarrollo de software es el seguro más barato que puede contratar un proyecto. Sin ella, cada proyecto nuevo reinventa sus documentos desde una página en blanco: los requisitos se recogen cada vez de una forma distinta, desaparecen los criterios de aceptación, surgen disputas de alcance porque nadie dejó por escrito lo que quedaba excluido y las versiones salen con unas notas que no son más que un volcado de mensajes de commit.

Un buen pack de plantillas lo resuelve dando a cada tarea recurrente — planificar, contratar, especificar, diseñar, desarrollar, probar y lanzar — una estructura acordada con un responsable claro. Es el mismo pack que usamos cuando prestamos servicios de ingeniería de producto para equipos de software en crecimiento: documentos breves que viven junto al código y cambian con él, no archivos en una unidad compartida olvidada.

Esta guía le ofrece quince plantillas gratuitas de desarrollo de software organizadas por fase del ciclo de vida del desarrollo de software, una tabla resumen con el responsable de cada una y cuándo prescindir de ella, esqueletos de campos listos para copiar, el mejor formato para cada documento, un método de siete pasos para adaptar las plantillas a su equipo, los errores habituales que vemos en proyectos de clientes y unas preguntas frecuentes.

¿Qué es una plantilla de desarrollo de software?

Una plantilla de desarrollo de software es un esqueleto de documento reutilizable para una tarea recurrente de un proyecto de software — por ejemplo, un plan de proyecto, una especificación de requisitos, un documento de diseño, un plan de pruebas o unas notas de versión. Fija las secciones, explica qué va en cada campo y nombra a la persona responsable del documento, de modo que todos los proyectos recogen la misma información en el mismo lugar.

Una plantilla no es documentación por la documentación. Su valor está en las decisiones que obliga a tomar: qué entra y qué queda fuera del alcance, qué requisitos son obligatorios, qué riesgos se aceptan, cómo se probará un cambio y quién aprueba una versión. Una plantilla que los equipos de desarrollo de software reutilizan de verdad tiene tres propiedades:

• Secciones fijas. Los mismos encabezados en el mismo orden, para que los lectores sepan dónde encontrar el alcance, los riesgos o los criterios de aceptación en cualquier proyecto.
• Indicaciones dentro de cada campo. Una línea de orientación bajo cada encabezado («enumere lo que queda explícitamente fuera del alcance») que se borra en cuanto se rellena el campo.
• Un responsable con nombre. Un rol encargado de mantener el documento al día; una plantilla sin responsable queda obsoleta después del primer sprint.

¿Por qué usar plantillas de desarrollo de software?

Los equipos usan plantillas de desarrollo de software porque hacen visible la información que falta antes de que se convierta en un defecto, una disputa o un retraso. Un campo vacío con la etiqueta «fuera del alcance» o «plan de reversión» es mucho más difícil de ignorar que una pregunta que a nadie se le ocurrió hacer.

• Menos requisitos olvidados. Las secciones fijas para requisitos no funcionales, restricciones y criterios de aceptación evitan que los equipos documenten solo el flujo principal.
• Incorporación más rápida. Los nuevos ingenieros, testers y proveedores encuentran la misma estructura en todos los proyectos y son productivos antes.
• Estimaciones y propuestas comparables. Cuando todos los proveedores responden a la misma RFP y todas las estimaciones usan el mismo desglose, las comparaciones son justas.
• Trazabilidad. Los identificadores que van del requisito a la historia de usuario, al caso de prueba y a la nota de versión muestran exactamente qué se desarrolló, se probó y se entregó.
• Auditorías y cumplimiento más sencillos. Los proyectos regulados pueden mostrar un rastro documental coherente sin un sprint de documentación de última hora.
• Mejor contexto para los asistentes de IA. Una plantilla bien estructurada da a los asistentes de programación y redacción el contexto que necesitan para redactar contenido útil en lugar de texto genérico.

¿Qué plantillas necesita en cada fase?

Cada fase de un proyecto de software necesita un número reducido de plantillas: la planificación y la contratación necesitan un plan, una SOW, una RFP y una estimación; los requisitos, un PRD, una SRS e historias de usuario; el diseño, un documento de diseño y ADR; el desarrollo, un plan de sprint y una plantilla de PR; las pruebas, un plan de pruebas, un informe de errores y una aceptación UAT; el lanzamiento, unas notas de versión. La tabla asigna las quince a su fase, su responsable y su caso de uso.

Para un equipo de cinco personas o menos, el conjunto mínimo viable es un plan de desarrollo de software ligero, un PRD, historias de usuario con criterios de aceptación, una plantilla de pull request y notas de versión. Estas cinco cubren por qué existe el producto, qué hay que desarrollar, cómo se revisan los cambios y qué se entregó realmente; todo lo demás se añade cuando el riesgo, la regulación o el tamaño del equipo lo justifican.

15 plantillas gratuitas de desarrollo de software, por fase

Las quince plantillas gratuitas de desarrollo de software que siguen están agrupadas por fase del ciclo de vida, y cada una incluye una definición, cuándo usarla, un esqueleto de campos listo para copiar y un consejo práctico. Cuando tenemos un artículo dedicado con un ejemplo completo, el esqueleto se mantiene breve y enlaza a él.

Plantillas de planificación y contrato

Las plantillas de planificación y contrato definen por qué existe el proyecto, qué se entregará, quién lo hará, por cuánto y bajo qué supuestos. Son los documentos que más a menudo se omiten en los proyectos pequeños y de los que más uno se arrepiente cuando se disputa el alcance.

1. Plan de desarrollo de software

Una plantilla de plan de desarrollo de software es un único documento que describe los objetivos, el alcance, el equipo, el calendario, los riesgos y las normas de comunicación del proyecto. Úsela siempre que intervenga más de un equipo, la fecha límite sea fija o un patrocinador ajeno al equipo deba aprobar el presupuesto.

• Objetivos y métricas de éxito (acta de constitución)
• Dentro del alcance / fuera del alcance
• Equipo, roles y responsables de las decisiones
• Hitos y calendario
• Registro de riesgos: riesgo, probabilidad, impacto, responsable, mitigación
• Dependencias y supuestos
• Frecuencia de comunicación y de informes

Consejo: mantenga el registro de riesgos dentro del plan en lugar de en un archivo aparte y revíselo en cada hito. En nuestra guía de plantilla de plan de proyecto de desarrollo de software encontrará una plantilla completa y un ejemplo desarrollado.

2. Declaración de trabajo (SOW)

Una plantilla de declaración de trabajo define exactamente qué entregará un proveedor, cómo funciona la aceptación y cómo se gestionan los cambios. Úsela en cualquier colaboración en la que un equipo externo escriba código para usted, tanto si el contrato es a precio cerrado como si es de tiempo y materiales.

• Antecedentes y objetivos
• Entregables con criterios de aceptación
• Elementos fuera del alcance
• Calendario e hitos
• Roles y responsabilidades de ambas partes
• Procedimiento de solicitud de cambios
• Calendario de pagos vinculado a los hitos

Consejo: la lista de elementos fuera del alcance evita más disputas que cualquier otra sección. El aspecto jurídico del acuerdo se trata en nuestra guía sobre el contrato de desarrollo de software.

3. Solicitud de propuesta (RFP)

Una plantilla de solicitud de propuesta es el documento que envía a varios proveedores para que sus propuestas respondan a las mismas preguntas con la misma estructura. Úsela cuando compare dos o más partners de desarrollo.

• Antecedentes de la empresa y del producto
• Objetivos de negocio y métricas de éxito
• Alcance funcional y recorridos de usuario clave
• Restricciones técnicas e integraciones
• Rango de presupuesto y calendario
• Formato de propuesta exigido y criterios de evaluación

Consejo: publique los criterios de evaluación y sus pesos en la propia RFP; así los proveedores optimizan para lo que usted realmente valora. Consulte nuestra guía sobre la RFP para desarrollo de software para obtener una plantilla completa.

4. Hoja de estimación y presupuesto

Una plantilla de hoja de estimación y presupuesto convierte el alcance en esfuerzo y coste con una estructura que todos pueden auditar. Úsela para la aprobación del presupuesto, para comparar presupuestos de proveedores y para cualquier oferta a precio cerrado.

• Estructura de desglose del trabajo (épicas y funcionalidades)
• Estimación de tres puntos por elemento: optimista, más probable, pesimista
• Roles y tarifas combinadas
• Esfuerzo ajeno al desarrollo: QA, DevOps, gestión de proyecto, diseño
• Reserva para contingencias y la razón de su tamaño
• Supuestos de los que depende la estimación

Consejo: aquí el formato adecuado es una hoja de cálculo, porque las fórmulas mantienen los totales correctos cuando cambian los elementos. Nuestra guía de estimación de proyectos de software explica las técnicas que hay detrás de cada columna.

Plantillas de requisitos

Las plantillas de requisitos describen lo que debe hacer el producto y cómo sabrá usted que lo hace. La mayoría de los equipos necesita un PRD e historias de usuario; los proyectos regulados o regidos por contrato añaden una SRS formal.

5. Documento de requisitos de producto (PRD)

Una plantilla de PRD describe un producto o una funcionalidad desde el punto de vista del usuario y del negocio: el problema, quién lo tiene, cómo es el éxito y qué entra en el alcance. Úsela para cada producto nuevo y cada funcionalidad lo bastante grande como para necesitar más de un sprint.

• Planteamiento del problema y usuarios objetivo
• Objetivos y métricas de éxito
• Recorridos de usuario o casos de uso
• Alcance funcional (must / should / could)
• Lo que no es objetivo
• Preguntas abiertas y dependencias
• Criterios de lanzamiento

Consejo: escriba lo que no es objetivo antes que los objetivos; obliga a tener pronto las conversaciones difíciles. La estructura completa está en nuestra guía sobre el documento de requisitos de producto.

6. Especificación de requisitos de software (SRS)

Una plantilla de especificación de requisitos de software enumera requisitos numerados y verificables del sistema, tanto funcionales como no funcionales. Úsela en trabajos regulados, críticos para la seguridad o regidos por contrato, en los que cada requisito debe verificarse y trazarse. La referencia internacional es ISO/IEC/IEEE 29148:2018, que define una familia de documentos de requisitos (especificaciones de requisitos de negocio, de las partes interesadas, del sistema y del software) y enumera nueve características de un requisito individual bien formulado — necesario, apropiado, inequívoco, completo, singular, viable, verificable, correcto y conforme —, más cinco para el conjunto de requisitos en su totalidad.

• Propósito, alcance y público destinatario
• Definiciones y abreviaturas
• Requisitos funcionales, cada uno con un identificador único
• Requisitos no funcionales: rendimiento, seguridad, disponibilidad, accesibilidad
• Interfaces externas: usuarios, hardware, software, comunicaciones
• Restricciones y supuestos
• Método de verificación por requisito (prueba, inspección, análisis, demostración)

Consejo: asigne a cada línea de requisito un identificador como FR-012 y reutilícelo en los casos de prueba y en las notas de versión. Un software de gestión de requisitos específico resulta útil cuando la lista supera unos cientos de elementos.

7. Historia de usuario y criterios de aceptación

Una plantilla de historia de usuario recoge una pequeña porción de valor para el usuario junto con las condiciones que demuestran que funciona. Úsela para cada elemento de un backlog ágil; las buenas historias siguen la lista de comprobación INVEST — independiente, negociable, valiosa, estimable, pequeña y verificable.

Story:  As a [type of user], I want [goal] so that [benefit].
ID:     US-___   Links: PRD section / FR-___
Acceptance criteria (Given / When / Then):
  Given [context]
  When  [action]
  Then  [observable result]
Notes:  edge cases, analytics events, design link

Consejo: si no puede escribir al menos una línea Given/When/Then, la historia no está lista para un sprint.

Plantillas de diseño

Las plantillas de diseño registran cómo se construirá el sistema y por qué se eligieron determinadas opciones. Son los documentos que los nuevos ingenieros leen primero y los que más tiempo ahorran cuando una decisión se cuestiona un año después.

8. Documento de diseño de software (SDD)

Una plantilla de documento de diseño de software explica cómo funcionará un nuevo servicio, módulo o integración antes de escribir la mayor parte del código. Úsela para nuevos servicios, modelos de datos, integraciones externas y todo lo que tenga riesgo de seguridad o de rendimiento. IEEE 1016, la norma para descripciones de diseño de software, es una lista útil de los puntos de vista que conviene cubrir.

• Contexto, objetivos y lo que no es objetivo
• Visión general y diagrama de la arquitectura
• Modelo de datos y almacenamiento
• API y contratos
• Alternativas consideradas y por qué se descartaron
• Consideraciones de seguridad, privacidad y cumplimiento
• Plan de despliegue, monitorización y reversión

Consejo: limite el tiempo dedicado al documento (unas pocas páginas suelen bastar) y revíselo con al menos un ingeniero de otro equipo.

9. Registro de decisiones de arquitectura (ADR)

Una plantilla de registro de decisiones de arquitectura recoge en un archivo breve una decisión técnica importante, su contexto y sus consecuencias. Úsela para cualquier decisión que sería cara de revertir: una base de datos, un framework, un patrón de integración, un modelo de alojamiento. El formato procede del artículo de Michael Nygard de 2011 Documenting Architecture Decisions.

# ADR-007: [short title of the decision]
Status:       Proposed | Accepted | Superseded by ADR-___
Context:      What forces and constraints led to this decision?
Decision:     What we will do, stated in full sentences.
Consequences: What becomes easier, what becomes harder, what we accept.

Consejo: guarde una decisión por archivo en docs/adr/ dentro del repositorio y no edite nunca un ADR aceptado — sustitúyalo por uno nuevo.

Plantillas de desarrollo

Las plantillas de desarrollo mantienen coherente la entrega diaria: a qué se compromete el equipo en un sprint y qué debe explicar cada cambio de código antes de fusionarse.

10. Plan de sprint y product backlog

Una plantilla de plan de sprint registra el objetivo del sprint, la capacidad del equipo y los elementos del backlog a los que se compromete el equipo. Úsela para cualquier entrega iterativa en sprints de duración fija; en un flujo Kanban puro, conserve el formato del backlog y elimine los campos del sprint.

• Objetivo del sprint (una frase)
• Fechas y capacidad del equipo (días-persona, vacaciones)
• Elementos del backlog comprometidos, con estimaciones
• Elementos opcionales (stretch)
• Dependencias y riesgos de este sprint
• Definición de terminado (Definition of Done)

Consejo: escriba la definición de terminado una sola vez a nivel de equipo y enlace a ella; no la vuelva a escribir en cada sprint. Encontrará más sobre las ceremonias que la rodean en nuestra guía de Scrum.

11. Plantilla de pull request

Una plantilla de pull request es un archivo Markdown que rellena de antemano la descripción de cada pull request, para que los revisores tengan siempre el contexto que necesitan. Úsela en todo repositorio con revisión de código. En GitHub se encuentra en .github/pull_request_template.md, como se describe en la documentación de GitHub.

## What and why
## Linked ticket
## How was this tested?
## Screenshots (UI changes)
## Risk and rollback plan
## Checklist
- [ ] Tests added or updated
- [ ] Docs / changelog updated
- [ ] No secrets or personal data in the diff

Consejo: manténgala por debajo de diez líneas; las plantillas de PR largas se borran en lugar de rellenarse. En nuestro artículo explicativo sobre la pull request encontrará el contexto del flujo de revisión.

Plantillas de pruebas

Las plantillas de pruebas definen cómo se comprueba la calidad, cómo se informa de los defectos y cómo acepta formalmente el cliente el resultado. ISO/IEC/IEEE 29119-3:2021 es la norma de referencia para la documentación de pruebas: define documentos como el plan de pruebas, los informes de estado y de finalización de pruebas, las especificaciones de diseño, casos y procedimientos de prueba y los requisitos de datos de prueba, y puede utilizarse con cualquier modelo de ciclo de vida.

12. Plan de pruebas y caso de prueba

Una plantilla de plan de pruebas describe qué se probará, cómo, dónde y quién lo hará; una plantilla de caso de prueba describe una comprobación concreta con su resultado esperado. Úselas en cualquier versión en la que estén en juego usuarios reales, dinero o datos.

Campos del plan de pruebas:

• Alcance y funcionalidades que no se prueban
• Enfoque y niveles de prueba (unitarias, de integración, de extremo a extremo, de rendimiento, de seguridad)
• Entornos y datos de prueba
• Criterios de entrada y de salida
• Calendario y roles
• Riesgos y contingencias

Campos del caso de prueba: identificador, requisito vinculado, condiciones previas, pasos, resultado esperado, resultado real, estado.

Consejo: mantenga los casos de prueba en una hoja de cálculo o en una herramienta de gestión de pruebas y vincule cada uno a un identificador de requisito. Nuestra guía de aseguramiento de la calidad en el desarrollo de software trata el proceso de QA en su conjunto.

13. Informe de errores

Una plantilla de informe de errores hace que cada defecto se pueda reproducir a la primera lectura. Úsela en cuanto alguien ajeno al equipo principal — testers, clientes, soporte — informe de incidencias.

• Título breve y concreto
• Entorno y versión (dispositivo, navegador, build)
• Pasos para reproducirlo
• Resultado esperado frente a resultado real
• Gravedad y prioridad
• Pruebas: capturas de pantalla, logs, vídeo

Consejo: en GitHub, conviértala en un formulario de issue en .github/ISSUE_TEMPLATE/ para que no se puedan omitir los campos obligatorios.

14. Aceptación UAT

Una plantilla de aceptación UAT deja constancia de que el cliente ha probado los escenarios acordados y acepta la versión, con los defectos conocidos aceptados de forma explícita. Úsela para la aceptación del cliente, los pagos por hitos y las decisiones de puesta en producción.

• Identificador de la versión o del hito
• Escenarios de prueba ejecutados, con superado / fallido
• Defectos abiertos aceptados para el lanzamiento, con su gravedad
• Condiciones de aceptación
• Nombre, rol y fecha de quien aprueba

Consejo: acuerde los escenarios UAT cuando se firme la SOW, no la semana antes de la puesta en producción. Más detalles en nuestra guía de pruebas de aceptación de usuario.

Plantillas de lanzamiento

Las plantillas de lanzamiento cuentan a desarrolladores y usuarios qué ha cambiado. Un changelog se escribe para desarrolladores e integradores; las notas de versión se escriben para los usuarios y explican el cambio en términos de beneficio.

15. Notas de versión y changelog

Una plantilla de notas de versión enumera lo nuevo, lo mejorado y lo corregido en una versión con un lenguaje que los usuarios entienden; un changelog enumera cada cambio relevante para los desarrolladores. La convención Keep a Changelog 1.1.0, de uso muy extendido, agrupa los cambios en Added, Changed, Deprecated, Removed, Fixed y Security, y combina bien con Semantic Versioning 2.0.0, en la que las versiones se numeran MAJOR.MINOR.PATCH.

## [2.4.0] - 2026-10-25
### Added
### Changed
### Deprecated
### Removed
### Fixed
### Security

Consejo: escriba las notas de versión a partir del changelog, no de los mensajes de commit, y empiece por el cambio que los usuarios notarán primero.

Word, Google Docs, Excel o Markdown: ¿qué formato funciona mejor?

El mejor formato depende de la frecuencia con la que cambia el documento y de quién lo edita: los documentos que cambian con el código van en Markdown dentro del repositorio, los contratos y las aceptaciones van en Word o Google Docs, y todo lo que tenga cifras va en una hoja de cálculo.

Las plantillas gratuitas de desarrollo de software se reúnen con más facilidad a partir de tres fuentes: los esqueletos de esta guía, las plantillas de pull request y de issues que GitHub admite en cada repositorio y normas públicas como ISO/IEC/IEEE 29148 y 29119-3 utilizadas como listas de comprobación. Evite copiar al pie de la letra los packs de plantillas comerciales; sus campos están ajustados a la herramienta del proveedor, no a su proceso.

¿Cómo adaptar una plantilla a su equipo?

Adapte una plantilla empezando con poco, eliminando cada campo que nadie usa y conectando los documentos mediante identificadores compartidos. Una plantilla que refleja cómo trabaja realmente su equipo se rellena; una genérica se ignora. Estos siete pasos sirven para equipos de cualquier tamaño:

1. Empiece con cinco documentos. Plan ligero, PRD, historias de usuario, plantilla de PR y notas de versión; añada otros solo cuando aparezca un problema real.
2. Elimine los campos que no se usan. Si un campo ha quedado vacío durante dos sprints, quítelo o fusiónelo con otro.
3. Nombre un responsable para cada plantilla. Un rol la mantiene al día y aprueba los cambios en su estructura.
4. Mantenga las plantillas en el control de versiones. Guárdelas en el repositorio o en un espacio versionado, para que cada cambio tenga autor, fecha y motivo.
5. Vincúlelo todo con identificadores. Requisito → historia de usuario → caso de prueba → nota de versión, con los mismos identificadores de principio a fin.
6. Revise el pack cada trimestre. Use las retrospectivas para añadir campos que habrían evitado un defecto o una disputa reales.
7. Automatice las comprobaciones. Use listas de comprobación en las PR, campos obligatorios en los formularios de issues y un paso de CI que falle cuando no se actualice el changelog.

Cada tipo de colaboración necesita una profundidad distinta: un contrato a precio cerrado necesita una SOW detallada y una aceptación UAT, un MVP de tiempo y materiales puede funcionar con un PRD, un backlog y notas de versión, y un producto regulado necesita la SRS y documentación de pruebas formal desde el principio.

¿Puede la IA rellenar las plantillas de desarrollo de software?

Sí, los asistentes de IA pueden rellenar las plantillas de desarrollo de software como primer borrador, pero las decisiones las siguen tomando y aprobando las personas. La plantilla aporta la estructura, el asistente redacta el contenido y un responsable comprueba cada requisito, riesgo y criterio de aceptación.

La adopción ya es casi universal. El informe DORA 2025 State of AI-assisted Software Development de Google concluyó que el 90 % de los profesionales del software usa IA en el trabajo, un 14 % más que el año anterior, con una mediana de dos horas al día. Más del 80 % afirmó que la IA mejoró su productividad y el 59 % señaló un efecto positivo en la calidad del código — sin embargo, solo el 24 % confiaba en los resultados de la IA «mucho» o «bastante», mientras que el 30 % confiaba en ellos «poco» o «nada». La investigación de DORA también señala que conectar las herramientas de IA con la documentación interna es una forma de mejorar la calidad de lo que producen (dora.dev).

Esa brecha de confianza es justo donde ayudan las plantillas. Un flujo de trabajo práctico:

• Dé al asistente la plantilla, la sección pertinente del PRD y las notas de las reuniones.
• Pídale que rellene todos los campos y que enumere la información que falta en lugar de inventarla.
• Haga que el responsable del documento revise cada requisito, estimación y riesgo línea por línea.
• No pegue nunca requisitos confidenciales de clientes en una herramienta que su empresa no haya aprobado para esos datos.

¿Cuáles son los errores más habituales con las plantillas y cómo se corrigen?

El error más habitual es tratar la plantilla como el objetivo en lugar de las decisiones que debe recoger. Las soluciones casi siempre consisten en hacer las plantillas más pequeñas, con responsable y conectadas entre sí.

¿Qué plantillas importan más en los proyectos ágiles y en los proyectos en cascada?

Los proyectos en cascada y los regulados dependen sobre todo de plantillas formales y elaboradas al inicio — SRS, SDD, un plan de pruebas alineado con ISO/IEC/IEEE 29119-3 y una aceptación UAT formal —, mientras que los proyectos ágiles se apoyan en plantillas ligeras y actualizadas de forma continua: un product backlog, historias de usuario, una definición de terminado, ADR, una plantilla de PR y un changelog.

• En cascada o regulado: plan de desarrollo de software, SOW, SRS con métodos de verificación, SDD, plan de pruebas e informe de finalización de pruebas, aceptación UAT.
• Ágil: PRD ligero, backlog e historias de usuario, definición de terminado, ADR, plantilla de PR, informe de errores, changelog y notas de versión.
• Híbrido: SOW, SRS y UAT formales a nivel de contrato, con plantillas ágiles para la entrega diaria dentro de cada hito.

Para una comparación más profunda de los dos modelos de entrega en sí, lea nuestra guía sobre ágil frente a cascada.

Preguntas frecuentes

Publicado el 25 de octubre de 2026. Fuentes: Google, DORA 2025 State of AI-assisted Software Development (en inglés); DORA, Balancing AI tensions (en inglés); ISO/IEC/IEEE 29148:2018, Requirements engineering (en inglés); ISO/IEC/IEEE 29119-3, Test documentation (en inglés); IEEE 1016-2009, Software Design Descriptions (en inglés); M. Nygard, Documenting Architecture Decisions, 2011 (en inglés); Keep a Changelog 1.1.0 (en inglés); Semantic Versioning 2.0.0 (en inglés); GitHub Docs, Creating a pull request template (en inglés). Los esqueletos de las plantillas son ilustrativos y deben adaptarse a su proceso.