linsaber1012-coder/pm-prd-to-demo

PM · PRD → Demo Flujo de Trabajo Integrado

Lleva una «idea de producto» a través del ciclo completo «Alineación → Documentación → Prototipo interactivo», produciendo un PRD listo para desarrollo, una definición de métricas autónoma, y un prototipo compartible que reutiliza la interfaz real de un repositorio base. Este flujo de trabajo es independiente del host (funciona con Claude Code / Codex / Cursor / Gemini); consulta la sección «Adaptación al Host» para más detalles sobre portabilidad.

Cuándo usarlo

• El usuario actúa como Product Manager y necesita generar entregables como PRD, definición de métricas o maquetas interactivas.
• Generalmente se trabaja sobre un repositorio o sistema existente para hacer mejoras, y se necesita reutilizar su estructura real.
• Se desea ver al mismo tiempo un prototipo preliminar, interactivo y compartible para facilitar la revisión.

No es adecuado para: tareas de implementación de código puro, cambios mínimos de una o dos líneas, o trabajos sin componentes de decisión de producto.

Qué obtendrás

1. PRD.md — La única fuente de verdad (qué hacer / para quién / alcance / riesgos / descripción detallada de páginas e interacciones).
2. Definición de Métricas.md — Un documento de especificaciones completamente autocontenido; los desarrolladores solo necesitan este archivo para implementar cada métrica o regla.
3. Prototipo HTML autocontenido y compartible — Izquierda = interfaz objetivo (reutilizando la UI real del repositorio base + tus cambios, con datos mock siempre etiquetados), Derecha = panel completo del PRD.

---

Disciplinas transversales a las tres fases (no negociables)

1. Cero invención, todo basado en evidencia: Las especificaciones deben provenir del código fuente / documentación oficial / confirmación del usuario; si no se encuentra, se dice explícitamente, no se inventa; los datos mock deben estar etiquetados de forma visible.
2. Cero emojis: No se usan emojis ni iconos de estado en toda la documentación ni en el prototipo; los estados se indican siempre con etiquetas de texto (conservar / actualizar / nuevo / no probado / pendiente de verificar, etc.).
3. Ciclo de redacción → revisión adversarial: Cualquier documento entregable se redacta primero, luego se revisa desde la perspectiva de un «PM senior exigente», y se revisa según los problemas encontrados hasta que pase la revisión (el prompt de revisión está en prompts/reviewer-agent.md).
4. Consistencia entre artefactos: PRD ↔ Definición de Métricas ↔ Prototipo deben tener especificaciones coherentes; si se encuentra un elemento huérfano o una contradicción, se corrige inmediatamente.
5. Adaptación al estilo de interacción del usuario: Algunos prefieren diálogo, otros prefieren opciones; si una aproximación es rechazada, se cambia de método sin insistir en el mismo.
6. No avanzar sin decisiones bloqueadas: Antes de redactar documentos, se deben aclarar las decisiones clave; si los objetivos no están claros, se detiene la conversación para discutirlos, no se adivina.
7. Eliminar el tono de IA (humanizar): El cuerpo del documento debe usar un lenguaje natural, directo, como si lo escribiera una persona, evitando activamente los rasgos típicos del lenguaje de IA (abuso de guiones largos, frases como «no solo X, sino también Y», paralelismos vacíos / estructuras triples, muletillas de precaución excesiva, adornos grandilocuentes, obviedades). Se puede cargar el skill humanizer local, o consultar references/writing-style.md (que resume stop-slop / Humanizer-zh / blader-humanizer). Nota: las especificaciones técnicas deben seguir siendo precisas — humanizar no significa sacrificar exactitud ni rellenar con muletillas.

---

Fase 0 · Descubrimiento interactivo y bloqueo de decisiones

Objetivo: Investigar y aclarar la idea real del usuario, sus necesidades y restricciones, y bloquear las decisiones clave — este paso lo completa la IA interactuando con la persona, no tomando decisiones por ella.

1. Explorar activos existentes: Leer la estructura real del repositorio / documentación / sistema antiguo que el usuario haya proporcionado (si el host lo permite, explorar en paralelo; si no, leer uno por uno). Entender qué hace realmente y qué elementos reutilizables tiene.
2. Refinar los requisitos mediante interacción: Usar preguntas y respuestas para ayudar al usuario a convertir ideas vagas en decisiones claras — lo típico que hay que bloquear: qué repositorio base usar, alcance incluido/excluido, qué métricas/funcionalidades se quieren, la arquitectura de visualización/información, y los no-objetivos explícitos. Hacer preguntas clave de una en una, no bombardear de golpe.
3. Generar un registro de decisiones: Escribir las decisiones bloqueadas en un archivo breve de «decisiones/planificación» que servirá como entrada para la Fase 1.

Criterio de salida: Cada decisión clave tiene una respuesta clara, y el usuario la ha validado.

Fase 1 · Generar PRD + Definición de Métricas

Objetivo: Producir dos documentos listos para desarrollo.

