Skill de Claude Code · gratis
La idea estaba clara hasta que alguien preguntó el scope.
Tienes la nota de voz, el hilo de WhatsApp y tres párrafos que el cliente mandó a medianoche. Todo apunta al mismo producto y nada dice dónde termina. Así se empieza a construir dos semanas antes de saber qué se está construyendo.
El costo real
Lo que no se escribió se negocia en la entrega.
Sin un documento que diga qué NO entra, cada feature que el cliente imaginó pero no pidió aparece el día de la demo. No es mala fe: nadie escribió la frontera, así que las dos partes se quedaron con una versión distinta del mismo acuerdo.
Y del otro lado, el agente que construye sin spec toma cincuenta decisiones chicas que nadie revisó. Cada una es defendible sola. Juntas son un producto que no se parece al que querías, y rehacerlo cuesta más que haberlo especificado.
El PRD no es burocracia. Es el único lugar donde “fuera de scope” queda por escrito antes de que cueste dinero.
El método
Diez fases, una decisión a la vez.
Es entrevista, no plantilla que se rellena. Cada fase cierra antes de que empiece la siguiente, y ninguna pregunta en abierto lo que se puede proponer concreto:
Brain dump
Texto libre: qué quieres construir, para quién y qué problema resuelve.
Propósito
Lo sintetiza en una a tres oraciones y te lo regresa para que confirmes o corrijas.
Features en scope
Propone de cuatro a ocho features core, una línea cada uno. Recortas o agregas.
Fuera de scope
Lo que podría estar y no va en v1, con la razón de cada exclusión escrita.
Stack
Detecta el que ya tienes. Si no hay, propone un default opinionado en vez de preguntar en abierto.
Integraciones
Por cada servicio externo: qué hace en lenguaje llano, qué proveedor y qué credenciales necesitas conseguir.
Modelo de datos
Las cosas que el sistema tiene que recordar y cómo se relacionan. Sin tipos de base de datos.
Scope por feature
Uno por uno, no en lote: qué ve el usuario, qué puede hacer, y qué versión más ambiciosa no entra.
Milestones
Tres opciones de corte —compacta, default o granular— y cada milestone entrega algo visible.
Dev Portal
Deja la nota del tracker en el PRD, pero no configura nada: eso es del onboarding, no del spec.
- _build_plan/prd.md — el PRD con sus milestones y el "done when" de cada uno
- _build_plan/milestones/N-slug/prompt.md — el prompt con el que arranca cada milestone
- CLAUDE.md — las reglas del repo para quien trabaje ahí
- AGENTS.md — la regla de no construir fuera del milestone activo
- llms.txt — qué es el proyecto, en un párrafo, para cualquier modelo
Instalar
Tres comandos y ya está corriendo.
# 1. Agrega el marketplace
claude plugin marketplace add gneuman/gnb-plugins
# 2. Instala el plugin
claude plugin install gnb-idea-to-prd@gnb-labs
# 3. Úsalo
/idea-to-prd # arranca con el brain dump
/idea-to-prd quiero un CRM... # o entra directo con la ideaTambién se dispara solo cuando dices “necesito un PRD”, “quiero construir”, “convertir esta idea en spec” o “nueva funcionalidad”.
El stack que propone por default, el nombre de tu agencia y el tracker que usas viven en un bloque [CUSTOMIZE] al final del skill. Los valores que trae funcionan tal cual: forkear es sobreescribir, no rellenar vacíos. Las diez fases no se tocan.
Por qué este y no otro
Documentación doble: para ti y para el agente.
Escribe para las dos audiencias
El PRD y el README los lee un humano. AGENTS.md y llms.txt los lee el modelo que va a construir. Un solo documento para los dos termina siendo malo para ambos.
Propone en vez de preguntar
Nunca pregunta '¿qué quieres?' cuando puede proponer algo concreto con su razón. Decidir sobre una propuesta es rápido; llenar un formulario en blanco es lo que hace que los PRD nunca se escriban.
Cada milestone entrega algo visible
El corte no es por capa técnica. Al terminar un milestone hay algo que se abre en el navegador y se verifica, con su criterio de 'done when' escrito desde el PRD.
Precio
Gratis. Licencia MIT.
El skill es tuyo sin pagar nada y sin dejar el correo. Si lo que quieres es montar esto adentro de tu operación —tus procesos, tu equipo, tus skills— eso se trabaja en el Club de IA: taller quincenal en vivo, cupo de 10 empresas.
El paso siguiente
Ya tienes el PRD. Ahora hay que romperlo en tickets.
`/prd-to-issues` toma este PRD y lo parte en issues que alguien puede tomar sin preguntarte nada: vertical slices, título que empieza con verbo y definición de listo.
Preguntas
Lo que se pregunta antes de instalarlo.
¿Sirve para un feature dentro de un proyecto que ya existe?
Sí, y lo detecta solo. Si hay codebase, lee tu CLAUDE.md y tu package.json, y en vez del set completo escribe nada más el PRD del feature en _build_plan/features/ más su prompt de milestone, y actualiza el AGENTS.md.
¿Por qué diez fases y no un formulario?
Porque un formulario en blanco te hace inventar respuestas. Cada fase propone algo concreto con su razón y tú confirmas, corriges o rechazas. Es más rápido decidir sobre una propuesta que redactar desde cero, y el resultado sale con menos huecos.
¿El PRD decide qué librerías uso?
No, a propósito. El PRD describe el qué —comportamiento, flujos, scope— y deja el cómo al agente que lo va a construir en plan mode. Un PRD que ya trae nombres de métodos amarra decisiones que se toman mejor con el código enfrente.
¿Me crea el proyecto en Linear o Jira?
No. Deja la nota de qué tracker se va a usar y cómo se organiza, pero no toca el tracker. Configurarlo es parte del onboarding, no del spec. Para romper el PRD en tickets está el skill hermano, prd-to-issues.
¿Y si mi idea es vaga?
Ahí es donde más sirve. Las fases 2 y 3 no te dejan pasar con "queremos que sea como Notion": piden features concretas y te hacen escribir qué NO va en v1. Si el scope no se puede aterrizar, lo vas a descubrir en la entrevista y no a la mitad del build.
Antes de instalar nada más
Te mando cómo se construyen estos skills por dentro.
Cada viernes: una táctica aplicable, la herramienta que la resuelve y qué costó. 3,000+ founders en LATAM. Gratis.