Hay un momento incómodo que todo PM conoce. Terminas de escribir una historia de usuario, la asignas al desarrollador, y a los 30 minutos recibes el mensaje: "¿Esto qué significa exactamente?"
Y entonces empieza el ping-pong de aclaraciones. Pero no es culpa del desarrollador: es culpa de un requerimiento que asume contexto que el otro no tiene.
La buena noticia: la IA puede cerrar esa brecha. No para que escriba el código por ti, sino para que estructures una spec tan completa que el desarrollador empiece a trabajar sin preguntarte nada. Y aunque tu equipo nunca adopte SDD formal y siga en Jira, ese documento base queda: es el ancla que evita 5 reuniones de aclaración.
Vamos.
— "Es como un login normal." → "¿Con email o con Google?" → "Las dos." → "¿Y si el usuario ya existe?" → "Uhm… validamos." → "¿Entonces?" → "Déjame preguntarle al cliente."
2.1. El Problema de Fondo: Sesgo de Conocimiento Compartido
Como PM, tú vives el producto 8 horas al día. Sabes cosas que el equipo técnico no sabe:
- Qué dijo el cliente en la llamada del jueves.
- Qué priorizó el sponsor la semana pasada.
- Qué feature fracasó hace 3 meses.
El problema es que asumes que ellos saben lo mismo. Cuando escribes "Agregar autenticación con Google", en tu cabeza hay 15 decisiones tomadas (qué datos traer, cómo manejar duplicados, qué error mostrar). Pero en el ticket solo escribiste 5 palabras.
Bien usada, la IA funciona como un interrogador estructurado: te obliga a explicitar esas 15 decisiones antes de que el ticket llegue al desarrollador.
2.2. El Prompt de Requerimiento Base
Este es el prompt que usarás como PM para redactar cualquier requerimiento con ayuda de IA. No importa si luego usas SDD, Scrum, o cascada. Este prompt te da un documento base.
PROMPT MAESTRO PARA REDACTAR REQUERIMIENTOS CON IA
Contexto para la IA:
"Eres un analista funcional senior con 10 años de experiencia
traduciendo necesidades de negocio a requerimientos técnicos.
Tu trabajo NO es escribir código. Tu trabajo es hacer preguntas
hasta que el PM haya cubierto todos los vacíos de ambigüedad.
Tu tono es directo, sin rodeos. Si algo no está claro, lo señalas.
No asumes nada. Si el PM no lo dijo, no existe."
Instrucciones para la sesión:
"Voy a describirte una necesidad de producto. Tu trabajo es:
1. Devolver un documento de requerimiento estructurado.
2. Al final, listar las preguntas que aún no he respondido.
3. Señalar los riesgos que identificas en mi descripción inicial.
No escribas código. No sugieras soluciones técnicas.
Solo estructura el requerimiento y encuentra los vacíos."
[DESCRIPCIÓN DE LA NECESIDAD — 3 a 5 líneas máximo]
Cómo usarlo:
- Copia el prompt completo en ChatGPT, Claude o Gemini.
- Al final, agrega tu descripción de la necesidad (3-5 líneas).
- La IA te devolverá un documento estructurado + preguntas pendientes.
- Respondes las preguntas, iteras, y al cerrar todos los vacíos, tienes tu documento base.
2.3. Ejemplo Práctico Paso a Paso
-
El PM escribe la necesidad en 3 líneas
"Necesitamos que los usuarios puedan pagar con tarjeta de crédito en nuestra plataforma de cursos. Actualmente solo tenemos transferencia bancaria y los usuarios nos piden tarjetas. Es para el checkout del curso."
-
La IA devuelve el documento estructurado
## Requerimiento: Pago con Tarjeta de Crédito ### 1. Descripción Funcional El sistema debe permitir a los usuarios finalizar la compra de un curso utilizando tarjeta de crédito como método de pago, además de la transferencia bancaria existente. ### 2. Flujo Principal 1. Usuario agrega curso al carrito. 2. Usuario va al checkout. 3. Usuario selecciona "Tarjeta de Crédito". 4. Sistema muestra formulario de datos de tarjeta. 5. Usuario ingresa datos y confirma. 6. Sistema procesa el pago. 7. Sistema muestra confirmación. 8. Usuario recibe acceso al curso. ### 3. Consideraciones Técnicas - Se requiere integración con gateway de pagos (no especificado). - Los datos de tarjeta no deben almacenarse en el backend (PCI DSS). - Se necesita manejo de errores para tarjetas rechazadas. ### 4. Reglas de Negocio - El pago debe ser en moneda local (no especificada). - Debe aplicarse la misma lógica de cupones que en transferencia. - El acceso al curso se otorga solo después de confirmación del pago. ### 5. Preguntas Pendientes 1. ¿Qué gateway de pagos usaremos? (Stripe, MercadoPago, otro) 2. ¿La moneda es COP, USD, o ambas? 3. ¿Qué pasa si el pago se autoriza pero el curso no se asigna? (rollback) 4. ¿Debemos soportar pagos recurrentes o solo únicos? 5. ¿Hay un monto mínimo o máximo para tarjeta? 6. ¿Qué datos de tarjeta soportamos? (débito, crédito, ambas) 7. ¿El formulario de tarjeta es embebido o redirige a un portal externo? 8. ¿Qué hacemos con los pagos fallidos? (reintento automático o manual) ### 6. Riesgos Identificados - **Riesgo regulatorio:** Si manejamos datos de tarjeta sin certificación PCI, exponemos a la empresa a multas y demandas. - **Riesgo técnico:** Si el gateway no tiene integración en el país, puede bloquear pagos sin previo aviso. - **Riesgo operativo:** Si no hay flujo de reembolso definido, soporte al cliente se verá saturado. -
El PM responde las preguntas pendientes y cierra vacíos
Después de investigar con el equipo y el cliente:
## [Iteración 2] Respuestas a Preguntas Pendientes 1. Gateway: Stripe (ya tienen cuenta, solo activar). 2. Moneda: COP, con conversión automática si el banco emisor es extranjero. 3. Rollback: Si el pago se autoriza pero falla la asignación, sistema debe reversar el cargo automáticamente (tarea del backend). 4. Solo pagos únicos. Recurrentes en fase 2. 5. Monto mínimo: $5,000 COP. Máximo: $5,000,000 COP. 6. Débito y crédito (Visa, Mastercard, Amex). 7. Formulario embebido (Stripe Elements). 8. Pagos fallidos: máximo 3 reintentos con 5 min de espera. Luego, notificar al usuario para que intente con otro método. -
El PM entrega el documento base al equipo técnico
El desarrollador recibe un documento que:
- Le dice qué construir exactamente.
- Le dice qué no está incluido (recurrentes son fase 2).
- Le dice cómo se comporta el sistema en cada caso (éxito, error, límite).
- Responde las preguntas que normalmente tendría que hacer en una reunión.
El desarrollador aún puede tener preguntas técnicas profundas (cómo implementar el rollback exactamente), pero ya no tiene que preguntar qué debería pasar — eso está escrito.
3.1. La Técnica de los 7 Porqués Técnicos
Cuando describas un requerimiento, la IA no debe aceptar tu primera versión. Usa esta secuencia de preguntas para obligarte a pensar más profundo:
- Iteración 1: Describe la necesidad (3-5 líneas).
- Iteración 2: La IA responde con su documento + preguntas. Responde cada pregunta.
Iteración 3 (profundización): Pídele a la IA:
"Ahora que respondí tus preguntas, vuelve a leer el documento completo. Para cada sección, dime: '¿Qué pasaría si esta suposición es incorrecta?' Si identificas una suposición no validada, márcala como RIESGO."
Iteración 4 (casos borde): Pídele a la IA:
"Genérame 10 casos borde que podrían ocurrir en este requerimiento. No me des soluciones. Solo dime qué podría fallar."
Resultado: Después de 4 iteraciones, tienes un documento que cubre no solo el flujo feliz, sino también los casos de error, las suposiciones no validadas y los riesgos operativos.
3.2. La Técnica del Espejo (Contexto del Equipo Técnico)
Antes de entregar el requerimiento, pídele a la IA:
"Ahora imagina que eres un desarrollador backend que recibe este documento. El desarrollador trabaja en 3 proyectos simultáneos, no ha hablado con el cliente, y necesita empezar a codificar mañana.
¿Qué preguntas le quedan aún después de leer este documento? ¿Qué información adicional necesita para sentirse seguro de empezar?"
Esto simula la mente del desarrollador y descubre vacíos que tú, como PM, no ves porque ya sabes las respuestas.
3.3. La Prueba del Silencio
Antes de enviar el requerimiento, haz esta prueba:
"Si yo desaparezco por 2 semanas y el desarrollador solo tiene este documento, ¿puede terminar la implementación sin contactarme?"
Si la respuesta de la IA es "Sí, con este documento es suficiente", tu requerimiento está listo. Si la IA dice "No, falta X, Y, Z", vuelve a iterar.
3.4. Flujo desde la Terminal: Spec Kit en GitHub y Open Spec
Este flujo es para el PM que ya no quiere depender de interfaces gráficas para gestionar sus especificaciones. Trabajar desde la terminal te da velocidad, trazabilidad (git) y la capacidad de integrar IA directamente desde la línea de comandos.
3.4.1. Requisito Mínimo: gh CLI (GitHub CLI)
Instala la CLI de GitHub si no la tienes:
# Windows (PowerShell)
winget install --id GitHub.cli
# macOS
brew install gh
# Linux (Debian/Ubuntu)
sudo apt install gh
Autentica tu cuenta:
gh auth login
3.4.2. Estructura de tu Spec Kit Local
Crea o clona tu repositorio de especificaciones localmente:
gh repo create spec-kit --private --description "Spec-Driven Development Kit"
git clone https://github.com/tu-usuario/spec-kit
cd spec-kit
mkdir -p templates active archive
Tu estructura de trabajo desde la terminal:
spec-kit/
├── templates/
│ └── pr-faq-template.md # Template de PR/FAQ
├── active/
│ └── feature-pagos-tarjeta.md # Spec en desarrollo
└── archive/ # Specs cerrados (historial)
3.4.3. Crear un Requerimiento Usando el Template desde la Terminal
Paso 1 — Copiar el template a active con un nombre descriptivo:
cp templates/pr-faq-template.md active/feature-pagos-tarjeta.md
Paso 2 — Abrir el archivo y llenar la necesidad base (3-5 líneas):
code active/feature-pagos-tarjeta.md
O cualquier editor desde terminal (vim, nano, VS Code).
Escribe tu necesidad al inicio del archivo (debajo de los metadatos):
## Necesidad Base
Los usuarios de la plataforma de cursos necesitan pagar con tarjeta de crédito.
Actualmente solo aceptamos transferencia bancaria. Los usuarios lo piden en los
comentarios de soporte. Esto es para el checkout del curso.
3.4.4. Usar la Terminal para Interrogar el Spec con una IA Local o API
Opción A — Usar una terminal AI nativa (Claude Code, GitHub Copilot CLI, etc.):
Si tienes Claude Code o similar, puedes pasarle directamente el archivo:
# Ejemplo con Claude Code (CLI nativo de Anthropic)
claude -p "Eres un analista funcional senior. Tu trabajo es encontrar vacíos
de ambigüedad en este requerimiento. No escribas código. Solo estructura el
documento y lista las preguntas que el PM debe responder." \
-f active/feature-pagos-tarjeta.md
El resultado se imprime en tu terminal. Toma notas, responde las preguntas en el archivo y repite.
Opción B — Usar curl para enviar el spec directamente a una API de IA:
Este es el flujo más portable porque funciona con cualquier proveedor (OpenAI, Anthropic, Gemini):
# Define tu API key (idealmente desde variable de entorno, no hardcodeada)
export OPENAI_API_KEY="sk-tu-api-key-aqui"
# Lee el contenido del spec y envíalo a la API de OpenAI
curl -s https://api.openai.com/v1/chat/completions \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-d "{
\"model\": \"gpt-4o\",
\"messages\": [
{\"role\": \"system\", \"content\": \"Eres un analista funcional senior con 10 años de experiencia traduciendo necesidades de negocio a requerimientos técnicos. Tu trabajo NO es escribir código. Tu trabajo es hacer preguntas hasta que el PM haya cubierto todos los vacíos de ambigüedad.\"},
{\"role\": \"user\", \"content\": \"$(cat active/feature-pagos-tarjeta.md)\"}
]
}" | jq '.choices[0].message.content'
El comando se lee así:
- curl -s: Hace la petición HTTP sin mostrar la barra de progreso.
- -H "Authorization: Bearer $OPENAI_API_KEY": Autentica contra la API usando tu clave (guardada en variable de entorno, nunca en el código).
- $(cat active/feature-pagos-tarjeta.md): Toma el contenido completo de tu spec y lo inyecta como contexto del usuario.
- | jq '.choices[0].message.content': Extrae solo el texto de la respuesta de la IA, omitiendo el JSON de metadatos.
Opción C — Usar la API de Anthropic (Claude) desde la terminal:
export ANTHROPIC_API_KEY="sk-ant-tu-api-key-aqui"
curl -s https://api.anthropic.com/v1/messages \
-H "Content-Type: application/json" \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-d "{
\"model\": \"claude-sonnet-4-20250514\",
\"max_tokens\": 4000,
\"system\": \"Eres un analista funcional senior con 10 años de experiencia. Tu trabajo NO es escribir código. Tu trabajo es hacer preguntas hasta que el PM haya cubierto todos los vacíos de ambigüedad.\",
\"messages\": [
{\"role\": \"user\", \"content\": \"$(cat active/feature-pagos-tarjeta.md)\"}
]
}" | jq '.content[0].text'
3.4.5. Flujo Iterativo Completo desde la Terminal
Crea un script interrogar-spec.sh (o interrogar-spec.ps1 para PowerShell) que automatice el ciclo:
Script para bash/zsh (macOS/Linux):
#!/bin/bash
# interrogar-spec.sh — Interroga un spec contra una API de IA
# Uso: ./interrogar-spec.sh active/feature-pagos-tarjeta.md
SPEC_FILE=$1
if [ -z "$SPEC_FILE" ]; then
echo "Uso: ./interrogar-spec.sh <ruta-al-spec.md>"
exit 1
fi
echo "📄 Interrogando spec: $SPEC_FILE"
echo "================================"
# Leer el contenido del spec
SPEC_CONTENT=$(cat "$SPEC_FILE")
# Enviar a la API de OpenAI y guardar la respuesta temporal
curl -s https://api.openai.com/v1/chat/completions \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-d "{
\"model\": \"gpt-4o\",
\"messages\": [
{\"role\": \"system\", \"content\": \"Eres un analista funcional senior. Revisa este requerimiento y devuelve: 1) Documento estructurado 2) Preguntas pendientes 3) Riesgos identificados.\"},
{\"role\": \"user\", \"content\": \"$SPEC_CONTENT\"}
]
}" | jq '.choices[0].message.content' > "${SPEC_FILE}.feedback.md"
echo "✅ Feedback guardado en: ${SPEC_FILE}.feedback.md"
echo "Abrelo, responde las preguntas, y ejecuta nuevamente."
Script equivalente para PowerShell (Windows):
# interrogar-spec.ps1
param([string]$SpecFile)
if (-not $SpecFile) {
Write-Host "Uso: .\interrogar-spec.ps1 <ruta-al-spec.md>"
exit 1
}
Write-Host "📄 Interrogando spec: $SpecFile"
$SpecContent = Get-Content $SpecFile -Raw
$ApiKey = $env:OPENAI_API_KEY
$Body = @{
model = "gpt-4o"
messages = @(
@{role = "system"; content = "Eres un analista funcional senior. Revisa este requerimiento y devuelve: 1) Documento estructurado 2) Preguntas pendientes 3) Riesgos identificados."}
@{role = "user"; content = $SpecContent}
)
} | ConvertTo-Json
$Result = Invoke-RestMethod -Uri "https://api.openai.com/v1/chat/completions" `
-Method Post `
-Headers @{"Authorization" = "Bearer $ApiKey"} `
-ContentType "application/json" `
-Body $Body
$Result.choices[0].message.content | Out-File "${SpecFile}.feedback.md"
Write-Host "✅ Feedback guardado en: ${SpecFile}.feedback.md"
3.4.6. Control de Versiones con Git (Trazabilidad Total)
Cada spec en tu Spec Kit tiene historia. Puedes rastrear cómo evolucionó el requerimiento:
# Ver el estado actual de tu spec kit
git status
# Ver qué cambió en el spec respecto a la última versión
git diff active/feature-pagos-tarjeta.md
# Ver el historial completo del spec
git log --oneline active/feature-pagos-tarjeta.md
# Si necesitas volver a una versión anterior del spec
git checkout <commit-hash> -- active/feature-pagos-tarjeta.md
# Publicar tus cambios al repositorio remoto (GitHub)
git add -A
git commit -m "feat(spec): agrega spec de pagos con tarjeta — iteración 2 después de feedback de IA"
gh pr create --title "Spec: Pagos con Tarjeta" --body "Requerimiento base para pagos con tarjeta. Pendiente: definir gateway y moneda." --reviewer @mi-equipo-tecnico
3.4.7. Open Spec: Un Estándar Portable para tus Requerimientos
Open Spec no es una herramienta ni una plataforma. Es una convención de formato para que cualquier especificación tuya pueda ser leída por cualquier herramienta —humano, IA, o CI/CD— sin necesidad de adaptación.
Las reglas de Open Spec son tres:
Regla 1 — Un solo archivo Markdown por feature.
Nada de spreads en Google Sheets, nada de documentación fragmentada en 3 wikis. Un feature = un .md.
Regla 2 — Secciones con prefijos predecibles. Cualquier herramienta (o IA) que abra tu spec sabe dónde encontrar cada cosa:
## Necesidad Base
[El problema en lenguaje de negocio, 3-5 líneas. Sin solución técnica.]
## Criterios de Éxito
[Lista de condiciones medibles. Si se cumplen todas, el feature está listo.]
## Restricciones
[Todo lo que NO se debe hacer. Límites técnicos, regulatorios, de negocio.]
## Preguntas Pendientes
[Lo que aún no sabes. Fecha tope para cada pregunta.]
## Riesgos
[Lo que podría fallar y cómo mitigarlo.]
Regla 3 — El spec se congela (se mergea a main) solo cuando ## Preguntas Pendientes está vacío.
# Antes de congelar:
grep "^- \[ \]" active/feature-pagos-tarjeta.md
# Si devuelve algo, aún hay preguntas sin respuesta. No está listo.
# Para congelar y mover a la historia del producto:
git checkout -b feature/spec-pagos-tarjeta
# ... iteraciones con IA desde terminal ...
# Cuando grep "Preguntas Pendientes" ya no muestra items sin respuesta:
git add active/feature-pagos-tarjeta.md
git commit -m "spec: feature pagos tarjeta — congelado"
git checkout main
git merge feature/spec-pagos-tarjeta
# El spec ahora es parte de la historia oficial del producto.
3.4.8. Resumen del Flujo Terminal para el PM
LUNES — Crear spec desde terminal
cp templates/pr-faq-template.md active/nueva-feature.md
code active/nueva-feature.md # Escribes la necesidad (3-5 líneas)
./interrogar-spec.sh active/nueva-feature.md
# Lees el feedback, respondes preguntas
code active/nueva-feature.md # 2da iteración
./interrogar-spec.sh active/nueva-feature.md
# Repites hasta que la IA diga "no hay más preguntas"
MARTES — Prueba del Silencio desde terminal
claude -p "¿Puede un desarrollador implementar esto sin hablar conmigo?" \
-f active/nueva-feature.md
# Si dice que sí, continúas
MIÉRCOLES — Abres PR del spec para revisión del equipo
git add -A && git commit -m "spec: nueva-feature — listo para review"
gh pr create --title "Spec: Nueva Feature" --body "Ver active/nueva-feature.md"
JUEVES — Mergeas el spec a main (congelado)
gh pr merge --squash
git checkout main && git pull
VIERNES — El equipo técnico ya tiene el spec como contexto inmutable
# Pueden empezar a estimar, profundizar, o code review
# Sin reuniones de aclaración
Beneficio: Todo el ciclo de vida del requerimiento —desde la necesidad borrosa hasta el spec congelado— queda registrado en git, revisable por el equipo, y reusable como contexto para cualquier LLM en el futuro.
La línea entre "usar IA para estructurar requerimientos" y "delegar el pensamiento a la IA" es delgada. Aquí están los límites:
| ✓ Está bien | ✗ No está bien |
|---|---|
| Que la IA te haga preguntas para aclarar tu pensamiento | Que la IA imagine respuestas por ti |
| Que la IA estructure el documento basado en tus respuestas | Que la IA genere un requerimiento desde cero sin tu input |
| Que la IA señale riesgos y vacíos | Que la IA decida cuáles vacíos cerrar y cuáles ignorar |
| Que la IA sugiera secciones que podrías haber olvidado | Que la IA escriba especificaciones técnicas que el equipo no pidió |
| Que la IA traduzca tu lenguaje de negocio a lenguaje técnico | Que la IA tome decisiones de arquitectura o diseño |
Tú eres el dueño del requerimiento. La IA es tu editor, no tu autor. Si no puedes explicar cada línea del documento, no lo entregues.
5.1. Flujo de Trabajo Semanal
Parte A — Bitácora de 3 requerimientos:
Usa el proceso de interrogatorio con IA para redactar 3 requerimientos reales de tu trabajo actual (o simulados si no tienes proyecto activo). Para cada uno, documenta:
- Versión 1: Tu descripción inicial (3-5 líneas).
- Preguntas que la IA te devolvió: Las preguntas pendientes que no habías considerado.
- Versión final: El documento de requerimiento completo después de responder preguntas.
- Preguntas que llegaron del equipo después: Si el equipo técnico preguntó algo que no estaba en el documento, anótalo como mejora para el próximo.
Parte B — Tu plantilla personal de requerimiento:
Basado en lo que aprendiste en las 3 iteraciones, crea tu propia plantilla de requerimiento en Google Docs o Markdown. Debe incluir:
- Secciones que consideras indispensables (basadas en las preguntas que más recibes).
- Instrucciones para ti mismo: "Antes de entregar este documento, verifica que hayas respondido X, Y, Z."
- Checklist de validación: "Este requerimiento está listo cuando..."
Formato de entrega: Un Google Doc (o archivo Markdown) con:
- Las 3 bitácoras de requerimiento.
- Tu plantilla personal.
- Una reflexión de 3 líneas: "¿Qué pregunta recurrente dejaste de recibir después de usar este proceso?"
- Error: pedirle a la IA que escriba el requerimiento desde cero. Corrección: su rol en este flujo es interrogar la ambigüedad del stakeholder, no inventar contexto que no existe.
- Error: aceptar la primera ronda de preguntas como suficiente. Corrección: itera el interrogatorio hasta que no queden huecos críticos: la segunda ronda encuentra lo que la primera asume.
- Error: pegar información sensible del cliente en el prompt. Corrección: anonimiza nombres, cifras y datos identificables antes de enviar nada a un modelo externo.
- Error: no validar las respuestas del interrogatorio con el stakeholder real. Corrección: la IA estructura las preguntas; el humano confirma las respuestas. Sin esa validación, es ficción ordenada.
- Error: dejar el resultado enterrado en un chat. Corrección: exporta el requerimiento a markdown y versiónalo junto al spec kit del módulo 3.
| Criterio | No Aprobado (0) | Aprobado (1) | Sobresaliente (2) |
|---|---|---|---|
| 1. Los requerimientos cierran vacíos de ambigüedad | Las versiones finales son similares a las versiones iniciales; no hubo aprendizaje real en las iteraciones | Los requerimientos finales tienen más detalle que los iniciales, pero aún quedan preguntas importantes sin responder | Cada requerimiento pasó por el proceso de interrogatorio y la versión final cubre al menos el 90% de los casos que el equipo técnico preguntaría |
| 2. La plantilla personal es práctica y reusable | No hay plantilla o es una copia del template del módulo sin adaptación | Hay plantilla con secciones pero le falta el checklist de validación o las instrucciones personalizadas | La plantilla incluye secciones, instrucciones para el PM, checklist de validación, y refleja los patrones de pregunta que el equipo técnico hace en tu contexto específico |
| 3. Hubo una reducción demostrable del ping-pong | No hay evidencia de que el proceso haya cambiado la dinámica con el equipo técnico | Reportas que al menos 1 requerimiento generó menos preguntas de lo normal | Identificas un patrón de pregunta que solías recibir siempre y que dejó de ocurrir después de aplicar el proceso sistemáticamente |
Aprobación: 2 de 3 criterios en "Aprobado" o superior.
Para cerrar este módulo: Entrega tu plantilla personal a un colega PM y pídele que redacte un requerimiento usándola. Si tu colega puede completarla sin pedirte ayuda, tu plantilla funciona.
- La IA no escribe tu requerimiento: te interroga hasta que lo vuelves irrompible.
- Un buen documento base explicita las 15 decisiones que tu cabeza da por hechas.
- La Prueba del Silencio es el filtro final: si un dev puede terminar sin contactarte, el spec está listo.
- Tú eres el autor; la IA es el editor. Si no puedes explicar cada línea, no lo entregues.
Kit: Requerimientos con IA
| Archivo | Descripción |
|---|---|
| ⬇ master-prompt-interrogatorio.md | Master Prompt de interrogatorio estructurado para IA |
| ⬇ interrogar-spec.sh | Shell script para interrogar specs vía API (Linux/macOS) |
| ⬇ interrogar-spec.ps1 | PowerShell script para interrogar specs vía API (Windows) |