1. Consultar la plantilla: Revisar references/prd-checklist.md (lista completa orientada a la práctica en China, con personalización según el tipo de proyecto) para determinar qué secciones incluir y cuáles se pueden omitir.
2. Redactar: Seguir prompts/writer-agent.md para redactar el PRD y la definición de métricas. Puntos clave:
   • El PRD debe cubrir: contexto/objetivos/métrica de éxito/alcance/riesgos/ estructura funcional + arquitectura de información + diagrama de flujo (se puede usar Mermaid) / descripción detallada de la interfaz frontal e interacciones de cada página (a nivel de campo) / glosario / reglas globales / partes interesadas.
   • La definición de métricas debe ser completamente autocontenida: incluir la especificación completa en línea, sin referencias a «ver otro documento»; los desarrolladores deben poder implementarla solo con este archivo.
3. Revisar: Usar el personaje de «PM senior» de prompts/reviewer-agent.md para una revisión adversarial (integridad / ejecutabilidad / coherencia de la especificación con el código fuente / alcance y no-objetivos / riesgos / cero emojis / sin enlaces rotos / coherencia entre documentos).
4. Ciclo de correcciones: Modificar según los ítems obligatorios de la revisión, y volver a revisar hasta que pase.
5. Pasar la lista de verificación: Antes de la entrega, revisar cada punto contra references/pitfalls.md (esta es una lista de verificación acumulada de errores anteriores).

Fase 2 · Crear prototipo compartible

Objetivo: Un prototipo interactivo con la interfaz objetivo a la izquierda y el PRD completo a la derecha; el diseño de la interfaz debe ser fiel a la fuente establecida (referencia / repositorio base / competencia, según el orden de prioridad a continuación). Las reglas estrictas están en references/prototype-guardrails.md.

1. Determinar la fuente de diseño (por orden de prioridad):
   • ① El usuario ha proporcionado un prototipo o diseño de referencia → Usar ese como base, reproduciendo fielmente su apariencia y maquetación.
   • ② Se trabaja sobre un repositorio base existente → Clonar/leer su frontend, extraer los tokens de diseño y la maquetación real (colores / modo claro-oscuro / barra lateral o superior / tarjetas / campos reales de cada vista y columnas de tablas), copiar sin improvisar.
   • ③ Ninguno de los anteriores → La IA construye por su cuenta, eligiendo páginas de productos similares / competidores como referencia para crear el diseño, y explicando en el prototipo a quién se ha tomado como referencia y por qué.
2. Crear HTML autocontenido: Un solo archivo, izquierda = interfaz objetivo (fiel al repositorio base + tus cambios, datos mock siempre etiquetados), derecha = panel completo del PRD (usando un renderizador minimalista de Markdown para incrustar el PRD en línea).
3. Seguro para CSP / autocontenido: Todo el CSS/JS debe estar en línea, sin enlazar a CDN externos, fuentes o iconos; los elementos que no se puedan renderizar en vivo (como ciertas galerías de imágenes) deben etiquetar honestamente la limitación y degradar a una representación legible.
4. Publicar e iterar: Publicar en un enlace compartible; cuando el usuario solicite cambios, modificar tanto el prototipo como el PRD simultáneamente, manteniéndolos sincronizados, y volver a publicar en el mismo enlace.

---

Lista de verificación previa a la entrega (resumen; ver references/pitfalls.md para más detalles)

• Cero emojis (incluyendo etiquetas de nodos en gráficos o bloques de código)
• Sin invenciones: todos los números/especificaciones tienen origen verificable; los datos mock están etiquetados
• Definición de métricas autocontenida, sin referencias externas tipo «ver otro documento»
• Coherencia entre artefactos, sin elementos huérfanos ni contradicciones
• Diseño del prototipo fiel a la fuente establecida (si hay referencia, se usa esa; si hay repositorio base, se copian sus tokens; si no hay, se referencia a la competencia y se explica), no improvisado
• Las puntuaciones compuestas/totales tienen fórmulas explícitas y desglose de componentes
• Los elementos que no se pueden renderizar / no se han probado / son desconocidos se etiquetan honestamente, sin hacerlos pasar por hechos

---

Adaptación al Host (Portabilidad)

El cuerpo de este SKILL.md contiene instrucciones en lenguaje natural independientes del host, que cualquier LLM puede seguir. Las diferencias entre hosts se resuelven fuera del cuerpo:

• Carga/activación: La instalación y forma de invocación en cada host se describe en README.md (Claude Code: colocar en el directorio de skills; Codex: usar su sistema de skills o referencia en AGENTS.md; Cursor/Gemini: sus respectivas rutas).
• Degradación de capacidades: Siempre que se mencione «enviar un subagente a revisar/explorar», si el host actual no soporta subagentes, tú mismo debes realizar esa misma revisión/exploración sin cambiar las disciplinas.
• Independencia de herramientas: El cuerpo solo describe acciones (buscar en internet, leer repositorios, escribir archivos, publicar prototipos), sin vincularse a nombres de herramientas específicos; cada host las mapea a sus propias herramientas.

Recursos adjuntos

• references/prd-checklist.md — Lista de componentes del PRD + personalización según tipo de proyecto
• references/prototype-guardrails.md — Reglas estrictas para el prototipo
• references/pitfalls.md — Lista de verificación de errores comunes
• references/writing-style.md — Reglas para eliminar el tono de IA / humanizar la escritura (resume stop-slop / Humanizer-zh / blader-humanizer + el skill humanizer local)
• prompts/writer-agent.md — Plantilla del prompt para el agente redactor
• prompts/reviewer-agent.md — Persona del PM senior para la revisión + lista de verificación
• templates/prd-skeleton.md / templates/metric-spec-skeleton.md — Plantillas de estructura