Cuando un desarrollador recibe un ticket de Jira que dice "mejorar el login", tiene dos opciones: preguntarte qué significa, o asumir. Ambas son malas. La primera te consume reuniones; la segunda te consume bugs en producción.
El problema no es la herramienta. Jira, Linear, Trello — todas son buenas para rastrear trabajo. Pero ninguna te obliga a pensar antes de escribir.
GitHub Spec Kit viene a resolver eso: un conjunto de templates —archivos Markdown— que te guían desde una idea borrosa hasta un conjunto de tareas listas para codificar. La spec, los ADRs y los RFCs tienen template propio. Y no necesitas que tu empresa lo adopte ni que tu equipo instale nada: basta con entender los templates y adaptarlos a tu flujo actual.
Vamos a destripar cada template. Al final tendrás tu propia batería lista para usar mañana, con cualquier equipo, en cualquier herramienta.
Vamos.
El Spec Kit organiza el trabajo en 4 fases, cada una con su template:
- ¿Qué construimos?
- spec-template.md
- ¿Cómo lo construimos?
- plan-template.md
- ¿Quién hace qué?
- tasks-template.md
- Código
- (equipo técnico)
Tu responsabilidad es llegar hasta el final de la Fase 1 (Spec) y asegurarte de que pasa el Quality Gate. Las fases 2-4 las ejecuta el equipo técnico, pero debes entender los templates para leerlos, revisarlos y dar feedback.
3.1. spec-template.md — El Corazón del Spec Kit
Propósito: Transformar una idea borrosa en una especificación estructurada que cualquier persona (o IA) pueda entender sin preguntar.
Secciones que contiene:
| Sección | ¿Qué Significa para el PM? | Ejemplo (Feature: Login con Google) |
|---|---|---|
| Feature Branch | La rama de git donde se desarrollará. No tienes que saber git, pero debes saber que tu spec vive en una rama. | 42-google-login |
| User Scenarios | Priorizados por importancia (P1, P2, P3). Define qué debe funcionar primero si el tiempo se acaba. | P1: Usuario inicia sesión con Google. P2: Usuario existente vincula cuenta de Google. P3: Usuario desvincula cuenta. |
| Edge Cases | Lo que puede fallar. Tu trabajo como PM es anticipar estos escenarios. | Cancelación del popup de Google, expiración del token, usuario sin conexión a internet. |
| Functional Requirements | Lista numerada de lo que el sistema debe hacer. Cada requisito debe ser comprobable. | FR-001: El sistema debe permitir iniciar sesión usando el proveedor OAuth de Google. FR-002: El sistema debe crear un usuario nuevo si el email de Google no existe en la base de datos. |
| Key Entities | Los datos que el feature toca o crea. Útil para pensar en consistencia de datos. | Usuario, Cuenta Vinculada, Token de Acceso. |
| Success Criteria | Cómo sabremos si el feature está completo. Debe ser medible. | El 95% de los intentos de login con Google se completan en menos de 3 segundos. Tasa de error <1%. |
El template prohíbe explícitamente incluir detalles de implementación (lenguajes, frameworks, APIs específicas). Tu spec describe qué debe pasar, no cómo. Si escribes "usar Node.js" en el spec, lo estás haciendo mal.
Cuándo usarlo como PM:
- Antes de crear cualquier epic en Jira. Si no tienes un spec, no tienes un epic.
- Cuando un stakeholder pide una feature: "Dame una semana y te devuelvo el spec para que revisemos si es lo que necesitas."
- Antes de una reunión de estimación. Si el spec no está listo, la reunión es una pérdida de tiempo.
3.2. plan-template.md — Traduciendo la Especificación a un Plan Técnico
Propósito: Convertir el spec en un plan de implementación con diseño técnico, estructura de datos y contratos.
Secciones clave para el PM:
| Sección | ¿Qué Significa para el PM? |
|---|---|
| Technical Context | El equipo técnico documenta sus suposiciones y decisiones. Tú debes validar que estas decisiones no contradicen el spec. |
| Constitution Check | Verifica que el plan cumple con las reglas del proyecto (stack aprobado, patrones establecidos). Tú debes saber si hay reglas de negocio que el plan está ignorando. |
| Research (Phase 0) | El equipo investiga opciones antes de decidir. Tú debes preguntar: "¿Cuánto tiempo vamos a invertir en investigar?" Si es más de un día, probablemente no vale la pena. |
| Data Model (Phase 1) | Cómo se estructuran los datos. Tú debes validar: ¿Esto captura toda la información que necesita el negocio? |
| Contracts | Acuerdos entre sistemas (APIs, eventos). Tú debes entender: ¿Esto rompe algo que ya existe? |
Cuándo revisarlo como PM:
- Cuando el equipo técnico termina el plan. No para aprobar cada detalle técnico, sino para asegurarte de que entrega lo que el spec promete.
- Si el plan dice que algo no es posible dentro del alcance actual, es tu responsabilidad negociar el alcance, no forzar al equipo a que lo haga igual.
3.3. tasks-template.md — El Backlog Listo para Ejecutar
Propósito: Descomponer el plan en tareas atómicas que el equipo técnico puede estimar, asignar y ejecutar.
Lo que el PM debe saber de este template:
- Cada tarea es lo suficientemente pequeña para completarse en 1-2 días.
- Las tareas tienen dependencias explícitas (Task 3 no puede empezar hasta que Task 1 y 2 terminen).
- El template incluye validación: ¿Hay tareas sin criterio de aceptación? ¿Hay tareas que dependen de algo que no existe?
Para el PM: Este template genera automáticamente lo que tú normalmente escribirías a mano en Jira. La diferencia es que aquí las tareas nacen del spec y del plan, no de tu intuición. Si una tarea no está en el template, probablemente no debería estar en tu backlog.
3.4. checklist-template.md — El Quality Gate que te Salva de Reuniones
Propósito: Validar que el spec está completo y no tiene ambigüedades antes de pasar a la fase de plan.
Ítems del checklist que te interesan como PM — antes de pasar el spec a Ingeniería:
- 📝 Content Quality
- Sin detalles de implementación (lenguajes, frameworks, APIs)
- Enfocado en valor de usuario y necesidades de negocio
- Escrito para stakeholders no técnicos
- Todas las secciones obligatorias completas
- ✅ Requirement Completeness
- No hay marcadores [NEEDS CLARIFICATION] sin resolver
- Los requisitos son comprobables y no ambiguos
- Los criterios de éxito son medibles
- Los casos borde están identificados
- El alcance está claramente delimitado
- Las dependencias y suposiciones están identificadas
- 🚀 Feature Readiness
- Todos los requisitos funcionales tienen criterios de aceptación claros
- Los escenarios de usuario cubren los flujos principales
- La feature cumple con los resultados medibles de Criterios de Éxito
Antes de enviar un spec al equipo, pásalo por este checklist. Si hay ítems sin marcar, no lo envíes: vuelve a trabajarlo. Esto reemplaza la reunión de "vamos a aclarar los requisitos" — si el spec pasa el checklist, no necesitas la reunión.
3.5. constitution-template.md — Las Reglas del Juego
Propósito: Documentar las reglas, restricciones y patrones que el equipo debe seguir. Es la "constitución" del proyecto.
Lo que debe tener para que el PM lo use:
- Stack aprobado: Qué lenguajes, frameworks y servicios están permitidos.
- Reglas de arquitectura: Patrones que no se pueden romper.
- Estándares de calidad: Cobertura de tests, rendimiento mínimo, accesibilidad.
- Reglas de seguridad: Qué no se puede hacer con datos de usuarios.
Para el PM: La constitución no la escribes tú, pero debes conocerla. Si el equipo técnico dice "no podemos hacer X porque la constitución lo prohíbe", respétalo. Si la constitución no existe, tu primera tarea como PM es asegurarte de que el equipo la cree.
Spec Kit tiene un ecosistema de extensiones mantenidas por la comunidad. Como PM, estas son las que más te interesan:
4.1. Product Forge — El Hermano Mayor del Spec Kit
Product Forge (de la comunidad) agrega fases de discovery y validación antes y después del ciclo SDD. Su estructura de archivos por feature te da un nivel de trazabilidad que Jira nunca podría:
features/mi-feature/
├── problem-discovery/ ← La fase de Discovery (Módulo 4)
│ ├── problem-statement.md ← El problema que resolvemos
│ └── interview-script.md ← Guía de entrevistas con usuarios
├── research/ ← Investigación
│ ├── competitors.md ← Qué hacen otros
│ ├── ux-patterns.md ← Patrones de diseño relevantes
│ └── metrics-roi.md ← El impacto esperado en métricas
├── product-spec/ ← Especificación completa
│ ├── product-spec.md ← PRD al estilo Amazon
│ ├── user-journey.md ← Mapa de viaje del usuario
│ ├── wireframes.md ← Estructura visual
│ └── metrics.md ← Cómo medimos el éxito
├── spec.md ← Spec Kit spec (generado)
├── plan.md ← Plan de implementación
├── tasks.md ← Tareas del backlog
└── testing/ ← Tests
├── test-plan.md ← Plan de pruebas
└── test-cases.md ← Casos de prueba
Por qué esto es oro para un PM: Todo el contexto de una decisión está en un solo lugar. Si alguien pregunta "¿por qué construimos esto?", abres problem-discovery/problem-statement.md y research/metrics-roi.md. No necesitas buscar en 3 herramientas distintas.
4.2. Presets que Cambian el Juego
Los Presets son colecciones de templates que adaptan Spec Kit a dominios específicos:
| Preset | Para Qué Sirve | Por Qué le Importa al PM |
|---|---|---|
| Architecture Governance | Agrega seguridad, modelado de amenazas y ADRs a los templates | Si trabajas en HealthTech, Fintech o cualquier industria regulada, esto te da trazabilidad para auditorías |
| Security Governance | Agrega OWASP, NIST SSDF y estándares de seguridad | Útil cuando el equipo de seguridad te pide "evidencia de que seguimos el proceso" |
| iSAQB Architecture Governance | Basado en el estándar iSAQB (arquitectura de software) | Para productos que necesitan documentación de arquitectura formal |
| Model Driven Engineering | Templates para ingeniería basada en modelos | Para productos donde los modelos de datos son el core del negocio |
4.3. Cómo Instalar y Probar una Extensión como PM (sin miedo a la terminal)
# Ver qué extensiones están disponibles
specify extension search product-forge
# Instalar Product Forge
specify extension add product-forge
# Configurar (copiar template de configuración)
cp .specify/extensions/product-forge/config.template.yml .specify/extensions/product-forge/config.yml
# Ahora tienes comandos nuevos como:
# /speckit.product-forge.research → Investigación
# /speckit.product-forge.product-spec → Spec de producto
# /speckit.product-forge.code-review → Revisión de código multi-agente
Lo que esto significa para ti como PM: No necesitas usar todos los comandos. Pero entender que existen y qué producen te permite pedírselos al equipo técnico cuando necesites trazabilidad o documentación.
No necesitas que tu equipo adopte Spec Kit completo para beneficiarte. Puedes tomar los templates y adaptarlos a tu herramienta actual.
5.1. Template Mínimo para Cualquier Feature (Si Hoy Usas Jira)
Toma la esencia del spec-template.md y crea un documento Google Docs o Markdown que siempre acompañe a tus epics de Jira:
## 1. Problema (3 líneas máximo)
[¿Qué problema resolvemos y para quién? Sin solución todavía.]
## 2. Escenarios de Usuario (Priorizados)
P1: [El escenario más importante — si solo esto funciona, el feature vale la pena]
P2: [Siguiente prioridad]
P3: [Deseable, no crítico]
## 3. Casos Borde
- [Caso borde 1]
- [Caso borde 2]
## 4. Requisitos Funcionales
FR-001: [El sistema debe...]
FR-002: [El sistema debe...]
## 5. Criterios de Éxito (Medibles)
- [Métrica 1: valor esperado]
- [Métrica 2: valor esperado]
## 6. Lo que NO está incluido
- [Fuera de alcance para esta versión]
Si no puedes llenar la sección "Lo que NO está incluido", el alcance de tu feature no está claro.
5.2. Tu Checklist Personal Antes de Entregar un Spec
Adapta el checklist-template.md a tu realidad. Cada vez que termines un spec, pásalo por esto:
- 📋 Requisitos
- Cada FR tiene un criterio de aceptación claro
- Los casos borde están escritos
- No hay "depende" o "lo vemos después" en ningún lado
- 🎯 Criterios de Éxito
- Son medibles (números, porcentajes, tiempos)
- No mencionan tecnología (no "la API responde en 200ms", sino "el usuario ve el resultado en menos de 2s")
- Cualquier persona del equipo puede leerlos y saber si se cumplieron
- 🧭 Alcance
- Hay una sección explícita de "Lo que NO está incluido"
- Puedo defender por qué esos ítems no están en esta versión
Si algún ítem está sin marcar, el spec no está listo.
Construye tu batería personal de templates basada en GitHub Spec Kit:
Archivo 1 — Template de Spec Personalizado:
- Toma el spec-template.md y simplifícalo para tu contexto.
- Agrega una sección que tu equipo siempre pregunta y que el template original no cubre.
- Elimina secciones que no aplican a tu industria (si no haces software puro, ajusta el lenguaje).
Archivo 2 — Template de Checklist Personal:
- Crea tu checklist de calidad para specs, basado en el checklist-template.md de Spec Kit.
- Debe reflejar los errores más comunes que cometes cuando escribes requerimientos.
Archivo 3 — Mapeo de Templates a tu Herramienta Actual:
- Crea una tabla que muestre cómo cada template de Spec Kit se traduce a tu herramienta actual.
- Ejemplo:
| Spec Kit Template | Cómo lo Uso Hoy | Qué Voy a Cambiar |
|---|---|---|
| spec-template.md | Ticket de Jira con descripción libre | Voy a crear un documento Google Docs por feature usando el template simplificado |
| checklist-template.md | No existe | Voy a agregarlo como checklist dentro de los tickets de Jira |
| constitution-template.md | No existe | Voy a proponer una reunión de 1 hora para crearlo con el equipo |
Formato de entrega: 3 archivos Markdown (o Google Docs) + breve explicación de cómo planeas integrarlos en tu flujo semanal.
- Error: copiar los templates sin adaptar campos y opciones a tu equipo. Corrección: ajusta labels, dropdowns y assignees antes del primer uso; un template genérico se ignora rápido.
- Error: YAML con indentación rota que GitHub rechaza en silencio. Corrección: valida el archivo en un linter YAML antes de commitear: GitHub simplemente no muestra el form roto.
- Error: guardar los Issue Forms en la carpeta equivocada.
Corrección: deben vivir exactamente en
.github/ISSUE_TEMPLATE/; en otra ruta no existen para GitHub. - Error: hacer todos los campos obligatorios. Corrección: cada campo obligatorio extra aumenta el abandono: exige solo lo crítico para triaje.
- Error: no configurar
config.ymlconblank_issues_enabled: false. Corrección: si el issue en blanco sigue disponible, la gente esquiva tus templates y vuelve el caos.
| Criterio | No Aprobado (0) | Aprobado (1) | Sobresaliente (2) |
|---|---|---|---|
| 1. El template de spec personalizado elimina ambigüedad | El template es una copia sin adaptación o tiene menos estructura que un ticket de Jira común | El template cubre las secciones básicas pero falta una sección crítica que tu equipo siempre pregunta (ej. dependencias, impacto en otras áreas) | El template está adaptado al contexto real del equipo, incluye una sección que resuelve el 90% de las preguntas recurrentes del equipo técnico, y el PM puede demostrar que reduce el ping-pong |
| 2. El checklist personal refleja los errores reales del PM | Checklist genérico sin conexión con errores pasados | Checklist cubre calidad general pero no incluye patrones de error específicos que el PM comete sistemáticamente | Checklist personalizado basado en errores reales de los últimos 3 specs, con instrucciones concretas de cómo evitar cada error |
| 3. Hay un plan real de adopción en el flujo actual | No hay plan o es "usaré los templates" sin fechas ni métricas | Hay un plan pero es vago ("empezaré a usarlos") sin cambios concretos en la herramienta actual | Hay un plan con fechas, herramientas específicas, y al menos un cambio concreto en cómo se crean los tickets hoy (ej. "a partir del lunes, ningún epic entra a Jira sin un spec en Google Docs que pase el checklist") |
Aprobación: 2 de 3 criterios en "Aprobado" o superior.
Para cerrar este módulo: Toma tu template de spec personalizado y tu checklist, y escribe un spec para la feature más pequeña de tu backlog actual. Si el spec te tomó más de 30 minutos, tu template tiene secciones de más. Si te tomó menos de 10, probablemente está incompleto. Ajusta hasta que el tiempo de escritura sea de 15-20 minutos para una feature pequeña.
- Spec Kit es un ciclo de 4 fases: Spec → Plan → Tasks → Implement. Tú eres dueño de la primera.
- El spec describe qué, nunca cómo: sin lenguajes, frameworks ni APIs.
- El Quality Gate (checklist) reemplaza la reunión de "aclaremos los requisitos".
- No necesitas que tu equipo adopte Spec Kit: los templates son portables a Jira, Linear o Google Docs.
Kit: Spec Kit Templates (mismo directorio que M03)
| Archivo | Descripción |
|---|---|
| ⬇ spec-template.md | Template de spec personalizado |
| ⬇ checklist-template.md | Checklist de validación personalizable |
| ⬇ constitution-template.md | Constitución del equipo + reglas de inmutabilidad |