Skill oficial · Producto

Revisión de una spec antes de construir

v1.0.1 · Actualizada el 4 de noviembre de 2026

Revisa un PRD o una spec antes de construir: ambigüedades, estados vacío/cargando/error/sin permiso que faltan, métricas, despliegue y un recorrido como usuario nuevo.

Agregar al pod de mi equipo

Funciona en Claude, ChatGPT y agentes de programación. En Team y Business, la skill oficial de tu pod se actualiza sola cuando la mejoramos.

Cuándo usarla

Un PRD o una spec está a punto de pasar a ingeniería para estimarlo
Una funcionalidad salió con sorpresas y la siguiente spec necesita más rigor

Qué le das

El texto de la spec o el PRD
Usuario objetivo (opcional)
Plazo y equipo (opcional)

Qué obtienes

Un veredicto, un recorrido como usuario nuevo, hallazgos bloqueantes y por corregir con citas, una tabla de estados y revisión de métricas y despliegue.

Cómo funciona

Recorre el flujo como un usuario que entra por primera vez Empieza por donde llega el usuario (enlace de un email, elemento del menú, cuenta vacía) y narra cada paso: qué ve, qué tiene que decidir, dónde hace clic. Siempre que la spec no diga qué aparece después, anota un hueco. Siempre que una etiqueta o una pregunta desconcertaría a alguien nuevo, anótalo.
Revisa los estados de cada pantalla En cada pantalla o componente, busca: vacío (primer uso, sin resultados), cargando, error, datos parciales, sin permiso y éxito. NN/g aconseja que un estado vacío muestre el estado del sistema, enseñe cómo empezar y dé un camino directo a la tarea, y que un mensaje de “no hay registros” nunca aparezca mientras los datos siguen cargando. Los mensajes de error deben ser visibles, en lenguaje sencillo, constructivos y conservar lo que el usuario escribió.
Encuentra las palabras ambiguas Marca “rápido”, “fácil”, “sencillo”, “intuitivo”, “debería”, “etc.”, “y/o”, “algunos” y “según haga falta”. Cada una necesita una cifra, una lista o una decisión. Marca cualquier requisito que dos lectores podrían probar de forma distinta.
Revisa las reglas y los límites ¿Quién puede hacerlo? ¿Cuántos? ¿Qué pasa al llegar al límite? ¿Qué pasa con los datos y usuarios existentes cuando salga? Las respuestas que faltan son bloqueantes si cambian el modelo de datos.
Revisa las métricas Tiene que haber una métrica principal vinculada al problema, una referencia, un objetivo y cómo se medirá. Si el evento que hay que contar todavía no existe, es un requisito que le falta a la spec.
Revisa el despliegue y la vuelta atrás ¿Va detrás de un flag? ¿Quién lo ve primero (interno, un porcentaje, un segmento)? ¿Qué métrica dispara la vuelta atrás, y se puede desactivar sin publicar una versión nueva? La guía de Martin Fowler sobre feature toggles distingue los toggles de lanzamiento (release toggles), los despliegues graduales por porcentaje y los interruptores de emergencia (kill switches); un kill switch tiene que poder accionarse rápido, sin una versión nueva.
Ordena y redacta los hallazgos Bloqueante = el equipo no puede construirlo o probarlo, o pone en riesgo datos o confianza. Conviene corregir = provocará retrabajo o confusión. Detalle = redacción. Cada hallazgo cita la spec, dice por qué importa y propone una corrección o una pregunta.

Compártela con tu equipo

Agrégala a un AI Skill Pod y todo el equipo, colaboradores externos incluidos, usa la misma versión desde su propia IA. Lee las mejores formas de compartir skills de IA con un equipo